Messages in this thread | | | Date | Mon, 11 Sep 2023 12:08:01 +0200 | From | Daniel Wagner <> | Subject | Re: [RFC v1 3/4] nvmet-fc: untangle cross refcounting objects |
| |
On Wed, Sep 06, 2023 at 01:22:28PM +0200, Hannes Reinecke wrote: > destroy_workqueue(queue->work_q); > > kfree_rcu(queue, rcu); > > @@ -1100,6 +1093,11 @@ nvmet_fc_delete_assoc(struct work_struct *work) > > container_of(work, struct nvmet_fc_tgt_assoc, del_work); > > nvmet_fc_delete_target_assoc(assoc); > > + > > + /* release get taken in nvmet_fc_find_target_assoc */ > > + nvmet_fc_tgt_a_put(assoc); > > + > > + /* final reference from nvmet_fc_ls_create_association */ > > nvmet_fc_tgt_a_put(assoc); > > } > That feels wrong. If we're having to do two put in a row it seems that > we're taking one reference too many here.
When the association is created the first reference is taken. This is the one we want to release here. But as nvmet_fc_find_target_assoc always takes a reference we have to drop that one too. One possibility would be to introduce a lookup function which doesn't take the reference.
> + /* prevent new I/Os entering the queues */ > > + for (i = NVMET_NR_QUEUES; i >= 0; i--) > > + rcu_assign_pointer(assoc->queues[i], NULL); > > + list_del_rcu(&assoc->a_list); > > + synchronize_rcu(); > Watch out for 'list_del_rcu()'. That does _not_ modify the pointer for the > element in question, only those from the list. > So to avoid concurrency with nvmet_fc_alloc_target_assoc() I guess we need > to get the tgtport lock here.
Yes, we need to protect from concurent write access obviously.
| |