> 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
