On Tue, Nov 24, 2020 at 3:21 AM Brendan Jackman <jackmanb@xxxxxxxxxx> wrote: > > 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? Ahh. The JITs need to check for imm==0 and enotsupp the rest? Right. In such case updating all JITs at once is necessary. I was hoping to avoid touching all of them to minimize the chance of merge conflicts. Looks like it's inevitable. I think it's fine then.
