Jan Hudec wrote: > > On Mon, Sep 09, 2002 at 03:09:51PM -0600, Joseph A. Knapka wrote: > > Seth Arnold wrote: > > > > > > On Sat, Sep 07, 2002 at 04:03:41AM -0600, Joseph A. Knapka wrote: > > > > I also suspect (though I do not know this for certain) > > > > that the kernel is smart enough to detect kernel-stack > > > > overflow and kill the offending process. > > > > > > Nope. Things just start acting funny. :) If you are lucky you get a > > > panic soon. > > > > > > > trivial: just keep a read-only PTE at the end of the > > > > kernel stack, and if anything tries to write > > > > there, take a page fault, notice that it's adjacent > > > > to the task stack, and kill the process. > > > > > > Iterate over $n processes .. where $n is disturbingly large on some > > > systems. > > > > Hmm... Why not just look at the stack for "current"? > > Well, yes. The first thing it destroys is the task struct. So scheduler > is likely to run into some broken pointer there sooner or later and > OOPS. Is that always true? There may be architectures where the stack grows away from the task_struct. Anyway, using a guard page would be (nearly) 100% reliable and would have very low runtime overhead, whereas a magic number would have to be checked manually and you might miss the problem entirely. Still, for debugging purposes it probably would suffice. (And of course it seems this is a non-problem anyway, but I'm just curious about how one would go about doing it.) Cheers, -- Joe "I'd rather chew my leg off than maintain Java code, which sucks, 'cause I have a lot of Java code to maintain and the leg surgery is starting to get expensive." - Me -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
