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.
signature.asc
Description: This is a digitally signed message part
