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: <20200806150703.sdg6cfh7pxqzf4wl@pengutronix.de>
Date:   Thu, 6 Aug 2020 17:07:03 +0200
From:   Uwe Kleine-König <u.kleine-koenig@...gutronix.de>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     Ahmad Fatoum <a.fatoum@...gutronix.de>,
        Linus Walleij <linus.walleij@...aro.org>,
        Bartosz Golaszewski <bgolaszewski@...libre.com>,
        linux-gpio@...r.kernel.org,
        Thorsten Scherer <t.scherer@...elmann.de>,
        linux-kernel@...r.kernel.org,
        Pengutronix Kernel Team <kernel@...gutronix.de>
Subject: Re: [PATCH] gpio: siox: indicate exclusive support of threaded IRQs

On Thu, Aug 06, 2020 at 12:20:52PM +0200, Thomas Gleixner wrote:
> Uwe Kleine-König <u.kleine-koenig@...gutronix.de> writes:
> > On Tue, Aug 04, 2020 at 11:16:03AM +0200, Ahmad Fatoum wrote:
> >> Generic GPIO consumers like gpio-keys use request_any_context_irq()
> >> to request a threaded handler if irq_settings_is_nested_thread() ==
> >> true or a hardirq handler otherwise.
> >> 
> >> Drivers using handle_nested_irq() must be sure that the nested
> >> IRQs were requested with threaded handlers, because the IRQ
> >> is handled by calling action->thread_fn().
> >> 
> >> The gpio-siox driver dispatches IRQs via handle_nested_irq,
> >> but has irq_settings_is_nested_thread() == false.
> >> 
> >> Set gpio_irq_chip::threaded to remedy this.
> >
> > Sounds reasonable, but I have to keep this for others to judge if this
> > is indeed how the irq stuff works.
> 
> handle_nested_irq() documentation clearly says: "Handle a nested irq
> from a irq thread". As a consequence the caller of this function must
> run in an interrupt thread. This is an optimization to spare tons of
> interrupt threads and context switches.
> 
> So the solution for this driver is either to make the dispatch handler
> threaded or use the hard interrupt variant of dispatching the
> demultiplexed GPIO interrupts.

The action item isn't entirely clear for me. There is no "parent" irq, I
have for siox a kthread that does some IO and looks that the resulting
data which effectively reports the current state of the GPIO line. And
if this GPIO is configured to trigger an irq and the matching transition
(or state) is seen, I want to trigger the irq action. So the caller has
neither hard nor threaded irq context.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