Messages in this thread | | | From | Andi Kleen <> | Subject | Re: [patch 0/5] lightweight robust futexes: -V1 | Date | Wed, 15 Feb 2006 21:25:52 +0100 |
| |
On Wednesday 15 February 2006 21:13, Antonio Vargas wrote: > On 2/15/06, Andi Kleen <ak@suse.de> wrote: > > On Wednesday 15 February 2006 20:49, Christopher Friesen wrote: > > > > > The goal is for the kernel to unlock the mutex, but the next task to > > > aquire it gets some special notification that the status is unknown. At > > > that point the task can either validate/clean up the data and reset the > > > mutex to clean (if it can) or it can give up the mutex and pass it on to > > > some other task that does know how to validate/clean up. > > > > The "send signal when any mapper dies" proposal would do that. The other process > > could catch the signal and do something with it. > > > > That would be a new signal such as SIG_FUTEXDIED, would it?
It could be probably made configurable, possibly even in fancy ways (RT signal with payload giving the process that got killed and other information)
However that would require a new field to the VMA which is a bit memory critical. Hardcoding the signal is probably better, then only a new bit would be needed. Or maybe two bits, one for SIGKILL and another for fixed real time signal with payload.
With that the list walking Ingo put into the kernel could be all done in user space.
Ok it might be tricky to ensure the VMA bit is set on all mappings that need it. I had some vague memories that SUS had a mmap flag for that, but I can't find it right now.
An alternative would be to make it not a VMA attribute, but a mm_struct attribute - then it would need to be enabled only once, not on each mmap.
-Andi
- 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/
| |