[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YW/GctbsXgvM+YsQ@hirez.programming.kicks-ass.net>
Date: Wed, 20 Oct 2021 09:34:10 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Josh Poimboeuf <jpoimboe@...hat.com>
Cc: x86@...nel.org, andrew.cooper3@...rix.com,
linux-kernel@...r.kernel.org, alexei.starovoitov@...il.com,
ndesaulniers@...gle.com
Subject: Re: [PATCH 9/9] bpf,x86: Respect X86_FEATURE_RETPOLINE*
On Thu, Oct 14, 2021 at 11:46:11AM +0200, Peter Zijlstra wrote:
> On Wed, Oct 13, 2021 at 11:54:51PM +0200, Peter Zijlstra wrote:
>
> > > But the rest of eBPF JIT just emits retpolines unconditionally
> > > regardless of feature, for example see RETPOLINE_RCX_BPF_JIT(). So I'm
> > > thinking this should probably be consistent with that (or that with
> > > this).
> >
> > Argh, I grepped for __x86_indirect_thunk, and missed they're writing
> > retpolines themselves. Bah.
> >
> > Yes, that needs cleaning up. I'll go prod at that tomorrow.
>
> Bah, i've too much of a head-ache to make sense of that bpf jit code :-(
>
> Alexei, emit_fallback_jump() uses emit_jump() and provides @prog as .ip
> argument, but other sites do weird things like 'image + addrs[i]',
> presumable because @prog points to an on-stack array instead of to the
> actual text location.
>
> Also @prog is confusingly sometimes a struct bpf_prog* and sometimes a
> u8* which makes grepping really confusing.
>
> I've ended up with the below.. which is known broken-crap for 32, but is
> likely simlar for 64bit as well :-( Can you please have a look?
OK, I've got a working version (thanks to Josh for finding my
brain-fart)! I'll go repost the series soon.
Powered by blists - more mailing lists