Linux Trace Kernel
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Feng Yang" <yangfeng59949@163.com>
Cc: bpf@vger.kernel.org, linux-trace-kernel@vger.kernel.org
Subject: Re: [PATCH bpf-next v4 2/2] selftests/bpf: Test faulting build IDs from a sleepable raw tracepoint
Date: Thu, 05 Nov 2026 09:41:52 +0000	[thread overview]
Message-ID: <sashiko-outbox-198772@kernel.org> (raw)
In-Reply-To: <20261105093212.826479-2-yangfeng59949@163.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] selftests/bpf: race setting target_tgid before target_syscall
- [Medium] selftests/bpf: unchecked signed-unsigned division in subtest_raw_tp()
--

commit 2b4f6f5d972293b188ccb421c050655343b0d0ee
Author: Feng Yang <yangfeng@kylinos.cn>

selftests/bpf: Test faulting build IDs from a sleepable raw tracepoint

This commit extends the build_id selftest with sleepable and non-sleepable
raw tracepoint subtests on sys_enter to verify user stack build ID extraction
when the build ID page is paged out.

> diff --git a/tools/testing/selftests/bpf/prog_tests/build_id.c b/tools/testing/selftests/bpf/prog_tests/build_id.c
> index aec9c8d6bc96b..98e3d09981793 100644
> --- a/tools/testing/selftests/bpf/prog_tests/build_id.c
> +++ b/tools/testing/selftests/bpf/prog_tests/build_id.c
[ ... ]
> +static int run_uprobe_multi_syscall(struct test_build_id *skel)
> +{
> +	char c = 'x';
> +	int pfd[2], status, err;
> +	pid_t pid;
> +
> +	if (pipe(pfd))
> +		return -errno;
> +
> +	pid = fork();
> +	if (pid < 0) {
> +		err = -errno;
> +		close(pfd[0]);
> +		close(pfd[1]);
> +		return err;
> +	}
> +	if (pid == 0) {
> +		close(pfd[1]);
> +		if (read(pfd[0], &c, 1) != 1)
> +			_exit(127);
> +		close(pfd[0]);
> +		execl("./uprobe_multi", "uprobe_multi", "paged-out-syscall", NULL);
> +		_exit(127);
> +	}
> +
> +	close(pfd[0]);
> +	skel->bss->target_tgid = pid;
> +	skel->bss->target_syscall = SYS_getpid;

[Severity: Medium]
Can setting target_tgid before target_syscall in run_uprobe_multi_syscall()
race with the child's read(pfd[0], &c, 1) on architectures where SYS_read is 0
(such as x86_64)?

In subtest_raw_tp(), skel->bss is zero-initialized (so target_syscall is 0)
and rawtp_sleepable or rawtp_nofault is already attached before calling
run_uprobe_multi_syscall():

subtest_raw_tp()
  bpf_program__attach()
  run_uprobe_multi_syscall()
    fork()

If the child enters sys_enter for read(pfd[0], &c, 1) after the parent stores
skel->bss->target_tgid = pid but before skel->bss->target_syscall = SYS_getpid
becomes visible, rawtp_nofault or rawtp_sleepable in
tools/testing/selftests/bpf/progs/test_build_id.c sees:

	if ((u32)(bpf_get_current_pid_tgid() >> 32) != (u32)target_tgid ||
	    id != target_syscall)
		return 0;

	/* Record only the first hit, a later getpid() must not overwrite it. */
	if (res_rawtp_sleepable)
		return 0;

Because id == 0 matches target_syscall == 0, the program records the stack of
the forked test_progs process before execl() and ignores the subsequent
SYS_getpid in uprobe_multi, causing the uprobe_multi build ID assertion to
fail. Should target_syscall be initialized before attaching or before setting
target_tgid?

> +	if (write(pfd[1], &c, 1) != 1) {
[ ... ]
> +static void subtest_raw_tp(bool sleepable)
> +{
[ ... ]
> +	if (sleepable) {
> +		res = skel->bss->res_rawtp_sleepable;
> +		stack = skel->bss->stack_rawtp_sleepable;
> +	} else {
> +		res = skel->bss->res_rawtp_nofault;
> +		stack = skel->bss->stack_rawtp_nofault;
> +	}
> +	frame_cnt = res / sizeof(struct bpf_stack_build_id);
> +	if (env.verbosity >= VERBOSE_NORMAL)
> +		print_stack(stack, frame_cnt);
> +
> +	ASSERT_GT(frame_cnt, 0, "frames");

[Severity: Medium]
If bpf_get_stack() returns a negative errno in res_rawtp_sleepable or
res_rawtp_nofault, does dividing the signed int res by the unsigned size_t
sizeof(struct bpf_stack_build_id) convert res to a large unsigned value before
checking if it succeeded?

On 32-bit architectures, where int and size_t are both 32-bit, a negative res
such as -EFAULT (-14) becomes 0xfffffff2U / 32 = 134217727 in frame_cnt, which
passes ASSERT_GT(frame_cnt, 0, "frames") and overflows the 128-element
stack_rawtp_sleepable or stack_rawtp_nofault array in print_stack(),
stack_has_build_id(), and stack_has_ip(). Even on 64-bit targets, a failed
ASSERT_GT(frame_cnt, 0, "frames") falls through to the subsequent stack checks
instead of jumping to cleanup.

Should subtest_raw_tp() check res before computing frame_cnt, matching
subtest_sleepable() in the same file:

	if (!ASSERT_GT(skel->bss->res_sleepable, 0, "res"))
		goto cleanup;

	stack = skel->bss->stack_sleepable;
	frame_cnt = skel->bss->res_sleepable / sizeof(struct bpf_stack_build_id);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261105093212.826479-1-yangfeng59949@163.com?part=2

      reply	other threads:[~2026-11-05  9:41 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-05  9:32 [PATCH bpf-next v4 1/2] bpf: Add sleepable version of bpf_get_stack in raw_tp_prog_func_proto and tp_prog_func_proto Feng Yang
2026-11-05  9:32 ` [PATCH bpf-next v4 2/2] selftests/bpf: Test faulting build IDs from a sleepable raw tracepoint Feng Yang
2026-11-05  9:41   ` sashiko-bot [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=sashiko-outbox-198772@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=yangfeng59949@163.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