lkml.org 
[lkml]   [2023]   [Mar]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [BUG] v6.3-rc2 regresses sched_getaffinity() for arm64
From
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

\
 
 \ /
  Last update: 2023-03-27 01:00    [W:0.063 / U:0.520 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site