linux-stable.git/tools/include/linux/filter.h, branch v7.2.6

tools: Ensure tools copy of linux/filter.h exports the UAPI

2026-09-14T11:40:24+00:00

[ Upstream commit 7a1f400ff5e57f41e23c8145a54ea084039b023c ]

Normally when there is an include/foo.h and an include/uapi/foo.h the
non-UAPI copy includes the UAPI copy.  This is the case for the in
kernel copy of linux/filter.h but not for the copy in tools/ which
results in build breaks for the newly added arm64
seccomp_ptrace_x0_bypass selftest.  Add an explicit include of the uapi
to fix the test and avoid future surprises.

Fixes: 2fcbc4adf997 ("kselftest/arm64: Add seccomp ptrace x0 bypass test")
Fixes: f143c11bb7b9 ("tools: bpf: Use local copy of headers including uapi/linux/filter.h")
Signed-off-by: Mark Brown 
Signed-off-by: Will Deacon 
Signed-off-by: Sasha Levin

bpftool: Probe for ISA v4 instruction set extension

2024-12-12T16:25:17+00:00

This patch introduces a new probe to check whether the kernel supports
instruction set extensions v4. The v4 extension comprises several new
instructions: BPF_{SDIV,SMOD} (signed div and mod), BPF_{LD,LDX,ST,STX,MOV}
(sign-extended load/store/move), 32-bit BPF_JA (unconditional jump),
target-independent BPF_ALU64 BSWAP (byte-swapping 16/32/64).

These have been introduced in the following commits respectively:

* ec0e2da95f72 ("bpf: Support new signed div/mod instructions.")
* 1f9a1ea821ff ("bpf: Support new sign-extension load insns")
* 8100928c8814 ("bpf: Support new sign-extension mov insns")
* 4cd58e9af8b9 ("bpf: Support new 32bit offset jmp instruction")
* 0845c3db7bf5 ("bpf: Support new unconditional bswap instruction")

Support in bpftool for previous ISA extensions was added in commit
0fd800b2456c ("bpftool: Probe for instruction set extensions"). These
probes are useful for userspace BPF projects that want to use newer
instruction set extensions on newer kernels, to reduce the programs'
sizes or their complexity.

