linux-kernel - Re: [patch] x86: Rendezvous all the cpu's for MTRR/PAT init

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: <20090819075034.GD30325@wotan.suse.de>
Date:	Wed, 19 Aug 2009 09:50:34 +0200
From:	Nick Piggin <npiggin@...e.de>
To:	Suresh Siddha <suresh.b.siddha@...el.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Shaohua Li <shaohua.li@...el.com>,
	"mingo@...e.hu" <mingo@...e.hu>, "hpa@...or.com" <hpa@...or.com>,
	"tglx@...utronix.de" <tglx@...utronix.de>,
	"Pallipadi, Venkatesh" <venkatesh.pallipadi@...el.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [patch] x86: Rendezvous all the cpu's for MTRR/PAT init

On Tue, Aug 18, 2009 at 11:20:57PM -0700, Suresh B wrote:
> To make it clean I can move the smp_store_cpu_info() call before
> local_irq_disable() in smp_callin(). But that needs more changes (for
> xen etc). So thinking more, I think it is safe to do smp_call_function()
> with interrupts disabled as the caller is currently not in the
> cpu_online_mask.
> 
> i.e., no one else sends smp_call_function interrupt to this AP who is
> doing smp_call_function() with interrupts disabled and as such there
> won't be any deadlocks typically associated with calling
> smp_call_function() with interrupts disabled. Copied Nick to confirm or
> correct my understanding.
> 
> New patch appended removes this irq enable/disable sequence around
> mtrr_ap_init() and add's a cpu_online() check in smp_call_function
> warn-on's.

Yes this seems like a fine idea to me. Maybe also add a
WARN_ON(cpu_online) in the interrupt-side as well just to
make it clear.

If you split the patch out with its own changelog and give
a comment for the special case, then you can add an
Acked-by: Nick Piggin <npiggin@...e.de>

Although until you get acks from all arch maintainers, the
functionality would have to only be used on a per-arch basis
but that's probably OK as it's a pretty tricky thing for
generic code to be doing :)


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