Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754492Ab3ITWOI (ORCPT ); Fri, 20 Sep 2013 18:14:08 -0400 Received: from mail-vc0-f178.google.com ([209.85.220.178]:62654 "EHLO mail-vc0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752824Ab3ITWOG (ORCPT ); Fri, 20 Sep 2013 18:14:06 -0400 MIME-Version: 1.0 In-Reply-To: <20130920162603.GA30381@localhost.localdomain> References: <1379620267-25191-1-git-send-email-fweisbec@gmail.com> <20130920162603.GA30381@localhost.localdomain> Date: Fri, 20 Sep 2013 15:14:05 -0700 X-Google-Sender-Auth: T9e81RVlTSmmDyRbdElw6JiP3ac Message-ID: Subject: Re: [RFC GIT PULL] softirq: Consolidation and stack overrun fix From: Linus Torvalds To: Frederic Weisbecker Cc: Thomas Gleixner , LKML , Benjamin Herrenschmidt , Paul Mackerras , Ingo Molnar , Peter Zijlstra , "H. Peter Anvin" , James Hogan , "James E.J. Bottomley" , Helge Deller , Martin Schwidefsky , Heiko Carstens , "David S. Miller" , Andrew Morton Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1460 Lines: 33 On Fri, Sep 20, 2013 at 9:26 AM, Frederic Weisbecker wrote: > > Now just for clarity, what do we then do with inline sofirq executions: on local_bh_enable() > for example, or explicit calls to do_softirq() other than irq exit? If we do a softirq because it was pending and we did a "local_bh_enable()" in normal code, we need a new stack. The "local_bh_enable()" may be pretty deep in the callchain on a normal process stack, so I think it would be safest to switch to a separate stack for softirq handling. So you have a few different cases: - irq_exit(). The irq stack is by definition empty (assuming itq_exit() is done on the irq stack), so doing softirq in that context should be fine. However, that assumes that if we get *another* interrupt, then we'll switch stacks again, so this does mean that we need two irq stacks. No, irq's don't nest, but if we run softirq on the first irq stack, the other irq *can* nest that softirq. - process context doing local_bh_enable, and a bh became pending while it was disabled. See above: this needs a stack switch. Which stack to use is open, again assuming that a hardirq coming in will switch to yet another stack. Hmm? Linus -- 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/