From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756947AbbAPUyV (ORCPT ); Fri, 16 Jan 2015 15:54:21 -0500 Received: from mail-wi0-f171.google.com ([209.85.212.171]:51401 "EHLO mail-wi0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753696AbbAPUyT (ORCPT ); Fri, 16 Jan 2015 15:54:19 -0500 Message-ID: <54B97A72.2050205@gmail.com> Date: Fri, 16 Jan 2015 21:54:10 +0100 From: "Michael Kerrisk (man-pages)" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Thomas Gleixner CC: mtk.manpages@gmail.com, "Carlos O'Donell" , Darren Hart , Ingo Molnar , Jakub Jelinek , "linux-man@vger.kernel.org" , lkml , Davidlohr Bueso , Arnd Bergmann , Steven Rostedt , Peter Zijlstra , Linux API , Torvald Riegel , Roland McGrath , Darren Hart , Anton Blanchard , Petr Baudis , Eric Dumazet , bill o gallmeister , Jan Kiszka , Daniel Wagner , Rich Felker Subject: Re: futex(2) man page update help request References: <537346E5.4050407@gmail.com> <5373D0CA.2050204@redhat.com> <54B7D87C.3090901@gmail.com> <54B92B71.2090509@gmail.com> In-Reply-To: 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 On 01/16/2015 04:20 PM, Thomas Gleixner wrote: > On Fri, 16 Jan 2015, Michael Kerrisk (man-pages) wrote: > >> Hello Thomas, >> >> On 01/15/2015 11:23 PM, Thomas Gleixner wrote: >>> On Thu, 15 Jan 2015, Michael Kerrisk (man-pages) wrote: >>>>> [EINVAL] uaddr equal uaddr2. Requeue to same futex. >>>> >>>> ??? I added this, but does this error not occur only for PI requeues? >>> >>> It's equally wrong for normal futexes. And its actually the same code >>> checking for this for all variants. >> >> I don't understand "equally wrong" in your reply, I'm sorry. Do you >> mean: >> >> a) This error text should be there for both normal and PI requeues > > It is there for both. The requeue code has that check independent of > the requeue type (normal/pi). It never makes sense to requeue > something to itself whether normal or pi futex. We added this for PI, > because there it is harmful, but we did not special case it. So normal > futexes get the same treatment. Hello Thomas, Color me stupid, but I can't see this in futex_requeue(). Where is that check that is "independent of the requeue type (normal/pi)"? When I look through futex_requeue(), all the likely looking sources of EINVAL are governed by a check on the 'requeue_pi' argument. Thanks, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/