Re: [PATCH 8/9] KVM: selftests: Add KVM syscall wrappers for pthread_{g,s}etaffinity_np()

On Thu, Jul 30, 2026, [email protected] wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Medium] KVM syscall wrappers for pthread functions produce misleading error messages on failure.
> --
> 
> --- Patch [8]: [PATCH 8/9] KVM: selftests: Add KVM syscall wrappers for pthread_{g,s}etaffinity_np() ---
> commit 9fc7623d339b95135fb5ecb9685356bc8dff9829
> Author: Sean Christopherson <[email protected]>
> 
> KVM: selftests: Add KVM syscall wrappers for pthread_{g,s}etaffinity_np()
> 
> This commit adds KVM wrappers for pthread_getaffinity_np() and 
> pthread_setaffinity_np() to simplify selftest code. It removes the need 
> to manually check for success or supply the size of cpu_set_t in the tests.
> 
> [ ... ]
> 
> > diff --git a/tools/testing/selftests/kvm/include/kvm_syscalls.h b/tools/testing/selftests/kvm/include/kvm_syscalls.h
> > index 002b5a4e59eb2..3d82351bef92e 100644
> > --- a/tools/testing/selftests/kvm/include/kvm_syscalls.h
> > +++ b/tools/testing/selftests/kvm/include/kvm_syscalls.h
> > @@ -97,6 +97,22 @@ __KVM_SYSCALL_DEFINE(ftruncate, 2, unsigned int, fd, off_t, length);
> >  __KVM_SYSCALL_DEFINE(madvise, 3, void *, addr, size_t, length, int, advice);
> >  __KVM_SYSCALL_DEFINE(sched_getaffinity, 3, pid_t, pid, size_t, cpusetsize, cpu_set_t *, mask);
> >  
> > +__KVM_SYSCALL_DEFINE(pthread_getaffinity_np, 3, pthread_t, thread,
> > +		     size_t, cpusetsize, cpu_set_t *, cpuset);
> > +__KVM_SYSCALL_DEFINE(pthread_setaffinity_np, 3, pthread_t, thread,
> > +		     size_t, cpusetsize, const cpu_set_t *, cpuset);
> 
> [Severity: Medium]
> Will these pthread wrappers print misleading error messages on failure?
> 
> The pthread_* functions return positive error codes directly on failure 
> rather than returning -1 and setting errno. If __KVM_SYSCALL_DEFINE formats 
> its failure messages assuming errno is set, failing to set affinity could 
> result in printing a stale or unrelated error string (such as "Success") 
> alongside the return code, which might impede debugging.

Empirically, no.  Just because they _also_ return an exact error code doesn't
make errno invalid.

==== Test Assertion Failure ====
  include/kvm_syscalls.h:117: !r
  pid=155681 tid=155681 errno=11 - Resource temporarily unavailable
  pthread_create failed, rc: 11 errno: 11 (Resource temporarily unavailable)