Messages in this thread | | | Date | Sat, 10 Apr 1999 03:04:30 +1000 | From | Martijn van Oosterhout <> | Subject | Re: [RFC] Trapping/tracing kernel stack overflows |
| |
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/
| |