* Carlos O'Donell: > On 11/5/19 6:56 AM, Thomas Gleixner wrote: >> On Tue, 5 Nov 2019, Florian Weimer wrote: >>> * Thomas Gleixner: >>>> On Tue, 5 Nov 2019, Florian Weimer wrote: >>>>> * Shawn Landden: >>>>>> If this new ABI is used, then bit 1 of the *next pointer of the >>>>>> user-space robust_list indicates that the futex_offset2 value should >>>>>> be used in place of the existing futex_offset. >>>>> >>>>> The futex interface currently has some races which can only be fixed by >>>>> API changes. I'm concerned that we sacrifice the last bit for some >>>>> rather obscure feature. What if we need that bit for fixing the >>>>> correctness issues? >>>> >>>> That current approach is going nowhere and if we change the ABI ever then >>>> this needs to happen with all *libc folks involved and agreeing. >>>> >>>> Out of curiosity, what's the race issue vs. robust list which you are >>>> trying to solve? >>> >>> Sadly I'm not trying to solve them. Here's one of the issues: >>> >>> <https://sourceware.org/bugzilla/show_bug.cgi?id=14485> >> >> That one seems more a life time problem, i.e. the mutex is destroyed, >> memory freed and map address reused while another thread was not yet out of >> the mutex_unlock() call. Nasty. > > It is difficult to fix. > > The other issue is this: > > "Robust mutexes do not take ROBUST_LIST_LIMIT into account" > https://sourceware.org/bugzilla/show_bug.cgi?id=19089 That's just a missing check in our implementation and something that few applications will encounter, if any. There is this one here: <https://sourceware.org/bugzilla/show_bug.cgi?id=19004> It contains a kernel patch. I thought that there were more issues in the current implementation, but I can't a record of them. 8-( Thanks, Florian
