From owner-freebsd-threads@FreeBSD.ORG Mon Oct 25 11:07:11 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 85D2910656CC for ; Mon, 25 Oct 2010 11:07:11 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 69CA68FC1E for ; Mon, 25 Oct 2010 11:07:11 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o9PB7Bqg088916 for ; Mon, 25 Oct 2010 11:07:11 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o9PB7Abl088914 for freebsd-threads@FreeBSD.org; Mon, 25 Oct 2010 11:07:10 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 25 Oct 2010 11:07:10 GMT Message-Id: <201010251107.o9PB7Abl088914@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-threads@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-threads@FreeBSD.org 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: Mon, 25 Oct 2010 11:07:11 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o threa/150959 threads [libc] Stub pthread_once in libc should call _libc_onc o threa/149366 threads pthread_cleanup_pop never runs the configured routine o threa/148515 threads Memory / syslog strangeness in FreeBSD 8.x ( possible o threa/141721 threads rtprio(1): (id|rt)prio priority resets when new thread o threa/136345 threads Recursive read rwlocks in thread A cause deadlock with o threa/135673 threads databases/mysql50-server - MySQL query lock-ups on 7.2 o threa/133734 threads 32 bit libthr failing pthread_create() o threa/128922 threads threads hang with xorg running o threa/127225 threads bug in lib/libthr/thread/thr_init.c o threa/122923 threads 'nice' does not prevent background process from steali o threa/121336 threads lang/neko threading ok on UP, broken on SMP (FreeBSD 7 o threa/116668 threads can no longer use jdk15 with libthr on -stable SMP o threa/116181 threads /dev/io-related io access permissions are not propagat o threa/115211 threads pthread_atfork misbehaves in initial thread o threa/110636 threads [request] gdb(1): using gdb with multi thread applicat o threa/110306 threads apache 2.0 segmentation violation when calling gethost o threa/103975 threads Implicit loading/unloading of libpthread.so may crash o threa/101323 threads [patch] fork(2) in threaded programs broken. s threa/100815 threads FBSD 5.5 broke nanosleep in libc_r s threa/94467 threads send(), sendto() and sendmsg() are not correct in libc s threa/84483 threads problems with devel/nspr and -lc_r on 4.x o threa/80992 threads abort() sometimes not caught by gdb depending on threa o threa/79887 threads [patch] freopen() isn't thread-safe o threa/79683 threads svctcp_create() fails if multiple threads call at the s threa/76694 threads fork cause hang in dup()/close() function in child (-l s threa/76690 threads fork hang in child for -lc_r s threa/69020 threads pthreads library leaks _gc_mutex s threa/49087 threads Signals lost in programs linked with libc_r s threa/48856 threads Setting SIGCHLD to SIG_IGN still leaves zombies under s threa/40671 threads pthread_cancel doesn't remove thread from condition qu s threa/39922 threads [threads] [patch] Threaded applications executed with s threa/37676 threads libc_r: msgsnd(), msgrcv(), pread(), pwrite() need wra s threa/34536 threads accept() blocks other threads s threa/32295 threads [libc_r] [patch] pthread(3) dont dequeue signals s threa/30464 threads pthread mutex attributes -- pshared s threa/24632 threads libc_r delicate deviation from libc in handling SIGCHL s threa/24472 threads libc_r does not honor SO_SNDTIMEO/SO_RCVTIMEO socket o 37 problems total. From owner-freebsd-threads@FreeBSD.ORG Tue Oct 26 23:20:07 2010 Return-Path: Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 412741065675 for ; Tue, 26 Oct 2010 23:20:07 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 022C88FC22 for ; Tue, 26 Oct 2010 23:20:07 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o9QNK6f0079827 for ; Tue, 26 Oct 2010 23:20:06 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o9QNK6kK079826; Tue, 26 Oct 2010 23:20:06 GMT (envelope-from gnats) Resent-Date: Tue, 26 Oct 2010 23:20:06 GMT Resent-Message-Id: <201010262320.o9QNK6kK079826@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-threads@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Mark Terribile Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 93C5A1065674 for ; Tue, 26 Oct 2010 23:13:23 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21]) by mx1.freebsd.org (Postfix) with ESMTP id 67B008FC08 for ; Tue, 26 Oct 2010 23:13:23 +0000 (UTC) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.14.3/8.14.3) with ESMTP id o9QNDNNO094864 for ; Tue, 26 Oct 2010 23:13:23 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.14.3/8.14.3/Submit) id o9QNDN6I094853; Tue, 26 Oct 2010 23:13:23 GMT (envelope-from nobody) Message-Id: <201010262313.o9QNDN6I094853@www.freebsd.org> Date: Tue, 26 Oct 2010 23:13:23 GMT From: Mark Terribile To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Cc: Subject: 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: Tue, 26 Oct 2010 23:20:07 -0000 >Number: 151767 >Category: threads >Synopsis: pthread_mutex_init returns success with bad attributes; SUBSEQUENT operations fail >Confidential: no >Severity: non-critical >Priority: medium >Responsible: freebsd-threads >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Oct 26 23:20:06 UTC 2010 >Closed-Date: >Last-Modified: >Originator: Mark Terribile >Release: 7.2 >Organization: >Environment: FreeBSD gold.local 7.2-RELEASE FreeBSD 7.2-RELEASE #3: Mon Nov 16 12:48:52 EST 2009 toor@silver.local:/usr/obj/usr/src/sys/SMP-GONDOLIN i386 >Description: 1) A pthread_mutexattr_t is initialized and then parameters are set. Some are unsupported or invalid, as shown below. All the operations return success. 2) The pthread_mutex_attr_t is used in the initialization of a pthread_mutex_t. The pthread_mutex_init returns success. 3) A subesequent operation (pthread_mutex_lock, pthread_mutex_destroy) on the mutex in question returns EINVAL. This delayed reporting makes finding an error very difficult, and is probably not correct. Can the pthread_mutex_init be said to succeed if the mutex cannot be used for anything without generating an EINVAL? I understand that 7.2 is not a supported release, but this problem does not seem to appear in the bug reports so it is likely also present in later releases. An upgrade at this site right now is not feasible; I need a very stable environment underneath me. >How-To-Repeat: Please refer to the code below. All operations up to the #if return 0. If the lock/unlock code is #if'd out, the pthread_mutex_destroy returns 22. If the lock/unlock code is #if'd in, the pthread_mutex_lock returns 22, the pthread_mutex_unlock returns 2 (probably correct, given the other errors) and the pthread_mutex_destroy still returns 22. #include #include int main() { pthread_mutexattr_t ma; int r = pthread_mutexattr_init( &ma ); printf( "mutexattr init %d\n", r ); r = pthread_mutexattr_setprotocol( &ma, PTHREAD_PRIO_PROTECT ); printf( "mutexattr setprotocol %d\n", r ); r = pthread_mutexattr_settype( &ma, PTHREAD_MUTEX_ERRORCHECK ); printf( "mutexattr settype %d\n", r ); r = pthread_mutexattr_setprioceiling( &ma, 2 ); printf( "mutexattr setprioceiling %d\n", r ); pthread_mutex_t mtx; r = pthread_mutex_init( &mtx, &ma ); printf( "mutex init %d\n", r ); #if 0 r = pthread_mutex_lock( &mtx ); printf( "mutex lock %d\n", r ); r = pthread_mutex_unlock( &mtx ); printf( "mutex unlock %d\n", r ); #endif r = pthread_mutex_destroy( &mtx ); printf( "mutex destroy %d\n", r ); return 0; } >Fix: >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-threads@FreeBSD.ORG Wed Oct 27 02:00:19 2010 Return-Path: Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DA3B3106566C for ; Wed, 27 Oct 2010 02:00:19 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C7F428FC19 for ; Wed, 27 Oct 2010 02:00:19 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o9R20Jcb043987 for ; Wed, 27 Oct 2010 02:00:19 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o9R20JaV043974; Wed, 27 Oct 2010 02:00:19 GMT (envelope-from gnats) Date: Wed, 27 Oct 2010 02:00:19 GMT Message-Id: <201010270200.o9R20JaV043974@freefall.freebsd.org> To: freebsd-threads@FreeBSD.org From: David Xu Cc: 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 Reply-To: David Xu List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 02:00:19 -0000 The following reply was made to PR threads/151767; it has been noted by GNATS. From: David Xu To: Mark Terribile Cc: freebsd-gnats-submit@freebsd.org Subject: Re: threads/151767: pthread_mutex_init returns success with bad attributes; SUBSEQUENT operations fail Date: Wed, 27 Oct 2010 09:54:55 +0000 Mark Terribile wrote: >> Number: 151767 >> Category: threads >> Synopsis: pthread_mutex_init returns success with bad attributes; SUBSEQUENT operations fail >> Confidential: no >> Severity: non-critical >> Priority: medium >> Responsible: freebsd-threads >> State: open >> Quarter: >> Keywords: >> Date-Required: >> Class: sw-bug >> Submitter-Id: current-users >> Arrival-Date: Tue Oct 26 23:20:06 UTC 2010 >> Closed-Date: >> Last-Modified: >> Originator: Mark Terribile >> Release: 7.2 >> Organization: >> Environment: > FreeBSD gold.local 7.2-RELEASE FreeBSD 7.2-RELEASE #3: Mon Nov 16 12:48:52 EST 2009 toor@silver.local:/usr/obj/usr/src/sys/SMP-GONDOLIN i386 > >> Description: > 1) A pthread_mutexattr_t is initialized and then parameters are set. Some are unsupported or invalid, as shown below. All the operations return success. > > 2) The pthread_mutex_attr_t is used in the initialization of a pthread_mutex_t. The pthread_mutex_init returns success. > > 3) A subesequent operation (pthread_mutex_lock, pthread_mutex_destroy) on the mutex in question returns EINVAL. > > This delayed reporting makes finding an error very difficult, and is probably not correct. Can the pthread_mutex_init be said to succeed if the mutex cannot be used for anything without generating an EINVAL? > > I understand that 7.2 is not a supported release, but this problem does not seem to appear in the bug reports so it is likely also present in later releases. An upgrade at this site right now is not feasible; I need a very stable environment underneath me. > > >> How-To-Repeat: > Please refer to the code below. All operations up to the #if return 0. If the lock/unlock code is #if'd out, the pthread_mutex_destroy returns 22. If the lock/unlock code is #if'd in, the pthread_mutex_lock returns 22, the pthread_mutex_unlock returns 2 (probably correct, given the other errors) and the pthread_mutex_destroy still returns 22. > > > #include > #include > > int main() > { > pthread_mutexattr_t ma; > > int r = pthread_mutexattr_init( &ma ); > > printf( "mutexattr init %d\n", r ); > > r = pthread_mutexattr_setprotocol( &ma, PTHREAD_PRIO_PROTECT ); > > printf( "mutexattr setprotocol %d\n", r ); > > r = pthread_mutexattr_settype( &ma, PTHREAD_MUTEX_ERRORCHECK ); > > printf( "mutexattr settype %d\n", r ); > > r = pthread_mutexattr_setprioceiling( &ma, 2 ); > > printf( "mutexattr setprioceiling %d\n", r ); > > pthread_mutex_t mtx; > > r = pthread_mutex_init( &mtx, &ma ); > > printf( "mutex init %d\n", r ); > > #if 0 > r = pthread_mutex_lock( &mtx ); > > printf( "mutex lock %d\n", r ); > > r = pthread_mutex_unlock( &mtx ); > > printf( "mutex unlock %d\n", r ); > #endif > > r = pthread_mutex_destroy( &mtx ); > > printf( "mutex destroy %d\n", r ); > > return 0; > } > >> Fix: > > >> Release-Note: >> Audit-Trail: >> Unformatted: 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: > /* > * If the score is interactive we place the thread in the realtime > * queue with a priority that is less than kernel and interrupt > * priorities. These threads are not subject to nice restrictions. > * > * Scores greater than this are placed on the normal timeshare queue > * where the priority is partially decided by the most recent cpu > * utilization and the rest is decided by nice value. > * > * The nice value of the process has a linear effect on the calculated > * score. Negative nice values make it easier for a thread to be > * considered interactive. > */ > score = imax(0, sched_interact_score(td) + td->td_proc->p_nice); > if (score < sched_interact) { > pri = PRI_MIN_REALTIME; > pri += ((PRI_MAX_REALTIME - PRI_MIN_REALTIME) / sched_interact) > * score; > KASSERT(pri >= PRI_MIN_REALTIME && pri <= PRI_MAX_REALTIME, > ("sched_priority: invalid interactive priority %d score %d", > pri, score)); > } else { > pri = SCHED_PRI_MIN; > if (td->td_sched->ts_ticks) > pri += SCHED_PRI_TICKS(td->td_sched); > pri += SCHED_PRI_NICE(td->td_proc->p_nice); > KASSERT(pri >= PRI_MIN_TIMESHARE && pri <= PRI_MAX_TIMESHARE, > ("sched_priority: invalid priority %d: nice %d, " > "ticks %d ftick %d ltick %d tick pri %d", > pri, td->td_proc->p_nice, td->td_sched->ts_ticks, > td->td_sched->ts_ftick, td->td_sched->ts_ltick, > SCHED_PRI_TICKS(td->td_sched))); > } > sched_user_prio(td, pri); > > return; > } However, I may remove trylock in pthread_mutex_destroy, because it does not help anything if there is a programming bug in application. From owner-freebsd-threads@FreeBSD.ORG Wed Oct 27 02:26:43 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 65B6F106564A; Wed, 27 Oct 2010 02:26:43 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 1D2DF8FC12; Wed, 27 Oct 2010 02:26:42 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.4/8.14.4/NETPLEX) with ESMTP id o9R2QfhP024766; Tue, 26 Oct 2010 22:26:41 -0400 (EDT) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.2.2 (mail.netplex.net [204.213.176.10]); Tue, 26 Oct 2010 22:26:41 -0400 (EDT) Date: Tue, 26 Oct 2010 22:26:41 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: David Xu In-Reply-To: <201010270200.o9R20JaV043974@freefall.freebsd.org> Message-ID: References: <201010270200.o9R20JaV043974@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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 Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 02:26:43 -0000 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. 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 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 > From owner-freebsd-threads@FreeBSD.ORG Wed Oct 27 02:50:05 2010 Return-Path: Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 14874106566C for ; Wed, 27 Oct 2010 02:50:05 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E70588FC0C for ; Wed, 27 Oct 2010 02:50:04 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o9R2o4N1095191 for ; Wed, 27 Oct 2010 02:50:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o9R2o4xb095190; Wed, 27 Oct 2010 02:50:04 GMT (envelope-from gnats) Date: Wed, 27 Oct 2010 02:50:04 GMT Message-Id: <201010270250.o9R2o4xb095190@freefall.freebsd.org> To: freebsd-threads@FreeBSD.org From: Mark Terribile Cc: 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 Reply-To: Mark Terribile List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 02:50:05 -0000 The following reply was made to PR threads/151767; it has been noted by GNATS. From: Mark Terribile To: David Xu Cc: freebsd-gnats-submit@freebsd.org Subject: Re: threads/151767: pthread_mutex_init returns success with bad attributes; SUBSEQUENT operations fail Date: Tue, 26 Oct 2010 19:27:29 -0700 (PDT) =0ADavid,=0A=0A> Mark Terribile wrote:=0A ...=0A> > 1) A pthread_mutexattr_= t is initialized and then=0A> parameters are set.=A0 Some are unsupported o= r invalid,=0A> as shown below.=A0 All the operations return success.=0A ...= =0A> > 2) The pthread_mutex_attr_t is used in the=0A> initialization of a p= thread_mutex_t.=A0 The=0A> pthread_mutex_init returns success.=0A ...=0A> >= 3) A subesequent operation (pthread_mutex_lock,=0A> pthread_mutex_destroy)= on the mutex in question returns=0A> EINVAL.=0A=0A> Long time ago, I had r= eported the priority issue in ULE=0A> scheduler,=0A> the scheduler incorrec= tly changed a time-sharing thread to=0A> real-time=0A> priority when it ret= urns to userland if it thinks it is=0A> interactive.=0A> so you can not use= prority protected mutex with ULE=0A> scheduler.=0A> see sched_ule.c:=0A=0A= David,=0A=0AThis isn't a critical problem for me. I ran into it while chec= king=0Amy own error-handling code. It's always a tricky business to MAKE= =0Athings go wrong to test it.=0A=0AAnd I have no problem with the priority= protected mutex being unavailable=0A(though others might). The problem fo= r me is that the initialization=0Asuceeds, but then every subsequent operat= ion fails. If you have code that=0Aassumes that a failure in pthread_mutex= _destroy() means a very sick=0Aprogram, you'll react the wrong way to an er= ror of this sort. And tracing=0Ait to the source cost me most of a day, ev= en though I was doing nothing=0Abut testing some wrappers on pthreads.=0A= =0ASo while this error is officially non-critical, it can cost a great deal= =0Aof time. It is a bizarre failure-at-a-distance for parameters that can= =0Aand should be checked--and probably are, but maybe not completely enough= .=0A=0ABut it's good to know that it reflects an underlying problem whose r= oot=0Acause is known. Thanks for explaining it.=0A=0A Mark Terribile=0A= =0A=0A From owner-freebsd-threads@FreeBSD.ORG Wed Oct 27 11:38:55 2010 Return-Path: Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F39971065670; Wed, 27 Oct 2010 11:38:54 +0000 (UTC) (envelope-from arundel@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C8E828FC17; Wed, 27 Oct 2010 11:38:54 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o9RBcsr9081809; Wed, 27 Oct 2010 11:38:54 GMT (envelope-from arundel@freefall.freebsd.org) Received: (from arundel@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o9RBcs3s081805; Wed, 27 Oct 2010 11:38:54 GMT (envelope-from arundel) Date: Wed, 27 Oct 2010 11:38:54 GMT Message-Id: <201010271138.o9RBcs3s081805@freefall.freebsd.org> To: materribile@yahoo.com, arundel@FreeBSD.org, freebsd-threads@FreeBSD.org, davidxu@FreeBSD.org From: arundel@FreeBSD.org Cc: 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 11:38:55 -0000 Synopsis: pthread_mutex_init returns success with bad attributes; SUBSEQUENT operations fail State-Changed-From-To: open->patched State-Changed-By: arundel State-Changed-When: Wed Oct 27 11:37:19 UTC 2010 State-Changed-Why: Patched in HEAD (r214410). Responsible-Changed-From-To: freebsd-threads->davidxu Responsible-Changed-By: arundel Responsible-Changed-When: Wed Oct 27 11:37:19 UTC 2010 Responsible-Changed-Why: Assign to David as MFC reminder. http://www.freebsd.org/cgi/query-pr.cgi?pr=151767