Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755066AbbG3ITV (ORCPT ); Thu, 30 Jul 2015 04:19:21 -0400 Received: from mail-wi0-f179.google.com ([209.85.212.179]:38246 "EHLO mail-wi0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753367AbbG3ITK (ORCPT ); Thu, 30 Jul 2015 04:19:10 -0400 Message-ID: <55B9DDF7.4010308@gmail.com> Date: Thu, 30 Jul 2015 10:19:03 +0200 From: "Michael Kerrisk (man-pages)" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Darren Hart , Thomas Gleixner CC: mtk.manpages@gmail.com, 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 References: <55B61EF3.7080302@gmail.com> <20150729041141.GE3171@vmdeb7> <20150729042141.GA62059@vmdeb7> In-Reply-To: <20150729042141.GA62059@vmdeb7> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4154 Lines: 97 On 07/29/2015 06:21 AM, Darren Hart wrote: > On Tue, Jul 28, 2015 at 09:11:41PM -0700, Darren Hart wrote: >> On Tue, Jul 28, 2015 at 10:23:51PM +0200, Thomas Gleixner wrote: >>> On Mon, 27 Jul 2015, Michael Kerrisk (man-pages) wrote: >> >> ... >> >>>> FUTEX_REQUEUE (since Linux 2.6.0) >>>> .\" FIXME(Torvald) Is there some indication that FUTEX_REQUEUE is broken >>>> .\" in general, or is this comment implicitly speaking about the >>>> .\" condvar (?) use case? If the latter we might want to weaken the >>>> .\" advice below a little. >>>> .\" [Anyone else have input on this?] >>> >>> The condvar use case exposes the flaw nicely, but that's pretty much >>> true for everything which wants a sane requeue operation. >> >> In an earlier discussion I argued this point (that FUTURE_REQUEUE is broken and >> should not be used in new code) and someone argued strongly against... stating >> that there were legitimate uses for it. Of course I'm struggling to find the >> thread and the reference at the moment - immensely useful, I know. >> >> I'll continue trying to find it and see if it can be useful here. I believe >> Torvald was on the thread as well. >> > > Found it on libc-alpha, here it is for reference: > > From: Rich Felker > Date: Wed, 29 Oct 2014 22:43:17 -0400 > To: Darren Hart > Cc: Carlos O'Donell , Roland McGrath , > Torvald Riegel , GLIBC Devel , > Michael Kerrisk > Subject: Re: Add futex wrapper to glibc? > > On Wed, Oct 29, 2014 at 06:59:15PM -0700, Darren Hart wrote: > > > We are IMO at the stage where futex is stable, few things are > > > changing, and with documentation in place, I would consider adding a > > > futex wrapper. > > > > Yes, at least for the defined OP codes. New OPs may be added of > > course, but that isn't a concern for supporting what exists today, and > > doesn't break compatibility. > > > > I wonder though... can we not wrap FUTEX_REQUEUE? It's fundamentally > > broken. FUTEX_CMP_REQUEUE should *always* be used instead. The glibc > > wrapper is one way to encourage developers to do the right thing > > (don't expose the bad op in the header). > > You're mistaken here. There are plenty of valid ways to use > FUTEX_REQUEUE - for example if the calling thread is requeuing the > target(s) to a lock that the calling thread owns. Just because it > doesn't meet the needs of the way glibc was using it internally > doesn't mean it's useless for other applications. > > In any case, I don't think there's a proposal to intercept/modify the > commands to futex, just to pass them through (and possibly do a > cancellable syscall for some of them). > > Rich > > >>> >>>> Avoid using this operation. It is broken for its intended >>>> purpose. Use FUTEX_CMP_REQUEUE instead. >>>> >>>> This operation performs the same task as >>>> FUTEX_CMP_REQUEUE, except that no check is made using the >>>> value in val3. (The argument val3 is ignored.) Thanks, Darren, that's really helpful! I've removed the statement in the man page that FUTEX_REQUEUE is broken. By the way, Darren. There were a couple of FIXMEs in the page where you are explicitly mentioned by name. Could you take a look at those? Specifically, the large block of text starting at: >> .\" FIXME XXX The following is my attempt at a definition of PI futexes, >> .\" based on mail discussions with Darren Hart. Does it seem okay? (tglx looked at this and blessed it, but I'd like you also to check.) Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- 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/