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]

Message-ID: <CADRPPNSZx126D9XMGTLPdjZXBg3o9BNwJ+djMaTVJyf4RY9Rqw@mail.gmail.com>
Date:   Thu, 22 Sep 2016 15:38:35 -0500
From:   Leo Li <pku.leo@...il.com>
To:     Marc Zyngier <marc.zyngier@....com>
Cc:     Marc Zyngier <maz@...terjones.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        lkml <linux-kernel@...r.kernel.org>
Subject: Re: recommended use of request_any_context_irq()

On Thu, Sep 22, 2016 at 3:10 AM, Marc Zyngier <marc.zyngier@....com> wrote:
> Leo,
>
> On 21/09/16 22:14, Leo Li wrote:
>> Hi Marc and Thomas,
>>
>> With the introduction of request_any_context_irq() routine, driver can
>> deal with interrupt controllers using either threaded irq or normal
>> irq.  But I don't see many drivers that have been changed to use this
>> function to request interrupt.  For on-board devices, the driver
>> normally don't know which kind of interrupt controller they are
>> connected to.  Why don't we make the request_any_context_irq()
>> mandatory or recommended for all drivers?  Is there any drawback for
>> changing all the request_irq() to the request_any_context_irq()?
>
> In 99.99% of the cases, a device is integrated in one particular way,
> always. For the 0.01% that is left, we have the above API. And if a
> particular device moves from the first category to the second, whoever
> designed the system will change the driver to use this API, and that
> driver only.

I'm not sure if these are such rare cases.  Devices which are not
integrated in the SoC and not on a bus with interrupt handling such as
PCI/PCIE could easily fall into this category.  For example, I2C
devices and SPI devices are very likely to be in this category.  I did
a quick search:

git grep -l 'i2c_driver\|spi_driver' drivers/ |xargs grep -l request_irq |wc -l

The result is 109.

>
> 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.  Right now, it might
take quite some time for a developer unfamiliar with the threaded
interrupt to figure out the problem.

Regards,
Leo