linux-kernel - Re: [PATCH UPDATED#2 04/16] x86: Use local variable to cache smp_processor_id() in setup_local

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: <4CF553A3.8030000@kernel.org>
Date:	Tue, 30 Nov 2010 20:42:27 +0100
From:	Tejun Heo <tj@...nel.org>
To:	Cyrill Gorcunov <gorcunov@...il.com>
CC:	linux-kernel@...r.kernel.org, mingo@...hat.com, tglx@...utronix.de,
	hpa@...or.com, x86@...nel.org, eric.dumazet@...il.com,
	yinghai@...nel.org, brgerst@...il.com, penberg@...nel.org
Subject: Re: [PATCH UPDATED#2 04/16] x86: Use local variable to cache	smp_processor_id()
 in setup_local_APIC()

On 11/30/2010 07:22 PM, Cyrill Gorcunov wrote:
> On Tue, Nov 30, 2010 at 07:11:45PM +0100, Tejun Heo wrote:
>> This is a trivial clean up.
>>
>> * Move initialization of @cpu inside preemption disabled region as
>>   suggested by Cyrill Gorcunov.
>>
>> Signed-off-by: Tejun Heo <tj@...nel.org>
>> Cc: Yinghai Lu <yinghai@...nel.org>
>> Cc: Cyrill Gorcunov <gorcunov@...il.com>
>> ---
>> Alright, updated yet again, but I frankly don't see the point in these
> 
> code structure, if we would be referring variable taken inside preempt
> off this always look suspicious, i think you agree with me :)

Not really.  smp_processor_id() outside of preemption/irq disabled
area is suspicious exactly the same and having @cpu initialized at the
head of the function has the advantage of making it clear that the
function as a whole is special w.r.t. which cpu it runs on.  In fact,
I think it's actually worse to put it inside preemption disabled area
as it gives the wrong impression that the function isn't special and
might be able to handle being called from another cpu.  In fact,
caching smp_processor_id() in @cpu is better than calling it every
time as it makes it clear that the function is bound to that cpu.

That said, I really don't think this matters one way or the other.
This function is called during smp bring up to initialize the CPU.
Things don't get much more arch/cpu dependent than this and the code
is thoroughly tested on each and every boot and power management
operations.  How @cpu is cached and used just doesn't matter, which is
why I didn't really care about it and changed as suggested.  So, let's
just let it go.

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/