threads/151767: pthread_mutex_init returns success with bad
attributes; SUBSEQUENT operations fail
davidxu at freebsd.org
Wed Oct 27 02:45:15 UTC 2010
Daniel Eischen wrote:
> On Wed, 27 Oct 2010, David Xu wrote:
>> Long time ago, I had reported the priority issue in ULE scheduler,
>> the scheduler incorrectly changed a time-sharing thread to real-time
>> priority when it returns to userland if it thinks it is interactive.
>> so you can not use prority protected mutex with ULE scheduler.
>> see sched_ule.c:
> I think pthread_mutex_lock() on a priority inherit/ceiling
> mutex by a thread without sufficient permission (time-sharing)
> should either return EPERM(*), or it should ignore the priority
> (with an appropriate statement in the man page) when attempting
> the mutex operation.
There is no priority bug in libthr with the pp mutex or pi mutex,
it is the kernel scheduler has incorrectly set a time-sharing
thread priority to real-time, that's culprit.
the time-sharing is simply a rr scheduling, or a correctly
implemented rr scheduling. in umtx, all time-sharing thread
has same priority, just one priority, the priority is lower than
any other real-time priorities. the time-sharing thread should
be abole to use pp or pi mutex without any problem.
this is what POSIX said:
> The mutex was created with the protocol attribute having the
> value PTHREAD_PRIO_PROTECT and the calling thread's priority is
> higher than the mutex's current priority ceiling.
The culprit is that ULE sets a time-sharing thread's priority
to 138 or 139 in the bug-reporter's code, which causes
umtx code found that the thread violates the standard and
> I think it is okay for any thread (with or without sufficient)
> permission to initialize the mutex, though. The thread that
> initializes the mutex may not be the same thread(s) that use
> the mutex, or it may even raise its permissions at a later
> point in time (before operating on the mutex).
> (*) POSIX says pthread_mutex_lock() should return EINVAL
> for a PTHREAD_PRIO_PROTECT mutex where the thread has a
> priority higher than the priority ceiling. Given that,
> it seems appropriate to return EINVAL for a priority
> inheritence mutex.
More information about the freebsd-threads