On Thu, Dec 03, 2020 at 10:42:19PM -0800, Yonghong Song wrote:
>
>
> On 12/3/20 8:02 AM, Brendan Jackman wrote:
> > This adds instructions for
> >
> > atomic[64]_[fetch_]and
> > atomic[64]_[fetch_]or
> > atomic[64]_[fetch_]xor
> >
> > All these operations are isomorphic enough to implement with the same
> > verifier, interpreter, and x86 JIT code, hence being a single commit.
> >
> > The main interesting thing here is that x86 doesn't directly support
> > the fetch_ version these operations, so we need to generate a CMPXCHG
> > loop in the JIT. This requires the use of two temporary registers,
> > IIUC it's safe to use BPF_REG_AX and x86's AUX_REG for this purpose.
> >
> > Change-Id: I340b10cecebea8cb8a52e3606010cde547a10ed4
> > Signed-off-by: Brendan Jackman <jackm...@google.com>
> > ---
> > arch/x86/net/bpf_jit_comp.c | 50 +++++++++++++++++++++++++++++-
> > include/linux/filter.h | 60 ++++++++++++++++++++++++++++++++++++
> > kernel/bpf/core.c | 5 ++-
> > kernel/bpf/disasm.c | 21 ++++++++++---
> > kernel/bpf/verifier.c | 6 ++++
> > tools/include/linux/filter.h | 60 ++++++++++++++++++++++++++++++++++++
> > 6 files changed, 196 insertions(+), 6 deletions(-)
> >
[...]
> > diff --git a/include/linux/filter.h b/include/linux/filter.h
> > index 6186280715ed..698f82897b0d 100644
> > --- a/include/linux/filter.h
> > +++ b/include/linux/filter.h
> > @@ -280,6 +280,66 @@ static inline bool insn_is_zext(const struct bpf_insn
> > *insn)
[...]
> > +#define BPF_ATOMIC_FETCH_XOR(SIZE, DST, SRC, OFF) \
> > + ((struct bpf_insn) { \
> > + .code = BPF_STX | BPF_SIZE(SIZE) | BPF_ATOMIC, \
> > + .dst_reg = DST, \
> > + .src_reg = SRC, \
> > + .off = OFF, \
> > + .imm = BPF_XOR | BPF_FETCH })
> > +
> > /* Atomic exchange, src_reg = atomic_xchg((dst_reg + off), src_reg) */
>
> Looks like BPF_ATOMIC_XOR/OR/AND/... all similar to each other.
> The same is for BPF_ATOMIC_FETCH_XOR/OR/AND/...
>
> I am wondering whether it makes sence to have to
> BPF_ATOMIC_BOP(BOP, SIZE, DST, SRC, OFF) and
> BPF_ATOMIC_FETCH_BOP(BOP, SIZE, DST, SRC, OFF)
> can have less number of macros?
Hmm yeah I think that's probably a good idea, it would be consistent
with the macros for non-atomic ALU ops.
I don't think 'BOP' would be very clear though, 'ALU' might be more
obvious.
