All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jiayuan Chen <jiayuan.chen@linux.dev>
To: Edward Adam Davis <eadavis@qq.com>, sashiko-bot@kernel.org
Cc: bpf@vger.kernel.org, sashiko-reviews@lists.linux.dev
Subject: Re: [PATCH v2] bpf: Fix smp_processor_id() call trace for preemptible kernels
Date: Tue, 30 Jun 2026 20:25:30 +0800	[thread overview]
Message-ID: <f72ebb75-66e8-47ae-b1f0-e77d6a24f3e0@linux.dev> (raw)
In-Reply-To: <tencent_94C3BFC44F9761376546C493608362896E05@qq.com>


On 6/30/26 7:14 PM, Edward Adam Davis wrote:
> On Tue, 30 Jun 2026 09:48:23 +0000, Sashiko wrote:
>> [Severity: High]
>> Does this fix the issue at the right layer? By adding the preemption
>> protection here, it masks the fact that the caller is running with migration
>> enabled, which leaves sibling APIs vulnerable.
>>
>> For example, in __rhtab_map_lookup_and_delete_batch() in
>> kernel/bpf/hashtab.c, the batch loop iterates and calls rhtab_delete_elem()
>> without disabling migration.
>>
>> If the map elements contain special fields (like BPF_KPTR),
>> rhtab_delete_elem() will first call rhtab_check_and_free_fields(), which
>> eventually calls bpf_mem_free().
>>
>> Since bpf_mem_free() also uses this_cpu_ptr() without get_cpu() protection:
>>
>> kernel/bpf/memalloc.c:bpf_mem_free() {
>>      ...
>>      unit_free(this_cpu_ptr(ma->caches)->cache + idx, ptr);
>>      ...
>> }
>>
>> Will this result in the exact same BUG being triggered on that path? Should
>> the missing migration protection be added to
>> __rhtab_map_lookup_and_delete_batch() instead of modifying the allocator
>> here?
> Like this?
>
> 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();


This splat is specific to rhash...

For HASH/PERCPU_HASH/..., most operations are performed under
bpf_disable_instrumentation(); see __htab_map_lookup_and_delete_batch().

But for rhash, bpf_mem_cache_free_rcu() is called outside the
bpf_disable_instrumentation() region; see 
__rhtab_map_lookup_and_delete_batch().

note: map_lookup_and_delete_batch() disable cpu migration



  reply	other threads:[~2026-06-30 12:25 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-30  6:20 [syzbot] [bpf?] BUG: using smp_processor_id() in preemptible code in bpf_mem_cache_free_rcu syzbot
2026-06-30  8:16 ` Edward Adam Davis
2026-06-30 10:26   ` syzbot
2026-06-30  8:20 ` Edward Adam Davis
2026-06-30 10:54   ` syzbot
2026-06-30  8:41 ` [PATCH] bpf: Fix smp_processor_id() call trace for preemptible kernels Edward Adam Davis
2026-06-30  8:49   ` sashiko-bot
2026-06-30  9:11     ` [PATCH v2] " Edward Adam Davis
2026-06-30  9:48       ` sashiko-bot
2026-06-30 11:14         ` Edward Adam Davis
2026-06-30 12:25           ` Jiayuan Chen [this message]
2026-06-30 12:46             ` Edward Adam Davis
2026-06-30 13:09               ` [PATCH v3] " Edward Adam Davis
2026-06-30 13:22                 ` sashiko-bot
2026-06-30 14:11                   ` [PATCH v4] " Edward Adam Davis
2026-06-30 14:29                     ` sashiko-bot
2026-06-30 14:46                     ` bot+bpf-ci
2026-07-01  0:27                   ` [PATCH v5] " Edward Adam Davis
2026-07-01 19:57                     ` Andrii Nakryiko
2026-07-02  4:34                       ` Edward Adam Davis
2026-07-02  5:40                         ` Alexei Starovoitov
2026-06-30  9:08 ` [syzbot] [bpf?] BUG: using smp_processor_id() in preemptible code in bpf_mem_cache_free_rcu Edward Adam Davis
2026-06-30 11:22   ` syzbot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f72ebb75-66e8-47ae-b1f0-e77d6a24f3e0@linux.dev \
    --to=jiayuan.chen@linux.dev \
    --cc=bpf@vger.kernel.org \
    --cc=eadavis@qq.com \
    --cc=sashiko-bot@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.