All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Alexei Starovoitov" <alexei.starovoitov@gmail.com>, bpf@vger.kernel.org
Cc: daniel@iogearbox.net, andrii@kernel.org, eddyz87@gmail.com,
	memxor@gmail.com, oleg@redhat.com, peterz@infradead.org,
	mhiramat@kernel.org, jolsa@kernel.org, akpm@linux-foundation.org,
	liam@infradead.org, ljs@kernel.org, surenb@google.com,
	david@kernel.org, vbabka@kernel.org, jannh@google.com,
	hughd@google.com, kees@kernel.org, mingo@redhat.com,
	tglx@kernel.org, x86@kernel.org,
	linux-trace-kernel@vger.kernel.org, linux-mm@kvack.org,
	linux-perf-users@vger.kernel.org
Subject: Re: [PATCH bpf-next 9/9] selftests/bpf: Test uprobes and fork() with busy mmap_lock
Date: Thu, 22 Oct 2026 02:10:52 +0000	[thread overview]
Message-ID: <sashiko-outbox-180860@kernel.org> (raw)
In-Reply-To: <20261022015712.1297331-10-alexei.starovoitov@gmail.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] selftests/bpf: integer overflow of AREA_MAX on 32-bit in hold_mmap_lock()
--

commit 27a041a03328fba58bd21d5e62e3d149445f0523
Author: Alexei Starovoitov <ast@kernel.org>

selftests/bpf: Test uprobes and fork() with busy mmap_lock

This commit adds a BPF selftest that exercises uprobe attach and detach
concurrently with fork() while a process holds its mmap_lock via
MADV_POPULATE_READ.

> diff --git a/tools/testing/selftests/bpf/prog_tests/uprobe_busy_mm.c b/tools/testing/selftests/bpf/prog_tests/uprobe_busy_mm.c
> new file mode 100644
> index 0000000000000..30614e8b92cd5
> --- /dev/null
> +++ b/tools/testing/selftests/bpf/prog_tests/uprobe_busy_mm.c
> @@ -0,0 +1,447 @@

[ ... ]

> +#define AREA_MAX	(64UL << 30)
> +#define AREA_MIN	(64UL << 20)

[ ... ]

