From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754247Ab0CYTPt (ORCPT ); Thu, 25 Mar 2010 15:15:49 -0400 Received: from smtp1.linux-foundation.org ([140.211.169.13]:33599 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753181Ab0CYTPs (ORCPT ); Thu, 25 Mar 2010 15:15:48 -0400 Date: Thu, 25 Mar 2010 12:10:22 -0700 (PDT) From: Linus Torvalds To: Ingo Molnar cc: Peter Zijlstra , Thomas Gleixner , Andi Kleen , x86@kernel.org, LKML , jesse.brandeburg@intel.com Subject: Re: [PATCH] Prevent nested interrupts when the IRQ stack is near overflowing v2 In-Reply-To: <20100325182930.GA7709@elte.hu> Message-ID: References: <20100324190150.GA18803@basil.fritz.box> <20100325003652.GG20695@one.firstfloor.org> <20100325093744.GH20695@one.firstfloor.org> <1269539254.12097.100.camel@laptop> <20100325182930.GA7709@elte.hu> User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 25 Mar 2010, Ingo Molnar wrote: > > So the patch below should at most trigger bugs in areas that need fixing > anyway, and i'm quite sure that under no circumstance would it cause > unforeseen problems in 'thousands of drivers'. If we do this, then we should just remove all the IRQF_DISABLED code in kernel/irq/manage.c too, and basically make IRQF_DISABLED a clear no-op (still leave it around as a #define, to not break any users). It won't make it any harder to revert if it causes problems, and that way there will be no crazy dead code (and comments) left around. And I just checked: even the 8250 serial driver doesn't use IRQF_DISABLED any more, so doing that shouldn't cause any latency issues (sure, the serial driver may interrupt another irq, but another irq can also interrupt the serial driver as things stand now, so the original latency issue with fast irq handlers doesn't actually work these days _anyway_). Linus