Re: [PATCH v7 02/19] xfs: Embed struct xfs_name in xfs_da_args

Allison Collins
2020-02-23T16:51:34Z

On 2/23/20 4:54 AM, Amir Goldstein wrote:
> On Sun, Feb 23, 2020 at 4:07 AM Allison Collins
> <allison.henderson@oracle.com> 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@oracle.com>
>> Reviewed-by: Brian Foster <bfoster@redhat.com>
>> ---
>> fs/xfs/libxfs/xfs_attr.c | 37 +++++++-------
>> fs/xfs/libxfs/xfs_attr_leaf.c | 104 +++++++++++++++++++++-------------------
>> fs/xfs/libxfs/xfs_attr_remote.c | 2 +-
>> fs/xfs/libxfs/xfs_da_btree.c | 6 ++-
>> 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, 130 insertions(+), 123 deletions(-)
>>
>> diff --git a/fs/xfs/libxfs/xfs_attr.c b/fs/xfs/libxfs/xfs_attr.c
>> index 6717f47..9acdb23 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)
>> + memcpy(&args->name, name, sizeof(struct xfs_name));
>
> Maybe xfs_name_copy and xfs_name_equal are in order?
You are suggesting to add xfs_name_copy and xfs_name_equal helpers? I'm
not sure there's a use case yet for xfs_name_equal, at least not in this
set. And I think people indicated that they preferred the memcpy in
past reviews rather than handling each member of the xfs_name struct.
Unless I misunderstood the question, I'm not sure there is much left for
a xfs_name_copy helper to cover that the memcpy does not?

>
>>
>> + /* Use name now stored in args */
>> + name = &args.name;
>> +
>
> It seem that the context of these comments be clear in the future.
You are asking to add more context to the comment? How about:
/*
* Use name now stored in args. Abandon the local name
* parameter as it will not be updated in the subroutines
*/

Does that help some?

>
>> 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(name->len, valuelen);
>>
>> error = xfs_bmap_add_attrfork(dp, sf_size, rsvd);
>> if (error)
>> @@ -457,6 +459,9 @@ xfs_attr_remove(
>> if (error)
>> return error;
>>
>> + /* Use name now stored in args */
>> + name = &args.name;
>> +
>> /*
>> * we have no control over the attribute names that userspace passes us
>> * to remove, so we have to allow the name lookup prior to attribute
>> @@ -532,10 +537,10 @@ xfs_attr_shortform_addname(xfs_da_args_t *args)
>> trace_xfs_attr_sf_addname(args);
>>
>> retval = xfs_attr_shortform_lookup(args);
>> - if ((args->flags & ATTR_REPLACE) && (retval == -ENOATTR)) {
>> + if ((args->name.type & ATTR_REPLACE) && (retval == -ENOATTR)) {
>> return retval;
>> } else if (retval == -EEXIST) {
>> - if (args->flags & ATTR_CREATE)
>> + if (args->name.type & ATTR_CREATE)
>> return retval;
>> retval = xfs_attr_shortform_remove(args);
>> if (retval)
>> @@ -545,15 +550,15 @@ xfs_attr_shortform_addname(xfs_da_args_t *args)
>> * that the leaf format add routine won't trip over the attr
>> * not being around.
>> */
>> - args->flags &= ~ATTR_REPLACE;
>> + args->name.type &= ~ATTR_REPLACE;
>
>
> This doesn't look good it looks like a hack.
>
> Even if want to avoid growing struct xfs_name we can store two shorts instead
> of overloading int type with flags.
> type doesn't even need more than a single byte, because XFS_DIR3_FT_WHT
> is not used and will never be used on-disk.
>
> Thanks,
> Amir.
>
The exact use of .type has gone around a few times since this patch
started, which was actually all the way back in parent pointers. :-)
Initially the xfs_name struct replaced anything that passed all three
parameters, and then later we decided that flags should stay separate
for top level get/set/remove routines, but become integrated below the
*_args routines. I don't recall people being concerned about growing
the struct, though a union seems reasonable to resolve the naming
weirdness. I would like to have a little more feedback from folks
though just to make sure everyones in agreement since this one's gone
through quite few reviews already. Thanks all!

Allison