On 10/24/2012 11:08 AM, Thomas Gleixner wrote: > On Wed, 24 Oct 2012, Siddhesh Poyarekar wrote: > >>> Now there is a different solution to that problem. Do not look at the >>> user space value at all and enforce a lookup of possibly available >>> pi_state. If pi_state can be found, then the new incoming locker T3 >>> blocks on that pi_state and legitimately races with T2 to acquire the >>> rt_mutex and the pi_state and therefor the proper ownership of the >>> user space futex. >> >> That works. Thanks for the detailed explanation too. > > Thanks for the reproducer and finding the trouble spot in the first > place!
Absolutely, that was great. Siddhesh, any objection to this test being incorporated into futextest? http://git.kernel.org/?p=linux/kernel/git/dvhart/futextest.git;a=summary > I'll queue that if Darren has no objections and mark it for stable as > well. I would mostly like to understand the stale waiters case you mentioned. Otherwise, it seems sound - but changing what appears to be a workaround for an undocumented cornercase in code this complex does make me a bit nervous. I'd feel better if we could get Siddhesh's and this stale waiters covered in futextest. -- Darren Hart Intel Open Source Technology Center Yocto Project - Technical Lead - Linux Kernel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
