linux-kernel - Re: [x86 this_cpu_has V1 2/4] x86: Avoid passing struct cpuinfo pointer to mce

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] [day] [month] [year] [list]

Date:	Sat, 12 Mar 2011 12:41:01 +0100
From:	Tejun Heo <tj@...nel.org>
To:	Christoph Lameter <cl@...ux.com>
Cc:	akpm@...ux-foundation.org, Pekka Enberg <penberg@...helsinki.fi>,
	linux-kernel@...r.kernel.org,
	Eric Dumazet <eric.dumazet@...il.com>,
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	x86@...nel.org
Subject: Re: [x86 this_cpu_has V1 2/4] x86: Avoid passing struct cpuinfo
 pointer to mce_available

On Fri, Mar 11, 2011 at 10:23:12AM -0600, Christoph Lameter wrote:
> If we do not pass the pointer to cpuinfio to mce available then its possible
> to use this_cpu_has.
> 
> There are two use cases of mce_available: One with the current processor
> and one with the boot cpu. Define a function for both cases. However, there
> is only one case in which boot_mce_available is used. If we somehow can
> get rid of that then the patch could be simplified.
> 
> Signed-off-by: Christoph Lameter <cl@...ux.com>

Christoph, I'm not sure about this one.  None of the conversions is in
hot path, which would be okay if the resulting code was simpler but,
well, it isn't necessarily worse but not distinctively better either,
so I fail to see the merits of this conversion.  I'll resend the other
three towards x86 tree.

Thank you.

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