Messages in this thread | | | Subject | Re: [PATCH bpf-next v3 10/14] bpf: Add bitwise atomic instructions | From | Yonghong Song <> | Date | Fri, 4 Dec 2020 07:21:22 -0800 |
| |
On 12/4/20 1:36 AM, Brendan Jackman wrote: > 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 <jackmanb@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.
BPF_ATOMIC_ALU and BPF_ATOMIC_FETCH_ALU indeed better.
>
| |