[PATCH v4] bpf: Fix smp_processor_id() call trace for preemptible kernels

[PATCH v4] bpf: Fix smp_processor_id() call trace for preemptible kernels

[Edward Adam Davis]

bpf_mem_cache_free_rcu() maybe called in preemptible context, this
will trigger the below warning message:

BUG: using smp_processor_id() in preemptible [00000000] code: syz.0.17/5820
caller is bpf_mem_cache_free_rcu+0x48/0xc0 kernel/bpf/memalloc.c:954
Call Trace:
 check_preemption_disabled+0xd3/0xe0 lib/smp_processor_id.c:47
 bpf_mem_cache_free_rcu+0x48/0xc0 kernel/bpf/memalloc.c:954
 rhtab_delete_elem+0x185a/0x1b30 kernel/bpf/hashtab.c:2969
 __rhtab_map_lookup_and_delete_batch+0x935/0xcb0 kernel/bpf/hashtab.c:3349
 bpf_map_do_batch+0x445/0x630 kernel/bpf/syscall.c:-1
 __sys_bpf+0x906/0xd90 kernel/bpf/syscall.c:-1

this_cpu_ptr() access needs to be guarded against migration.
Wrapping this batch operation in bpf_disable_instrumentation() risk
blinding BPF tracing globally on the CPU if preemption occurs.

bpf_disable_instrumentation() increments the per-CPU bpf_prog_active counter.
Because migrate_disable() and rcu_read_lock() do not disable preemption under
CONFIG_PREEMPT_RCU, the task can be preempted during this potentially long
loop.

If preempted, bpf_prog_active would remain elevated on that CPU, which could
cause subsequent tasks scheduled on the same CPU to silently drop BPF tracing
events (kprobes, tracepoints, perf).

Therefore, we fix this by disabling preemption rather than prohibiting
migration.

Fixes: 5af6807bdb10 ("bpf: Introduce bpf_mem_free_rcu() similar to kfree_rcu().")
Reported-by: syzbot+fd7e415d891073b83e1f@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=fd7e415d891073b83e1f
Signed-off-by: Edward Adam Davis <eadavis@qq.com>
---
v1 -> v2: using guard against preemption
v2 -> v3: replace get/put_cpu() to bpf_disable/enable_instrumentation()
v3 -> v4: disable preempt to make this_cpu_ptr() work

 kernel/bpf/hashtab.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/kernel/bpf/hashtab.c b/kernel/bpf/hashtab.c
index 9f394e1aa2e8..7b98c2eea685 100644
--- a/kernel/bpf/hashtab.c
+++ b/kernel/bpf/hashtab.c
@@ -3345,8 +3345,10 @@ static int __rhtab_map_lookup_and_delete_batch(struct bpf_map *map,
 	}
 
 	if (do_delete) {
+		get_cpu();
 		for (i = 0; i < total; i++)
 			rhtab_delete_elem(rhtab, del_elems[i], NULL, 0);
+		put_cpu();
 	}
 
 	rcu_read_unlock();
-- 
2.43.0

Re: [PATCH v4] bpf: Fix smp_processor_id() call trace for preemptible kernels

[bot+bpf-ci]

