Kernel KVM virtualization development
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Aaron Lewis" <aaronlewis@google.com>
Cc: kvm@vger.kernel.org
Subject: Re: [PATCH 3/4] vfio: selftests: Allow a size for vfio_dma_mapping_perf_test
Date: Wed, 01 Jul 2026 20:44:24 +0000	[thread overview]
Message-ID: <20260701204424.CDDF11F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260701203311.326798-4-aaronlewis@google.com>

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [Medium] The -h option and invalid arguments fail to exit the program, causing unintended execution of all tests.
- [Medium] Multiple usages of the '-a' flag overwrite the wordexp structure without WRDE_REUSE, causing memory leaks and dropping previous arguments.
- [Medium] Using size_t for math and return type in parse_size() causes undefined behavior and silent truncation on 32-bit architectures.
--

commit d938d0d26cc3c95a10e15ae011fce57f55a320c9
Author: Aaron Lewis <aaronlewis@google.com>

vfio: selftests: Allow a size for vfio_dma_mapping_perf_test
    
Allow the user to specify a DMA region size via the command line for
vfio_dma_mapping_perf_test.

> diff --git a/tools/testing/selftests/vfio/vfio_dma_mapping_perf_test.c b/tools/testing/selftests/vfio/vfio_dma_mapping_perf_test.c
> index 4639bda7ebaa3..2d8fc3e8e0787 100644
> --- a/tools/testing/selftests/vfio/vfio_dma_mapping_perf_test.c
> +++ b/tools/testing/selftests/vfio/vfio_dma_mapping_perf_test.c
[ ... ]
> +size_t parse_size(const char *size)
> +{
> +	size_t base;
> +	char *scale;
> +	int shift = 0;
[ ... ]
> +	switch (tolower(*scale)) {
> +	case 't':
> +		shift = 40;
> +		break;
[ ... ]
> +	VFIO_ASSERT_TRUE((base << shift) >> shift == base,
> +			 "Overflow scaling size!");
> +
> +	return base << shift;
> +}

[Severity: Medium]
On 32-bit architectures where size_t is 32-bit, will shifting a 32-bit integer 
by 40 when parsing terabytes cause undefined behavior?

Because compilers can mask over-sized shift counts, the overflow check here
might evaluate as true and silently pass while returning a drastically
truncated size. Should this function use u64 internally and as its return
type to match test_params.size?

[ ... ]
> +static void populate_harness_args(struct harness_args *args, const char *argv_0,
> +				  const char *cmdlne)
> +{
> +	if (wordexp(argv_0, &args->exp, WRDE_NOCMD) == 0 &&
> +	    wordexp(cmdlne, &args->exp, WRDE_APPEND | WRDE_NOCMD) == 0) {

[Severity: Medium]
If a user passes multiple '-a' flags, does the first wordexp() call without
WRDE_REUSE or WRDE_APPEND leak the previously allocated memory in args->exp?

This also looks like it would discard any arguments appended by earlier '-a'
flags, and potentially leave args->argv pointing to leaked allocations if the
second wordexp() fails.

> +		args->argc = args->exp.we_wordc;
> +		args->argv = args->exp.we_wordv;
> +	}
> +}
> +
> +static void setup_test(struct harness_args *args, int argc, char *argv[])
> +{
> +	int opt;
> +
> +	test_params = (struct test_params) {
> +		.size = SZ_1G,
> +	};
> +
> +	while ((opt = getopt(argc, argv, "a:b:h")) != -1) {
> +		switch (opt) {
[ ... ]
> +		case 'h':
> +		default:
> +			help(argv[0]);
> +			goto out;
> +		}
> +	}
> +
> +out:
> +	// Reset getopt() state to allow the test harness to use it.
> +	optind = 1;
> +}

[Severity: Medium]
When the '-h' option or an invalid argument is provided, does jumping to 'out' 
unintentionally allow the program to continue executing?

Because setup_test() returns normally to main() in this path, main() will
subsequently execute test_harness_run(), which runs the full test suite
immediately after printing the help message instead of terminating.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260701203311.326798-1-aaronlewis@google.com?part=3

  reply	other threads:[~2026-07-01 20:44 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-01 20:33 [PATCH 0/4] Introduce vfio_dma_mapping_perf_test Aaron Lewis
2026-07-01 20:33 ` [PATCH 1/4] vfio: selftests: " Aaron Lewis
2026-07-01 20:44   ` sashiko-bot
2026-07-01 20:33 ` [PATCH 2/4] vfio: selftests: Add memfd test to vfio_dma_mapping_perf_test Aaron Lewis
2026-07-01 20:43   ` sashiko-bot
2026-07-01 20:33 ` [PATCH 3/4] vfio: selftests: Allow a size for vfio_dma_mapping_perf_test Aaron Lewis
2026-07-01 20:44   ` sashiko-bot [this message]
2026-07-01 20:33 ` [PATCH 4/4] vfio: selftests: Allow the flag MAP_POPULATE to be set on the cmdline Aaron Lewis

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=20260701204424.CDDF11F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=aaronlewis@google.com \
    --cc=kvm@vger.kernel.org \
    --cc=sashiko-reviews@lists.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox