Messages in this thread | | | Date | Mon, 26 Sep 2022 19:28:37 +0900 | Subject | Re: [PATCH v3] rapidio/tsi721: Replace flush_scheduled_work() with flush_work(). | From | Tetsuo Handa <> |
| |
On 2022/09/26 2:27, Andrew Morton wrote: > On Sat, 24 Sep 2022 14:11:25 +0900 Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> wrote: > >> Like commit c4f135d643823a86 ("workqueue: Wrap flush_workqueue() using a >> macro") says, flush_scheduled_work() is dangerous and will be forbidden. >> We are on the way for removing all flush_scheduled_work() callers from >> the kernel, and this patch is for removing flush_scheduled_work() call >> from tsi721 driver. >> >> Since "struct tsi721_device" is per a device struct, I assume that >> tsi721_remove() needs to wait for only two works associated with that >> device. Therefore, wait for only these works using flush_work(). >> >> --- a/drivers/rapidio/devices/tsi721.c >> +++ b/drivers/rapidio/devices/tsi721.c >> @@ -2941,7 +2941,8 @@ static void tsi721_remove(struct pci_dev *pdev) >> >> tsi721_disable_ints(priv); >> tsi721_free_irq(priv); >> - flush_scheduled_work(); >> + flush_work(&priv->idb_work); >> + flush_work(&priv->pw_work); >> rio_unregister_mport(&priv->mport); > > Why not use cancel_work[_sync](), as the flush_scheduled_work() comment > recommends? >
Alan Stern suggested to use cancel_work_sync() in commit eef6a7d5c2f38ada ("workqueue: warn about flush_scheduled_work()") and Tejun Heo suggested to use flush_work() in https://lkml.kernel.org/r/YjivtdkpY+reW0Gt@slm.duckdns.org .
Is there some reason to prefer one over the other? I think that user-visible results between flush_work() and cancel_work_sync() are the same because both wait until work completes.
| |