linux-kernel - Re: [RFC 4/6] x86, NMI, Rewrite NMI handler

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: <20100913140419.GA27371@redhat.com>
Date:	Mon, 13 Sep 2010 10:04:19 -0400
From:	Don Zickus <dzickus@...hat.com>
To:	Huang Ying <ying.huang@...el.com>
Cc:	Andi Kleen <andi@...stfloor.org>, Ingo Molnar <mingo@...e.hu>,
	"H. Peter Anvin" <hpa@...or.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC 4/6] x86, NMI, Rewrite NMI handler

On Mon, Sep 13, 2010 at 10:09:30AM +0800, Huang Ying wrote:
> > The reason I asked was, I thought it would be easier to have a global
> > variable that tells the nmi handler which cpu has the NMI's routed to its
> > io port.  This way if you want to swap out the bsp cpu, you could perhaps
> > just re-route the nmi to a new cpu and the global variable would be
> > updated accordingly?
> 
> Then we need some kind of protection or race condition between
> re-routing NMI and updating the variable. Do you think so?

Well, I thought the only reasonable place to update the variable is when
the cpu is being taken offline, during the MTRR update.  Since no NMIs can
be processed when the cpu's are syncing their MTRR, there shouldn't be a
race condition, no?

Then again I am probably missing something obvious.  Like I don't know how
cpu's deal with interrupts/NMIs when they are going offline.

It was just a thought to avoid the spinlock.

Cheers,
Don
--
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/