Bug 19089 - Robust mutexes do not take ROBUST_LIST_LIMIT into account
Summary: Robust mutexes do not take ROBUST_LIST_LIMIT into account
Status: NEW
Alias: None
Product: glibc
Classification: Unclassified
Component: nptl (show other bugs)
Version: 2.23
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
Depends on:
Reported: 2015-10-08 11:21 UTC by Florian Weimer
Modified: 2017-10-18 15:52 UTC (History)
1 user (show)

See Also:
Last reconfirmed:
fweimer: security-

tst-robust10.c (1.32 KB, text/plain)
2015-10-08 11:21 UTC, Florian Weimer

Note You need to log in before you can comment on or make changes to this bug.
Description Florian Weimer 2015-10-08 11:21:56 UTC
Created attachment 8686 [details]

The kernel limits the length of the robust mutex list to 2048 entries.  This constant does not seem to be exported to user space.

glibc needs to keep track of the number of locked robust mutexes and fail locking additional ones once ROBUST_LIST_LIMIT is exceeded.  Otherwise, some locks will not be marked as EOWNERDEAD if the process exits while holding more than ROBUST_LIST_LIMIT locks.

The attached test case fails if invoked with an argument of 2049.

I found this while looking for a cause for bug 19004, but I think this is a completely different bug.
Comment 1 Florian Weimer 2015-10-08 12:16:10 UTC
It is not possible to check for the limit at pthread_mutex_init time because the mutex could have been created in another process, and the limit is really a lock count limit.

I requested a clarification of the POSIX specification: http://austingroupbugs.net/view.php?id=988
Comment 2 Florian Weimer 2016-07-14 15:41:00 UTC
It seems that POSIX already permits returning an EAGAIN error in this case.