Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752585AbbHSWla (ORCPT ); Wed, 19 Aug 2015 18:41:30 -0400 Received: from www.linutronix.de ([62.245.132.108]:33877 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751062AbbHSWl2 (ORCPT ); Wed, 19 Aug 2015 18:41:28 -0400 Date: Thu, 20 Aug 2015 00:40:46 +0200 (CEST) From: Thomas Gleixner To: Darren Hart cc: "Michael Kerrisk (man-pages)" , Torvald Riegel , "Carlos O'Donell" , Ingo Molnar , Jakub Jelinek , linux-man , lkml , Davidlohr Bueso , Arnd Bergmann , Steven Rostedt , Peter Zijlstra , Linux API , Roland McGrath , Anton Blanchard , Eric Dumazet , bill o gallmeister , Jan Kiszka , Daniel Wagner , Rich Felker , Andy Lutomirski , bert hubert , Rusty Russell , Heinrich Schuchardt Subject: Re: Next round: revised futex(2) man page for review In-Reply-To: <20150805222140.GA74817@vmdeb7> Message-ID: References: <55B61EF3.7080302@gmail.com> <20150805222140.GA74817@vmdeb7> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2956 Lines: 64 On Wed, 5 Aug 2015, Darren Hart wrote: > On Mon, Jul 27, 2015 at 02:07:15PM +0200, Michael Kerrisk (man-pages) wrote: > > .\" FIXME XXX ===== Start of adapted Hart/Guniguntala text ===== > > .\" The following text is drawn from the Hart/Guniguntala paper > > .\" (listed in SEE ALSO), but I have reworded some pieces > > .\" significantly. Please check it. > > > > The PI futex operations described below differ from the other > > futex operations in that they impose policy on the use of the > > value of the futex word: > > > > * If the lock is not acquired, the futex word's value shall be > > 0. > > > > * If the lock is acquired, the futex word's value shall be the > > thread ID (TID; see gettid(2)) of the owning thread. > > > > * If the lock is owned and there are threads contending for the > > lock, then the FUTEX_WAITERS bit shall be set in the futex > > word's value; in other words, this value is: > > > > FUTEX_WAITERS | TID > > > > > > Note that a PI futex word never just has the value FUTEX_WAITERS, > > which is a permissible state for non-PI futexes. > > The second clause is inappropriate. I don't know if that was yours or > mine, but non-PI futexes do not have a kernel defined value policy, so > ==FUTEX_WAITERS cannot be a "permissible state" as any value is > permissible for non-PI futexes, and none have a kernel defined state. Depends. If the regular futex is configured as robust, then we have a kernel defined value policy as well. > > .\" FIXME I'm not quite clear on the meaning of the following sentence. > > .\" Is this trying to say that while blocked in a > > .\" FUTEX_WAIT_REQUEUE_PI, it could happen that another > > .\" task does a FUTEX_WAKE on uaddr that simply causes > > .\" a normal wake, with the result that the FUTEX_WAIT_REQUEUE_PI > > .\" does not complete? What happens then to the FUTEX_WAIT_REQUEUE_PI > > .\" opertion? Does it remain blocked, or does it unblock > > .\" In which case, what does user space see? > > > > The > > waiter can be removed from the wait on uaddr via > > FUTEX_WAKE without requeueing on uaddr2. > > Userspace should see the task wake and continue executing. This would > effectively be a cancelation operation - which I didn't think was > supported. Thomas? We probably never intended to support it, but looking at the code it works (did not try it though). It returns to user space with -EWOULDBLOCK. So it basically behaves like any other spurious wakeup. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/