threads/151767: pthread_mutex_init returns success with bad attributes; SUBSEQUENT operations fail

[David Xu]

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:
> EINVAL]
>     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
aborted.

> 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.
> 
> -- 
> DE
>