[-- Attachment #1: Type: text/plain, Size: 3946 bytes --]

> bpf: Fix smp_processor_id() call trace for preemptible kernels
>
> bpf_mem_cache_free_rcu() maybe called in preemptible context, this
> will trigger the below warning message:
>
> BUG: using smp_processor_id() in preemptible [00000000] code: syz.0.17/5820
> caller is bpf_mem_cache_free_rcu+0x48/0xc0 kernel/bpf/memalloc.c:954
> Call Trace:
>  check_preemption_disabled+0xd3/0xe0 lib/smp_processor_id.c:47
>  bpf_mem_cache_free_rcu+0x48/0xc0 kernel/bpf/memalloc.c:954
>  rhtab_delete_elem+0x185a/0x1b30 kernel/bpf/hashtab.c:2969
>  __rhtab_map_lookup_and_delete_batch+0x935/0xcb0 kernel/bpf/hashtab.c:3349
>  bpf_map_do_batch+0x445/0x630 kernel/bpf/syscall.c:-1
>  __sys_bpf+0x906/0xd90 kernel/bpf/syscall.c:-1
>
> this_cpu_ptr() access needs to be guarded against migration.

The commit message says "guarded against migration" but the fix actually
disables preemption using get_cpu()/put_cpu(). Is this description accurate?

get_cpu() does preempt_disable() + __smp_processor_id(), not just
migrate_disable(). The later sentence "disabling preemption rather than
prohibiting migration" correctly describes the fix, but this earlier line
understates the requirement.

> Wrapping this batch operation in bpf_disable_instrumentation() risk
> blinding BPF tracing globally on the CPU if preemption occurs.
>
> bpf_disable_instrumentation() increments the per-CPU bpf_prog_active counter.
> Because migrate_disable() and rcu_read_lock() do not disable preemption under
> CONFIG_PREEMPT_RCU, the task can be preempted during this potentially long
> loop.
>
> If preempted, bpf_prog_active would remain elevated on that CPU, which could
> cause subsequent tasks scheduled on the same CPU to silently drop BPF tracing
> events (kprobes, tracepoints, perf).

The reasoning about bpf_disable_instrumentation() is sound, but could the
commit message clarify that rhtab_delete_elem() already calls
bpf_disable_instrumentation() internally?

Looking at rhtab_delete_elem():

kernel/bpf/hashtab.c:rhtab_delete_elem() {
    ...
    bpf_disable_instrumentation();
    ret = rhashtable_remove_fast(&rhtab->table, &elem->htab_node,
                                  rhtab->rhtable_params);
    bpf_enable_instrumentation();
    ...
}

This means the same "blinding BPF tracing" window already exists in the
per-element path. The argument is against a longer-held instrumentation
disable across the entire loop, not a categorical concern.

> Therefore, we fix this by disabling preemption rather than prohibiting
> migration.
>
> Fixes: 5af6807bdb10 ("bpf: Introduce bpf_mem_free_rcu() similar to kfree_rcu().")

Should the Fixes tag point to a different commit? The bug occurs when
__rhtab_map_lookup_and_delete_batch() calls rhtab_delete_elem() which calls
bpf_mem_cache_free_rcu() in preemptible context.

Commit 5af6807bdb10 introduced bpf_mem_free_rcu() in 2023 but did not modify
kernel/bpf/hashtab.c or introduce the rhtab code. The call chain was
introduced by:

  Fixes: 6905f8601298 ("bpf: Allow special fields in resizable hashtab")

which added the rhtab implementation including __rhtab_map_lookup_and_delete_batch()
and the call to bpf_mem_cache_free_rcu() in rhtab_delete_elem().

> Reported-by: syzbot+fd7e415d891073b83e1f@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=fd7e415d891073b83e1f
> Signed-off-by: Edward Adam Davis <eadavis@qq.com>

[ ... ]

> diff --git a/kernel/bpf/hashtab.c b/kernel/bpf/hashtab.c
> --- a/kernel/bpf/hashtab.c
> +++ b/kernel/bpf/hashtab.c
> @@ -3345,8 +3345,10 @@
>  	}
>
>  	if (do_delete) {
> +		get_cpu();
>  		for (i = 0; i < total; i++)
>  			rhtab_delete_elem(rhtab, del_elems[i], NULL, 0);
> +		put_cpu();
>  	}
>
>  	rcu_read_unlock();

---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md

CI run summary: https://github.com/kernel-patches/bpf/actions/runs/28451219226

[PATCH v5] bpf: Fix smp_processor_id() call trace for preemptible kernels

[Edward Adam Davis]

bpf_mem_cache_free_rcu() maybe called in preemptible context, this
will trigger the below warning message:

BUG: using smp_processor_id() in preemptible [00000000] code: syz.0.17/5820
caller is bpf_mem_cache_free_rcu+0x48/0xc0 kernel/bpf/memalloc.c:954
Call Trace:
 check_preemption_disabled+0xd3/0xe0 lib/smp_processor_id.c:47
 bpf_mem_cache_free_rcu+0x48/0xc0 kernel/bpf/memalloc.c:954
 rhtab_delete_elem+0x185a/0x1b30 kernel/bpf/hashtab.c:2969
 __rhtab_map_lookup_and_delete_batch+0x935/0xcb0 kernel/bpf/hashtab.c:3349
 bpf_map_do_batch+0x445/0x630 kernel/bpf/syscall.c:-1
 __sys_bpf+0x906/0xd90 kernel/bpf/syscall.c:-1

