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

[Linus Torvalds]

On Tue, Mar 14, 2023 at 5:51 PM Linus Torvalds
<torvalds at 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