Messages in this thread |  | | From | Linus Torvalds <> | Date | Tue, 14 Mar 2023 18:35:06 -0700 | Subject | Re: [BUG] v6.3-rc2 regresses sched_getaffinity() for arm64 |
| |
On Tue, Mar 14, 2023 at 5:51 PM Linus Torvalds <torvalds@linux-foundation.org> wrote: > > The immediate fix for your issue is likely the attached patch, but I'm > not particularly happy with it. I'd need to at the very least also fix > the same issue in the compat code, but there might be other cases of > this too, where people use the "allocation size" as the "valid bits > size".
It does look like all other users of cpumask_size() get it right and treat it as an allocation size (and will explicitly clear the cpumask if they then also use the size-in-bytes later for other things)
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.
It looks like we have never actually done a "what is the size of a bitmap of X bits" helper function. We have that
unsigned int len = BITS_TO_LONGS(nbits) * sizeof(unsigned long);
expanded many times by hand, but there is no simple helper for that rather common expression.
We've got a few places that clearly got tired of not having said helper, so drivers/md/dm-clone-metadata.c has that "bitmap_size()" as an inline function, and lib/math/prime_numbers.c has it as a macro.
So I guess I can't blame the getaffinity() code for then using the allocation size helper, since it was there and it worked until it didn't. The setaffinity() code actually gets it right, and uses it basically as a "this is the allocation size" thing, and then fills it up correctly.
And the reason this hits mainly on arm64 is presumably that on x86-64, people either use MAXSMP (ugh) or have smaller cpu masks, and you really need to hit that "64 < NR_CPU <= 256" case to get the problematic situation.
Linus
|  |