linux-kernel - Re: Is IRQ number 0 a valid IRQ ?

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.21.1910141414210.2531@nanos.tec.linutronix.de>
Date:   Mon, 14 Oct 2019 14:25:28 +0200 (CEST)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Hans de Goede <hdegoede@...hat.com>
cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: Is IRQ number 0 a valid IRQ ?

Hans,

On Sat, 5 Oct 2019, Hans de Goede wrote:

> This is something which I have been wondering for ever since there are
> several places in the kernel where IRQ number 0 is treated as not being
> valid (as no IRQ found mostly I guess). Where as other places do treat
> IRQ number 0 as valid... ?

IRQ0 is a historical x86 nuisance. On x86 irq0 is still valid - it's the
legacy timer irq. I'd be happy to fix that up, but there are quite some
assumptions vs. the irq numbering of the x86 legacy interrupt numbers in
general. BIOS/ACPI has them hard coded as well, so it's not entirely
trivial to fix that up.

For everything else than x86 (and maybe ia64( irq 0 should not exist and DT
based irq enumeration treated it as invalid interrupt number forever.

Though there were some old ARM subarchs which used to have hardcoded legacy
interrupt numbers including 0 as well.

> Some examples which treat IRQ 0 special:
> 
> drivers/base/platform.c: __platform_get_irq() :
> 
>         if (IS_ENABLED(CONFIG_OF_IRQ) && dev->dev.of_node) {
>                 int ret;
> 
>                 ret = of_irq_get(dev->dev.of_node, num);
>                 if (ret > 0 || ret == -EPROBE_DEFER)
>                         return ret;
>         }
> 
> Note if (ret > 0) not if (ret >= 0)

Yeah. It makes the code fall through when ret == 0 so it can try the other
methods. What a mess...

> Other example: drivers/usb/dwc3/gadget.c: dwc3_gadget_get_irq() :
> 
>         if (!irq)
>                 irq = -EINVAL;

That one translates irq0 into an error code.

> So 2 questions:
> 
> 1) Is this special handling of IRQ number 0 valid code, or just
> mostly some leftover from older days when IRQ number 0 was maybe
> special ?

Kinda both.

> 2) Either way (*) I think we (I volunteer) should document this somewhere,
> other then adding a note about this to the platform_get_irq docs any
> other place where it would be good to specify this?
> 
> *) Either IRQ number 0 is not special and then we need to stop the
> cargo-culting of treating it special, or it is special and then we
> need to document that.

One way to solve it would be to change the '0' return value from the core
functions (irqdomain) to -EINVAL or such, but that needs some thorough
analysis whether there is valid irq 0 usage outside of x86/ia64.

Thanks,

	tglx