linux-kernel - Re: [PATCH] genirq: Check irq disabled & masked states in 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: <20170530231956.GA25960@google.com>
Date:   Tue, 30 May 2017 16:20:00 -0700
From:   Brian Norris <briannorris@...omium.org>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     jeffy <jeffy.chen@...k-chips.com>,
        LKML <linux-kernel@...r.kernel.org>, dianders@...omium.org,
        tfiga@...omium.org, Johannes Berg <johannes.berg@...el.com>
Subject: Re: [PATCH] genirq: Check irq disabled & masked states in
 irq_shutdown

Hi,

To address a tangent brought up here:

On Sat, May 27, 2017 at 10:16:37AM +0200, Thomas Gleixner wrote:
> On Sat, 27 May 2017, jeffy wrote:
> > for example when a driver(drivers/net/wireless/marvell/mwifiex/main.c) try to
> > do these:
> > 
> > devm_request_irq->irq_startup->irq_enable
> > disable_irq                                     <-- disabled and masked
> > devm_free_irq->irq_shutdown                     <-- disable it again
> 
> This driver is broken as hell.

No argument on the general statement :)

> It requests the interrupt _BEFORE_ the whole
> thing is initialized. If there is a pending interrupt on that line, it will
> explode nicely before it is able to disable the irq. But that's a different
> problem.

For that particular interrupt, it's mostly an informational interrupt
regarding wakeups. We don't do anything that could blow up there, except
report a (spurious) wakeup event. (And this spurious wakeup event only
occurs because the Wifi firmware may toggle its "wake" pin even when the
system is already awake. A weird behavior...)

So yes, the pattern isn't great, but no, it's not going to blow up,
AFAIK.

However, if you were to look at the same driver's .../mwifiex/pcie.c,
you would see a similar problem, and you *would* be right if you claimed
that things could blow up badly there! mwifiex_pcie_request_irq() is
called much too early, and if an interrupt gets queued up at the wrong
time, we won't handle it very nicely.

Anyway, I just thought I'd mention it, in case someone else following
this thread is curious. Coincidentally, I'm already working on patching
this on linux-wireless@.

Side note: for issues like the first problem above, I wonder why there
isn't a flag that once could pass to request_irq() that suggests the IRQ
should be initially disabled? I know this wouldn't work for shared
interrupts (but request_irq() could reject that combination, no?), but
it seems like there are plenty of cases where it might be useful. Some
devices simply don't have a device-level interrupt mask, and always
expect to have a dedicated interrupt. With the status quo, a driver for
such a device has to defer their request_irq() until
sometimes-inconvient times [1], or else accept some subpar behavior (see
above "spurious wakeup reporting").

Regards,
Brian

[1] Note that, for one, request_irq() can fail, whereas enable_irq()
    cannot.