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-next>] [day] [month] [year] [list]
Date:	Mon, 9 May 2016 14:39:34 -0400
From:	Josef Bacik <jbacik@...com>
To:	<tglx@...utronix.de>
CC:	LKML <linux-kernel@...r.kernel.org>,
	kernel-team <Kernel-team@...com>
Subject: Regression introduced by cf6d445f68974d0b15a14cf6021be38a91f2b5d8

Hello,

I've hit a regression that was introduced by the commit in $SUBJECT. I'm 
building a minimal kernel config that doesn't have CONFIG_SMP set, which 
results in the topology for the box to look different than with 
CONFIG_SMP set. Specifically boot_cpu_data.x86_max_cores comes out to 16 
without CONFIG_SMP set, but 12 with CONFIG_SMP set. So when we are doing 
the init for the uncore_msr_uncores types we panic when trying to do 
uncore_box_init on the 13th box for hswep_uncore_cbox when doing the 
wrmsrl in snbep_uncore_msr_init_box(). I'm hoping this makes sense to 
you, because this is all greek to me. For now I've just enabled 
CONFIG_SMP (it only adds like .1 mb to my image), but I figure we should 
probably fix this. It takes me no time to reproduce so I can test 
whatever patch you come up with, or run whatever debugging you want me 
to run. Thanks,

Josef

Powered by blists - more mailing lists