linux-kernel - threadirqs deadlocks

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

Date:   Tue, 16 Mar 2021 11:56:56 +0100
From:   Johan Hovold <johan@...nel.org>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     Krzysztof Kozlowski <krzysztof.kozlowski@...onical.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Andy Shevchenko <andy.shevchenko@...il.com>,
        linux-serial@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: threadirqs deadlocks

Hi Thomas,

We've gotten reports of lockdep splats correctly identifying a potential
deadlock in serial drivers when running with forced interrupt threading.

Typically, a serial driver takes the port spin lock in its interrupt
handler, but unless also disabling interrupts the handler can be
preempted by another interrupt which can end up calling printk. The
console code takes then tries to take the port lock and we deadlock.

It seems to me that forced interrupt threading cannot generally work
without updating drivers that expose locks that can be taken by other
interrupt handlers, for example, by using spin_lock_irqsave() in their
interrupt handlers or marking their interrupts as IRQF_NO_THREAD.

What are your thoughts on this given that forced threading isn't that
widely used and was said to be "mostly a debug option". Do we need to
vet all current and future drivers and adapt them for "threadirqs"?

Note that we now have people sending cleanup patches for interrupt
handlers by search-and-replacing spin_lock_irqsave() with spin_lock()
which can end up exposing this more.

Johan