From: bot+bpf-ci@kernel.org
To: dingning04@gmail.com,bpf@vger.kernel.org
Cc: ast@kernel.org,daniel@iogearbox.net,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,shuah@kernel.org,dingning04@gmail.com,zhouchuyi@bytedance.com,linux-kernel@vger.kernel.org,linux-kselftest@vger.kernel.org,ast@kernel.org,andrii@kernel.org,daniel@iogearbox.net,martin.lau@kernel.org,eddyz87@gmail.com,yonghong.song@linux.dev,clm@meta.com,ihor.solodrai@linux.dev
Subject: Re: [PATCH bpf-next v2 2/2] selftests/bpf: Test RCU iterator state pruning
Date: Tue, 11 Aug 2026 04:41:31 +0000 (UTC) [thread overview]
Message-ID: <3ac6ad5d1acfbf15bc536519ba1fc748ea85ece109397bbb50e56cdffb9ce726@mail.kernel.org> (raw)
In-Reply-To: <20260811035955.132989-3-dingning04@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2553 bytes --]
> selftests/bpf: Test RCU iterator state pruning
>
> Add a path where RCU protection reaches zero and then starts again.
> The iterator is untrusted after this gap and must be rejected.
>
> Signed-off-by: Ning Ding <dingning04@gmail.com>
This isn't a bug, but could the changelog mention why BPF_F_TEST_STATE_FREQ
is needed and that both arms deliberately converge with the same RCU lock
depth, so a future reader knows what keeps this test meaningful?
> diff --git a/tools/testing/selftests/bpf/progs/iters_task_failure.c b/tools/testing/selftests/bpf/progs/iters_task_failure.c
> index fe3663dedbe1..566a1d3dffea 100644
> --- a/tools/testing/selftests/bpf/progs/iters_task_failure.c
> +++ b/tools/testing/selftests/bpf/progs/iters_task_failure.c
> @@ -61,6 +61,52 @@ int BPF_PROG(iter_tasks_lock_and_unlock)
> return 0;
> }
>
> +SEC("?fentry.s/" SYS_PREFIX "sys_getpgid")
> +__failure __msg("expected an RCU CS when using bpf_iter_task_next")
> +__flag(BPF_F_TEST_STATE_FREQ)
> +int BPF_PROG(iter_tasks_rcu_state_pruning)
> +{
> + struct bpf_iter_task it;
> +
> + asm volatile (
> + "call %[bpf_rcu_read_lock];"
> + "r1 = %[it];"
> + "r2 = 0;"
> + "r3 = 0;" /* BPF_TASK_ITER_ALL_PROCS */
> + "call %[bpf_iter_task_new];"
> +
> + "call %[bpf_get_prandom_u32];"
> + "if w0 == 0 goto unprotected_%=;"
> +
> + /* Keep the outer RCU lock active on the straight-line path. */
> + "call %[bpf_rcu_read_lock];"
> + "call %[bpf_rcu_read_unlock];"
This isn't a bug, but would it help to say what the nested lock/unlock
pair is for here - e.g. that it scratches the caller-saved registers so
the only state difference at merge_ is the iterator's MEM_RCU vs
PTR_UNTRUSTED type?
> + "goto merge_%=;"
> +
> + "unprotected_%=:"
> + /* Create an unprotected gap on the taken path. */
> + "call %[bpf_rcu_read_unlock];"
> + "call %[bpf_rcu_read_lock];"
> +
> + "merge_%=: r1 = %[it];"
> + "call %[bpf_iter_task_next];"
> + "r1 = %[it];"
> + "call %[bpf_iter_task_destroy];"
> + "call %[bpf_rcu_read_unlock];"
> + :
> + : __imm_ptr(it),
> + __imm(bpf_get_prandom_u32),
> + __imm(bpf_iter_task_new),
> + __imm(bpf_iter_task_next),
> + __imm(bpf_iter_task_destroy),
> + __imm(bpf_rcu_read_lock),
> + __imm(bpf_rcu_read_unlock)
> + : __clobber_common
> + );
> +
> + return 0;
> +}
> +
---
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/31457825387
next prev parent reply other threads:[~2026-08-11 4:41 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-11 3:59 [PATCH bpf-next v2 0/2] bpf: Compare iterator types during " Ning Ding
2026-08-11 3:59 ` [PATCH bpf-next v2 1/2] " Ning Ding
2026-08-11 3:59 ` [PATCH bpf-next v2 2/2] selftests/bpf: Test RCU iterator " Ning Ding
2026-08-11 4:41 ` bot+bpf-ci [this message]
2026-08-11 21:54 ` Eduard Zingerman
2026-08-11 22:00 ` [PATCH bpf-next v2 0/2] bpf: Compare iterator types during " patchwork-bot+netdevbpf
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=3ac6ad5d1acfbf15bc536519ba1fc748ea85ece109397bbb50e56cdffb9ce726@mail.kernel.org \
--to=bot+bpf-ci@kernel.org \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=clm@meta.com \
--cc=daniel@iogearbox.net \
--cc=dingning04@gmail.com \
--cc=eddyz87@gmail.com \
--cc=emil@etsalapatis.com \
--cc=ihor.solodrai@linux.dev \
--cc=jolsa@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=martin.lau@kernel.org \
--cc=martin.lau@linux.dev \
--cc=memxor@gmail.com \
--cc=shuah@kernel.org \
--cc=song@kernel.org \
--cc=yonghong.song@linux.dev \
--cc=zhouchuyi@bytedance.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®