Re: [BUG] v6.3-rc2 regresses sched_getaffinity() for arm64

[Ryan Roberts <ryan.roberts@arm.com>]

On 15/03/2023 02:48, Linus Torvalds wrote:
> On Tue, Mar 14, 2023 at 6:35 PM Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
>>
>> So this does look  like purely a sched_getaffinity() thing (including
>> the compat handling for same).
>>
>> And I can see why sched_getaffinity() uses cpumask_size(): we have no
>> other good helper for this.
> 
> I decided that the cleanest fix is to just keep the cpumask_size() use
> as-is, and just use zalloc_cpumask_var() to make sure the cpumask is
> fully initialized.
> 
> Yes, we could play games with the exact size, but there just isn't any
> excuse for it. Either it's a small on-stack allocation that gets
> copied to user space (in which case we really are better off just
> initializing it instead of doing anything clever), or it's an explicit
> allocation due to the x86-64 MAXSMP case (in which case zeroing the
> allocation is the least of our problems).
> 
> And zeroing the cpumask was what other somewhat similar cases seemed
> to be doing, so it's consistent.

Thanks for the fast response and clear explanation! FWIW, the fix you committed
looks sensible to me.

> 
> I've pushed out my fix. It looks ObviouslyCorrect(tm), but it would be
> good to get verification that it does indeed fix things for you.

I tested at 6015b1aca1a233379625385feb01dd014aca60b5 and all looks good now, so:

Tested-by: Ryan Roberts <ryan.roberts@arm.com>

> 
> Because sometimes things look a bit more obvious than they actually are ;)
> 
>               Linus