All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: alex@zadarastorage.com
Cc: linux-xfs@vger.kernel.org, bfoster@redhat.com,
	darrick.wong@oracle.com, libor.klepac@bcom.cz
Subject: Re: [PATCH] xfs: hold xfs_buf locked between shortform->leaf conversion and the addition of an attribute
Date: Thu, 10 Aug 2017 07:33:07 +1000	[thread overview]
Message-ID: <20170809213307.GJ21024@dastard> (raw)
In-Reply-To: <1502276772-24293-1-git-send-email-alex@zadarastorage.com>

On Wed, Aug 09, 2017 at 02:06:12PM +0300, alex@zadarastorage.com wrote:
> From: Alex Lyakas <alex@zadarastorage.com>
> 
> The new attribute leaf buffer is not held locked across
> the transaction roll between the shortform->leaf modification
> and the addition of the new entry. As a result, the attribute
> buffer modification being made is not atomic from
> an operational perspective. Hence the AIL push can grab it in
> the transient state of "just created" after the initial
> transaction is rolled, because the buffer has been released.
> This leads to xfs_attr3_leaf_verify() asserting that
> hdr.count is zero, treating this as in-memory corruption,
> and shutting down the filesystem.
> 
> Signed-off-by: Alex Lyakas <alex@zadarastorage.com>
> ---
>  fs/xfs/libxfs/xfs_attr.c      | 19 ++++++++++++++++++-
>  fs/xfs/libxfs/xfs_attr_leaf.c |  4 +++-
>  fs/xfs/libxfs/xfs_attr_leaf.h |  3 ++-
>  3 files changed, 23 insertions(+), 3 deletions(-)
> 
> diff --git a/fs/xfs/libxfs/xfs_attr.c b/fs/xfs/libxfs/xfs_attr.c
> index de7b9bd..982e322 100644
> --- a/fs/xfs/libxfs/xfs_attr.c
> +++ b/fs/xfs/libxfs/xfs_attr.c
> @@ -216,10 +216,11 @@
>  	struct xfs_defer_ops	dfops;
>  	struct xfs_trans_res	tres;
>  	xfs_fsblock_t		firstblock;
>  	int			rsvd = (flags & ATTR_ROOT) != 0;
>  	int			error, err2, local;
> +	struct xfs_buf		*leaf_bp = NULL;
>  
>  	XFS_STATS_INC(mp, xs_attr_set);
>  
>  	if (XFS_FORCED_SHUTDOWN(dp->i_mount))
>  		return -EIO;
> @@ -325,11 +326,17 @@
>  		/*
>  		 * It won't fit in the shortform, transform to a leaf block.
>  		 * GROT: another possible req'mt for a double-split btree op.
>  		 */
>  		xfs_defer_init(args.dfops, args.firstblock);
> -		error = xfs_attr_shortform_to_leaf(&args);
> +		error = xfs_attr_shortform_to_leaf(&args, &leaf_bp);
> +		/*
> +		 * Prevent the leaf buffer from being unlocked
> +		 * when "args.trans" transaction commits.
> +		 */
> +		if (leaf_bp)
> +			xfs_trans_bhold(args.trans, leaf_bp);
>  		if (!error)
>  			error = xfs_defer_finish(&args.trans, args.dfops, dp);
>  		if (error) {
>  			args.trans = NULL;
>  			xfs_defer_cancel(&dfops);

Hmmmm, looking closer at xfs_defer_finish(), just holding the buffer
here isn't sufficient. xfs_defer_finish() can roll the transaction a
number of times and holding the buffer is a one-shot deal. Hence the
buffer held buffer will have BLI_HOLD removed on the next commit
and be unlocked by the second commit, whether it be inside
xfs_defer_finish() or the roll that occurs below.

ISTR a previous discussion with Darrick that we needed something
like xfs_defer_join() with buffers instead of inodes to allow them
to be held across a call to xfs_defer_finish()....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

  parent reply	other threads:[~2017-08-09 21:33 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-09 11:06 [PATCH] xfs: hold xfs_buf locked between shortform->leaf conversion and the addition of an attribute alex
2017-08-09 13:17 ` Brian Foster
2017-08-09 21:33 ` Dave Chinner [this message]
2017-08-10  8:02   ` Alex Lyakas
2017-08-10 11:33     ` Dave Chinner
2017-08-10 12:09       ` Alex Lyakas
2017-08-10 14:52         ` Brian Foster
2017-08-10 17:55           ` Darrick J. Wong
2017-08-10 18:32             ` Brian Foster
2017-08-11  2:22               ` Dave Chinner
2017-08-11 14:27                 ` Brian Foster
2017-08-12  0:16                   ` Dave Chinner
2017-08-12 14:04                     ` Brian Foster
2017-08-14  0:28                       ` Dave Chinner
2017-08-14  8:11                         ` Alex Lyakas
2017-08-14 12:22                           ` Brian Foster
2017-08-14 16:04                             ` Alex Lyakas
2017-08-14 21:33                               ` Darrick J. Wong
2019-03-22  9:12                             ` Shyam Kaushik
2019-03-22 16:08                               ` Darrick J. Wong
2019-03-25 13:49                                 ` Shyam Kaushik
2019-03-25 18:17                                   ` Darrick J. Wong
2019-03-27 16:03                                     ` Alex Lyakas
2019-03-27 20:46                                       ` Dave Chinner
2019-03-28 11:26                                         ` Alex Lyakas
2017-08-17 20:38                         ` Brian Foster
2017-08-17 22:31                           ` Darrick J. Wong
2017-08-18 11:39                             ` Brian Foster
2017-08-18 15:37                               ` Darrick J. Wong
2017-08-18  2:04                           ` Dave Chinner
2017-08-18 11:42                             ` Brian Foster
2017-08-11  2:09             ` Dave Chinner
2017-08-11 14:30               ` Brian Foster
2017-08-11 12:53   ` Christoph Hellwig
2017-08-11 16:52     ` Darrick J. Wong
2017-08-12  7:37       ` Christoph Hellwig
2017-11-21 15:31 ` Libor Klepáč
2017-11-21 16:24   ` Brian Foster
2017-11-21 18:50     ` Darrick J. Wong
2017-11-30 17:55       ` Darrick J. Wong

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=20170809213307.GJ21024@dastard \
    --to=david@fromorbit.com \
    --cc=alex@zadarastorage.com \
    --cc=bfoster@redhat.com \
    --cc=darrick.wong@oracle.com \
    --cc=libor.klepac@bcom.cz \
    --cc=linux-xfs@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.