All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nikolay Borisov <nborisov@suse.com>
To: Anand Jain <anand.jain@oracle.com>, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 3/4 RESEND] btrfs: open code btrfs_set_prop in inherit_prop
Date: Tue, 2 Apr 2019 16:35:12 +0300	[thread overview]
Message-ID: <8fedbab1-6fec-92cb-25b2-c9b9ff264103@suse.com> (raw)
In-Reply-To: <20190402100742.8355-5-anand.jain@oracle.com>



On 2.04.19 г. 13:07 ч., Anand Jain wrote:
> When an inode inherits property from its parent, we call btrfs_set_prop().
> btrfs_set_prop() does an elaborate checks, which is not required in the
> context of inheriting a property. Instead just open-code only the required
> items from btrfs_set_prop() and then call btrfs_setxattr() directly. So
> now the only user of btrfs_set_prop() is gone, (except for the wraper
> function btrfs_set_prop_trans()).
> 
> Signed-off-by: Anand Jain <anand.jain@oracle.com>
> ---
>  fs/btrfs/props.c | 27 +++++++++++++++++++++------
>  1 file changed, 21 insertions(+), 6 deletions(-)
> 
> diff --git a/fs/btrfs/props.c b/fs/btrfs/props.c
> index 72a06c4d3c70..fb84e76f3b1d 100644
> --- a/fs/btrfs/props.c
> +++ b/fs/btrfs/props.c
> @@ -367,20 +367,35 @@ static int inherit_props(struct btrfs_trans_handle *trans,
>  		if (!value)
>  			continue;
>  
> +		/* may be removed */

This comment brings no value. Either explain *why* it can be removed or
remove it altogether.

> +		ret = h->validate(value, strlen(value));
> +		if (ret)
> +			continue;
> +
>  		num_bytes = btrfs_calc_trans_metadata_size(fs_info, 1);
>  		ret = btrfs_block_rsv_add(root, trans->block_rsv,
>  					  num_bytes, BTRFS_RESERVE_NO_FLUSH);
>  		if (ret)
> -			goto out;
> -		ret = btrfs_set_prop(trans, inode, h->xattr_name, value,
> +			return ret;
> +
> +		ret = btrfs_setxattr(trans, inode, h->xattr_name, value,
>  				     strlen(value), 0);
> +		if (!ret) {
> +			ret = h->apply(inode, value, strlen(value));
> +			if (ret)
> +				btrfs_setxattr(trans, inode, h->xattr_name,
> +					       NULL, 0, 0);
> +			else
> +				set_bit(BTRFS_INODE_HAS_PROPS,
> +					&BTRFS_I(inode)->runtime_flags);
> +		}
> +
>  		btrfs_block_rsv_release(fs_info, trans->block_rsv, num_bytes);

(not related to this patch) but should the reservation be released after
setxattr is called, even if it succeeds, since we need to hold it until
the reservation is committed. E.g. if we have to inherit 2 props then in
the first iteration of the loop we reserve space, we call btrfs_Setxattr
with enough reserved space, then in the 2nd reservation we need another
reservation on top of the previous one, no ?

Otherwise the change per se looks good:

Reviewed-by: Nikolay Borisov <nborisov@suse.com>


>  		if (ret)
> -			goto out;
> +			return ret;
>  	}
> -	ret = 0;
> -out:
> -	return ret;
> +
> +	return 0;
>  }
>  
>  int btrfs_inode_inherit_props(struct btrfs_trans_handle *trans,
> 

  reply	other threads:[~2019-04-02 13:35 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-02 10:07 [PATCH 0/4 RESEND] btrfs: fix property bugs Anand Jain
2019-04-02 10:07 ` [PATCH 1/4 RESEND] btrfs: fix zstd compression parameter Anand Jain
2019-04-02 22:09   ` David Sterba
2019-04-02 10:07 ` [PATCH] fstests: btrfs/048: amend property validation cases Anand Jain
2019-04-02 12:51   ` Nikolay Borisov
2019-04-03  0:32     ` Anand Jain
2019-04-02 10:07 ` [PATCH 2/4 RESEND] btrfs: fix vanished compression property after failed set Anand Jain
2019-04-02 13:00   ` Nikolay Borisov
2019-04-02 22:14   ` David Sterba
2019-04-02 10:07 ` [PATCH 3/4 RESEND] btrfs: open code btrfs_set_prop in inherit_prop Anand Jain
2019-04-02 13:35   ` Nikolay Borisov [this message]
2019-04-02 21:41     ` David Sterba
2019-04-02 23:24     ` David Sterba
2019-04-03  0:42       ` Anand Jain
2019-04-02 21:41   ` David Sterba
2019-04-02 10:07 ` [PATCH 4/4 RESEND] btrfs: fix property validate fail should not increment generation Anand Jain
2019-04-02 13:45   ` Nikolay Borisov
2019-04-02 21:13     ` David Sterba
2019-04-02 22:04   ` David Sterba
2019-04-02 23:03     ` Anand Jain

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=8fedbab1-6fec-92cb-25b2-c9b9ff264103@suse.com \
    --to=nborisov@suse.com \
    --cc=anand.jain@oracle.com \
    --cc=linux-btrfs@vger.kernel.org \
    /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.