From: William L. I. I. <wl...@ho...> - 2003-05-13 06:28:50
|
At some point in the past, someone wrote: >> I'm not 100% convinced it DTRT on modern kernels. I vaguely wonder if >> the following would be more appropriate. Shame the typedef isn't there >> yet; the _struct suffix is an eyesore. On Mon, May 12, 2003 at 08:41:22PM -0700, Martin J. Bligh wrote: > So are the new bits of the patch related to the KSTK_E* bit? > They don't seem to be ... however, this bit looks really good: Random incidental cleanups. At some point in the past, someone wrote: >> -#define KSTK_EIP(tsk) (((unsigned long *)(4096+(unsigned long)(tsk)->thread_info))[1019]) >> -#define KSTK_ESP(tsk) (((unsigned long *)(4096+(unsigned long)(tsk)->thread_info))[1022]) >> +#define KSTK_EIP(task) ((task)->thread.eip) >> +#define KSTK_ESP(task) ((task)->thread.esp) On Mon, May 12, 2003 at 08:41:22PM -0700, Martin J. Bligh wrote: > Can I assume it's tested, or does it need someone to do that? Not tested. AFAICT it's returning random garbage somewhere near the beginning of the kernel stack now but haven't checked the answers generated at runtime to see if they look valid. This at least vaguely resembles the intent of the code, but it might actually want (task)->thread.esp0 or other such nonsense and so on now that I think about it some more. At the very least it looks plausible and doesn't perform accesses that aren't actually on the stack as they're supposed to be when you shrink the stack to 4KB. AIUI those kinds of out-of-bounds accesses to potentially freed memory are oopsable with some debugging patches like manfred's that unmaps freed pages. -- wli |