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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu May 15 2003 - 22:00:43 EST