Bug 6955 - PRIO_INHERIT mutexes do not use FUTEX_PRIVATE_FLAG
Summary: PRIO_INHERIT mutexes do not use FUTEX_PRIVATE_FLAG
Status: RESOLVED FIXED
Alias: None
Product: glibc
Classification: Unclassified
Component: nptl (show other bugs)
Version: 2.8
: P2 normal
Target Milestone: ---
Assignee: Ulrich Drepper
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-10-09 19:18 UTC by Ben Jackson
Modified: 2014-07-02 06:54 UTC (History)
1 user (show)

See Also:
Host: x86_64-redhat-linux-gnu
Target: x86_64-linux
Build: x86_64-redhat-linux-gnu
Last reconfirmed:
fweimer: security-


Attachments
Add FUTEX_PRIVATE_FLAG support for PRIO_INHERIT mutexes (957 bytes, patch)
2008-10-09 19:20 UTC, Ben Jackson
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Ben Jackson 2008-10-09 19:18:56 UTC
Code in the PRIO_INHERIT cases of pthread_mutex_lock/unlock/trylock/timedlock
call futex() directly with FUTEX_(UN)LOCK_PI regardless of the pshared-ness of
the mutex.  Other cases call futex() indirectly through __lll_*() interfaces
that set FUTEX_PRIVATE_FLAG as appropriate.  This was observed to cause
contention on mm->mmap_sema leading to large, random latencies on otherwise
quick lock operations (apparently due to brk() holding mmap_sema).

I patched nptl to set the private flag in the PRIO_INHERIT cases (based on the
pshared-ness of the mutex) and tested that against the regression tests and my
application.  The tests pass, the application works, and the performance problem
is solved.  However, I am working from a fairly superficial understanding of
this code, and I have not received replies from my inquiries to experts in this
code.

I will try to attach my patch after I submit.  I think it illustrates the
desired behavior, but it may not be exactly what glibc maintainers would want.
Comment 1 Ben Jackson 2008-10-09 19:20:42 UTC
Created attachment 2988 [details]
Add FUTEX_PRIVATE_FLAG support for PRIO_INHERIT mutexes

as described in the original bug report
Comment 2 Ulrich Drepper 2008-11-01 19:56:31 UTC
I've checked in a slightly different, more efficient patch.