[lkml]   [2023]   [Mar]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [BUG] v6.3-rc2 regresses sched_getaffinity() for arm64
On 15/03/2023 02:48, Linus Torvalds wrote:
> On Tue, Mar 14, 2023 at 6:35 PM Linus Torvalds
> <> 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 <>

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

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