linux-kernel - Re: [PATCH] x86: Replace uses of current_cpu_data with this

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]

Message-ID: <4CFFBE67.8070809@kernel.org>
Date:	Wed, 08 Dec 2010 18:20:39 +0100
From:	Tejun Heo <tj@...nel.org>
To:	Eric Dumazet <eric.dumazet@...il.com>
CC:	Christoph Lameter <cl@...ux.com>, akpm@...ux-foundation.org,
	Yinghai Lu <yinghai@...nel.org>, Ingo Molnar <mingo@...e.hu>,
	Pekka Enberg <penberg@...helsinki.fi>,
	linux-kernel@...r.kernel.org,
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Subject: Re: [PATCH] x86: Replace uses of current_cpu_data with this_cpu ops

Hello,

On 12/08/2010 06:17 PM, Eric Dumazet wrote:
> Le mercredi 08 décembre 2010 à 09:33 -0600, Christoph Lameter a écrit :
>> On Wed, 8 Dec 2010, Eric Dumazet wrote:
>>
>>>> In the long run, it might be a good idea to remove cpu_data() macro
>>>> too and use per_cpu macro directly.
>>>>
>>>
>>> or introduce this_cpu_has() to remove the adress computation
>>>
>>> -	if (cpu_has(__this_cpu_ptr(&cpu_info), X86_FEATURE_ARAT)) {
>>>
>>> +	if (this_cpu_has(X86_FEATURE_ARAT)) {
>>>
>>
>> The fundamental problem is that bitops require memory addresses which does
>> not work with per cpu ops.
>>
> 
> Sure, set() or clear() needs the address, but the read doesnt ?
> 
> This can be implemented as
> 
>   (__this_cpu_read(cpu_info.word[X]) & MASK)
> 
> Anyway, even if mapped to cpu_has(__this_cpu_ptr(&cpu_info), XXX), 
> it would be cleaner to use this_cpu_has() helper.

Agreed.  I'd also like to see cpu_data() gone too.  It isn't used too
many times and mixed with direct percpu ops only makes things more
confusing without much benefit.  Does somebody care to send patches
for these cleanups?

Thanks.

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