On Tue, Feb 15, 2022 at 12:37:43PM -0800, Bart Van Assche wrote: > On 2/15/22 10:51, Leon Romanovsky wrote: > > On Tue, Feb 15, 2022 at 10:26:50AM -0800, Bart Van Assche wrote: > > > diff --git a/drivers/infiniband/ulp/srp/ib_srp.c b/drivers/infiniband/ulp/srp/ib_srp.c > > > index 2db7429b42e1..8e1561a6d325 100644 > > > +++ b/drivers/infiniband/ulp/srp/ib_srp.c > > > @@ -4044,12 +4044,10 @@ static void srp_remove_one(struct ib_device *device, void *client_data) > > > mutex_lock(&host->target_mutex); > > > list_for_each_entry(target, &host->target_list, list) > > > srp_queue_remove_work(target); > > > + list_for_each_entry(target, &host->target_list, list) > > > + flush_work(&target->tl_err_work); > > > > Sorry for my silly question, but why do you do flush and not cancel > > here? You anyway remove SRP device, so the result of flush is not > > really important, am I right? > > That's a great question. It probably doesn't matter much whether > flush_work() or cancel_work_sync() is called in this context since > srp_queue_remove_work() indirectly cancels tl_err_work. See also the > following code in srp_remove_target(): > cancel_work_sync(&target->tl_err_work); If it is already canceled then why call flush? Jason
