linux-kernel - Re: [PULL -- 5.1 REGRESSION] Bluetooth: btusb: request wake pin with NOAUTOEN

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]

Date:   Tue, 9 Apr 2019 16:20:33 -1000
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Brian Norris <briannorris@...omium.org>
Cc:     Marcel Holtmann <marcel@...tmann.org>,
        Johan Hedberg <johan.hedberg@...il.com>,
        linux-bluetooth <linux-bluetooth@...r.kernel.org>,
        Linux List Kernel Mailing <linux-kernel@...r.kernel.org>,
        Matthias Kaehlcke <mka@...omium.org>,
        Rajat Jain <rajatja@...gle.com>,
        Heiko Stuebner <heiko@...ech.de>
Subject: Re: [PULL -- 5.1 REGRESSION] Bluetooth: btusb: request wake pin with NOAUTOEN

On Tue, Apr 9, 2019 at 8:49 AM Brian Norris <briannorris@...omium.org> wrote:
>
> Badly-designed systems might have (for example) active-high wake pins
> that default to high (e.g., because of external pull ups) until they
> have an active firmware which starts driving it low. This can cause an
> interrupt storm in the time between request_irq() and disable_irq().

Why is the fix not to move the request_irq() down to below the proper
initialization sequence?

That's what drivers *should* do: initialize their hardware first,
request interrupts only after that. Initializing the interrupt handler
before the hw is actually up seems wrong..

              Linus