[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAADnVQKAFfOKWe+rdvaM=sKp229Kn14jj=K6+8oybw5m2Mh-RQ@mail.gmail.com>
Date: Thu, 3 Apr 2025 13:33:01 -0700
From: Alexei Starovoitov <alexei.starovoitov@...il.com>
To: Luis Gerhorst <luis.gerhorst@....de>
Cc: Alexei Starovoitov <ast@...nel.org>, Daniel Borkmann <daniel@...earbox.net>,
Andrii Nakryiko <andrii@...nel.org>, Martin KaFai Lau <martin.lau@...ux.dev>,
Eduard Zingerman <eddyz87@...il.com>, Song Liu <song@...nel.org>,
Yonghong Song <yonghong.song@...ux.dev>, John Fastabend <john.fastabend@...il.com>,
KP Singh <kpsingh@...nel.org>, Stanislav Fomichev <sdf@...ichev.me>, Hao Luo <haoluo@...gle.com>,
Jiri Olsa <jolsa@...nel.org>, Puranjay Mohan <puranjay@...nel.org>,
Xu Kuohai <xukuohai@...weicloud.com>, Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will@...nel.org>, Hari Bathini <hbathini@...ux.ibm.com>,
Christophe Leroy <christophe.leroy@...roup.eu>, Naveen N Rao <naveen@...nel.org>,
Madhavan Srinivasan <maddy@...ux.ibm.com>, Michael Ellerman <mpe@...erman.id.au>,
Nicholas Piggin <npiggin@...il.com>, Mykola Lysenko <mykolal@...com>, Shuah Khan <shuah@...nel.org>,
Henriette Herzog <henriette.herzog@....de>, Cupertino Miranda <cupertino.miranda@...cle.com>,
Matan Shachnai <m.shachnai@...il.com>, Dimitar Kanaliev <dimitar.kanaliev@...eground.com>,
Shung-Hsi Yu <shung-hsi.yu@...e.com>, Daniel Xu <dxu@...uu.xyz>, bpf <bpf@...r.kernel.org>,
linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>, LKML <linux-kernel@...r.kernel.org>,
ppc-dev <linuxppc-dev@...ts.ozlabs.org>,
"open list:KERNEL SELFTEST FRAMEWORK" <linux-kselftest@...r.kernel.org>, George Guo <guodongtai@...inos.cn>,
WANG Xuerui <git@...0n.name>, Tiezhu Yang <yangtiezhu@...ngson.cn>, Maximilian Ott <ott@...fau.de>,
Milan Stephan <milan.stephan@....de>
Subject: Re: [PATCH bpf-next 11/11] bpf: Fall back to nospec for spec path verification
On Wed, Mar 19, 2025 at 2:06 AM Luis Gerhorst <luis.gerhorst@....de> wrote:
>
> Thank you very much for having a look. Let me know whether the above
> resolves your concern.
>
> In any case, should I separate patches 1-3 into another series?
Sorry for the delay. lsfmm was followed by the busy merge window.
Please rebase and repost the patches with the detailed
explanation of how lfence works internally and it affects on
the algorithm.
I mistakenly thought that lfence is a load fence only.
That it forces all prior loads to complete, but not the other insns.
Since it's an absolute speculation barrier the algorithm appears sound.
My only remaining reservation is a heuristic in this patch.
If we don't do it, we wouldn't have to special case push_stack() too,
right?
Let's continue discussion in the new thread.
Powered by blists - more mailing lists