From: Petr Mladek <pmladek@suse.com> To: Grygorii Strashko <grygorii.strashko@ti.com> Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, linux-rt-users@vger.kernel.org, Linux ARM <linux-arm-kernel@lists.infradead.org>, netdev <netdev@vger.kernel.org>, Richard Cochran <richardcochran@gmail.com> Subject: Re: Question about kthread_mod_delayed_work() allowed context Date: Wed, 12 Feb 2020 16:41:16 +0100 [thread overview] Message-ID: <20200212154116.hh2vdyi7e2xflxr5@pathway.suse.cz> (raw) In-Reply-To: <cfa886ad-e3b7-c0d2-3ff8-58d94170eab5@ti.com> On Tue 2020-02-11 12:23:59, Grygorii Strashko wrote: > Hi All, > > I'd like to ask question about allowed calling context for kthread_mod_delayed_work(). > > The comment to kthread_mod_delayed_work() says: > > * This function is safe to call from any context including IRQ handler. > * See __kthread_cancel_work() and kthread_delayed_work_timer_fn() > * for details. > */ > > But it has del_timer_sync() inside which seems can't be called from hard_irq context: > kthread_mod_delayed_work() > |-__kthread_cancel_work() > |- del_timer_sync() > |- WARN_ON(in_irq() && !(timer->flags & TIMER_IRQSAFE)); It is safe because kthread_delayed_work_timer_fn() is IRQ safe. Note that it uses raw_spin_lock_irqsave(). It is the reason why the timer could have set TIMER_IRQSAFE flag, see KTHREAD_DELAYED_WORK_INIT(). In more details. The timer is either canceled before the callback is called. Or it waits for the callback but the callback is safe because it can't sleep. > My use case is related to PTP processing using PTP auxiliary worker: > (commit d9535cb7b760 ("ptp: introduce ptp auxiliary worker")): > - periodic work A is started and res-schedules itself for every dtX > - on IRQ - the work A need to be scheduled immediately This is exactly where kthread_mod_delayed_work() need to be used in the IRQ context with 0 delay. > Any advice on how to proceed? > Can kthread_queue_work() be used even if there is delayed work is > scheduled already (in general, don't care if work A will be executed one > more time after timer expiration)? Yes, it can be used this way. It should behave the same way as the workqueue API. I am happy that there are more users for this API. I wanted to convert more kthreads but it was just falling down in my TODO. I hope that I answered all questions. Feel free to ask more when in doubts. Best Regards, Petr
WARNING: multiple messages have this Message-ID (diff)
From: Petr Mladek <pmladek@suse.com> To: Grygorii Strashko <grygorii.strashko@ti.com> Cc: netdev <netdev@vger.kernel.org>, Richard Cochran <richardcochran@gmail.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Linux ARM <linux-arm-kernel@lists.infradead.org>, linux-rt-users@vger.kernel.org Subject: Re: Question about kthread_mod_delayed_work() allowed context Date: Wed, 12 Feb 2020 16:41:16 +0100 [thread overview] Message-ID: <20200212154116.hh2vdyi7e2xflxr5@pathway.suse.cz> (raw) In-Reply-To: <cfa886ad-e3b7-c0d2-3ff8-58d94170eab5@ti.com> On Tue 2020-02-11 12:23:59, Grygorii Strashko wrote: > Hi All, > > I'd like to ask question about allowed calling context for kthread_mod_delayed_work(). > > The comment to kthread_mod_delayed_work() says: > > * This function is safe to call from any context including IRQ handler. > * See __kthread_cancel_work() and kthread_delayed_work_timer_fn() > * for details. > */ > > But it has del_timer_sync() inside which seems can't be called from hard_irq context: > kthread_mod_delayed_work() > |-__kthread_cancel_work() > |- del_timer_sync() > |- WARN_ON(in_irq() && !(timer->flags & TIMER_IRQSAFE)); It is safe because kthread_delayed_work_timer_fn() is IRQ safe. Note that it uses raw_spin_lock_irqsave(). It is the reason why the timer could have set TIMER_IRQSAFE flag, see KTHREAD_DELAYED_WORK_INIT(). In more details. The timer is either canceled before the callback is called. Or it waits for the callback but the callback is safe because it can't sleep. > My use case is related to PTP processing using PTP auxiliary worker: > (commit d9535cb7b760 ("ptp: introduce ptp auxiliary worker")): > - periodic work A is started and res-schedules itself for every dtX > - on IRQ - the work A need to be scheduled immediately This is exactly where kthread_mod_delayed_work() need to be used in the IRQ context with 0 delay. > Any advice on how to proceed? > Can kthread_queue_work() be used even if there is delayed work is > scheduled already (in general, don't care if work A will be executed one > more time after timer expiration)? Yes, it can be used this way. It should behave the same way as the workqueue API. I am happy that there are more users for this API. I wanted to convert more kthreads but it was just falling down in my TODO. I hope that I answered all questions. Feel free to ask more when in doubts. Best Regards, Petr _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-02-12 15:41 UTC|newest] Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-02-11 10:23 Question about kthread_mod_delayed_work() allowed context Grygorii Strashko 2020-02-11 10:23 ` Grygorii Strashko 2020-02-12 15:41 ` Petr Mladek [this message] 2020-02-12 15:41 ` Petr Mladek 2020-02-12 19:17 ` Grygorii Strashko 2020-02-12 19:17 ` Grygorii Strashko 2020-02-13 8:33 ` Petr Mladek 2020-02-13 8:33 ` Petr Mladek
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=20200212154116.hh2vdyi7e2xflxr5@pathway.suse.cz \ --to=pmladek@suse.com \ --cc=grygorii.strashko@ti.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-rt-users@vger.kernel.org \ --cc=netdev@vger.kernel.org \ --cc=richardcochran@gmail.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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.