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: <20101130205257.GD20818@lenovo>
Date:	Tue, 30 Nov 2010 23:52:57 +0300
From:	Cyrill Gorcunov <gorcunov@...il.com>
To:	Tejun Heo <tj@...nel.org>
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 Tue, Nov 30, 2010 at 08:42:27PM +0100, Tejun Heo wrote:
...
> 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

well, i take the opposite, if function is not ever supposed to be called
outside of cpu it runs on there should not be references even in local
variables outside of preempt scope (even if we know that it is safe
to cache 'cpu' early), but I think this is a question of habbit :)

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

*sure*, as one Ingo merge it we would be able to clean it a bit on top

[ in particular I believe we should preempt disable at the very beginning
  on the function and use cached cpu then until the preemption gets on
  at the end, and we would cover cmci_recheck with cached cpu as well.
  this would eliminate all the questions I believe ]

> 
> Thanks.
> 
> -- 
> tejun
> 
  Cyrill
--
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/