Re: [PATCH] KVM: selftests: Use KVM's task pinning APIs in steal_time

[Sean Christopherson <seanjc@google.com>]

On Mon, Jul 06, 2026, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Medium] Race condition causing intermittent test failure (ESRCH) due to late thread pinning
> --
> 
> commit 27b6bbfae99d5564cda41cbc7b8c36c7b9a4ed64
> Author: Sean Christopherson <seanjc@google.com>
> 
> KVM: selftests: Use KVM's task pinning APIs in steal_time
> 
> This commit updates the steal_time test to use KVM's task pinning APIs
> (pin_self_to_cpu and pin_task_to_cpu) to pin the vCPU and stealer threads
> to pCPU0. This removes the use of pthread_attr_setaffinity_np, allowing
> the test to build against non-glibc C libraries.
> 
> Link: https://lore.kernel.org/all/aLIroyJSWQ26wnY4@google.com/
> 
> > diff --git a/tools/testing/selftests/kvm/steal_time.c b/tools/testing/selftests/kvm/steal_time.c
> > index 76fcdd1fd3cb4..19a97d6a36076 100644
> > --- a/tools/testing/selftests/kvm/steal_time.c
> > +++ b/tools/testing/selftests/kvm/steal_time.c
> [ ... ]
> > @@ -558,7 +552,9 @@ int main(int ac, char **av)
> >  
> >  		/* Steal time from the VCPU. The steal time thread has the same CPU affinity as the VCPUs. */
> >  		run_delay = get_run_delay();
> > -		pthread_create(&thread, &attr, do_steal_time, NULL);
> > +		pthread_create(&thread, NULL, do_steal_time, NULL);
> > +		pin_task_to_cpu(thread, 0);
> 
> [Severity: Medium]
> Could this introduce a race condition that causes intermittent test failures?
> 
> Since pthread_create is called before pinning, there is a small window
> where the child thread (do_steal_time) could execute and complete its very
> brief 200us run before the parent thread executes pin_task_to_cpu.
> 
> If the child thread exits before pin_task_to_cpu attempts to set its
> affinity, it will return ESRCH and trigger the TEST_ASSERT inside
> pin_task_to_cpu, abruptly aborting the test.
> 
> Is the explicit pin_task_to_cpu call necessary here?

Nope, which means we can simply drop the problematic pthread_attr_setaffinity_np(),
though I think it makes sense to add a sanity check that the worker did indeed
inherit the affinity, if only to document what's happening.

I'll send a v2.

Thanks for posting this Hisam!

> Since the main thread already called pin_self_to_cpu(0) earlier, the new
> thread created by pthread_create should automatically inherit the parent's
> CPU affinity mask.