linux-kernel - Re: [PATCH 0/3] simulated interrupts

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 19 Jul 2017 15:19:58 +0100
From:   Marc Zyngier <marc.zyngier@....com>
To:     Thomas Gleixner <tglx@...utronix.de>,
        Bartosz Golaszewski <brgl@...ev.pl>
Cc:     Linus Walleij <linus.walleij@...aro.org>,
        Jonathan Corbet <corbet@....net>,
        Bamvor Jian Zhang <bamvor.zhangjian@...aro.org>,
        Jonathan Cameron <jic23@...nel.org>,
        Lars-Peter Clausen <lars@...afoo.de>,
        linux-kernel@...r.kernel.org, linux-gpio@...r.kernel.org,
        linux-doc@...r.kernel.org
Subject: Re: [PATCH 0/3] simulated interrupts

On 19/07/17 14:58, Thomas Gleixner wrote:
> On Wed, 19 Jul 2017, Bartosz Golaszewski wrote:
> 
>> 2017-07-19 14:25 GMT+02:00 Thomas Gleixner <tglx@...utronix.de>:
>>> On Wed, 19 Jul 2017, Bartosz Golaszewski wrote:
>>>
>>>> Some frameworks (e.g. iio, gpiolib) use irq_work to implement simulated
>>>> interrupts that can be 'fired' from process context when needed and
>>>> requested just like normal interrupts. This is useful for testing and
>>>> development purposes.
>>>>
>>>> Currently this code is reimplemented by every user. This series
>>>> proposes to add a new set of functions that can be used by drivers
>>>> that want to simulate interrupts without having to duplicate any
>>>> boilerplate code.
>>>>
>>>> The first patch adds a simple irq simulator framework. The second
>>>> extends it with resource management. The third uses the new
>>>> functionality in the gpio-mockup testing driver.
>>>>
>>>> NOTE: The next candidate for using this API would be iio-dummy-evgen.
>>>
>>> I like the general idea - have not looked at the code yet. Just a quick
>>> question: How many copies/variants of this scheme do we have in tree?
>>>
>>> Thanks,
>>>
>>>         tglx
>>
>> Currently there are two: iio and gpiolib basically duplicate the same
>> code in their respective testing drivers. I only used irq_sim in
>> gpio-mockup in this series as an example and to see if there's any
>> interest in merging it before spending time on iio-dummy-evgen.
> 
> Yes, I think so. Consolidation is always a good thing and simulation is
> useful for developing or validating code.

Indeed, that's pretty interesting.

On a slightly tangential subject, there is another aspect that I thought
of implementing for a while, but always ended up just relying on a quick
hack: forcing the injection of an actual interrupt. A number of
interrupt controllers have the ability to make an interrupt pending, for
it to be handled as if a device had actually triggered it.

In my case, it has proved to be incredibly useful when debugging the
interrupt controller itself, and also things that mess with interrupts
in a creative way (like KVM) while relying on a particular interrupt
controller.

What I had in mind was something like:

echo 1 >/proc/irq/9/trigger (or the corresponding
/sys/kernel/debug/irq/irqs/ interface if we want to make sure that this
is really not for production use...).

If there is any interest, I'll try to whip something up.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...