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