Re: [RFC v1 3/4] nvmet-fc: untangle cross refcounting objects

Daniel Wagner
2023-09-11T10:07:39Z

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.