linux-kernel - Re: [PATCH 1/7] mm: allocate mm_cpumask dynamically based on nr_cpu

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1531172317.5350.33.camel@surriel.com>
Date:   Mon, 09 Jul 2018 17:38:37 -0400
From:   Rik van Riel <riel@...riel.com>
To:     Mike Galbraith <efault@....de>, linux-kernel@...r.kernel.org
Cc:     x86@...nel.org, luto@...nel.org, dave.hansen@...ux.intel.com,
        mingo@...nel.org, kernel-team@...com, tglx@...utronix.de,
        songliubraving@...com, hpa@...or.com
Subject: Re: [PATCH 1/7] mm: allocate mm_cpumask dynamically based on
 nr_cpu_ids

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.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)