On Wed 2020-02-12 21:17:53, Grygorii Strashko wrote: > > > On 12/02/2020 17:41, Petr Mladek wrote: > > 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. > > I think, my issue (warning) could be related to the fact that kthread_init_delayed_work() > is used, which seems doesn't set TIMER_IRQSAFE flag. Great catch! It is a bug. Would you like to send the fix for kthread_init_delayed_work() or would you prefer me doing so? Best Regards, Petr
