Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp4726297pxk; Wed, 30 Sep 2020 10:05:04 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwbcwe+fsUz7SURfA7vR7I+uJECWLXbtwZCPg4+jmBw7Y/wkGYnxjgq1WVl8pRKhh5LJljk X-Received: by 2002:a17:906:d9da:: with SMTP id qk26mr3706884ejb.435.1601485504653; Wed, 30 Sep 2020 10:05:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1601485504; cv=none; d=google.com; s=arc-20160816; b=PwwtdNBK5aK52Jbevs5YIyyshgx82LqH0iW7lKQjtajA9bhRUDY+DXyHJ8YqIgobvq t9PAVZcYlFbmUdFvSI9Eak+wKGLq9Q7/KygOoV1wgz1IvdlgwVdNhwD7Y3h4E2fV6w2S e+j3C+jkoBkWInEhruXCTLtHXRty3S/WHJ/z+VTl3BVVrPWR5Bd+jxz8KbsBKS0EogfC 2OmcJso+LiXFnMdjtF6PLHzDFOJpC4MIq3LdSwD+ld+lnUd7KYyp+yy5BGVpJDoKPVj8 HH4pSHqWaM16osTUcTDXhs6W9gfThdf+iwvvqWXHrV5pdbMerE7WVWccmyia72+POSNE OTyA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=MMthncIuRiOfaiEZfDxlAanpq7cwXkc95Eu54otq0Iw=; b=QIZUN3l0GyCruwmyGq6yqPrt6iIP3vTsn2pfzfF4XGmbpqaDKsKYjdMdwxwdFxxiEc uYzEa3QAEkXkYzizPxvCQo0R847CCaUnCPFZGNB4s74N1XCfBUnBKRBO2YZ0SOxsGKvT u1htQxOr4f/ycNjGbd10bQSTURd8cDRV+CI9X3iSQIY46B8FoVZGVwpwtOQ14ziKmz39 R67nAUhltw+UZqbydPm7vIMmm6ce21aAYpddYNtcnGhBcW70SImcDKLYeTL8cvpsxJhf m+LWzwzyJtYZPQ9GyHCql8VSDnjDigtwqVRnAlqubOoxe6PTszk4BMQThcEp/HWXt8mi ytSg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@infradead.org header.s=merlin.20170209 header.b=1KmfELOd; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id 19si1484651ejb.381.2020.09.30.10.04.39; Wed, 30 Sep 2020 10:05:04 -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=@infradead.org header.s=merlin.20170209 header.b=1KmfELOd; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728805AbgI3RDe (ORCPT + 99 others); Wed, 30 Sep 2020 13:03:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56990 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725355AbgI3RDe (ORCPT ); Wed, 30 Sep 2020 13:03:34 -0400 Received: from merlin.infradead.org (merlin.infradead.org [IPv6:2001:8b0:10b:1231::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 122B6C061755; Wed, 30 Sep 2020 10:03:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=merlin.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=MMthncIuRiOfaiEZfDxlAanpq7cwXkc95Eu54otq0Iw=; b=1KmfELOdqa9i5Kk2StW7u12SMi Srz+ADPn4f4mwy305WvjdGzCq8zlMCdiX2rK3A4jsdgkQyCBjzYQcXOvwJnUj3IOTcH54d3/eUQvq uHjAmTGIDOfWUaCbmyMPtaCGVXHx9f40VTg9K0w1PW5Si2FuvmkUF4q4AJgvnvUcBGDCImLLvkWiF oYOwbH2hgYqOLJb6AOS0Xr+8hpi3lB8XUt1uxQAPXiYaNmPjGrucr//h00SfMPBp+Qw1MhwTNw4Ov xklsX86qlNMyt1G1R1hcE0DIYXUph0Gnj3KBOHbhIvyAjr+p4ZJsYyfDXl11LoPp2vHMyOtbiwnYF 9dBMsK0w==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=noisy.programming.kicks-ass.net) by merlin.infradead.org with esmtpsa (Exim 4.92.3 #3 (Red Hat Linux)) id 1kNfVf-0004BU-Rq; Wed, 30 Sep 2020 17:03:20 +0000 Received: from hirez.programming.kicks-ass.net (hirez.programming.kicks-ass.net [192.168.1.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by noisy.programming.kicks-ass.net (Postfix) with ESMTPS id 17B9B301179; Wed, 30 Sep 2020 19:03:17 +0200 (CEST) Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id 02B4A20115B0E; Wed, 30 Sep 2020 19:03:16 +0200 (CEST) Date: Wed, 30 Sep 2020 19:03:16 +0200 From: Peter Zijlstra To: Thomas Gleixner Cc: Lukas Bulwahn , Balbir Singh , 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() Message-ID: <20200930170316.GB2628@hirez.programming.kicks-ass.net> References: <20200928124457.27289-1-lukas.bulwahn@gmail.com> <20200929071211.GJ2628@hirez.programming.kicks-ass.net> <20200929083709.GC2651@hirez.programming.kicks-ass.net> <87eemji887.fsf@nanos.tec.linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87eemji887.fsf@nanos.tec.linutronix.de> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Sep 30, 2020 at 05:40:08PM +0200, Thomas Gleixner wrote: > On Tue, Sep 29 2020 at 10:37, Peter Zijlstra wrote: > > Here, I fixed it.. > > Well, no. What Balbir is trying to do here is to establish whether a > task runs on a !SMT core. sched_smt_active() is system wide, but their > setup is to have a bunch of SMT enabled cores and cores where SMT is off > because the sibling is offlined. They affine these processes to non SMT > cores and the check there validates that before it enabled that flush > thingy. Yes, I see that it does that. But it's still complete shit. > Of course this is best effort voodoo because if all CPUs in the mask are > offlined then the task is moved to a SMT enabled one where L1D flush is > useless. Though offlining their workhorse CPUs is probably not the daily > business for obvious raisins. Not only hotplug, you can trivially change the affinity after this check. Also, that preempt_disable() in there doesn't actually do anything. Worse, preempt_disable(); for_each_cpu(); is an anti-pattern. It mixes static_cpu_has() and boot_cpu_has() in the same bloody condition and has a pointless ret variable. It's shoddy code, that only works if you align the planets right. We really shouldn't provide interfaces that are this bad. It's correct operation is only by accident.