From owner-freebsd-threads@FreeBSD.ORG Wed Oct 27 02:45:15 2010 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0DDF5106566C; Wed, 27 Oct 2010 02:45:15 +0000 (UTC) (envelope-from davidxu@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id EFFC68FC19; Wed, 27 Oct 2010 02:45:14 +0000 (UTC) Received: from xyf.my.dom (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o9R2jDNI095000; Wed, 27 Oct 2010 02:45:14 GMT (envelope-from davidxu@freebsd.org) Message-ID: <4CC802BA.9030707@freebsd.org> Date: Wed, 27 Oct 2010 10:45:14 +0000 From: David Xu User-Agent: Thunderbird 2.0.0.24 (X11/20100630) MIME-Version: 1.0 To: Daniel Eischen References: <201010270200.o9R20JaV043974@freefall.freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-threads@freebsd.org Subject: Re: threads/151767: pthread_mutex_init returns success with bad attributes; SUBSEQUENT operations fail X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 02:45:15 -0000 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 >