linux-kernel - Re: [PATCH 1/4] regmap: irq: Fix lost interrupts by introducing handle

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:   Tue, 28 Mar 2017 16:18:49 +0100
From:   Mark Brown <broonie@...nel.org>
To:     Tony Lindgren <tony@...mide.com>
Cc:     linux-kernel@...r.kernel.org, linux-omap@...r.kernel.org,
        Charles Keepax <ckeepax@...nsource.wolfsonmicro.com>,
        Lee Jones <lee.jones@...aro.org>,
        Marcel Partap <mpartap@....net>,
        Michael Scott <michael.scott@...aro.org>
Subject: Re: [PATCH 1/4] regmap: irq: Fix lost interrupts by introducing
 handle_reread

On Mon, Mar 27, 2017 at 05:36:48PM -0700, Tony Lindgren wrote:
> * Mark Brown <broonie@...nel.org> [170327 10:52]:

> > So, I see your use case but the fact is that as Charles observed this is
> > exactly the code used for emulating level triggered IRQs with edge
> > triggered interrupt controllers.  This means someone is doubtless going
> > to end up using it for precisely that.  This makes me uncomfortable, we
> > do have this open coded into various drivers already but this is more of
> > a core thing and it feels like this should be in genirq rather than
> > here...  that said, looking at the code:

> Yes.. But then again we might avoid piling up yet more driver
> specific hacks. I don't know what the genirq solution would look

Right, my thinking here is that by pushing into genirq we minimise the
need even further since it'll also be available to drivers not using
regmap-irq.

> like, handle until we get IRQ_NONE? :)

Well, that's what the per driver emulation does so...  yeah.  Probably
with an upper limit on the number of times we do that.

> > There's no protection against screaming interrupts here, I'd really like
> > to see that.  Also some tracing of the number of times we spin.

> Good idea. How about something like below where handle_reread checks
> for the total time spent in the thread loop with a large enough
> timeout? Or do you have some better ideas in mind?

> I tested I can hit that warning with timeout set to much lower
> 10 ms with retries being 1 or 2 at that point.

That looks sensible, yes.

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