Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754504Ab2ETMTj (ORCPT ); Sun, 20 May 2012 08:19:39 -0400 Received: from mail-pz0-f46.google.com ([209.85.210.46]:44083 "EHLO mail-pz0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754200Ab2ETMTh (ORCPT ); Sun, 20 May 2012 08:19:37 -0400 Date: Sun, 20 May 2012 20:19:26 +0800 From: Yong Zhang To: Christophe Huriaux Cc: Uwe =?utf-8?Q?Kleine-K=EF=BF=BDnig?= , linux-rt-users@vger.kernel.org, Thomas Gleixner , Steven Rostedt , linux-kernel@vger.kernel.org, Andreas Mohr Subject: [PATCH v2] genirq: don't sync irq thread if current happen to be the very irq thread Message-ID: <20120520121926.GA24585@zhy> Reply-To: Yong Zhang References: <20120509174931.GB31844@pengutronix.de> <20120520052731.GA3864@zhy> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20120520052731.GA3864@zhy> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3462 Lines: 90 On Sun, May 20, 2012 at 01:27:31PM +0800, Yong Zhang wrote: > --- a/kernel/irq/manage.c > +++ b/kernel/irq/manage.c > @@ -41,6 +41,7 @@ early_param("threadirqs", setup_forced_irqthreads); > void synchronize_irq(unsigned int irq) > { > struct irq_desc *desc = irq_to_desc(irq); > + struct irqaction *action = desc->action; Bad time for dereferencing *action. --- From: Yong Zhang Date: Sun, 20 May 2012 12:56:46 +0800 Subject: [PATCH v2] genirq: don't sync irq thread if current happen to be the very irq thread Christophe reported against -rt http://marc.info/?l=linux-rt-users&m=133665600214984&w=2 BUG: scheduling while atomic: irq/37-s3c-mci/253/0x00000102 Modules linked in: [] (unwind_backtrace+0x0/0x12c) from [] (__schedule+0x58/0x2c0) [] (__schedule+0x58/0x2c0) from [] (schedule+0x8c/0xb0) [] (schedule+0x8c/0xb0) from [] (synchronize_irq+0xbc/0xd8) [] (synchronize_irq+0xbc/0xd8) from [] (pio_tasklet+0x34/0x11c) [] (pio_tasklet+0x34/0x11c) from [] (__tasklet_action+0x68/0x80) [] (__tasklet_action+0x68/0x80) from [] (__do_softirq+0x88/0x130) [] (__do_softirq+0x88/0x130) from [] (do_softirq+0x48/0x54) [] (do_softirq+0x48/0x54) from [] (local_bh_enable+0x8c/0xc0) [] (local_bh_enable+0x8c/0xc0) from [] (irq_forced_thread_fn+0x4c/0x54) [] (irq_forced_thread_fn+0x4c/0x54) from [] (irq_thread+0xa0/0x1c0) [] (irq_thread+0xa0/0x1c0) from [] (kthread+0x84/0x8c) [] (kthread+0x84/0x8c) from [] (kernel_thread_exit+0x0/0x8) Whe looking at this issue, I find that there is a typical deadlock scenario with forced treaded irq, irq_forced_thread_fn() local_bh_enable(); do_softirq(); disable_irq(); synchronize_irq(); wait_event(); /*DEAD*/ Cure it by unsync if current happen to be the very irq thread. Reported-by: Christophe Huriaux Signed-off-by: Yong Zhang Cc: Steven Rostedt Cc: Thomas Gleixner --- kernel/irq/manage.c | 10 ++++++++++ 1 files changed, 10 insertions(+), 0 deletions(-) diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c index 89a3ea8..7a48f74 100644 --- a/kernel/irq/manage.c +++ b/kernel/irq/manage.c @@ -41,6 +41,7 @@ early_param("threadirqs", setup_forced_irqthreads); void synchronize_irq(unsigned int irq) { struct irq_desc *desc = irq_to_desc(irq); + struct irqaction *action; bool inprogress; if (!desc) @@ -67,7 +68,16 @@ void synchronize_irq(unsigned int irq) /* * We made sure that no hardirq handler is running. Now verify * that no threaded handlers are active. + * But for theaded irq, we don't sync if current happens to be + * the irq thread; otherwise we could deadlock. */ + action = desc->action; + while (action) { + if (action->thread && action->thread == current) + return; + action = action->next; + } + wait_event(desc->wait_for_threads, !atomic_read(&desc->threads_active)); } EXPORT_SYMBOL(synchronize_irq); -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/