From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755742AbbDIOts (ORCPT ); Thu, 9 Apr 2015 10:49:48 -0400 Received: from mail-wg0-f43.google.com ([74.125.82.43]:33621 "EHLO mail-wg0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755722AbbDIOtn (ORCPT ); Thu, 9 Apr 2015 10:49:43 -0400 Date: Thu, 9 Apr 2015 16:49:38 +0200 From: Ingo Molnar To: Thomas Gleixner Cc: Marc Zyngier , "jiang.liu@linux.intel.com" , "linux-kernel@vger.kernel.org" , "hpa@zytor.com" , "linux-tip-commits@vger.kernel.org" Subject: Re: [tip:irq/core] genirq: MSI: Fix freeing of unallocated MSI Message-ID: <20150409144938.GB15910@gmail.com> References: <1422299419-6051-1-git-send-email-marc.zyngier@arm.com> <20150409120023.GA12468@gmail.com> <20150409134246.6442ede0@why.wild-wind.fr.eu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Thomas Gleixner wrote: > On Thu, 9 Apr 2015, Marc Zyngier wrote: > > On Thu, 9 Apr 2015 13:00:23 +0100 > > Ingo Molnar wrote: > > > > > > Hm, so this appears to be the first time that 'irq == 0' assumptions > > > are getting into the genirq core. Is NO_IRQ dead? I realize that the > > > MSI code uses '!irq' as a flag, but still, quite a few architectures > > > define NO_IRQ so it appears to matter to them. > > > > NO_IRQ strikes back, everybody takes cover! ;-) > > > > More seriously, this seems to be two schools of thoughts on that > > one. The irqdomain subsystem seems to treat 'irq == 0' as the > > indication that 'this is not a valid IRQ', and so does MSI (as you > > noticed). Given that this code deals with MSI in conjunction with > > irqdomains, it felt natural to adopt the same convention. > > > > Also, not all the architecture are defining NO_IRQ, and it only > > seems to be used in code that is doesn't look portable across > > architectures. Either these architecture don't care about MSI, or > > they are happy enough to consider that virtual interrupt 0 is > > invalid in the MSI case. > > > > So I'm a bit lost on that one. I sincerely thought NO_IRQ was > > being retired (https://lwn.net/Articles/470820/). Should we > > introduce a NO_MSI_IRQ (set to zero) to take care of this case? > > Nah, that'd be overkill. irq 0 is invalid for MSI in any case so we > really should stick with that convention. That makes sense - should we more aggressively eliminate NO_IRQ perhaps? I'm seeing stuff like: irq = irq_of_parse_and_map(np, 0); if (!handle || (irq == NO_IRQ)) { in fairly recent (2-4 years old) code, and irq_of_parse_and_map() is used in 300+ places. Thanks, Ingo