From: Peter Zijlstra <peterz@infradead.org>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Lukas Bulwahn <lukas.bulwahn@gmail.com>,
Balbir Singh <sblbir@amazon.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
Andy Lutomirski <luto@kernel.org>, Ingo Molnar <mingo@redhat.com>,
Borislav Petkov <bp@alien8.de>,
x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
Nathan Chancellor <natechancellor@gmail.com>,
Nick Desaulniers <ndesaulniers@google.com>,
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()
Date: Wed, 30 Sep 2020 19:03:16 +0200 [thread overview]
Message-ID: <20200930170316.GB2628@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <87eemji887.fsf@nanos.tec.linutronix.de>
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.
next prev parent reply other threads:[~2020-09-30 17:03 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-28 12:44 [PATCH -next for tip:x86/pti] x86/tlb: drop unneeded local vars in enable_l1d_flush_for_task() Lukas Bulwahn
2020-09-28 20:43 ` Nathan Chancellor
2020-09-29 7:12 ` Peter Zijlstra
2020-09-29 8:33 ` Lukas Bulwahn
2020-09-29 8:37 ` Peter Zijlstra
2020-09-30 15:40 ` Thomas Gleixner
2020-09-30 16:53 ` Lukas Bulwahn
2020-09-30 17:03 ` Peter Zijlstra [this message]
2020-09-30 18:00 ` Thomas Gleixner
2020-09-30 18:35 ` Peter Zijlstra
2020-09-30 21:38 ` Thomas Gleixner
2020-09-30 22:59 ` Singh, Balbir
2020-09-30 23:49 ` Singh, Balbir
2020-10-01 0:48 ` Singh, Balbir
2020-10-01 8:17 ` Thomas Gleixner
2020-10-01 8:19 ` Peter Zijlstra
2020-09-30 22:46 ` Singh, Balbir
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200930170316.GB2628@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=bp@alien8.de \
--cc=clang-built-linux@googlegroups.com \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=kernel-janitors@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-safety@lists.elisa.tech \
--cc=lukas.bulwahn@gmail.com \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=natechancellor@gmail.com \
--cc=ndesaulniers@google.com \
--cc=sblbir@amazon.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox