linux-kernel - Re: [PATCH 1/3] x86: only call smp_processor

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: <20101118153546.GA15430@redhat.com>
Date:	Thu, 18 Nov 2010 10:35:46 -0500
From:	Don Zickus <dzickus@...hat.com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Frédéric Weisbecker <fweisbec@...il.com>
Subject: Re: [PATCH 1/3] x86: only call smp_processor_id in non-preempt cases

On Thu, Nov 18, 2010 at 03:49:21PM +0100, Ingo Molnar wrote:
> 
> * Don Zickus <dzickus@...hat.com> wrote:
> 
> > On Thu, Nov 18, 2010 at 09:14:07AM +0100, Ingo Molnar wrote:
> > > 
> > > * Don Zickus <dzickus@...hat.com> wrote:
> > > 
> > > > There are some paths that walk the die_chain with preemption on.
> > > 
> > > What are those codepaths? At minimum it's worth documenting them.
> > 
> > Well the one that caused the bug was do_general_protection which walks the
> > die_chain with DIE_GPF.
> > 
> > I can document them, though it might be time consuming to audit them and hope they 
> > don't change.
> 
> Listing one example is enough.
> 
> > [...]  I guess my bigger question is, is it expected that anyone who calls the 
> > die_chain to have preemption disabled?  If not, then does it matter if we document 
> > it?
> 
> Yes, it might be a bug to call those handlers with preemption on (or even with irqs 
> on). But if the code is fine as-is then documenting a single example would be nice.
> 

Is this better?

Cheers, 
Don

------------------------------------->
From: Don Zickus <dzickus@...hat.com>
Date: Mon, 1 Nov 2010 13:34:33 -0400
Subject: [PATCH 1/6] x86: only call smp_processor_id in non-preempt cases

There are some paths that walk the die_chain with preemption on.
Make sure we are in an NMI call before we start doing anything.

This was triggered by do_general_protection calling notify_die with
DIE_GPF.

Reported-by: Jan Kiszka <jan.kiszka@....de>
Signed-off-by: Don Zickus <dzickus@...hat.com>
---
 arch/x86/kernel/apic/hw_nmi.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/arch/x86/kernel/apic/hw_nmi.c b/arch/x86/kernel/apic/hw_nmi.c
index 5c4f952..ef4755d 100644
--- a/arch/x86/kernel/apic/hw_nmi.c
+++ b/arch/x86/kernel/apic/hw_nmi.c
@@ -49,7 +49,7 @@ arch_trigger_all_cpu_backtrace_handler(struct notifier_block *self,
 {
 	struct die_args *args = __args;
 	struct pt_regs *regs;
-	int cpu = smp_processor_id();
+	int cpu;
 
 	switch (cmd) {
 	case DIE_NMI:
@@ -60,6 +60,7 @@ arch_trigger_all_cpu_backtrace_handler(struct notifier_block *self,
 	}
 
 	regs = args->regs;
+	cpu = smp_processor_id();
 
 	if (cpumask_test_cpu(cpu, to_cpumask(backtrace_mask))) {
 		static arch_spinlock_t lock = __ARCH_SPIN_LOCK_UNLOCKED;
-- 
1.7.3.2

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