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.
