linux-kernel - Re: 'global' rq->clock

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: <20080503.163600.93588714.davem@davemloft.net>
Date:	Sat, 03 May 2008 16:36:00 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	mingo@...e.hu
Cc:	benh@...nel.crashing.org, a.p.zijlstra@...llo.nl, efault@....de,
	elendil@...net.nl, parag.warudkar@...il.com,
	linux-kernel@...r.kernel.org, guichaz@...oo.fr, andi@...stfloor.org
Subject: Re: 'global' rq->clock

From: David Miller <davem@...emloft.net>
Date: Sat, 03 May 2008 16:04:08 -0700 (PDT)

> From: Ingo Molnar <mingo@...e.hu>
> Date: Sun, 4 May 2008 00:38:44 +0200
> 
> > the same bug existed on x86 too: that too does a few IPIs without 
> > irq_enter/irq_exit. We now removed the softlockup dependency so it 
> > should not be required to do an irq_enter()/exit anymore - unless the 
> > code that the IPI uses accesses jiffies. (but that would be unusual)
> 
> That move doesn't solve the problem, I'm strongly certain
> arch's still need to add the irq_{enter,exit}().
> 
> I'll revert the irq_{enter,exit}() changes on one of my
> sparc64 boxes to validate this later today.

False alarm, which is good news, thanks Ingo.  I can revert
the following it seems:

commit 2664ef44cf5053d2b7dff01cecac70bc601a5f68
Author: David S. Miller <davem@...emloft.net>
Date:   Fri Apr 25 03:11:37 2008 -0700

    [SPARC64]: Wrap SMP IPIs with irq_enter()/irq_exit().
    
    Otherwise all sorts of bad things can happen, including
    spurious softlockup reports.
    
    Other platforms have this same bug, in one form or
    another, just don't see the issue because they
    don't sleep as long as sparc64 can in NOHZ.
    
    Thanks to some brilliant debugging by Peter Zijlstra.
    
    Signed-off-by: David S. Miller <davem@...emloft.net>

diff --git a/arch/sparc64/kernel/smp.c b/arch/sparc64/kernel/smp.c
index 524b889..409dd71 100644
--- a/arch/sparc64/kernel/smp.c
+++ b/arch/sparc64/kernel/smp.c
@@ -866,14 +866,21 @@ void smp_call_function_client(int irq, struct pt_regs *regs)
 	void *info = call_data->info;
 
 	clear_softint(1 << irq);
+
+	irq_enter();
+
+	if (!call_data->wait) {
+		/* let initiator proceed after getting data */
+		atomic_inc(&call_data->finished);
+	}
+
+	func(info);
+
+	irq_exit();
+
 	if (call_data->wait) {
 		/* let initiator proceed only after completion */
-		func(info);
 		atomic_inc(&call_data->finished);
-	} else {
-		/* let initiator proceed after getting data */
-		atomic_inc(&call_data->finished);
-		func(info);
 	}
 }
 
@@ -1032,7 +1039,9 @@ void smp_receive_signal(int cpu)
 
 void smp_receive_signal_client(int irq, struct pt_regs *regs)
 {
+	irq_enter();
 	clear_softint(1 << irq);
+	irq_exit();
 }
 
 void smp_new_mmu_context_version_client(int irq, struct pt_regs *regs)
@@ -1040,6 +1049,8 @@ void smp_new_mmu_context_version_client(int irq, struct pt_regs *regs)
 	struct mm_struct *mm;
 	unsigned long flags;
 
+	irq_enter();
+
 	clear_softint(1 << irq);
 
 	/* See if we need to allocate a new TLB context because
@@ -1059,6 +1070,8 @@ void smp_new_mmu_context_version_client(int irq, struct pt_regs *regs)
 	load_secondary_context(mm);
 	__flush_tlb_mm(CTX_HWBITS(mm->context),
 		       SECONDARY_CONTEXT);
+
+	irq_exit();
 }
 
 void smp_new_mmu_context_version(void)
@@ -1217,6 +1230,8 @@ void smp_penguin_jailcell(int irq, struct pt_regs *regs)
 {
 	clear_softint(1 << irq);
 
+	irq_enter();
+
 	preempt_disable();
 
 	__asm__ __volatile__("flushw");
@@ -1229,6 +1244,8 @@ void smp_penguin_jailcell(int irq, struct pt_regs *regs)
 	prom_world(0);
 
 	preempt_enable();
+
+	irq_exit();
 }
 
 /* /proc/profile writes can call this, don't __init it please. */
--
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/