linux-kernel - Re: [PATCH -tip 2/2 resend] x86, traps: Drop nmi_reason

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: <20110302154645.GA11827@elte.hu>
Date:	Wed, 2 Mar 2011 16:46:45 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Cyrill Gorcunov <gorcunov@...nvz.org>
Cc:	Don Zickus <dzickus@...hat.com>,
	"Huang, Ying" <ying.huang@...el.com>,
	"Maciej W. Rozycki" <macro@...ux-mips.org>,
	lkml <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH -tip 2/2 resend] x86, traps: Drop nmi_reason_lock until
 it is really needed


* Cyrill Gorcunov <gorcunov@...nvz.org> wrote:

> At moment we have only BSP apic configured to listen
> for external NMIs. So there is no reason for additional
> spinlock since only BSP will receive them.
> 
> Though we still have UV chips which do enable external NMIs
> on all cpus, but since an approach to allow retrieving
> NMI reason on BSP only was working pretty fine before --
> I assume it still remains valid.

I'm not sure I get the point here: we might get NMIs on non-BSP on UV
systems ... so we want to remove the spinlock?

If UV systems can get NMIs on any CPU then the lock is needed.

It might have worked before - but UV systems are rare and relatively
new - plus the race window is small, so it might not have been triggered
in practice.

> Also it's worth to mention that an initial idea of all this
> NMI code-path changes was to make BSP hot-unpluggable but
> until all other parts of kernel is prepared for it (which
> might consume quite a time to implement) I believe we should
> not lock/unlock for nothing.

That would be another argument in favor of keeping the lock, right?

Thanks,

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