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

On Wed Aug 5, 2026 at 9:00 AM CEST, Ning Ding wrote:
>> > 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.
>

Sounds plausible. Once you have a fix and test that triggers bad pruning
behavior reliably, please send it as a patch set.

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