linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Gao Xiang <hsiangkao@redhat.com>
To: linux-xfs@vger.kernel.org
Cc: Eric Sandeen <sandeen@sandeen.net>, Donald Douwsma <ddouwsma@redhat.com>
Subject: Re: [RFC PATCH v2] xfsrestore: fix rootdir due to xfsdump bulkstat misuse
Date: Mon, 16 Nov 2020 16:13:59 +0800	[thread overview]
Message-ID: <20201116081359.GA1486562@xiangao.remote.csb> (raw)
In-Reply-To: <20201116080723.1486270-1-hsiangkao@redhat.com>

On Mon, Nov 16, 2020 at 04:07:23PM +0800, Gao Xiang wrote:
> If rootino is wrong and misspecified to a subdir inode #,
> the following assertion could be triggered:
>   assert(ino != persp->p_rootino || hardh == persp->p_rooth);
> 
> This patch adds a '-x' option (another awkward thing is that
> the codebase doesn't support long options) to address
> problamatic images by searching for the real dir, the reason
> that I don't enable it by default is that I'm not very confident
> with the xfsrestore codebase and xfsdump bulkstat issue will
> also be fixed immediately as well, so this function might be
> optional and only useful for pre-exist corrupted dumps.
> 
> In details, my understanding of the original logic is
>  1) xfsrestore will create a rootdir node_t (p_rooth);
>  2) it will build the tree hierarchy from inomap and adopt
>     the parent if needed (so inodes whose parent ino hasn't
>     detected will be in the orphan dir, p_orphh);
>  3) during this period, if ino == rootino and
>     hardh != persp->p_rooth (IOWs, another node_t with
>     the same ino # is created), that'd be definitely wrong.
> 
> So the proposal fix is that
>  - considering the xfsdump root ino # is a subdir inode, it'll
>    trigger ino == rootino && hardh != persp->p_rooth condition;
>  - so we log this node_t as persp->p_rooth rather than the
>    initial rootdir node_t created in 1);
>  - we also know that this node is actually a subdir, and after
>    the whole inomap is scanned (IOWs, the tree is built),
>    the real root dir will have the orphan dir parent p_orphh;
>  - therefore, we walk up by the parent until some node_t has
>    the p_orphh, so that's it.
> 
> Cc: Donald Douwsma <ddouwsma@redhat.com>
> Signed-off-by: Gao Xiang <hsiangkao@redhat.com>
> ---
> changes since RFC v1:
>  - fix non-dir fake rootino cases since tree_begindir()
>    won't be triggered for these non-dir, and we could do
>    that in tree_addent() instead (fault injection verified);
> 
>  - fix fake rootino case with gen = 0 as well, for more
>    details, see the inlined comment in link_hardh()
>    (fault injection verified as well).
> 
> Anyway, all of this behaves like a workaround and I have
> no idea how to deal it more gracefully.
>

My manual fault injection patch:
 - inject a non-dir fake rootino;
 - inject all inode gen = 0 (to check the fake rootino case with gen = 0);
 - disable the fake rootino case with gen = 0 workaround, and see
    xfsrestore: tree.c:1003: tree_addent: Assertion `hardp->n_nrh != NRH_NULL' failed.
   could happen.


diff --git a/dump/content.c b/dump/content.c
index c11d9b4..2d27d24 100644
--- a/dump/content.c
+++ b/dump/content.c
@@ -1509,6 +1509,7 @@ baseuuidbypass:
 	}
 
 	scwhdrtemplatep->cih_rootino = sc_rootxfsstatp->bs_ino;
+	scwhdrtemplatep->cih_rootino = 25166002;	/* inject some real non-dir ino # */
 	inomap_writehdr(scwhdrtemplatep);
 
 	/* log the dump size. just a rough approx.
diff --git a/restore/content.c b/restore/content.c
index e807a83..f493fdb 100644
--- a/restore/content.c
+++ b/restore/content.c
@@ -8143,7 +8143,7 @@ read_filehdr(drive_t *drivep, filehdr_t *fhdrp, bool_t fhcs)
 			return RV_CORRUPT;
 		}
 	}
-
+	bstatp->bs_gen = 0;
 	return RV_OK;
 }
 
@@ -8277,6 +8277,8 @@ read_dirent(drive_t *drivep,
 		}
 	}
 
+	dhdrp->dh_gen = 0;
+
 	mlog(MLOG_NITTY,
 	      "read dirent hdr ino %llu gen %u size %u\n",
 	      dhdrp->dh_ino,
diff --git a/restore/tree.c b/restore/tree.c
index 918fa01..2d8dec5 100644
--- a/restore/tree.c
+++ b/restore/tree.c
@@ -3886,6 +3886,7 @@ link_hardh(xfs_ino_t ino, gen_t gen)
 {
 	nh_t tmp = hash_find(ino, gen);
 
+#if 0
 	/*
 	 * XXX (another workaround): the simply way is that don't reuse node_t
 	 * with gen = 0 created in tree_init(). Otherwise, it could cause
@@ -3903,6 +3904,7 @@ _("link out fake rootino %llu with gen=0 created in tree_init()\n"), ino);
 		orig_rooth = tmp;
 		return NH_NULL;
 	}
+#endif
 	return tmp;
 }
 
-- 
2.18.4



  reply	other threads:[~2020-11-16  8:27 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-13 12:51 [RFC PATCH] xfsrestore: fix rootdir due to xfsdump bulkstat misuse Gao Xiang
2020-11-13 14:10 ` Eric Sandeen
2020-11-13 14:15   ` Gao Xiang
2020-11-16  8:23     ` Gao Xiang
2020-11-16  8:07 ` [RFC PATCH v2] " Gao Xiang
2020-11-16  8:13   ` Gao Xiang [this message]
2021-09-27 15:00   ` Bill O'Donnell
2021-12-20 15:14   ` Masayoshi Mizuma
2022-06-10 23:05   ` Hironori Shiina
2022-06-30 19:19     ` Hironori Shiina
2022-09-28 19:10   ` [RFC PATCH V3] " Hironori Shiina
2022-09-29 18:17     ` Darrick J. Wong
2023-04-19 14:16       ` Eric Sandeen
2023-04-19 15:40         ` Darrick J. Wong
2023-04-21  9:10           ` Carlos Maiolino
2023-04-21 16:14             ` 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=20201116081359.GA1486562@xiangao.remote.csb \
    --to=hsiangkao@redhat.com \
    --cc=ddouwsma@redhat.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).