From: Vincent Donnefort <vdonnefort@gmail.com>
To: Tejun Heo <tj@kernel.org>
Cc: Bryan Wu <cooloney@gmail.com>, Hugh Dickins <hughd@google.com>,
Valdis.Kletnieks@vt.edu,
Linux LED Subsystem <linux-leds@vger.kernel.org>,
lkml <linux-kernel@vger.kernel.org>,
linux-wireless@vger.kernel.org
Subject: Re: [PATCH] leds: make led_blink_set IRQ safe
Date: Mon, 25 Aug 2014 10:50:20 +0200 [thread overview]
Message-ID: <20140825085020.GA5071@ns3274321.ip-5-39-88.eu> (raw)
In-Reply-To: <20140823172456.GH13540@mtj.dyndns.org>
On Sat, Aug 23, 2014 at 01:24:56PM -0400, Tejun Heo wrote:
> Hello,
>
> On Fri, Aug 22, 2014 at 05:21:30PM -0700, Bryan Wu wrote:
> > On Tue, Aug 19, 2014 at 6:51 PM, Hugh Dickins <hughd@google.com> wrote:
> > > On Tue, 19 Aug 2014, Vincent Donnefort wrote:
> > >
> > >> This patch introduces a work which take care of reseting the blink workqueue and
> > >> avoid calling the cancel_delayed_work_sync function which may sleep, from an IRQ
> > >> context.
> > >>
> >
> > Vincent, I'm just wandering can we use cancel_delayed_work() instead
> > of sync version here.
> > cancel_delayed_work() can be called from IRQ context.
>
> But it doesn't wait for the currently running one to finish. It
> should wait, right?
>
It should indeed wait. Using the cancel_delayed_work() function was my first
thought, however as described into the function header, when calling
cancel_delayed_work(), the work may be running and since it re-arms
itself, the next work may still be queued.
> > > May I (most ungratefully!) say that your patch doesn't fill me with
> > > confidence that it's the right solution: adding yet another work_struct
> > > to get around the issue seemed dubious to me, I wonder if it might expose
> > > new races.
> >
> > I agree with Hugh about this new cancel work_struct. But if we revert
> > it back, I saw led_blink_set() will call del_timer_sync() which might
> > also sleep and can't be used in IRQ context. Looks like we can't call
> > led_blink_set() in any IRQ/atomic context.
>
> del_timer_sync() doesn't block but it does run from bh. It naturally
> can't be waited from an IRQ context. It may be sitting on top of a
> running instance.
>
> > > But rest assured that I know nothing about this, and I'm not at all
> > > qualified to review your patch: I hope Bryan and others will do so.
> >
> > Let me invite Tejun to give some advice on how to solve this problem.
> >
> > Tejun, Vincent's commit 8b37e1bef5a6b60e949e28a4db3006e4b00bd758
> > convert a timer into work_struct, but Hugh found it will cause
> > sleeping BUGs [1]. Could you give some opinion about that?
>
> Not knowing the code base, I'm not sure how helpful I can be but if
> something wants to synchronize against another thing which can block,
> that something needs to be able to block too. There's no way around
> it and it holds the same for timers. As long as all the work items
> are properly shut down at the end, there's nothing wrong with using
> multiple of them even when they form a dependency chain.
>
> Heh, I think I need more specific questions to be actually useful. :)
>
> Thanks.
>
> --
> tejun
next prev parent reply other threads:[~2014-08-25 8:50 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-17 3:27 3.17-rc1: leds blink workqueue causes sleeping BUGs Hugh Dickins
2014-08-19 12:58 ` [PATCH] leds: make led_blink_set IRQ safe Vincent Donnefort
2014-08-19 12:58 ` Vincent Donnefort
2014-08-20 1:51 ` Hugh Dickins
2014-08-23 0:21 ` Bryan Wu
2014-08-23 17:24 ` Tejun Heo
2014-08-25 8:50 ` Vincent Donnefort [this message]
2014-08-19 17:06 ` 3.17-rc1: leds blink workqueue causes sleeping BUGs Valdis.Kletnieks
2014-08-25 21:13 ` Sabrina Dubroca
2014-08-25 21:23 ` Samuel Thibault
2014-08-25 21:37 ` Samuel Thibault
2014-08-25 22:00 ` Hugh Dickins
2014-08-25 23:34 ` Samuel Thibault
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=20140825085020.GA5071@ns3274321.ip-5-39-88.eu \
--to=vdonnefort@gmail.com \
--cc=Valdis.Kletnieks@vt.edu \
--cc=cooloney@gmail.com \
--cc=hughd@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=tj@kernel.org \
/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).