Date: Wed, 27 Oct 2010 10:45:14 +0000 From: David Xu <davidxu@freebsd.org> To: Daniel Eischen <deischen@freebsd.org> Cc: freebsd-threads@freebsd.org Subject: Re: threads/151767: pthread_mutex_init returns success with bad attributes; SUBSEQUENT operations fail Message-ID: <4CC802BA.9030707@freebsd.org> In-Reply-To: <Pine.GSO.4.64.1010262209080.19313@sea.ntplx.net> References: <201010270200.o9R20JaV043974@freefall.freebsd.org> <Pine.GSO.4.64.1010262209080.19313@sea.ntplx.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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 >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4CC802BA.9030707>