Re: [RFC] Trapping/tracing kernel stack overflows
Martijn van Oosterhout (kleptog@cupid.suninternet.com)
Sat, 10 Apr 1999 03:04:30 +1000
Alexander Viro wrote:
>
> 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.
You are right. It could be done by attaching the locks
as a linked list to the current process, which would allow
you to track them all down, but it would penelize all the
times where nothing goes wrong. After all, it won't be
needed when the kernel is bug free :)
Where do I find out more on the IKD?
Martijn van Oosterhout
Australa
-
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/