this_cpu_ptr() requires the caller to prevent task migration.
These helpers currently do not enforce that requirement and may
be invoked from preemptible contexts, leading to accesses to another
CPU's per-CPU cache after migration. Use get_cpu_ptr()/put_cpu_ptr()
to pin the task while accessing the per-CPU allocator state.

Fixes: 5af6807bdb10 ("bpf: Introduce bpf_mem_free_rcu() similar to kfree_rcu().")
Fixes: 7c8199e24fa0 ("bpf: Introduce any context BPF specific memory allocator.")
Reported-by: syzbot+fd7e415d891073b83e1f@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=fd7e415d891073b83e1f
Signed-off-by: Edward Adam Davis <eadavis@qq.com>
---
v1 -> v2: using guard against preemption
v2 -> v3: replace get/put_cpu() to bpf_disable/enable_instrumentation()
v3 -> v4: disable preempt to make this_cpu_ptr() work
v4 -> v5: in mem free disable preemption

 kernel/bpf/memalloc.c | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/kernel/bpf/memalloc.c b/kernel/bpf/memalloc.c
index e9662db7198f..2118fe725ed4 100644
--- a/kernel/bpf/memalloc.c
+++ b/kernel/bpf/memalloc.c
@@ -911,7 +911,8 @@ void notrace bpf_mem_free(struct bpf_mem_alloc *ma, void *ptr)
 	if (WARN_ON_ONCE(idx < 0))
 		return;
 
-	unit_free(this_cpu_ptr(ma->caches)->cache + idx, ptr);
+	unit_free(get_cpu_ptr(ma->caches)->cache + idx, ptr);
+	put_cpu_ptr(ma->caches);
 }
 
 void notrace bpf_mem_free_rcu(struct bpf_mem_alloc *ma, void *ptr)
@@ -927,7 +928,8 @@ void notrace bpf_mem_free_rcu(struct bpf_mem_alloc *ma, void *ptr)
 	if (WARN_ON_ONCE(idx < 0))
 		return;
 
-	unit_free_rcu(this_cpu_ptr(ma->caches)->cache + idx, ptr);
+	unit_free_rcu(get_cpu_ptr(ma->caches)->cache + idx, ptr);
+	put_cpu_ptr(ma->caches);
 }
 
 void notrace *bpf_mem_cache_alloc(struct bpf_mem_alloc *ma)
@@ -951,7 +953,8 @@ void notrace bpf_mem_cache_free_rcu(struct bpf_mem_alloc *ma, void *ptr)
 	if (!ptr)
 		return;
 
