lkml.org 
[lkml]   [2018]   [Jul]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH 1/7] mm: allocate mm_cpumask dynamically based on nr_cpu_ids
From
Date
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.[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2018-07-09 23:39    [W:0.129 / U:0.340 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site