Messages in this thread |  | | Date | Wed, 15 Mar 2023 09:17:58 +0000 | Subject | Re: [BUG] v6.3-rc2 regresses sched_getaffinity() for arm64 | From | Ryan Roberts <> |
| |
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
|  |