On 05/24, Petr Mladek wrote:
Your patch changes the semantic. The current semantic is the same for the workqueue's counter-part mod_delayed_work_on().
OK, I see, thanks. I was confused by the comment.
We should actually keep the "ret" value as is to stay compatible with workqueue API:
/* * Canceling could run in parallel from kthread_cancel_delayed_work_sync * and change work's canceling count as the spinlock is released and regain * in __kthread_cancel_work so we need to check the count again. Otherwise, * we might incorrectly queue the dwork and further cause * cancel_delayed_work_sync thread waiting for flush dwork endlessly. * * Keep the ret code. The API primary informs the caller * whether some pending work has been canceled (not proceed). */ if (work->canceling) goto out;
Agreed, we should keep the "ret" value.
but unless I am confused again this doesn't match mod_delayed_work_on() which always returns true if it races with cancel(). Nevermind, I think this doesn't matter.
Thanks,
Oleg.