On Mon, Nov 23, 2020 at 10:50:04PM -0800, Alexei Starovoitov wrote: > On Mon, Nov 23, 2020 at 05:31:58PM +0000, Brendan Jackman wrote: > > A subsequent patch will add additional atomic operations. These new > > operations will use the same opcode field as the existing XADD, with > > the immediate discriminating different operations. > > > > In preparation, rename the instruction mode BPF_ATOMIC and start > > calling the zero immediate BPF_ADD. > > > > This is possible (doesn't break existing valid BPF progs) because the > > immediate field is currently reserved MBZ and BPF_ADD is zero. > > > > All uses are removed from the tree but the BPF_XADD definition is > > kept around to avoid breaking builds for people including kernel > > headers. > > > > Signed-off-by: Brendan Jackman <jackmanb@xxxxxxxxxx> > > --- > > Documentation/networking/filter.rst | 27 +++++++++------- > > arch/arm/net/bpf_jit_32.c | 7 ++--- > > arch/arm64/net/bpf_jit_comp.c | 16 +++++++--- > > arch/mips/net/ebpf_jit.c | 11 +++++-- > > arch/powerpc/net/bpf_jit_comp64.c | 25 ++++++++++++--- > > arch/riscv/net/bpf_jit_comp32.c | 20 +++++++++--- > > arch/riscv/net/bpf_jit_comp64.c | 16 +++++++--- > > arch/s390/net/bpf_jit_comp.c | 26 +++++++++------- > > arch/sparc/net/bpf_jit_comp_64.c | 14 +++++++-- > > arch/x86/net/bpf_jit_comp.c | 30 +++++++++++------- > > arch/x86/net/bpf_jit_comp32.c | 6 ++-- > > I think this massive rename is not needed. > BPF_XADD is uapi and won't be removed. > Updating documentation, samples and tests is probably enough. Ack, will tone down my agression against BPF_XADD! However the majority of these changes are to various JITs, which do need to be updated, since they need to check for nonzero immediate fields. Do you think I should keep the renames where we're touching the code anyway?
