linux-kernel - Re: [tip:irq/core] genirq: MSI: Fix freeing of unallocated MSI

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20150409144938.GB15910@gmail.com>
Date:	Thu, 9 Apr 2015 16:49:38 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	Marc Zyngier <marc.zyngier@....com>,
	"jiang.liu@...ux.intel.com" <jiang.liu@...ux.intel.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"hpa@...or.com" <hpa@...or.com>,
	"linux-tip-commits@...r.kernel.org" 
	<linux-tip-commits@...r.kernel.org>
Subject: Re: [tip:irq/core] genirq: MSI: Fix freeing of unallocated MSI


* Thomas Gleixner <tglx@...utronix.de> wrote:

> On Thu, 9 Apr 2015, Marc Zyngier wrote:
> > On Thu, 9 Apr 2015 13:00:23 +0100
> > Ingo Molnar <mingo@...nel.org> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/