From: Yanmin Zhang <yanmin_zhang@linux.intel.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Liu ShuoX <shuox.liu@intel.com>,
linux-kernel@vger.kernel.org, gregkh@linuxfoundation.org,
fweisbec@gmail.com, sedat.dilek@gmail.com,
srivatsa.bhat@linux.vnet.ibm.com,
Zhang Yanmin <yanmin.zhang@intel.com>
Subject: Re: [PATCH] irq: add a new function irq_in_progress to check pending IRQ handlers
Date: Fri, 07 Jun 2013 08:53:29 +0800 [thread overview]
Message-ID: <1370566409.4432.41.camel@ymzhang.sh.intel.com> (raw)
In-Reply-To: <alpine.LFD.2.02.1306061505210.2905@ionos>
On Thu, 2013-06-06 at 15:18 +0200, Thomas Gleixner wrote:
> On Thu, 6 Jun 2013, shuox.liu@intel.com wrote:
> > From: Zhang Yanmin <yanmin.zhang@intel.com>
> >
> > synchronize_irq waits pending IRQ handlers to be finished. If using this
> > function while holding a resource, the IRQ handler may cause deadlock.
> >
> > Here we add a new function irq_in_progress which doesn't wait for the handlers
> > to be finished.
> >
> > A typical use case at suspend-to-ram:
> >
> > device driver's irq handler is complicated and might hold a mutex at rare cases.
> > Its suspend function is called and a suspended flag is set.
> > In case its IRQ handler is running, suspend function calls irq_in_progress. if
> > handler is running, abort suspend.
> > The irq handler checks the suspended flag. If the device is suspended, irq handler
> > either ignores the interrupt, or wakes up the whole system, and the driver's
> > resume function could deal with the delayed interrupt handling.
>
> This is as wrong as it can be. Fix the driver instead of hacking racy
> functions into the core code.
>
> So your problem looks like this:
>
> CPU 0 CPU 1
> irq_handler_thread() suspend()
> ..... mutex_lock(&m);
> mutex_lock(&m); synchronize_irq();
>
> So why needs the mutex to be taken before synchronize_irq()? Why not
> doing the obvious?
>
> suspend()
> disable_irq(); (Implies synchronize_irq)
> mutex_lock(&m);
> ....
> mutex_unlock(&m);
> enable_irq();
Thanks for the kind comment.
We do consider your solution before and it works well indeed with some specific
simple drivers. For example, some drives use GPIO pin as interrupt source.
On one specific platform, disable_irq would really disable the irq at RTE entry,
which means we lose the wakeup capability of this device.
synchronize_irq can be another solution. But we did hit 'DPM device timeout' issue
reported by dpm_wd_handler at suspend-to-ram.
The driver is complicated. We couldn't change too many functions to optimize it.
In addition, we have to use the driver instead of throwing it away.
With irq_in_progress, we can resolve this issue and it does work, although it
looks like ugly.
Yanmin
next prev parent reply other threads:[~2013-06-07 0:51 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-06 7:38 [PATCH] irq: add a new function irq_in_progress to check pending IRQ handlers shuox.liu
2013-06-06 13:18 ` Thomas Gleixner
2013-06-07 0:53 ` Yanmin Zhang [this message]
2013-06-07 1:02 ` Greg KH
2013-06-07 2:37 ` Yanmin Zhang
2013-06-07 3:08 ` Greg KH
2013-06-07 3:18 ` Yanmin Zhang
2013-06-07 4:19 ` Greg KH
2013-06-07 4:54 ` Yanmin Zhang
2013-06-07 15:08 ` Greg KH
2013-06-08 2:34 ` Yanmin Zhang
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=1370566409.4432.41.camel@ymzhang.sh.intel.com \
--to=yanmin_zhang@linux.intel.com \
--cc=fweisbec@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sedat.dilek@gmail.com \
--cc=shuox.liu@intel.com \
--cc=srivatsa.bhat@linux.vnet.ibm.com \
--cc=tglx@linutronix.de \
--cc=yanmin.zhang@intel.com \
/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