Re: [PATCH 1/7] mm: allocate mm_cpumask dynamically based on nr_cpu_ids

[Rik van Riel <riel@surriel.com>]

[-- Attachment #1: Type: text/plain, Size: 1560 bytes --]

On Sun, 2018-07-08 at 16:13 +0200, Mike Galbraith wrote:
> On Sat, 2018-07-07 at 17:25 -0400, Rik van Riel wrote:
> > 
> > > ./include/linux/bitmap.h:208:3: warning: ‘memset’ writing 64
> > > bytes
> > > into a region of size 0 overflows the destination [-Wstringop-
> > > overflow=]
> > >    memset(dst, 0, len);
> > >    ^~~~~~~~~~~~~~~~~~~
> > 
> > I don't understand this one.
> > 
> > Inside init_mm we have this line:
> >         .cpu_bitmap     = { [BITS_TO_LONGS(NR_CPUS)] = 0},
> > 
> > which is the way the documentation suggests statically
> > allocated variable size arrays should be allocated 
> > and initialized.
> > 
> > How does that result in a memset of the same size,
> > on the same array, to throw an error like above?
> 
> Compiler knows that ->cpu_bitmap is 64 bits of storage, and with
> !CPUMASK_OFFSTACK, nr_cpumask_bits = NR_CPUS.  With NR_CPUS > 64,
> compiler gripes, with NR_CPUS <= 64 it's a happy camper.
> 
> > What am I doing wrong?
> 
> Below is what I did to get box to both STHU, and to boot with the
> openSUSE master branch config I sent.  Without the efi_mm hunk, boot
> hangs early with or without the other hunk.
> 
> I build and boot tested the openSUSE config, a NOPREEMPT+MAXSMP
> config,
> my local config w. NR_CPUS=8, and master-rt w. NR_CPUS=256, which is
> the only one that got any real exercise (building the others).
> 

Thank you for tracking that down.

I added your code, and Signed-off-By in patch
1 for version 5 of the series.

-- 
All Rights Reversed.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]