Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp3621870pxk; Tue, 29 Sep 2020 01:37:28 -0700 (PDT) X-Google-Smtp-Source: ABdhPJykdY/Vdpx4O80OcwmkbfZ+BUT8UhujdgZ2a8eNhlbC+tpla1ZSSZ8VFdV3HaanVTNvc4yq X-Received: by 2002:a05:6402:144c:: with SMTP id d12mr2106145edx.168.1601368648062; Tue, 29 Sep 2020 01:37:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1601368648; cv=none; d=google.com; s=arc-20160816; b=rdtNvKURJhPZsqeC0h29W13oIciaTePsbNGrwaSSV8yjhs8b7FC2ZODG4naiBATQ5Z qq2xrUa1uC+2X+hutyxLNrOtMmMGglsPJOktgpitQHZxj1Z8NLOBje3IYhTU/MQu3NrY e+n44euFwh31JwW/tSMi4hN6VWWfveiJAoT8RnE3hm4lMMfwBuHEtX0eY9Zy+H0Z3H/j yoP9REBjaEHZnWcQ3xyJImoTGTekFeWOn6yj5sNo4+afZt2sjdzBmgcRkhRhx2+HSIuz fMICxv71SyB7lB2R8ia7yQyoPs/j5caPHuLbXGsUcabCwrx158RYwUED8EocVZhdM02s cJqw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent:references:message-id :in-reply-to:subject:cc:to:date:from:dkim-signature; bh=HK41/qbPxO+SoGRXquqjP/gEh3I+38ZE+z63fzbFSAM=; b=V+RinH0OCPP4naGF/k3I6YQhkVqyL1uYdEnHVXzcnyGJpw2ukPM12f3KugOG3jUhdx 6pKr6daAXRYPCl/eTtpu/X6YAdC0I2VLKwTFgdySYXUKHmsZCjT7rAKrFjZroQTsTgRi 6xrDQpFUcVj3RRT76OtbJuTzBeJtafqBs6P71rKvL4gnb9UcoakX4ZBzobczpVElRxVk wAM+Hoo+3TN/1LviF1LmPcKycYKop/pNoaJmBdSTPlOZjD+b7F+y8a/GnkIymDchUtyW YQO0K/T05wEq+RyfjIHuG01wh948UrvTfz8+rgKYUHlUX8qkxQu0q5E94O2HYrEJGfIJ 5ZVw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=S8yJWuwR; 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=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id df26si2378321edb.486.2020.09.29.01.37.05; Tue, 29 Sep 2020 01:37:28 -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; dkim=pass header.i=@gmail.com header.s=20161025 header.b=S8yJWuwR; 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=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727916AbgI2IdQ (ORCPT + 99 others); Tue, 29 Sep 2020 04:33:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37622 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727893AbgI2IdN (ORCPT ); Tue, 29 Sep 2020 04:33:13 -0400 Received: from mail-ed1-x543.google.com (mail-ed1-x543.google.com [IPv6:2a00:1450:4864:20::543]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id ED92EC0613D5; Tue, 29 Sep 2020 01:33:11 -0700 (PDT) Received: by mail-ed1-x543.google.com with SMTP id e22so5418560edq.6; Tue, 29 Sep 2020 01:33:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:date:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version; bh=HK41/qbPxO+SoGRXquqjP/gEh3I+38ZE+z63fzbFSAM=; b=S8yJWuwRM6E6vG99yfmoQMLxY2mnpbYIcvbtstIvuN666T+YtUHi8dh3la0w5Yafct PZ/XVQQn9ZDZjIkn4uGu2dWW1+YOT5H5gGswkiD/F5rQIANePpgPusGcvJ6YplN7IZfP WshdCVcyQ4ipZgpJwuIkCAotuYHX/k7lKN4DNBdxG1vIVH5x0h00kep03tjP3ggBWszA nj8BzeKlG4yfnwmTtrV1GJoGQDLgRRI1iVYvEBI9TD5nYieaMf8Np5G1atY+LEHy8GBo tfAdIRvOSPfaa6A2tJ/HySv258TxNjiCkJvG4IwF6Pn8G83LykzK+q8vWwIbnOcYDMYZ tH6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:date:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version; bh=HK41/qbPxO+SoGRXquqjP/gEh3I+38ZE+z63fzbFSAM=; b=RBmB2+3xCKjVc9l35kLufYxUL/276DTJufkP+incWKuwnaQttEW/3kSGj+9RHHpusr uW0Ny049s6cTT5jHV3e3pzMskAq4b/N3oiG8jFWE3zsjGvpIiB5TrIcY3Zop8Dx/CIqv UButUDOe8bIDHJx/F+9T5uqqKy6vH8WucaoOOj/GY4dXVMFHwI0Wls5TkRrAwQafu4R/ 9D2MKj6JnYwWkmH4feNvaDlknujHfNRYtcjjyyERGRTSsmtwQRczR3hnGRGti6VFSzRN 67M1drh3P980l53v/DCz5VFuqgwb8iYp+nkH8w+8o+o46p8kZ0XaqWYmfnTB6/Rudaps HDcA== X-Gm-Message-State: AOAM532NCrt/OQaI/HcV326JdRWmLQhT6aZEA9rsdaSl0sYaf9OrmB08 wdxEqBgm8seE2D6uAePBDf4= X-Received: by 2002:aa7:d4d0:: with SMTP id t16mr2020758edr.83.1601368390650; Tue, 29 Sep 2020 01:33:10 -0700 (PDT) Received: from felia ([2001:16b8:2d89:9100:1da1:773b:dbb4:3fc9]) by smtp.gmail.com with ESMTPSA id cn21sm5173410edb.14.2020.09.29.01.33.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 29 Sep 2020 01:33:09 -0700 (PDT) From: Lukas Bulwahn X-Google-Original-From: Lukas Bulwahn Date: Tue, 29 Sep 2020 10:33:08 +0200 (CEST) X-X-Sender: lukas@felia To: Peter Zijlstra , Balbir Singh cc: Lukas Bulwahn , Thomas Gleixner , Dave Hansen , Andy Lutomirski , Ingo Molnar , Borislav Petkov , x86@kernel.org, "H. Peter Anvin" , Nathan Chancellor , Nick Desaulniers , linux-kernel@vger.kernel.org, clang-built-linux@googlegroups.com, kernel-janitors@vger.kernel.org, linux-safety@lists.elisa.tech Subject: Re: [PATCH -next for tip:x86/pti] x86/tlb: drop unneeded local vars in enable_l1d_flush_for_task() In-Reply-To: <20200929071211.GJ2628@hirez.programming.kicks-ass.net> Message-ID: References: <20200928124457.27289-1-lukas.bulwahn@gmail.com> <20200929071211.GJ2628@hirez.programming.kicks-ass.net> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 29 Sep 2020, Peter Zijlstra wrote: > On Mon, Sep 28, 2020 at 02:44:57PM +0200, Lukas Bulwahn wrote: > > diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c > > index 6b0f4c88b07c..90515c04d90a 100644 > > --- a/arch/x86/mm/tlb.c > > +++ b/arch/x86/mm/tlb.c > > @@ -316,7 +316,7 @@ EXPORT_SYMBOL_GPL(leave_mm); > > > > int enable_l1d_flush_for_task(struct task_struct *tsk) > > { > > - int cpu, ret = 0, i; > > + int i; > > > > /* > > * Do not enable L1D_FLUSH_OUT if > > @@ -329,7 +329,7 @@ int enable_l1d_flush_for_task(struct task_struct *tsk) > > !static_cpu_has(X86_FEATURE_FLUSH_L1D)) > > return -EINVAL; > > > > - cpu = get_cpu(); > > + get_cpu(); > > > > for_each_cpu(i, &tsk->cpus_mask) { > > if (cpu_data(i).smt_active == true) { > > @@ -340,7 +340,7 @@ int enable_l1d_flush_for_task(struct task_struct *tsk) > > > > set_ti_thread_flag(&tsk->thread_info, TIF_SPEC_L1D_FLUSH); > > put_cpu(); > > - return ret; > > + return 0; > > } > > If you don't use the return value of get_cpu(), then change it over to > preempt_{dis,en}able(), but this got me looking at the function, wtf is > that garbage supposed to do in the first place I also thought that preempt_{dis,en}able() would do, but thought maybe Balbir just considered {get,put}_cpu stylistically nicer... so I stayed with the functions as-is. > > What do we need to disable preemption for? > I have no clue... not a good premise for touching the code, but I just wanted to make clang-analyzer happy without modifying any semantics. Balbir, can you help out here? What was your intent? > Please explain the desired semantics against sched_setaffinity(). > I am happy to send a proper v2 once I understand if disabling preemption is required and the preempt_{dis,en}able() function are preferred to the {get,put}_cpu functions. Lukas