All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Sean Christopherson" <seanjc@google.com>
Cc: "Marc Zyngier" <maz@kernel.org>,
	"Oliver Upton" <oupton@kernel.org>,
	kvmarm@lists.linux.dev, kvm@vger.kernel.org
Subject: Re: [PATCH v2 06/12] KVM: selftests: Affine threads to random CPUs in hardware disable test
Date: Fri, 31 Jul 2026 17:15:40 +0000	[thread overview]
Message-ID: <20260731171540.7B3FF1F00AC4@smtp.kernel.org> (raw)
In-Reply-To: <20260731170619.2620845-7-seanjc@google.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Randomly selected CPUs are not removed from `allowed_cpu_set`, leading to duplicate selections and artificially reduced test concurrency.
--

--- Patch [6]: [PATCH v2 06/12] KVM: selftests: Affine threads to random CPUs in hardware disable test ---
commit 093b65b96e15e7cdd5b611bd7d8556fb88cae6e6
Author: Sean Christopherson <seanjc@google.com>

KVM: selftests: Affine threads to random CPUs in hardware disable test

This patch modifies the hardware disable test to affine worker threads
to random CPUs instead of hardcoding them to CPUs 0-3. It also honors
the starting CPU set during this process.

> diff --git a/tools/testing/selftests/kvm/hardware_disable_test.c b/tools/testing/selftests/kvm/hardware_disable_test.c
> index d8288147b0a69..bd23c13003707 100644
> --- a/tools/testing/selftests/kvm/hardware_disable_test.c
> +++ b/tools/testing/selftests/kvm/hardware_disable_test.c
> @@ -149,12 +149,15 @@ void wait_for_child_setup(pid_t pid)
>  
>  int main(int argc, char **argv)
>  {
> +	cpu_set_t allowed_cpu_set;
>  	u32 i;
>  	int s, r;
>  	pid_t pid;
>  
> -	for (i = 0; i < VCPU_NUM; i++)
> -		CPU_SET(i, &threads_cpu_set);
> +	kvm_sched_getaffinity(0, sizeof(cpu_set_t), &allowed_cpu_set);
> +
> +	for (i = 0; i < VCPU_NUM && CPU_COUNT(&allowed_cpu_set); i++)
> +		CPU_SET(kvm_pick_random_cpu(&allowed_cpu_set), &threads_cpu_set);

[Severity: Medium]
Since kvm_pick_random_cpu() doesn't clear the selected CPU from
allowed_cpu_set, can the same CPU be selected multiple times here?

Because the selected CPU is not cleared (for example, with CPU_CLR),
threads_cpu_set could end up with fewer than VCPU_NUM unique CPUs. This
might artificially reduce the test's concurrency.

Additionally, the loop condition checks CPU_COUNT(&allowed_cpu_set), but
since allowed_cpu_set is never modified inside the loop, this count
will remain constant. Was there an intention to remove the chosen CPU
from allowed_cpu_set in each iteration?

>  	sem = sem_open("vm_sem", O_CREAT | O_EXCL, 0644, 0);
>  	sem_unlink("vm_sem");

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260731170619.2620845-1-seanjc@google.com?part=6

  reply	other threads:[~2026-07-31 17:15 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-31 17:06 [PATCH v2 00/12] KVM: selftests: Add more syscall wrappers, fix hardware_disable_test Sean Christopherson
2026-07-31 17:06 ` [PATCH v2 01/12] KVM: selftests: Add a KVM syscall wrapper for sched_setaffinity() Sean Christopherson
2026-07-31 17:06 ` [PATCH v2 02/12] KVM: selftests: Set threads CPU affinity before doing work in hardware disable test Sean Christopherson
2026-07-31 17:06 ` [PATCH v2 03/12] KVM: selftests: Pre-set threads affinity in hardware disable test when possible Sean Christopherson
2026-07-31 17:20   ` sashiko-bot
2026-07-31 17:06 ` [PATCH v2 04/12] KVM: selftests: Return the target CPU from pin_task_to_random_cpu() Sean Christopherson
2026-07-31 17:06 ` [PATCH v2 05/12] KVM: selftests: Extract picking of random CPU from cpu_set_t to separate API Sean Christopherson
2026-07-31 17:06 ` [PATCH v2 06/12] KVM: selftests: Affine threads to random CPUs in hardware disable test Sean Christopherson
2026-07-31 17:15   ` sashiko-bot [this message]
2026-07-31 17:27     ` Sean Christopherson
2026-07-31 17:06 ` [PATCH v2 07/12] KVM: selftests: Drop unreachable, dead code from " Sean Christopherson
2026-07-31 17:06 ` [PATCH v2 08/12] KVM: selftests: Add KVM syscall wrapper for pthread_create() Sean Christopherson
2026-07-31 17:20   ` sashiko-bot
2026-07-31 17:06 ` [PATCH v2 09/12] KVM: selftests: Add KVM syscall wrappers for pthread_{cancel,join}() Sean Christopherson
2026-07-31 17:18   ` sashiko-bot
2026-07-31 17:06 ` [PATCH v2 10/12] KVM: selftests: Add helper APIs to cancel+join pthreads Sean Christopherson
2026-07-31 17:06 ` [PATCH v2 11/12] KVM: selftests: Add KVM syscall wrappers for pthread_{g,s}etaffinity_np() Sean Christopherson
2026-07-31 17:06 ` [PATCH v2 12/12] KVM: selftests: Clean up global constants in hardware disable test Sean Christopherson

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=20260731171540.7B3FF1F00AC4@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.linux.dev \
    --cc=maz@kernel.org \
    --cc=oupton@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=seanjc@google.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 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.