Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752867AbbG2MAa (ORCPT ); Wed, 29 Jul 2015 08:00:30 -0400 Received: from www.linutronix.de ([62.245.132.108]:39923 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750864AbbG2MA2 (ORCPT ); Wed, 29 Jul 2015 08:00:28 -0400 Date: Wed, 29 Jul 2015 14:00:03 +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: <20150729042141.GA62059@vmdeb7> Message-ID: References: <55B61EF3.7080302@gmail.com> <20150729041141.GE3171@vmdeb7> <20150729042141.GA62059@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,URIBL_BLOCKED=0.001 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2058 Lines: 46 On Tue, 28 Jul 2015, Darren Hart wrote: > 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). Fair enough. Did not think about the requeue to futex held by the caller case. In that case FUTEX_REQUEUE works as advertised. 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/