Re: [PATCH bpf-next v5 0/3] bpf, x86: Support fetching AND/OR/XOR atomics in arena

[patchwork-bot+netdevbpf@kernel.org]

Hello:

This series was applied to bpf/bpf-next.git (master)
by Alexei Starovoitov <ast@kernel.org>:

On Fri, 16 Oct 2026 10:13:11 -0700 you wrote:
> Changelog:
> v1: https://lore.kernel.org/all/20260923165301.3463007-1-puranjay@kernel.org/
> v2: https://lore.kernel.org/all/20260924160354.531101-1-puranjay@kernel.org/
> v3: https://lore.kernel.org/all/20260925134828.2012199-2-puranjay@kernel.org/
> v4: https://lore.kernel.org/all/20261014125017.1426212-1-puranjay@kernel.org/
> 
> Changes in v5:
> - Patch 1: support these ops for accesses through a number too, instead of
>   refusing them, per Alexei. BPF_F_ARENA_SCALAR accesses keep their
>   address in BPF_REG_AX, where the loop saves R0, so for those R0 is
>   saved on the stack with push and pop, as the div and mod lowering does.
>   An R0 operand stays in that stack slot: the new value is built from it,
>   RAX ends up holding the old value that R0 is to return, and the slot is
>   dropped instead of popped. Both exception table entries resume before
>   the pop, so a fault leaves the stack balanced. Accesses through an
>   arena pointer are emitted exactly as in v4. The refusal in v4 also hid
>   the reason: programs passed the verifier and then failed to load with
>   ENOTSUPP and an empty log, where the verifier used to say the atomic is
>   not allowed.
> - Patch 2: the fetching and/or/xor tests in verifier_arena_scalar now
>   have to load and pass on x86-64 as well as arm64, at both widths and
>   with the operand in a register and in R0. Two more run a fetching or
>   against a freed page, with the operand in a register and in R0, so that
>   the access faults, and check that the fetched register comes back 0 and
>   that R0 is left alone. The page holds a nonzero value first, so that an
>   access which did not fault would show, and R0 is compared with a value
>   derived from the page address, as a constant comparison would be decided
>   by the verifier and dropped. The 32-bit operands have bits set above 32.
> - Patch 2: read the address back after the faulting access, in both the
>   freed-page tests and uaf. A fault that missed the JIT's exception table
>   entry would be recovered by the arena mapping its zeroed scratch page and
>   the access would succeed, which the checks on the registers alone could
>   not tell apart. uaf now faults on the page after the freed one, as the
>   freed page's 32-bit address is 0 and the address check was empty.
> - Patch 2: skip the uaf register checks on powerpc64, whose JIT does not
>   clear the fetched register of a faulting atomic yet.
> - Rebased.
> 
> [...]

Here is the summary with links:
  - [bpf-next,v5,1/3] bpf, x86: Support fetching AND/OR/XOR atomics in arena
    https://git.kernel.org/bpf/bpf-next/c/d9efbaed7e61
  - [bpf-next,v5,2/3] selftests/bpf: Test fetching AND/OR/XOR atomics in arena
    https://git.kernel.org/bpf/bpf-next/c/9e35f216e5c5
  - [bpf-next,v5,3/3] sched_ext: Use fetching atomics for cmask instead of a cmpxchg loop
    (no matching commit)

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html