From: "Alexei Starovoitov" <alexei.starovoitov@gmail.com>
To: "Ömer Mete Kaya" <omermetekaya0@gmail.com>, daniel@iogearbox.net
Cc: <john.fastabend@gmail.com>, <andrii@kernel.org>,
<eddyz87@gmail.com>, <memxor@gmail.com>, <martin.lau@linux.dev>,
<song@kernel.org>, <yonghong.song@linux.dev>, <jolsa@kernel.org>,
<emil@etsalapatis.com>, <ihor.solodrai@linux.dev>,
<bpf@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<syzbot+fd7e415d891073b83e1f@syzkaller.appspotmail.com>
Subject: Re: [PATCH bpf] bpf: Fix smp_processor_id() warning in rhtab_delete_elem()
Date: Tue, 29 Sep 2026 06:09:44 +0000 [thread overview]
Message-ID: <DLRKRNCH0N6U.2CRAUPOWA8P2D@gmail.com> (raw)
In-Reply-To: <20260928173703.504474-1-omermetekaya0@gmail.com>
On Mon, Sep 28, 2026 at 08:31 PM Ömer Mete Kaya <omermetekaya0@gmail.com> wrote:
> bpf_mem_cache_free_rcu() uses this_cpu_ptr() which requires preemption
> to be disabled. In rhtab_delete_elem(), this call happens after
> bpf_enable_instrumentation(), so preemption is re-enabled at that
> point and this_cpu_ptr() triggers:
bpf_disable_instrumentation() doesn't disable preemption.
It's migrate_disable() plus bpf_prog_active++.
bpf_mem_alloc relies on the callers to disable migration.
See the comment above bpf_mem_alloc().
All callers of rhtab_delete_elem() do that except
__rhtab_map_lookup_and_delete_batch(). That's the bug.
bpf_disable_instrumentation() in rhtab_delete_elem() protects
the bucket lock from NMI progs. rhtab_map_update_elem() calls
bpf_mem_cache_alloc/free() outside of it too.
Don't stretch it. Disable migration in the batch.
> Fixes: 6905f8601298 ("bpf: Allow special fields in resizable hashtab")
Wrong tag. The batch came in
commit 818e00848227 ("bpf: Implement iteration ops for resizable hashtab")
pw-bot: cr
prev parent reply other threads:[~2026-09-29 6:09 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-28 17:31 [PATCH bpf] bpf: Fix smp_processor_id() warning in rhtab_delete_elem() Ömer Mete Kaya
2026-09-28 18:16 ` bot+bpf-ci
2026-09-29 6:09 ` Alexei Starovoitov [this message]
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=DLRKRNCH0N6U.2CRAUPOWA8P2D@gmail.com \
--to=alexei.starovoitov@gmail.com \
--cc=andrii@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=emil@etsalapatis.com \
--cc=ihor.solodrai@linux.dev \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=martin.lau@linux.dev \
--cc=memxor@gmail.com \
--cc=omermetekaya0@gmail.com \
--cc=song@kernel.org \
--cc=syzbot+fd7e415d891073b83e1f@syzkaller.appspotmail.com \
--cc=yonghong.song@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.