Re: [PATCH bpf-next v2 0/2] bpf: Invalidate RCU pointers after final spin unlock

Ning Ding <[email protected]> Wed, 5 Aug 2026 00:00:29 -0700
Newsgroups org.kernel.vger.bpf
Message-ID <CAJP4iuthyUKs5wYMpjGLyQKW8syiHm6pub+9rMMo7wsw-w6G+Q@mail.gmail.com>
> > 1. Disabling preemption
> > 2. Disabling bottom halves
> > 3. Disabling interrupts
> > 4. Acquiring a spin lock
> >
> > As you are doing it for 4, can you also do it for 1 and 3? I don't think
> > BPF can disable bottom halves right now.

Hi, I have written the follow-up patch to account for
preemption-disabled and irq-disabled regions. But still working on the
selftests.
While checking rcu gaps, I also found what looks like a separate issue
for state pruning also regarding the MEM_RCU and PTR_UNTRUSTED. A
sample example is:

  bpf_rcu_read_lock();
  bpf_iter_task_new(&it, NULL, BPF_TASK_ITER_ALL_PROCS);

  if (condition) {
  /* Safe: the outer RCU lock remains active. */
  bpf_rcu_read_lock();
  bpf_rcu_read_unlock();
  } else {
  /* Unsafe: protection reaches zero, creating an unguarded gap. */
  bpf_rcu_read_unlock();
  bpf_rcu_read_lock();
  }

  /* Both branches have one active RCU lock here. */
  bpf_iter_task_next(&it);
  bpf_rcu_read_unlock();

But STACK_ITER comparison in stacksafe() does not compare
spilled_ptr.type. So the verifier considers the trusted and untrusted
iterator states are equivalent. It can possibly prune the unsafe path
before is_iter_reg_valid_init() rejects it.

https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/tree/kernel/bpf/states.c?id=6655c409707ec8ce9ce0850ffe4fe02331fd4d9c#n806