Received: by 2002:a05:6a10:a841:0:0:0:0 with SMTP id d1csp1692782pxy; Fri, 23 Apr 2021 14:41:25 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy6kaPQ5Z1GkPoeG6yBjTWlHwVjgF5CR1f9KqxS5g7nGgzmPtraZVHX/UijVihNpcYehDE7 X-Received: by 2002:a65:6095:: with SMTP id t21mr5668633pgu.383.1619214085033; Fri, 23 Apr 2021 14:41:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1619214085; cv=none; d=google.com; s=arc-20160816; b=LFteyMqUCO9YGHJSsqr6QhjFmHBqS4fAIcLKknB5D/oT5coX7ZdfLWA7fQWlRJPmLQ 5Q/WGF1GAZsr7Xuh1p0ghcSm+m3UATruN77UntghLFi59XwKO2683n2Ge7XjZW6nQU5Y AygsAVbgETY6XqeHWj2T00jSDu958QnJj8DXXQ5weXO4o/WGAkazPk2K5/UHMwbdj+uN 9AKYhxpeAYsNhqXtxYB/cXY8oRLdHaGAnk8JzE1IzRNuErcUW2BX+/j9FzEAiEZXIXRX VcYTFy9Eu0OVZ8bIPZ8Xb85yHUmDkZsWRTPAGf8Wfi0/w663xI7gWYsQatah/alF92jG U7Cw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=ho0JLp0AJAWu66dco8fMAX3Kag7mecbmzhsUVUIYtTs=; b=fPSRIPu2sHmjS/hUfeDVPHXNBs42mplbJmdR4m98GwK+4WTwRl3U6PuDOOg+QxrE2N EBtFsooo7NKn3EdPkPuyzv/RC/UnTHJNsRqRDujAPo8XlerDLIbAeH+WOVzwP/o+B9d9 SYxty4Q7dq3DZBy8wzMYlT5T4bLwjQF5TdlPOOHmfO3NEKUMw2rAE3yNjgZc4NMEqJa5 ADc5ILtlvqBwKfwGZlUi8/jXLLxSe8NJ9PXZSQun/WLF3Z9VLfVRIy0VBRkRsJnf398J c2E1nC+mXBNz+rDBG86VFq1+F/Uiw3pzb1imQ6T35KsFOaOUtfeBR1CyX7P0nltXyPNi Z9ew== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=collabora.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id i22si10705609pju.10.2021.04.23.14.41.12; Fri, 23 Apr 2021 14:41:25 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=collabora.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244084AbhDWVlH (ORCPT + 99 others); Fri, 23 Apr 2021 17:41:07 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52886 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244088AbhDWVlB (ORCPT ); Fri, 23 Apr 2021 17:41:01 -0400 Received: from bhuna.collabora.co.uk (bhuna.collabora.co.uk [IPv6:2a00:1098:0:82:1000:25:2eeb:e3e3]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1D20EC061574 for ; Fri, 23 Apr 2021 14:40:23 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: tonyk) with ESMTPSA id AB8A91F40FD7 Subject: Re: [patch 3/6] futex: Get rid of the val2 conditional dance To: Thomas Gleixner , LKML Cc: Peter Zijlstra , Adhemerval Zanella , Lukasz Majewski , Florian Weimer , Carlos O'Donell , "Michael Kerrisk (man-pages)" , Davidlohr Bueso , Ingo Molnar , Darren Hart , Andrei Vagin , Kurt Kanzenbach , kernel@collabora.com References: <20210422194417.866740847@linutronix.de> <20210422194705.125957049@linutronix.de> From: =?UTF-8?Q?Andr=c3=a9_Almeida?= Message-ID: Date: Fri, 23 Apr 2021 18:40:13 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0 MIME-Version: 1.0 In-Reply-To: <20210422194705.125957049@linutronix.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Thomas, Às 16:44 de 22/04/21, Thomas Gleixner escreveu: > There is no point in checking which FUTEX operand treats the utime pointer > as 'val2' argument because that argument to do_futex() is only used by > exactly these operands. > > So just handing it in unconditionally is not making any difference, but > removes a lot of pointless gunk. > > Signed-off-by: Thomas Gleixner > --- > kernel/futex.c | 16 ++-------------- > 1 file changed, 2 insertions(+), 14 deletions(-) > > --- a/kernel/futex.c > +++ b/kernel/futex.c > @@ -3765,7 +3765,6 @@ SYSCALL_DEFINE6(futex, u32 __user *, uad > { > struct timespec64 ts; > ktime_t t, *tp = NULL; > - u32 val2 = 0; > int cmd = op & FUTEX_CMD_MASK; > > if (utime && (cmd == FUTEX_WAIT || cmd == FUTEX_LOCK_PI || > @@ -3785,15 +3784,8 @@ SYSCALL_DEFINE6(futex, u32 __user *, uad > t = timens_ktime_to_host(CLOCK_MONOTONIC, t); > tp = &t; > } > - /* > - * requeue parameter in 'utime' if cmd == FUTEX_*_REQUEUE_*. > - * number of waiters to wake in 'utime' if cmd == FUTEX_WAKE_OP. > - */ > - if (cmd == FUTEX_REQUEUE || cmd == FUTEX_CMP_REQUEUE || > - cmd == FUTEX_CMP_REQUEUE_PI || cmd == FUTEX_WAKE_OP) > - val2 = (u32) (unsigned long) utime; > > - return do_futex(uaddr, op, val, tp, uaddr2, val2, val3); > + return do_futex(uaddr, op, val, tp, uaddr2, (unsigned long)utime, val3); Given do_futex()'s type signature, I think it makes more sense to cast utime to u32. > } > > #ifdef CONFIG_COMPAT > @@ -3961,7 +3953,6 @@ SYSCALL_DEFINE6(futex_time32, u32 __user > { > struct timespec64 ts; > ktime_t t, *tp = NULL; > - int val2 = 0; > int cmd = op & FUTEX_CMD_MASK; > > if (utime && (cmd == FUTEX_WAIT || cmd == FUTEX_LOCK_PI || > @@ -3979,11 +3970,8 @@ SYSCALL_DEFINE6(futex_time32, u32 __user > t = timens_ktime_to_host(CLOCK_MONOTONIC, t); > tp = &t; > } > - if (cmd == FUTEX_REQUEUE || cmd == FUTEX_CMP_REQUEUE || > - cmd == FUTEX_CMP_REQUEUE_PI || cmd == FUTEX_WAKE_OP) > - val2 = (int) (unsigned long) utime; > > - return do_futex(uaddr, op, val, tp, uaddr2, val2, val3); > + return do_futex(uaddr, op, val, tp, uaddr2, (unsigned long)utime, val3); Same here. > } > #endif /* CONFIG_COMPAT_32BIT_TIME */ > >