Re: [PATCH v4 03/17] xfs: Embed struct xfs_name in xfs_da_args

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Nov 08, 2019 at 09:11:54AM -0700, Allison Collins wrote:
> On 11/7/19 6:25 PM, Darrick J. Wong wrote:
> > On Wed, Nov 06, 2019 at 06:27:47PM -0700, Allison Collins wrote:
> > > This patch embeds an xfs_name in xfs_da_args, replacing the name,
> > > namelen, and flags members.  This helps to clean up the xfs_da_args
> > > structure and make it more uniform with the new xfs_name parameter
> > > being passed around.
> > > 
> > > Signed-off-by: Allison Collins <allison.henderson@xxxxxxxxxx>
> > > Reviewed-by: Brian Foster <bfoster@xxxxxxxxxx>
> > > ---
> > >   fs/xfs/libxfs/xfs_attr.c        |  36 +++++++-------
> > >   fs/xfs/libxfs/xfs_attr_leaf.c   | 106 +++++++++++++++++++++-------------------
> > >   fs/xfs/libxfs/xfs_attr_remote.c |   2 +-
> > >   fs/xfs/libxfs/xfs_da_btree.c    |   5 +-
> > >   fs/xfs/libxfs/xfs_da_btree.h    |   4 +-
> > >   fs/xfs/libxfs/xfs_dir2.c        |  18 +++----
> > >   fs/xfs/libxfs/xfs_dir2_block.c  |   6 +--
> > >   fs/xfs/libxfs/xfs_dir2_leaf.c   |   6 +--
> > >   fs/xfs/libxfs/xfs_dir2_node.c   |   8 +--
> > >   fs/xfs/libxfs/xfs_dir2_sf.c     |  30 ++++++------
> > >   fs/xfs/scrub/attr.c             |  12 ++---
> > >   fs/xfs/xfs_trace.h              |  20 ++++----
> > >   12 files changed, 128 insertions(+), 125 deletions(-)
> > > 
> > > diff --git a/fs/xfs/libxfs/xfs_attr.c b/fs/xfs/libxfs/xfs_attr.c
> > > index 5a9624a..b77b985 100644
> > > --- a/fs/xfs/libxfs/xfs_attr.c
> > > +++ b/fs/xfs/libxfs/xfs_attr.c
> > > @@ -72,13 +72,12 @@ xfs_attr_args_init(
> > >   	args->geo = dp->i_mount->m_attr_geo;
> > >   	args->whichfork = XFS_ATTR_FORK;
> > >   	args->dp = dp;
> > > -	args->flags = flags;
> > > -	args->name = name->name;
> > > -	args->namelen = name->len;
> > > -	if (args->namelen >= MAXNAMELEN)
> > > +	name->type = flags;
> > 
> > Is there a purpose for modifying the caller's @name, instead of setting
> > args.name.type = flags after the memcpy?
> Not really other than to just make them consistent so that the mem copy
> would cover all three members.  I think initially they were set
> individually, but people preferred the memcpy, and then later we decided to
> break the flags variable out of the name struct.  I can explicitly set
> args.name.type if folks prefer.
> 
> A subtle pitfall I noticed about using the name struct like this now:
> callers need to take care to abandon the original name struct or update the
> original pointer to this struct.  It's kind of easy to continue using the
> original struct like it's a convenience pointer, but it not the same memory
> so if args gets passed into some subroutine that modifies it, now you're out
> of sync.  If it doesnt get passed around or modified, it doesnt matter, but
> we've created a sort of usage rule about how to handle the name param which
> may not be entirely obvious to other developers.

Hm, maybe the da_args should keep a pointer to the caller's name, if
you're worried about coherency between different xfs_names?

Though, the only state that changes is the type field, right?  Maybe we
don't care and that should stay internal to the da_args anyway...

> > 
> > > +	memcpy(&args->name, name, sizeof(struct xfs_name));
> > > +	if (args->name.len >= MAXNAMELEN)
> > >   		return -EFAULT;		/* match IRIX behaviour */
> > > -	args->hashval = xfs_da_hashname(args->name, args->namelen);
> > > +	args->hashval = xfs_da_hashname(args->name.name, args->name.len);
> > >   	return 0;
> > >   }
> > > @@ -236,7 +235,7 @@ xfs_attr_try_sf_addname(
> > >   	 * Commit the shortform mods, and we're done.
> > >   	 * NOTE: this is also the error path (EEXIST, etc).
> > >   	 */
> > > -	if (!error && (args->flags & ATTR_KERNOTIME) == 0)
> > > +	if (!error && (args->name.type & ATTR_KERNOTIME) == 0)
> > >   		xfs_trans_ichgtime(args->trans, dp, XFS_ICHGTIME_CHG);
> > >   	if (mp->m_flags & XFS_MOUNT_WSYNC)
> > > @@ -357,6 +356,9 @@ xfs_attr_set(
> > >   	if (error)
> > >   		return error;
> > > +	/* Use name now stored in args */
> > > +	name = &args.name;
> > 
> > You could probably set this as part of the variable declaration, e.g.
> > 
> > struct xfs_name		*name = &args.name;
> No, because name is a parameter here, so you would loose the contents at the
> start of the function if we did this.  And then args init would memcopy and
> empty struct onto itself.  And then confusion would ensue.... :-(
> 
> > 
> > > +
> > >   	args.value = value;
> > >   	args.valuelen = valuelen;
> > >   	args.op_flags = XFS_DA_OP_ADDNAME | XFS_DA_OP_OKNOENT;
> > > @@ -372,7 +374,7 @@ xfs_attr_set(
> > >   	 */
> > >   	if (XFS_IFORK_Q(dp) == 0) {
> > >   		int sf_size = sizeof(xfs_attr_sf_hdr_t) +
> > > -			XFS_ATTR_SF_ENTSIZE_BYNAME(args.namelen, valuelen);
> > > +			XFS_ATTR_SF_ENTSIZE_BYNAME(args.name.len, valuelen);
> > 
> > If you're going to keep the convenience variable @name, then please use
> > it throughout the function.
> I think this is the only place it's used for this function at this time.  I
> use it later in patch 15 though.  I think I stumbled across the name sync
> bug then, and corrected it with the parameter pointer assignment above just
> because it seemed like the right place to fix it.
> 
> Do you want the function to uniformly use an explicit reference, or the
> param?  Seems like a bit of a wart unfortunately :-(

One or the other, just not both mixed in the same function.

--D

> > 
> > >   		error = xfs_bmap_add_attrfork(dp, sf_size, rsvd);
> > >   		if (error)
> > 
> > <snip>
> > 
> > > diff --git a/fs/xfs/libxfs/xfs_da_btree.c b/fs/xfs/libxfs/xfs_da_btree.c
> > > index 4fd1223..129ec09 100644
> > > --- a/fs/xfs/libxfs/xfs_da_btree.c
> > > +++ b/fs/xfs/libxfs/xfs_da_btree.c
> > > @@ -2040,8 +2040,9 @@ xfs_da_compname(
> > >   	const unsigned char *name,
> > >   	int		len)
> > >   {
> > > -	return (args->namelen == len && memcmp(args->name, name, len) == 0) ?
> > > -					XFS_CMP_EXACT : XFS_CMP_DIFFERENT;
> > 
> > Wow that's gross. :)
> > 
> > 	if (args->name.len == len && !memcmp(args->name.name, name, len))
> > 		return XFS_CMP_EXACT;
> > 
> > 	return XFS_CMP_DIFFERENT;
> > 
> > Hmm, is that better?
> Sure, will fix.
> 
> Allison
> 
> > 
> > The rest looks reasonable...
> > 
> > --D
> > 



[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux