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

Message-ID: <c89f2f3d-5bb1-3e84-e989-bb61a36b3548@redhat.com>
Date:   Wed, 16 Oct 2019 10:41:52 +0200
From:   Hans de Goede <hdegoede@...hat.com>
To:     Thomas Gleixner <tglx@...utronix.de>
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 ?

Hi,

On 10/14/19 2:25 PM, Thomas Gleixner wrote:
> 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.

I see, so the TL;DR: is its complicated. So I guess it is best to leave
this as is, thank you for your explanation.

Regards,

Hans