From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760357AbYDYH5s (ORCPT ); Fri, 25 Apr 2008 03:57:48 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754169AbYDYH5k (ORCPT ); Fri, 25 Apr 2008 03:57:40 -0400 Received: from 74-93-104-97-Washington.hfc.comcastbusiness.net ([74.93.104.97]:57054 "EHLO sunset.davemloft.net" rhost-flags-OK-FAIL-OK-OK) by vger.kernel.org with ESMTP id S1752152AbYDYH5j (ORCPT ); Fri, 25 Apr 2008 03:57:39 -0400 Date: Fri, 25 Apr 2008 00:57:38 -0700 (PDT) Message-Id: <20080425.005738.114887644.davem@davemloft.net> To: a.p.zijlstra@chello.nl Cc: mingo@elte.hu, torvalds@linux-foundation.org, linux-kernel@vger.kernel.org, akpm@linux-foundation.org, viro@zeniv.linux.org.uk, alan@lxorguk.ukuu.org.uk, tglx@linutronix.de Subject: Re: [git pull] scheduler/misc fixes From: David Miller In-Reply-To: <1209109710.7115.400.camel@twins> References: <20080424225530.GA8717@elte.hu> <20080424.204620.88617191.davem@davemloft.net> <1209109710.7115.400.camel@twins> X-Mailer: Mew version 5.2 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Peter Zijlstra Date: Fri, 25 Apr 2008 09:48:30 +0200 > c) there are 'IPI' handlers on SPARC64 that look like they can wake > the CPU from idle sleep but do not appear to call irq_enter() which > has the above patch's touch_softlock_watchdog() in its callchain. > > tl0_irq1: TRAP_IRQ(smp_call_function_client, 1) > tl0_irq2: TRAP_IRQ(smp_receive_signal_client, 2) > tl0_irq3: TRAP_IRQ(smp_penguin_jailcell, 3) > tl0_irq4: TRAP_IRQ(smp_new_mmu_context_version_client, 4) > > > > So the current working thesis is that the bug in a) hides a real problem > not quite fixed by b) and exploited by c). The equivalent to smp_receive_signal_client() on x86 (smp_reschedule_interrupt) doesn't do an irq_enter() either. However x86 does do an irq_enter() for smp_call_function() interrupt handling. What is the rule in these cases? Anyways, does the following patch fix the problem? diff --git a/arch/sparc64/kernel/smp.c b/arch/sparc64/kernel/smp.c index 524b889..bf4ef84 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); } }