linux-kernel - Re: [PATCH v6 1/5] x86: Move per cpu cpu_llc_shared_map to a field in struct cpuinfo

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, 30 Apr 2012 12:05:50 -0300
From:	Kevin Winchester <kjwinchester@...il.com>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Ingo Molnar <mingo@...e.hu>, Thomas Gleixner <tglx@...utronix.de>,
	Borislav Petkov <bp@...en8.de>,
	Randy Dunlap <rdunlap@...otime.net>,
	Nick Bowler <nbowler@...iptictech.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v6 1/5] x86: Move per cpu cpu_llc_shared_map to a field in
 struct cpuinfo_x86

On 29 April 2012 20:37, H. Peter Anvin <hpa@...or.com> wrote:
> On 04/29/2012 04:33 PM, Kevin Winchester wrote:
>> Commit 141168c36cde ("x86: Simplify code by removing a !SMP #ifdefs from
>> 'struct cpuinfo_x86'") caused the compilation error:
>>
>> mce_amd.c:(.cpuinit.text+0x4723): undefined reference to 'cpu_llc_shared_map'
>>
>> by removing an #ifdef CONFIG_SMP around a block containing a reference
>> to cpu_llc_shared_map.  Rather than replace the #ifdef, move
>> cpu_llc_shared_map to be a new cpumask_t field llc_shared_map in
>> struct cpuinfo_x86 and adjust all references to cpu_llc_shared_map.
>>
>
> Okay...  I must not get this.
>
> Why is this better than just moving the DEFINE_PER_CPU to a place which
> isn't dependent on SMP?
>

To be honest, the idea was suggested by Ingo a while back, and I just
volunteered to implement it.  I believe the idea was to work towards
gathering all CPU-specific data for SMP and !SMP into one place.  That
said, moving the DEFINE_PER_CPU elsewhere would likely still give the
same benefits as my patch in terms of ifdef reduction.  I cannot
really see a benefit/downside either way, really.

Perhaps Ingo will chime in, and you and he (and anyone else with an
opinion) can figure out the best way of accomplishing this
simplification, and then I can adjust my series accordingly.

-- 
Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/