BPF List
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Tushar Vyavahare" <tushar.vyavahare@intel.com>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH 5/5] selftests/xsk: Introduce mmap_size in umem struct
Date: Wed, 29 Apr 2026 08:47:43 +0000	[thread overview]
Message-ID: <20260429084743.E9047C19425@smtp.kernel.org> (raw)
In-Reply-To: <20260428080317.702124-6-tushar.vyavahare@intel.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Meaningful code and commit message mismatch regarding `mmap_size` computation, failing to resolve the over-unmapping risk.
--

commit 88aa7962c655c10bde2c97d706550190e3d87126
Author: Tushar Vyavahare <tushar.vyavahare@intel.com>

selftests/xsk: Introduce mmap_size in umem struct

This commit stores the finalized mapping length in xsk_umem_info as mmap_size
when the UMEM mapping is created. The intent is to use this exact value during
teardown instead of recomputing it from the frame geometry.

> diff --git a/tools/testing/selftests/bpf/prog_tests/test_xsk.c b/tools/testing/selftests/bpf/prog_tests/test_xsk.c
> index ba4768f83eb6..ba1bcfc6b74b 100644
> --- a/tools/testing/selftests/bpf/prog_tests/test_xsk.c
> +++ b/tools/testing/selftests/bpf/prog_tests/test_xsk.c
[ ... ]
> @@ -1594,6 +1594,8 @@ static int thread_common_ops(struct test_spec *test, struct ifobject *ifobject)
>  	if (bufs == MAP_FAILED)
>  		return -errno;
>  
> +	umem->mmap_size = ceil_u64(umem_sz, HUGEPAGE_SIZE) * HUGEPAGE_SIZE;
> +
>  	ret = xsk_configure_umem(ifobject, umem, bufs, umem_sz);
>  	if (ret)
>  		return ret;

The commit message states that this change "removes duplicated size
arithmetic in cleanup and guarantees that munmap() uses the same canonical
size that was established at setup time."

However, looking earlier in thread_common_ops():

	bufs = mmap(NULL, umem_sz, PROT_READ | PROT_WRITE, mmap_flags, -1, 0);

The size passed to mmap() is just umem_sz, without the hugepage rounding.

By setting umem->mmap_size to the rounded-up value here, does this still
duplicate the size arithmetic rather than using the exact mapping metadata?

If standard pages are used and umem_sz is not a multiple of HUGEPAGE_SIZE,
could this cause munmap() to use an inflated size and inadvertently unmap
adjacent memory?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260428080317.702124-1-tushar.vyavahare@intel.com?part=5

      reply	other threads:[~2026-04-29  8:47 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-28  8:03 [PATCH 0/5] selftests/xsk: foundational UMEM refactoring Tushar Vyavahare
2026-04-28  8:03 ` [PATCH 1/5] selftests/xsk: Introduce helpers for setting UMEM properties Tushar Vyavahare
2026-04-28 10:28   ` bot+bpf-ci
2026-04-28 12:39     ` Vyavahare, Tushar
2026-04-29  8:47   ` sashiko-bot
2026-04-28  8:03 ` [PATCH 2/5] selftests/xsk: Eliminate umem reference from ifobject Tushar Vyavahare
2026-04-29  8:47   ` sashiko-bot
2026-04-28  8:03 ` [PATCH 3/5] selftests/xsk: Remove umem from pkt_generate parameters Tushar Vyavahare
2026-04-28  8:03 ` [PATCH 4/5] selftests/xsk: Use umem_size() helper consistently Tushar Vyavahare
2026-04-29  8:47   ` sashiko-bot
2026-04-28  8:03 ` [PATCH 5/5] selftests/xsk: Introduce mmap_size in umem struct Tushar Vyavahare
2026-04-29  8:47   ` 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=20260429084743.E9047C19425@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=sashiko@lists.linux.dev \
    --cc=tushar.vyavahare@intel.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