[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <kl45f37ubitdm7djwb37zxox22e4bieoqdyetxibgb4dtmaevc@jafhs7q2ajy2>
Date: Mon, 11 Sep 2023 12:08:01 +0200
From: Daniel Wagner <dwagner@...e.de>
To: Hannes Reinecke <hare@...e.de>
Cc: linux-nvme@...ts.infradead.org, linux-kernel@...r.kernel.org,
Sagi Grimberg <sagi@...mberg.me>,
Jason Gunthorpe <jgg@...pe.ca>,
James Smart <james.smart@...adcom.com>,
Chaitanya Kulkarni <kch@...dia.com>,
Christoph Hellwig <hch@....de>
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.
Powered by blists - more mailing lists