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: <20110302184053.GW11359@redhat.com>
Date:	Wed, 2 Mar 2011 13:40:53 -0500
From:	Don Zickus <dzickus@...hat.com>
To:	Cyrill Gorcunov <gorcunov@...nvz.org>
Cc:	Ingo Molnar <mingo@...e.hu>, "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

On Wed, Mar 02, 2011 at 07:13:42PM +0300, Cyrill Gorcunov wrote:
> On 03/02/2011 07:03 PM, Ingo Molnar wrote:
> ...
> > 
> > Well, the lock serializes the read-out of the 'NMI reason' port, the handling of 
> > whatever known reason and then the reassertion of the NMI (on 32-bit). 
> > 
> > EDAC has a callback in pci_serr_error() - and this lock serializes that. So we 
> > cannot just remove a lock like that, if there's any chance of parallel execution on 
> > multiple CPUs.
> > 
> > Thanks,
> > 
> > 	Ingo
> 
> OK, probably we need some UV person CC'ed (not sure whom) just to explain the
> reason for such nmi-listening model. Meanwhile -- lets drop my patch.

It's for debugging reasons.  When their huge machine deadlocks, they
wanted an easy mechanism to dump the cpu stacks.  That mechanism was an
nmi button.  The problem was the button would only dump the first cpu.  By
opening up the other cpus to accept external nmis, they could dump all the
cpus.

Now this spinlock doesn't affect them, because they registered an nmi
handler to catch it and dump their stack (I modified the code to use
DIE_NMIUNKNOWN instead of DIE_NMI to avoid conflict with the
nmi_watchdog).  But I don't know what the affect is, if that spinlock is
not there (I sent a private email to SGI inquiring, their guy wasn't
around this week).

Personally I am indifferent to this patch.  I don't have any problems with
the code the way it is now, but can understand what you mean having stuff
lying around as 'dead code'.  I had thought Intel would have pushed more
patches upstream to remove the BSP lock-in by now.

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/