-	unit_free_rcu(this_cpu_ptr(ma->cache), ptr);
+	unit_free_rcu(get_cpu_ptr(ma->cache), ptr);
+	put_cpu_ptr(ma->cache);
 }
 
 /* Directly does a kfree() without putting 'ptr' back to the free_llist
-- 
2.43.0

Re: [PATCH v5] bpf: Fix smp_processor_id() call trace for preemptible kernels

[Andrii Nakryiko]

On Tue, Jun 30, 2026 at 5:27 PM Edward Adam Davis <eadavis@qq.com> wrote:
>
> bpf_mem_cache_free_rcu() maybe called in preemptible context, this
> will trigger the below warning message:
>
> BUG: using smp_processor_id() in preemptible [00000000] code: syz.0.17/5820
> caller is bpf_mem_cache_free_rcu+0x48/0xc0 kernel/bpf/memalloc.c:954
> Call Trace:
>  check_preemption_disabled+0xd3/0xe0 lib/smp_processor_id.c:47
>  bpf_mem_cache_free_rcu+0x48/0xc0 kernel/bpf/memalloc.c:954
>  rhtab_delete_elem+0x185a/0x1b30 kernel/bpf/hashtab.c:2969
>  __rhtab_map_lookup_and_delete_batch+0x935/0xcb0 kernel/bpf/hashtab.c:3349
>  bpf_map_do_batch+0x445/0x630 kernel/bpf/syscall.c:-1
>  __sys_bpf+0x906/0xd90 kernel/bpf/syscall.c:-1
>
> this_cpu_ptr() requires the caller to prevent task migration.
> These helpers currently do not enforce that requirement and may
> be invoked from preemptible contexts, leading to accesses to another
> CPU's per-CPU cache after migration. Use get_cpu_ptr()/put_cpu_ptr()
> to pin the task while accessing the per-CPU allocator state.
>
> Fixes: 5af6807bdb10 ("bpf: Introduce bpf_mem_free_rcu() similar to kfree_rcu().")
> Fixes: 7c8199e24fa0 ("bpf: Introduce any context BPF specific memory allocator.")
> Reported-by: syzbot+fd7e415d891073b83e1f@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=fd7e415d891073b83e1f
> Signed-off-by: Edward Adam Davis <eadavis@qq.com>
> ---

from what I can see, bpf_mem_free() is called through bpf kfuncs only,
and all BPF programs run with migration disabled. So this seems like a
false positive. For per-cpu checking, it should probably check that
either preemption is disabled or migration is disabled. tl;dr, there
doesn't seem to be any

pw-bot: cr

> v1 -> v2: using guard against preemption
> v2 -> v3: replace get/put_cpu() to bpf_disable/enable_instrumentation()
> v3 -> v4: disable preempt to make this_cpu_ptr() work
> v4 -> v5: in mem free disable preemption
>

maybe throttle your patch resubmission spree a bit?..

Re: [PATCH v5] bpf: Fix smp_processor_id() call trace for preemptible kernels

[Edward Adam Davis]

On Wed, 1 Jul 2026 12:57:52 -0700, Andrii Nakryiko wrote:
> > bpf_mem_cache_free_rcu() maybe called in preemptible context, this
> > will trigger the below warning message:
> >
> > BUG: using smp_processor_id() in preemptible [00000000] code: syz.0.17/5820
> > caller is bpf_mem_cache_free_rcu+0x48/0xc0 kernel/bpf/memalloc.c:954
> > Call Trace:
> >  check_preemption_disabled+0xd3/0xe0 lib/smp_processor_id.c:47
> >  bpf_mem_cache_free_rcu+0x48/0xc0 kernel/bpf/memalloc.c:954
> >  rhtab_delete_elem+0x185a/0x1b30 kernel/bpf/hashtab.c:2969
> >  __rhtab_map_lookup_and_delete_batch+0x935/0xcb0 kernel/bpf/hashtab.c:3349
> >  bpf_map_do_batch+0x445/0x630 kernel/bpf/syscall.c:-1
> >  __sys_bpf+0x906/0xd90 kernel/bpf/syscall.c:-1
> >
> > this_cpu_ptr() requires the caller to prevent task migration.
> > These helpers currently do not enforce that requirement and may
> > be invoked from preemptible contexts, leading to accesses to another
> > CPU's per-CPU cache after migration. Use get_cpu_ptr()/put_cpu_ptr()
> > to pin the task while accessing the per-CPU allocator state.
> >
> > Fixes: 5af6807bdb10 ("bpf: Introduce bpf_mem_free_rcu() similar to kfree_rcu().")
> > Fixes: 7c8199e24fa0 ("bpf: Introduce any context BPF specific memory allocator.")
> > Reported-by: syzbot+fd7e415d891073b83e1f@syzkaller.appspotmail.com
> > Closes: https://syzkaller.appspot.com/bug?extid=fd7e415d891073b83e1f
> > Signed-off-by: Edward Adam Davis <eadavis@qq.com>
> > ---
> 
> from what I can see, bpf_mem_free() is called through bpf kfuncs only,
> and all BPF programs run with migration disabled. So this seems like a
> false positive. For per-cpu checking, it should probably check that
> either preemption is disabled or migration is disabled. tl;dr, there
> doesn't seem to be any
Today, I researched the call sites of bpf_mem_free() in detail; it is
called directly by bpf kfuns only. 

Different BPF program types execute in distinct kernel contexts: for
instance, XDP and TC typically run in non-sleepable networking contexts,
whereas `raw_tp`, `tracing`, `LSM`, `syscall` and especially sleepable
BPF programs may run in contexts where preemption and migration are
enabled. Consequently, any shared BPF code (such as a helper or kfunc)
that accesses per-CPU data must not rely on the caller having disabled
migration; instead, it must internally ensure that CPU migration does
not occur during the access.

Taking into account the CI reviewer's feedback [1] and my further
investigation into BPF programs as described above, the adjustments
related to bpf_mem_free() should be retained.

[1]
https://lore.kernel.org/all/20260630094823.897BD1F00A3D@smtp.kernel.org
> 
> pw-bot: cr
> 
> > v1 -> v2: using guard against preemption
> > v2 -> v3: replace get/put_cpu() to bpf_disable/enable_instrumentation()
> > v3 -> v4: disable preempt to make this_cpu_ptr() work
> > v4 -> v5: in mem free disable preemption
> >
> 
> maybe throttle your patch resubmission spree a bit?..
My earlier actions were driven by a desire to keep pace with the CI
reviewer's response speed.
Moving forward, I will slow down the cadence of new patch submissions,
as you suggested.

Re: [PATCH v5] bpf: Fix smp_processor_id() call trace for preemptible kernels

[Alexei Starovoitov]

On Wed, Jul 1, 2026 at 9:35 PM Edward Adam Davis <eadavis@qq.com> wrote:
>
> On Wed, 1 Jul 2026 12:57:52 -0700, Andrii Nakryiko wrote:
> > > bpf_mem_cache_free_rcu() maybe called in preemptible context, this
> > > will trigger the below warning message:
> > >
> > > BUG: using smp_processor_id() in preemptible [00000000] code: syz.0.17/5820
> > > caller is bpf_mem_cache_free_rcu+0x48/0xc0 kernel/bpf/memalloc.c:954
> > > Call Trace:
> > >  check_preemption_disabled+0xd3/0xe0 lib/smp_processor_id.c:47
> > >  bpf_mem_cache_free_rcu+0x48/0xc0 kernel/bpf/memalloc.c:954
> > >  rhtab_delete_elem+0x185a/0x1b30 kernel/bpf/hashtab.c:2969
> > >  __rhtab_map_lookup_and_delete_batch+0x935/0xcb0 kernel/bpf/hashtab.c:3349
> > >  bpf_map_do_batch+0x445/0x630 kernel/bpf/syscall.c:-1
> > >  __sys_bpf+0x906/0xd90 kernel/bpf/syscall.c:-1
> > >
> > > this_cpu_ptr() requires the caller to prevent task migration.
> > > These helpers currently do not enforce that requirement and may
> > > be invoked from preemptible contexts, leading to accesses to another
> > > CPU's per-CPU cache after migration. Use get_cpu_ptr()/put_cpu_ptr()
> > > to pin the task while accessing the per-CPU allocator state.
> > >
> > > Fixes: 5af6807bdb10 ("bpf: Introduce bpf_mem_free_rcu() similar to kfree_rcu().")
> > > Fixes: 7c8199e24fa0 ("bpf: Introduce any context BPF specific memory allocator.")
> > > Reported-by: syzbot+fd7e415d891073b83e1f@syzkaller.appspotmail.com
> > > Closes: https://syzkaller.appspot.com/bug?extid=fd7e415d891073b83e1f
> > > Signed-off-by: Edward Adam Davis <eadavis@qq.com>
> > > ---
> >
> > from what I can see, bpf_mem_free() is called through bpf kfuncs only,
> > and all BPF programs run with migration disabled. So this seems like a
> > false positive. For per-cpu checking, it should probably check that
> > either preemption is disabled or migration is disabled. tl;dr, there
> > doesn't seem to be any
> Today, I researched the call sites of bpf_mem_free() in detail; it is
> called directly by bpf kfuns only.
>
> Different BPF program types execute in distinct kernel contexts: for
> instance, XDP and TC typically run in non-sleepable networking contexts,
> whereas `raw_tp`, `tracing`, `LSM`, `syscall` and especially sleepable
> BPF programs may run in contexts where preemption and migration are
> enabled. Consequently, any shared BPF code (such as a helper or kfunc)
> that accesses per-CPU data must not rely on the caller having disabled
> migration; instead, it must internally ensure that CPU migration does
> not occur during the access.
>
> Taking into account the CI reviewer's feedback [1] and my further
> investigation into BPF programs as described above, the adjustments
> related to bpf_mem_free() should be retained.
>
> [1]
> https://lore.kernel.org/all/20260630094823.897BD1F00A3D@smtp.kernel.org
> >
> > pw-bot: cr
> >
> > > v1 -> v2: using guard against preemption
> > > v2 -> v3: replace get/put_cpu() to bpf_disable/enable_instrumentation()
> > > v3 -> v4: disable preempt to make this_cpu_ptr() work
> > > v4 -> v5: in mem free disable preemption
> > >
> >
> > maybe throttle your patch resubmission spree a bit?..
> My earlier actions were driven by a desire to keep pace with the CI
> reviewer's response speed.
> Moving forward, I will slow down the cadence of new patch submissions,
> as you suggested.

Don't bother. You don't sound like a human.
Bots are not welcomed here.