> +/*
> + * MADV_POPULATE_READ holds mmap_lock for reading while it maps zero page
> + * all over the area. It costs page tables only.
> + */
> +static void *hold_mmap_lock(void *arg)
> +{
> +	size_t size = AREA_MIN;
> +	void *area;
> +	__u64 t;
> +
> +	area = mmap(NULL, AREA_MAX, PROT_READ, MAP_PRIVATE | MAP_ANONYMOUS | MAP_NORESERVE, -1, 0);
> +	if (area == MAP_FAILED)
> +		goto err;

[Severity: Medium]
In tools/testing/selftests/bpf/prog_tests/uprobe_busy_mm.c, does AREA_MAX
overflow on 32-bit architectures when passed to mmap() in hold_mmap_lock()?

When serial_test_uprobe_busy_mm() runs on a 32-bit system via:

  serial_test_uprobe_busy_mm()
    -> start_busy_process()
      -> busy_process()
        -> hold_mmap_lock()

unsigned long and size_t are 32 bits wide, so (64UL << 30) overflows to 0
(and a 64 GiB area exceeds the 32-bit virtual address space). Passing 0 as
the length to mmap() causes it to return MAP_FAILED with EINVAL, jumping to
err and failing the test.

Should AREA_MAX be sized appropriately for 32-bit architectures as well?

> +	/* EINVAL without CONFIG_TRANSPARENT_HUGEPAGE */
> +	madvise(area, AREA_MAX, MADV_NOHUGEPAGE);
> +
> +	t = now_ns();
> +	if (madvise(area, size, MADV_POPULATE_READ))
> +		goto err;
> +	t = now_ns() - t;
> +	size *= sh->hold_ms * 1000000ULL / t + 1;
> +	if (size > AREA_MAX)
> +		size = AREA_MAX;
> +
> +	while (!LOAD(sh->stop)) {
> +		STORE(sh->in_hold, 1);
> +		t = now_ns();
> +		madvise(area, size, MADV_POPULATE_READ);
> +		/* before anything that can fault and wait for fork() */
> +		INC(sh->hold_seq);
> +		STORE(sh->hold_ns, now_ns() - t);
> +		STORE(sh->in_hold, 0);
> +		madvise(area, size, MADV_DONTNEED);
> +		STORE(sh->ready, 1);
> +	}
> +	return NULL;
> +err:
> +	INC(sh->errors);
> +	STORE(sh->ready, 1);
> +	return NULL;
> +}

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261022015712.1297331-1-alexei.starovoitov@gmail.com?part=9


  reply	other threads:[~2026-10-22  2:11 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-22  1:57 [PATCH bpf-next 0/9] uprobes: Don't stall fork() when mmap_lock is busy Alexei Starovoitov
2026-10-22  1:57 ` [PATCH bpf-next 1/9] mm: Bring back mmap_write_trylock() Alexei Starovoitov
2026-10-22  2:02   ` sashiko-bot
2026-10-22  1:57 ` [PATCH bpf-next 2/9] uprobes: Don't run exit_mmap() under dup_mmap_sem Alexei Starovoitov
2026-10-22  2:04   ` sashiko-bot
2026-10-22  1:57 ` [PATCH bpf-next 3/9] uprobes/x86: Finish an unoptimization which failed half-way Alexei Starovoitov
2026-10-22  2:06   ` sashiko-bot
2026-10-22  2:57   ` Gregory Price (Meta)
2026-10-23  7:13   ` Jiri Olsa
2026-10-22  1:57 ` [PATCH bpf-next 4/9] uprobes/x86: Don't WARN if an optimized probe can't be written Alexei Starovoitov
2026-10-22  2:03   ` sashiko-bot
2026-10-22  2:37   ` bot+bpf-ci
2026-10-22 17:56   ` Jann Horn
2026-10-22 19:33     ` Liam R. Howlett
2026-10-23 14:06       ` Lorenzo Stoakes (ARM)
2026-10-23  7:13   ` Jiri Olsa
2026-10-22  1:57 ` [PATCH bpf-next 5/9] uprobes: Don't sleep on mmap_lock under dup_mmap_sem Alexei Starovoitov
2026-10-22  2:16   ` sashiko-bot
2026-10-22  2:37   ` bot+bpf-ci
2026-10-22 23:11   ` Andrii Nakryiko
2026-10-22  1:57 ` [PATCH bpf-next 6/9] uprobes: Don't sleep on mmap_lock with dup_mmap_sem held in dup_mmap() Alexei Starovoitov
2026-10-22  2:15   ` sashiko-bot
2026-10-22 18:42   ` Jann Horn
2026-10-23 20:51   ` David Hildenbrand (Arm)
2026-10-27 15:38   ` Lorenzo Stoakes (ARM)
2026-10-22  1:57 ` [PATCH bpf-next 7/9] fork: Let the new task point to its mm before uprobes can find it Alexei Starovoitov
2026-10-22  2:23   ` sashiko-bot
2026-10-27 16:08   ` Lorenzo Stoakes (ARM)
2026-10-22  1:57 ` [PATCH bpf-next 8/9] uprobes: Don't leak the breakpoints if the unregistering task is killed Alexei Starovoitov
2026-10-22  2:20   ` sashiko-bot
2026-10-22  1:57 ` [PATCH bpf-next 9/9] selftests/bpf: Test uprobes and fork() with busy mmap_lock Alexei Starovoitov
2026-10-22  2:10   ` sashiko-bot [this message]
2026-10-22  2:22     ` Alexei Starovoitov
2026-10-22  2:37   ` bot+bpf-ci

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-180860@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=alexei.starovoitov@gmail.com \
    --cc=andrii@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=david@kernel.org \
    --cc=eddyz87@gmail.com \
    --cc=hughd@google.com \
    --cc=jannh@google.com \
    --cc=jolsa@kernel.org \
    --cc=kees@kernel.org \
    --cc=liam@infradead.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=ljs@kernel.org \
    --cc=memxor@gmail.com \
    --cc=mhiramat@kernel.org \
    --cc=mingo@redhat.com \
    --cc=oleg@redhat.com \
    --cc=peterz@infradead.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=surenb@google.com \
    --cc=tglx@kernel.org \
    --cc=vbabka@kernel.org \
    --cc=x86@kernel.org \
    /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.