linux-kernel - Re: [PATCH] i2c: s3c2410: Properly handle interrupts of number 0

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]

Date:   Sat, 3 Mar 2018 18:36:14 +0000
From:   Russell King - ARM Linux <linux@...linux.org.uk>
To:     Andy Shevchenko <andy.shevchenko@...il.com>
Cc:     Mark Rutland <mark.rutland@....com>,
        Dan Carpenter <dan.carpenter@...cle.com>,
        linux-samsung-soc@...r.kernel.org,
        Wolfram Sang <wsa@...-dreams.de>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Krzysztof Kozlowski <krzk@...nel.org>,
        Kukjin Kim <kgene@...nel.org>,
        linux-i2c <linux-i2c@...r.kernel.org>,
        Ben Dooks <ben-linux@...ff.org>,
        Stable <stable@...r.kernel.org>,
        linux-arm Mailing List <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH] i2c: s3c2410: Properly handle interrupts of number 0

On Sat, Mar 03, 2018 at 06:25:17PM +0200, Andy Shevchenko wrote:
> On Fri, Mar 2, 2018 at 6:28 PM, Mark Rutland <mark.rutland@....com> wrote:
> > On Fri, Mar 02, 2018 at 03:32:22PM +0000, Russell King - ARM Linux wrote:
> >> How do we break this status quo and finally solve the IRQ 0 and
> >> NO_IRQ issue?
> 
> Guys, the question: Wouldn't be request_irq() failed when it gets a
> wrong number on input?

Unfortunately not - IRQ 0 is kind of valid on x86 (it's the i8253 PIT)
and an exception is made for x86 arch code with regard to this.  It
gets setup using setup_irq() rather than request_irq() (see
arch/x86/kernel/time.c::setup_default_timer_irq()).

request_irq() doesn't deny IRQ 0 - it denies IRQ_NOTCONNECTED and
anything that irq_to_desc() returns NULL for, which can be a radix
tree lookup or simply any unsigned IRQ number less than NR_IRQS for
legacy platforms.

If you're on a DT platform, then the IRQ subsystem avoids allocating
IRQ0 for any DT IRQ controller, so DT platforms should be fine.  It's
just the legacy platforms that continue to be an ongoing issue wrt
the IRQ 0 / NO_IRQ business, and those will generally be using the
non-radix tree version of irq_to_desc().

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up