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
| ||
|
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