From owner-svn-src-all@freebsd.org Sat Jun 25 17:30:03 2016 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 50657B81072; Sat, 25 Jun 2016 17:30:03 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EEEE112D8; Sat, 25 Jun 2016 17:30:02 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u5PHTuw6012726 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 25 Jun 2016 20:29:56 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u5PHTuw6012726 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u5PHTu6q012725; Sat, 25 Jun 2016 20:29:56 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 25 Jun 2016 20:29:56 +0300 From: Konstantin Belousov To: Jilles Tjoelker , Daniel Eischen Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r302194 - head/lib/libthr/thread Message-ID: <20160625172956.GE38613@kib.kiev.ua> References: <201606251130.u5PBUeGC001988@repo.freebsd.org> <20160625171440.GA19698@stack.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160625171440.GA19698@stack.nl> User-Agent: Mutt/1.6.1 (2016-04-27) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jun 2016 17:30:03 -0000 On Sat, Jun 25, 2016 at 07:14:40PM +0200, Jilles Tjoelker wrote: > On Sat, Jun 25, 2016 at 11:30:40AM +0000, Konstantin Belousov wrote: > > Author: kib > > Date: Sat Jun 25 11:30:40 2016 > > New Revision: 302194 > > URL: https://svnweb.freebsd.org/changeset/base/302194 > > > Log: > > For pthread_mutex_trylock() call on owned error-check or non-portable > > adaptive mutex, return EDEADLK as required by POSIX. The > > pthread_mutex_lock() is already compliant. > > > Tested by: Guy Yur > > Sponsored by: The FreeBSD Foundation > > MFC after: 2 weeks > > Approved by: re (gjb) > > > Modified: > > head/lib/libthr/thread/thr_mutex.c > > > Modified: head/lib/libthr/thread/thr_mutex.c > > ============================================================================== > > --- head/lib/libthr/thread/thr_mutex.c Sat Jun 25 10:08:04 2016 (r302193) > > +++ head/lib/libthr/thread/thr_mutex.c Sat Jun 25 11:30:40 2016 (r302194) > > @@ -850,9 +850,12 @@ mutex_self_trylock(struct pthread_mutex > > > > switch (PMUTEX_TYPE(m->m_flags)) { > > case PTHREAD_MUTEX_ERRORCHECK: > > - case PTHREAD_MUTEX_NORMAL: > > case PTHREAD_MUTEX_ADAPTIVE_NP: > > - ret = EBUSY; > > + ret = EDEADLK; > > + break; > > + > > + case PTHREAD_MUTEX_NORMAL: > > + ret = EBUSY; > > break; > > > > case PTHREAD_MUTEX_RECURSIVE: > > I think POSIX (SUSv4tc1, XSH 3 pthread_mutex_lock) is clear that only > pthread_mutex_lock() can fail with [EDEADLK], not > pthread_mutex_trylock(). Instead, the error [EBUSY] listed for > pthread_mutex_trylock() applies whenever the mutex could not be acquired > because it was already locked. This includes the case where the mutex is > owned by the current thread. Note that POSIX intends to allow not > storing the owning thread's ID in non-recursive non-robust mutexes. > > Failing pthread_mutex_trylock() on owned mutexes only with [EBUSY] also > matches our code before this commit and NetBSD's code, and is apparently > expected by other code. > > Therefore, I think this commit should be reverted. > I already asked re for approval of the reversal and got it. But I am still hesitating doing the revert vs. returning EDEADLK for error-checking mutexes. My initial mistake was reading the statement about PTHREAD_MUTEX_ERRORCHECK returning EDEADLK as the requirement for both functions. It was induced by reading the following code in samba: https://github.com/samba-team/samba/blob/master/lib/tdb/common/mutex.c#L928 I did extracted this into stand-alone test and checked that glibc does return EDEADLK in this case. BTW, if somebody has Solaris machine available to test this, I would be grateful. Code is available at https://www.kib.kiev.ua/kib/pshared/pthread_samba.c I.e., plain revert would disable the only known to me consumer of the robust mutexes. The patch which I mailed last time, returns EDEADLK for trylock on ERRORCHECKed mutexes only. And I am tending toward glibc compatibility there, over the literal POSIX compliance, but I want to see the confirmation from the Klimenko' test first.