netdev - Re: [bisected] x86 boot still broken on -rc2

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]

Date:   Mon, 4 Dec 2017 11:48:30 -0800
From:   Jakub Kicinski <kubakici@...pl>
To:     Prarit Bhargava <prarit@...hat.com>
Cc:     linux-kernel@...r.kernel.org,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Clark Williams <williams@...hat.com>
Subject: Re: [bisected] x86 boot still broken on -rc2

On Mon,  4 Dec 2017 11:45:21 -0500, Prarit Bhargava wrote:
> On 12/04/2017 08:13 AM, Prarit Bhargava wrote:
> > x86: Booting SMP configuration:
> > .... node  #0, CPUs:        #1  #2  #3  #4
> > .... node  #1, CPUs:    #5  #6  #7  #8  #9
> > .... node  #0, CPUs:   #10 #11 #12 #13 #14
> > .... node  #1, CPUs:   #15 #16 #17 #18 #19
> > smp: Brought up 2 nodes, 20 CPUs
> > smpboot: Max logical packages: 1
> > 
> > which means that the calculation of logical packages is wrong because
> > 
> >       ncpus = cpu_data(0).booted_cores * smp_num_siblings;
> >       ncpus = 10 * 2;
> >       ncpus = 20;
> > 
> > smp_num_siblings is defined as "The number of threads in a core" which
> > should be 1 if HT/SMT is disabled.
> > 
> > It looks like my patch has exposed a bug in the
> > smp_num_siblings calculation.   I'm still debugging ...  
> 
> The bug is that smp_num_siblings has been incorrectly calculated as the
> *maximum* number of threads in a core, and not the actual number of threads in
> a core on systems which have a CPUID level greater than 0xb.  (see
> arch/x86/kernel/cpu/topology.c:59)
> 
> That will take some time to investigate and come up with a proper solution and
> fix.  In the meantime, the patch below will fix the problem in the short-term.
> I've tested the patch using SMT enabled, SMT disabled, maxcpus=1 and nr_cpus=1.

Thanks Prarit, the work around does the job!  Indeed, I have SMT
disabled.