lkml.org 
[lkml]   [1999]   [Apr]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC] Trapping/tracing kernel stack overflows


On Fri, 9 Apr 1999, Martijn van Oosterhout wrote:
[snip]
> Any process that is that deep probably has a
> lot of locks. Just dying would probably kill
> everything anyway. AFAIK the linux kernel has no
> machanism for undoing locks held by a faulting
> process. If it did you'd be able to use the
> floppy drive after the fat module had segfaulted
> on a bad floppy.

Yes, it's the common problem with all kernel-mode faults. The
problem being: you don't know *who* had set the lock/spinlock/semaphore,
increased the usage counter, etc. and which resources were held by dying
process. Any attempt to store this information (i.e. do equivalent of
destructors) will have a nasty side-effect - we'll slow down a lot of
stuff on nearly every time-critical path ;-/ So the current behaviour is
least of two evils - after all, it doesn't punish correct code.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:51    [W:0.049 / U:0.112 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site