From: Sean Christopherson <seanjc@google.com>
To: sashiko-reviews@lists.linux.dev
Cc: kvm@vger.kernel.org
Subject: Re: [PATCH v2 2/2] KVM: selftests: Randomize pCPU in steal time test
Date: Tue, 7 Jul 2026 09:15:32 -0700 [thread overview]
Message-ID: <ak0mJLxaz2TBwM0p@google.com> (raw)
In-Reply-To: <20260707152943.290581F000E9@smtp.kernel.org>
On Tue, Jul 07, 2026, sashiko-bot@kernel.org wrote:
> > diff --git a/tools/testing/selftests/kvm/steal_time.c b/tools/testing/selftests/kvm/steal_time.c
> > --- a/tools/testing/selftests/kvm/steal_time.c
> > +++ b/tools/testing/selftests/kvm/steal_time.c
> [ ... ]
> > @@ -514,14 +514,12 @@ int main(int ac, char **av)
> > long stolen_time;
> > long run_delay;
> > bool verbose;
> > - int i;
> > + int i, cpu;
> >
> > verbose = ac > 1 && (!strncmp(av[1], "-v", 3) || !strncmp(av[1], "--verbose", 10));
> >
> > /* Set CPU affinity so we can force preemption of the VCPU */
> > - CPU_ZERO(&cpuset);
> > - CPU_SET(0, &cpuset);
> > - pthread_setaffinity_np(pthread_self(), sizeof(cpu_set_t), &cpuset);
> > + cpu = pin_self_to_any_cpu();
> >
> > /* Create a VM and an identity mapped memslot for the steal time structure */
> > vm = vm_create_with_vcpus(NR_VCPUS, guest_code, vcpus);
> [ ... ]
> > @@ -557,7 +555,7 @@ int main(int ac, char **av)
> > run_delay = get_run_delay();
> > pthread_create(&thread, NULL, do_steal_time, NULL);
> > pthread_getaffinity_np(thread, sizeof(cpuset), &cpuset);
> > - TEST_ASSERT(CPU_COUNT(&cpuset) == 1 && CPU_ISSET(0, &cpuset),
> > + TEST_ASSERT(CPU_COUNT(&cpuset) == 1 && CPU_ISSET(cpu, &cpuset),
>
> [Severity: Medium]
> Is there a race condition here if the worker thread exits before the parent
> reads its affinity?
>
> When pthread_create() spawns the worker thread, the child runs for a short
> duration and exits. If the parent thread is preempted right after creation,
> the child might finish its work and exit before pthread_getaffinity_np()
> executes in the parent.
>
> If the kernel task is already gone, pthread_getaffinity_np() will fail with
No, because the kernel task is kept alive until pthread_join(). As per the
pthread_create() manpage[*]:
Only when a terminated joinable thread has been joined are the last of its
resources released back to the system.
And by empirical testing, that includes the kernel task.
[*] https://man7.org/linux/man-pages/man3/pthread_create.3.html
> ESRCH. Because the explicit initialization of cpuset was removed earlier in
> main(), cpuset remains completely uninitialized.
>
> Could this cause CPU_COUNT() and CPU_ISSET() to evaluate garbage stack memory
> and trigger sporadic TEST_ASSERT failures? Should the return value of
> pthread_getaffinity_np() be checked, or should cpuset be initialized before
> the call?
The return value should be checked, but I'd rather handle that in a separate
cleanup by adding a wrapper in kvm_syscalls.h.
prev parent reply other threads:[~2026-07-07 16:15 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-07 15:07 [PATCH v2 0/2] KVM: selftest: Fix steal time w/ non-glibc builds Sean Christopherson
2026-07-07 15:07 ` [PATCH v2 1/2] KVM: selftests: Drop superfluous use of pthread_attr_setaffinity_np() Sean Christopherson
2026-07-07 15:21 ` sashiko-bot
2026-07-07 16:03 ` Sean Christopherson
2026-07-07 15:07 ` [PATCH v2 2/2] KVM: selftests: Randomize pCPU in steal time test Sean Christopherson
2026-07-07 15:29 ` sashiko-bot
2026-07-07 16:15 ` Sean Christopherson [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=ak0mJLxaz2TBwM0p@google.com \
--to=seanjc@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 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.