All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tyler Hicks <tyhicks@linux.microsoft.com>
To: Dominique Martinet <asmadeus@codewreck.org>
Cc: Christian Schoenebeck <linux_oss@crudebyte.com>,
	Eric Van Hensbergen <ericvh@gmail.com>,
	Latchesar Ionkov <lucho@ionkov.net>,
	v9fs-developer@lists.sourceforge.net,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 06/06] 9p fid refcount: cleanup p9_fid_put calls
Date: Mon, 13 Jun 2022 15:12:41 -0500	[thread overview]
Message-ID: <20220613201241.GH7401@sequoia> (raw)
In-Reply-To: <YqeVFTkREfWUfPFi@codewreck.org>

On 2022-06-14 04:50:45, Dominique Martinet wrote:
> Thanks for the reviews,
> 
> Tyler Hicks wrote on Mon, Jun 13, 2022 at 12:55:09PM -0500:
> > > @@ -189,13 +197,13 @@ static struct p9_fid *v9fs_fid_lookup_with_uid(struct dentry *dentry,
> > >  		else
> > >  			uname = v9ses->uname;
> > >  
> > > -		root_fid = p9_client_attach(v9ses->clnt, NULL, uname, uid,
> > > -					    v9ses->aname);
> > > -		if (IS_ERR(root_fid))
> > > -			return root_fid;
> > > +		fid = p9_client_attach(v9ses->clnt, NULL, uname, uid,
> > 
> > To keep the readability benefits in my "9p: Track the root fid with its
> > own variable during lookups" patch, I think root_fid should be assigned
> > here and then used in the error check and return statement.
> > 
> > > +				       v9ses->aname);
> > > +		if (IS_ERR(fid))
> > > +			return fid;
> > >  
> > > -		p9_fid_get(root_fid);
> > > -		v9fs_fid_add(dentry->d_sb->s_root, root_fid);
> > > +		root_fid = p9_fid_get(fid);
> > > +		v9fs_fid_add(dentry->d_sb->s_root, &fid);
> > 
> > root_fid should be used in the two lines above, too.
> 
> This actually was the only place where we still want to use the root_fid
> after calling v9fs_fid_add; if we keep root_fid above we need to do
> something like
> 
> fid = p9_fid_get(root_fid);
> v9fs_Fid_add(dentry->d_sb->s_root, &root_fid);
> root_fid = fid;
> // fid = NULL; ? not strictly needed as we set it again shortly afterwards
> 
> which I wanted to avoid, but I guess I don't mind strongly either way --
> pick your poison.

Ah, very good point. I missed that subtly.

> I could also just keep v9fs_fid_add as a non-stealing version, but I
> think it's better that way as it strongly signal that we stashed that
> ref away and shouldn't use the fid anymore unless another ref was
> obtained through fid_get like we do here.
> (I was actually tempted to do the same with p9_fid_put, but checking
> other kernel "put"s I didn't see any code that does this so I refrained
> from that churn)

I like the stealing version. Lets go with it and keep this patch as-is.

Please feel free to slap this tag on it:

 Reviewed-by: Tyler Hicks <tyhicks@linux.microsoft.com>


Tyler

> 
> -- 
> Dominique
> 

  reply	other threads:[~2022-06-13 20:54 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-12  8:53 [PATCH 00/06] fid refcounting improvements and fixes Dominique Martinet
2022-06-12  8:53 ` [PATCH 01/06] 9p: fix fid refcount leak in v9fs_vfs_atomic_open_dotl Dominique Martinet
2022-06-13 16:27   ` Tyler Hicks
2022-06-14 13:17   ` Christian Schoenebeck
2022-06-12  8:53 ` [PATCH 02/06] 9p: fix fid refcount leak in v9fs_vfs_get_link Dominique Martinet
2022-06-13 16:29   ` Tyler Hicks
2022-06-14 13:19   ` Christian Schoenebeck
2022-06-12  8:53 ` [PATCH 03/06] 9p: v9fs_fid_lookup_with_uid fix's fix suggestion Dominique Martinet
2022-06-13 20:08   ` Tyler Hicks
2022-06-12  8:53 ` [PATCH 04/06] 9p fid refcount: add p9_fid_get/put wrappers Dominique Martinet
2022-06-12 23:45   ` [PATCH v2 " Dominique Martinet
2022-06-13 17:31     ` Tyler Hicks
2022-06-14 13:55     ` Christian Schoenebeck
2022-06-14 14:27       ` Dominique Martinet
2022-06-15  3:16       ` [PATCH v3 " Dominique Martinet
2022-06-15 13:00         ` Christian Schoenebeck
2022-06-15 13:47           ` Dominique Martinet
2022-06-12  8:53 ` [PATCH 05/06] 9p fid refcount: add a 9p_fid_ref tracepoint Dominique Martinet
2022-06-12 22:46   ` Steven Rostedt
2022-06-12 23:46     ` [PATCH v2 " Dominique Martinet
2022-06-13  7:00       ` Dominique Martinet
2022-06-12  8:53 ` [PATCH 06/06] 9p fid refcount: cleanup p9_fid_put calls Dominique Martinet
2022-06-13 17:55   ` Tyler Hicks
2022-06-13 19:50     ` Dominique Martinet
2022-06-13 20:12       ` Tyler Hicks [this message]
2022-06-13 20:20 ` [PATCH 00/06] fid refcounting improvements and fixes Tyler Hicks
2022-06-13 21:00   ` Dominique Martinet
2022-06-14  1:14     ` Tyler Hicks

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220613201241.GH7401@sequoia \
    --to=tyhicks@linux.microsoft.com \
    --cc=asmadeus@codewreck.org \
    --cc=ericvh@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux_oss@crudebyte.com \
    --cc=lucho@ionkov.net \
    --cc=v9fs-developer@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.