From: Thomas Gleixner <tglx@linutronix.de>
To: Till Straumann <strauman@slac.stanford.edu>
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] genirq: Sanitize spurious interrupt detection of threaded irqs
Date: Fri, 8 Mar 2013 20:41:22 +0100 (CET) [thread overview]
Message-ID: <alpine.LFD.2.02.1303082032390.22263@ionos> (raw)
In-Reply-To: <513A1D88.5060606@slac.stanford.edu>
On Fri, 8 Mar 2013, Till Straumann wrote:
> On 03/08/2013 05:12 PM, Thomas Gleixner wrote:
> > On Fri, 8 Mar 2013, Till Straumann wrote:
> >
> > > 1) I'm not sure adding the SPURIOUS_DEFERRED flag into
> > > threads_handled_last is OK - what happens if the atomic_t counter
> > > can hold more than 31 bits? In this case, when thread handlers
> > > increment the counter there is interference with the flag. If
> > > this is not harmful then it is at least ugly.
> > atomic_t is going to stay 32 bit otherwise we'll have more horrible
> > problems than that one.
> I know. But this means that when the counter overflows 31 bits (2^31 - 1)
> then it spills into the SPURIOUS_DEFERRED flag, right?
Gah, yes. /me should stop doing overoptimizations :)
> > > 2) note_interrupt is also called from irq/chip.c:handle_nested_irq() and I
> > > believe
> > > this routine would also need to increment the 'threads_handled'
> > > counter
> > > rather
> > > than calling note_interrupt.
> > That's a different issue. The nested_irq handler is for interrupts
> > which are demultiplexed by a primary threaded handler. That interrupt
> > is never handled in hard interrupt context. It's always called from
> > the context of the demultiplxing thread.
> So you are saying that there 'handle_nested_irq()' can never be executed
> from more than one thread for a single interrupt?
>
> I find, however, that e.g., the gpio-sx150x.c driver calls
>
> request_threaded_irq() with IRQF_SHARED set and it's thread_fn does call
> handle_nested_irq(). It would thus be possible that multiple drivers
> could share an interrupt and each driver would call handle_nested_irq()
> which in-turn executes note_interrupt(). This would again raise the
> issues we already discussed (note_interrupt() not serialized and thinking
> that an interrupt was not handled because it was handled by a different
> thread).
>
> Probably I'm missing something regarding the use of nested interrupts
> - I would really appreciate if you could help me understand why
> it should be OK for handle_nested_irq() to call note_interrupt().
The thing about nested irqs is:
main irq is threaded (requested by the driver for stuff like i2c)
The handler of this irq reads a pending irq register in the chip and
then invokes handle_nested_irq() for each of the pending bits.
Those interrupts cannot be shared even if the driver request them as
shared:
irqd_set(&desc->irq_data, IRQD_IRQ_INPROGRESS);
raw_spin_unlock_irq(&desc->lock);
action_ret = action->thread_fn(action->irq, action->dev_id);
if (!noirqdebug)
note_interrupt(irq, desc, action_ret);
raw_spin_lock_irq(&desc->lock);
irqd_clear(&desc->irq_data, IRQD_IRQ_INPROGRESS);
So there is no loop over action->next. And even if that code would
loop over action next, then it still would be serialized
main irq is raised
-> wake thread
thread runs
read pending reg()
for each pending bit {
handle_nested_irq();
action = desc->action;
while (action) {
action->thread_fn()
action = action->next)
}
note_interrupt();
}
thread done
Hope that helps. Thanks,
tglx
next prev parent reply other threads:[~2013-03-08 19:41 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-07 13:53 [PATCH] genirq: Sanitize spurious interrupt detection of threaded irqs Thomas Gleixner
2013-03-08 14:47 ` Till Straumann
2013-03-08 16:12 ` Thomas Gleixner
2013-03-08 17:19 ` Till Straumann
2013-03-08 19:41 ` Thomas Gleixner [this message]
2013-03-12 13:22 ` Till Straumann
2014-05-03 21:19 ` [tip:irq/core] " tip-bot for Thomas Gleixner
[not found] <CANGgnMbszHzYe9pF2C6wag4MY_PfBG2qrMCC=rMmQnb-jyXXXw@mail.gmail.com>
[not found] ` <52CAB05F.4010303@hartkopp.net>
2014-04-07 18:38 ` [PATCH] " Austin Schuh
2014-04-07 18:41 ` Thomas Gleixner
2014-04-07 20:05 ` Austin Schuh
2014-04-07 20:07 ` Thomas Gleixner
2014-04-07 20:08 ` Austin Schuh
2014-04-28 20:20 ` Austin Schuh
2014-04-28 20:44 ` Thomas Gleixner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.LFD.2.02.1303082032390.22263@ionos \
--to=tglx@linutronix.de \
--cc=linux-kernel@vger.kernel.org \
--cc=strauman@slac.stanford.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).