[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7ab71df0-e9e8-4035-a215-f5259c69fe88@flourine.local>
Date: Fri, 28 Feb 2025 09:45:12 +0100
From: Daniel Wagner <dwagner@...e.de>
To: Hannes Reinecke <hare@...e.de>
Cc: James Smart <james.smart@...adcom.com>, Christoph Hellwig <hch@....de>,
Sagi Grimberg <sagi@...mberg.me>, Chaitanya Kulkarni <kch@...dia.com>,
Keith Busch <kbusch@...nel.org>, linux-nvme@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 08/11] nvmet-fc: take tgtport reference only once
On Fri, Feb 28, 2025 at 08:34:51AM +0100, Hannes Reinecke wrote:
> On 2/26/25 19:46, Daniel Wagner wrote:
> > The reference counting code can be simplified. Instead taking a tgtport
> > refrerence at the beginning of nvmet_fc_alloc_hostport and put it back
> > if not a new hostport object is allocated, only take it when a new
> > hostport object is allocated.
> >
> Can it really?
> Main point of this operation is that 'tgtport' isn't going away during while
> we're figuring out whether we need it.
>
> With this patch it means that
The tgtport is not going away. nvmet_fc_alloc_hostport can only be
called with reference on tgtport being hold:
nvmet_fc_rcv_ls_req
nvmet_fc_tgtport_get(tgtport)
nvmet_fc_handle_ls_rqst_work
nvmet_fc_handle_ls_rqst
nvmet_fc_ls_create_association
nvmet_fc_alloc_target_assoc
nvmet_fc_alloc_hostport
The goal with this patch here is to make it simpler to read where we
take a ref. IMO, there is not really anything gained by the existing
logic, though I agree it's not obvious that the tgtport is not going
away. Would it be okay to add a comment?
Powered by blists - more mailing lists