Messages in this thread | | | From | Yiwei Zhang <> | Date | Thu, 18 Feb 2021 22:29:24 -0800 | Subject | Re: [PATCH] kthread: add kthread_mod_pending_delayed_work api |
| |
> 2. User triggered clean up races with the clean up triggered by > timeout. You try to handle this scenario by this patch. Yes, exactly.
> 3. User does clean up after the clean up has already been done > by the timeout. This case is well handled. So only (2) has a potential race.
Let me clarify a bit more here. The "clean up" is not the clean up when a process tears down, but it's actually a "post-work" to cancel out an early "pre-work". The "pre-work" enqueues the delayed "post work" for the timeout purpose. That pair of operations can repeatedly happen.
The racing is currently worked around by refcounting the delayed_work container, and the later "post-work" will take care of the work deallocation.
I mainly want to reach out to see if we agree that this is a valid API to be supported by kthread. Or we extend the existing kthread_mod_delayed_work api to take another option to not re-queue if the cancel failed.
Best, Yiwei
| |