linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Brian Foster <bfoster@redhat.com>
To: "Darrick J. Wong" <darrick.wong@oracle.com>
Cc: sandeen@sandeen.net, linux-xfs@vger.kernel.org, alex@zadara.com
Subject: Re: [PATCH 6/6] xfs_repair: check plausibility of root dir pointer before trashing it
Date: Thu, 5 Dec 2019 09:38:58 -0500	[thread overview]
Message-ID: <20191205143858.GF48368@bfoster> (raw)
In-Reply-To: <157547910268.974712.78208912903649937.stgit@magnolia>

On Wed, Dec 04, 2019 at 09:05:02AM -0800, Darrick J. Wong wrote:
> From: Darrick J. Wong <darrick.wong@oracle.com>
> 
> If sb_rootino doesn't point to where we think mkfs should have allocated
> the root directory, check to see if the alleged root directory actually
> looks like a root directory.  If so, we'll let it live because someone
> could have changed sunit since formatting time, and that changes the
> root directory inode estimate.
> 
> Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
> ---
>  repair/xfs_repair.c |   45 +++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 45 insertions(+)
> 
> 
> diff --git a/repair/xfs_repair.c b/repair/xfs_repair.c
> index abd568c9..b0407f4b 100644
> --- a/repair/xfs_repair.c
> +++ b/repair/xfs_repair.c
> @@ -426,6 +426,37 @@ _("would reset superblock %s inode pointer to %"PRIu64"\n"),
>  	*ino = expected_ino;
>  }
>  
> +/* Does the root directory inode look like a plausible root directory? */
> +static bool
> +has_plausible_rootdir(
> +	struct xfs_mount	*mp)
> +{
> +	struct xfs_inode	*ip;
> +	xfs_ino_t		ino;
> +	int			error;
> +	bool			ret = false;
> +
> +	error = -libxfs_iget(mp, NULL, mp->m_sb.sb_rootino, 0, &ip,
> +			&xfs_default_ifork_ops);
> +	if (error)
> +		goto out;
> +	if (!S_ISDIR(VFS_I(ip)->i_mode))
> +		goto out_rele;
> +
> +	error = -libxfs_dir_lookup(NULL, ip, &xfs_name_dotdot, &ino, NULL);
> +	if (error)
> +		goto out_rele;
> +
> +	/* The root directory '..' entry points to the directory. */
> +	if (ino == mp->m_sb.sb_rootino)
> +		ret = true;
> +
> +out_rele:
> +	libxfs_irele(ip);
> +out:
> +	return ret;
> +}
> +
>  /*
>   * Make sure that the first 3 inodes in the filesystem are the root directory,
>   * the realtime bitmap, and the realtime summary, in that order.
> @@ -436,6 +467,20 @@ calc_mkfs(
>  {
>  	xfs_ino_t		rootino = libxfs_ialloc_calc_rootino(mp, -1);
>  
> +	/*
> +	 * If the root inode isn't where we think it is, check its plausibility
> +	 * as a root directory.  It's possible that somebody changed sunit
> +	 * since the filesystem was created, which can change the value of the
> +	 * above computation.  Don't blow up the root directory if this is the
> +	 * case.
> +	 */
> +	if (mp->m_sb.sb_rootino != rootino && has_plausible_rootdir(mp)) {
> +		do_warn(
> +_("sb root inode value %" PRIu64 " inconsistent with alignment (expected %"PRIu64")\n"),
> +			mp->m_sb.sb_rootino, rootino);
> +		rootino = mp->m_sb.sb_rootino;
> +	}
> +

A slightly unfortunate side effect of this is that there's seemingly no
straightforward way for a user to "clear" this state/warning. We've
solved the major problem by allowing repair to handle this condition,
but AFAICT this warning will persist unless the stripe unit is changed
back to its original value.

IOW, what if this problem exists simply because a user made a mistake
and wants to undo it? It's probably easy enough for us to say "use
whatever you did at mkfs time," but what if that's unknown or was set
automatically? I feel like that is the type of thing that in practice
could result in unnecessary bugs or error reports unless the tool can
make a better suggestion to the end user. For example, could we check
the geometry on secondary supers (if they exist) against the current
rootino and use that as a secondary form of verification and/or suggest
the user reset to that geometry (if desired)? OTOH, I guess we'd have to
consider what happens if the filesystem was grown in that scenario too..
:/

(Actually on a quick test, it looks like growfs updates every super,
even preexisting..).

Brian

>  	ensure_fixed_ino(&mp->m_sb.sb_rootino, rootino,
>  			_("root"));
>  	ensure_fixed_ino(&mp->m_sb.sb_rbmino, rootino + 1,
> 


  reply	other threads:[~2019-12-05 14:39 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-04 17:04 [PATCH v2 0/6] xfs_repair: do not trash valid root dirs Darrick J. Wong
2019-12-04 17:04 ` [PATCH 1/6] xfs: don't commit sunit/swidth updates to disk if that would cause repair failures Darrick J. Wong
2019-12-04 17:04 ` [PATCH 2/6] mkfs: check root inode location Darrick J. Wong
2019-12-05 14:36   ` Brian Foster
2019-12-04 17:04 ` [PATCH 3/6] xfs_repair: enforce that inode btree chunks can't point to AG headers Darrick J. Wong
2019-12-05 14:37   ` Brian Foster
2019-12-05 16:28     ` Darrick J. Wong
2019-12-06 16:00       ` Brian Foster
2019-12-12 19:11       ` Eric Sandeen
2019-12-12 20:38   ` Eric Sandeen
2019-12-12 22:10     ` Darrick J. Wong
2019-12-04 17:04 ` [PATCH 4/6] xfs_repair: refactor fixed inode location checks Darrick J. Wong
2019-12-05 14:37   ` Brian Foster
2019-12-04 17:04 ` [PATCH 5/6] xfs_repair: use libxfs function to calculate root inode location Darrick J. Wong
2019-12-05 14:37   ` Brian Foster
2019-12-04 17:05 ` [PATCH 6/6] xfs_repair: check plausibility of root dir pointer before trashing it Darrick J. Wong
2019-12-05 14:38   ` Brian Foster [this message]
2019-12-12 22:46     ` [PATCH 6/6] xfs_repair: check plausibility of root dir pointer before trashing it\ Darrick J. Wong
2019-12-13 11:19       ` Brian Foster
2019-12-16 16:34         ` Darrick J. Wong
2019-12-17 11:32           ` Brian Foster

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=20191205143858.GF48368@bfoster \
    --to=bfoster@redhat.com \
    --cc=alex@zadara.com \
    --cc=darrick.wong@oracle.com \
    --cc=linux-xfs@vger.kernel.org \
    --cc=sandeen@sandeen.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).