LLVM provides the mcpu=v4 option since LLVM commit 8f28e8069c4b ("[BPF]
support for BPF_ST instruction in codegen") [0].

Signed-off-by: Simone Magnani 
Signed-off-by: Daniel Borkmann 
Reviewed-by: Quentin Monnet 
Link: https://github.com/llvm/llvm-project/commit/8f28e8069c4ba1110daee8bddc4d5049b6d4646e [0]
Link: https://lore.kernel.org/bpf/20241209145439.336362-1-simone.magnani@isovalent.com

selftests/bpf: add fp-leaking precise subprog result tests

2024-04-05T01:31:08+00:00

Add selftests validating that BPF verifier handles precision marking
for SCALAR registers derived from r10 (fp) register correctly.

Given `r0 = (s8)r10;` syntax is not supported by older Clang compilers,
use the raw BPF instruction syntax to maximize compatibility.

Signed-off-by: Andrii Nakryiko 
Acked-by: Yonghong Song 
Link: https://lore.kernel.org/r/20240404214536.3551295-2-andrii@kernel.org
Signed-off-by: Alexei Starovoitov

bpf: Add bitwise atomic instructions

2021-01-15T02:34:29+00:00

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.

Signed-off-by: Brendan Jackman 
Signed-off-by: Alexei Starovoitov 
Acked-by: Yonghong Song 
Link: https://lore.kernel.org/bpf/20210114181751.768687-10-jackmanb@google.com

bpf: Add instructions for atomic_[cmp]xchg

2021-01-15T02:34:29+00:00

This adds two atomic opcodes, both of which include the BPF_FETCH
flag. XCHG without the BPF_FETCH flag would naturally encode
atomic_set. This is not supported because it would be of limited
value to userspace (it doesn't imply any barriers). CMPXCHG without
BPF_FETCH woulud be an atomic compare-and-write. We don't have such
an operation in the kernel so it isn't provided to BPF either.

There are two significant design decisions made for the CMPXCHG
instruction:

 - To solve the issue that this operation fundamentally has 3
   operands, but we only have two register fields. Therefore the
   operand we compare against (the kernel's API calls it 'old') is
   hard-coded to be R0. x86 has similar design (and A64 doesn't
   have this problem).

   A potential alternative might be to encode the other operand's
   register number in the immediate field.

 - The kernel's atomic_cmpxchg returns the old value, while the C11
   userspace APIs return a boolean indicating the comparison
   result. Which should BPF do? A64 returns the old value. x86 returns
   the old value in the hard-coded register (and also sets a
   flag). That means return-old-value is easier to JIT, so that's
   what we use.

Signed-off-by: Brendan Jackman 
Signed-off-by: Alexei Starovoitov 
Acked-by: Yonghong Song 
Link: https://lore.kernel.org/bpf/20210114181751.768687-8-jackmanb@google.com

bpf: Add BPF_FETCH field / create atomic_fetch_add instruction

2021-01-15T02:34:29+00:00

The BPF_FETCH field can be set in bpf_insn.imm, for BPF_ATOMIC
instructions, in order to have the previous value of the
atomically-modified memory location loaded into the src register
after an atomic op is carried out.

Suggested-by: Yonghong Song 
Signed-off-by: Brendan Jackman 
Signed-off-by: Alexei Starovoitov 
Acked-by: John Fastabend 
Link: https://lore.kernel.org/bpf/20210114181751.768687-7-jackmanb@google.com

bpf: Rename BPF_XADD and prepare to encode other atomics in .imm

2021-01-15T02:34:29+00:00

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 
Signed-off-by: Alexei Starovoitov 
Acked-by: Björn Töpel 
Link: https://lore.kernel.org/bpf/20210114181751.768687-5-jackmanb@google.com

bpf, selftest: test {rd, wr}only flags and direct value access

2019-04-10T00:05:47+00:00

Extend test_verifier with various test cases around the two kernel
extensions, that is, {rd,wr}only map support as well as direct map
value access. All passing, one skipped due to xskmap not present
on test machine:

  # ./test_verifier
  [...]
  #948/p XDP pkt read, pkt_meta' <= pkt_data, bad access 1 OK
  #949/p XDP pkt read, pkt_meta' <= pkt_data, bad access 2 OK
  #950/p XDP pkt read, pkt_data <= pkt_meta', good access OK
  #951/p XDP pkt read, pkt_data <= pkt_meta', bad access 1 OK
  #952/p XDP pkt read, pkt_data <= pkt_meta', bad access 2 OK
  Summary: 1410 PASSED, 1 SKIPPED, 0 FAILED

Signed-off-by: Daniel Borkmann 
Acked-by: Martin KaFai Lau 
Signed-off-by: Alexei Starovoitov

bpf: JIT blinds support JMP32

2019-01-26T21:33:01+00:00

This patch adds JIT blinds support for JMP32.

Like BPF_JMP_REG/IMM, JMP32 version are needed for building raw bpf insn.
They are added to both include/linux/filter.h and
tools/include/linux/filter.h.

Reviewed-by: Jakub Kicinski 
Signed-off-by: Jiong Wang 
Signed-off-by: Alexei Starovoitov

bpf: test case for map pointer poison with calls/branches

2018-06-03T14:42:06+00:00

Add several test cases where the same or different map pointers
originate from different paths in the program and execute a map
lookup or tail call at a common location.

Signed-off-by: Daniel Borkmann 
Acked-by: Alexei Starovoitov 
Acked-by: Song Liu 
Signed-off-by: Alexei Starovoitov