linux-kernel - Re: recommended use of request_any_context

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:   Thu, 22 Sep 2016 16:52:14 -0500
From:   Leo Li <pku.leo@...il.com>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     Marc Zyngier <marc.zyngier@....com>,
        Marc Zyngier <maz@...terjones.org>,
        lkml <linux-kernel@...r.kernel.org>
Subject: Re: recommended use of request_any_context_irq()

On Thu, Sep 22, 2016 at 3:47 PM, Thomas Gleixner <tglx@...utronix.de> wrote:
> On Thu, 22 Sep 2016, Leo Li wrote:
>> On Thu, Sep 22, 2016 at 3:10 AM, Marc Zyngier <marc.zyngier@....com> wrote:
>> > There is strictly no reason to perform a blanket change of all the
>> > drivers. What would be the reason to change them other than to cater for
>> > a contrived use case that may never happen?
>>
>> Maybe we could do blanket change to drivers that meet certain
>> criteria?  At least we should improve the messaging when a driver
>> cannot request interrupt due to nested threading.
>
> Nested threading is a result of requesting an any context interrupt not
> something which is there already.
>
>> Right now, it might take quite some time for a developer unfamiliar with
>> the threaded interrupt to figure out the problem.
>
> Did you have issues with a driver which was not able to request an
> interrupt? If yes, please explain in detail what the failure was and why
> you think that this should be changed. If not, please explain which problem
> you are trying to solve.

My problem was with sc16is7xx, an SPI-to-UART
device(drivers/tty/serial/sc16is7xx.c), the interrupt of it is
connected together with interrupts from other on-board devices to a
GPIO expander (drivers/gpio/gpio-pca953x.c).  The interrupt handler of
pca953x interrupt controller is threaded, but the sc16is7xx driver is
currently requesting plain interrupt.  So the sc16is7xx just fails
when requesting irq.  The problem can be fixed by changing the
sc16is7xx driver to use the request_any_context_irq().  But it is not
easy to see this is because of requesting plain interrupt on a
threaded interrupt controller without some debugging effort into the
core code.  And my concerns is that there are other drivers can hit
the same problem if connected to the threaded interrupt controller.
What can we do prevent similar problem in the future?

Regards,
Leo