All of lore.kernel.org
 help / color / mirror / Atom feed
From: Brian Foster <bfoster@redhat.com>
To: Christoph Hellwig <hch@lst.de>
Cc: "Darrick J. Wong" <darrick.wong@oracle.com>, linux-xfs@vger.kernel.org
Subject: Re: [PATCH 08/12] xfs: remove xfs_ifork_ops
Date: Thu, 7 May 2020 12:28:46 -0400	[thread overview]
Message-ID: <20200507162846.GG9003@bfoster> (raw)
In-Reply-To: <20200507134355.GF9003@bfoster>

On Thu, May 07, 2020 at 09:43:55AM -0400, Brian Foster wrote:
> On Thu, May 07, 2020 at 02:34:11PM +0200, Christoph Hellwig wrote:
> > On Fri, May 01, 2020 at 02:23:16PM -0400, Brian Foster wrote:
> > > Can we use another dummy parent inode value in xfs_repair? It looks to
> > > me that we set it to zero in phase 4 if it fails verification and set
> > > the parent to NULLFSINO (i.e. unknown) in repair's in-core tracking.
> > > Phase 6 walks the directory entries and explicitly sets the parent inode
> > > number of entries with an unknown parent (according to the in-core
> > > tracking). IOW, I don't see where we actually rely on the directory
> > > header having a parent inode of zero outside of detecting it in the
> > > custom verifier. If that's the only functional purpose, I wonder if we
> > > could do something like set the bogus parent field of a sf dir to the
> > > root inode or to itself, that way the default verifier wouldn't trip
> > > over it..
> > 
> > I don't think we need a dummy parent at all - we can just skip the
> > parent validation entirely, which is what my incremental patch does.
> > 
> 
> xfs_repair already skips the parent validation, this patch just
> refactors it. What I was considering above is whether repair uses the
> current dummy value of zero for any functional reason. If not, it kind
> of looks like the earlier phase of repair checks the parent, sees that
> it would fail a verifier, replaces it with zero (which would also fail
> the verifier) and then eventually replaces zero with a valid parent or
> ditches the entry in phase 6. If we placed a temporary parent value in
> the early phase that wouldn't explicitly fail a verifier by being an
> invalid inode number (instead of using 0 to notify the verifier to skip
> the validation), then we wouldn't need to skip the parent validation in
> phase 6 when we look up the inode again.
> 
...

To demonstrate, I hacked on repair a bit using an fs with an
intentionally corrupted shortform parent inode and had to make the
following tweaks to work around the custom fork verifier. The
ino_discovery checks were added because phases 3 and 4 toggle that flag
such that the former clears the parent value in the inode, but the
latter actually updates the external parent tracking. IOW, setting a
"valid" inode in phase 3 would otherwise trick phase 4 into using it.
I'd probably try to think of something cleaner for that issue if we were
to take such an approach.

Brian

diff --git a/repair/dir2.c b/repair/dir2.c
index cbbce601..c30ccb37 100644
--- a/repair/dir2.c
+++ b/repair/dir2.c
@@ -165,7 +165,7 @@ process_sf_dir2(
 	int			tmp_elen;
 	int			tmp_len;
 	xfs_dir2_sf_entry_t	*tmp_sfep;
-	xfs_ino_t		zero = 0;
+	xfs_ino_t		zero = mp->m_sb.sb_rootino;
 
 	sfp = (struct xfs_dir2_sf_hdr *)XFS_DFORK_DPTR(dip);
 	max_size = XFS_DFORK_DSIZE(dip, mp);
@@ -494,7 +494,8 @@ _("bogus .. inode number (%" PRIu64 ") in directory inode %" PRIu64 ", "),
 		if (!no_modify)  {
 			do_warn(_("clearing inode number\n"));
 
-			libxfs_dir2_sf_put_parent_ino(sfp, zero);
+			if (!ino_discovery)
+				libxfs_dir2_sf_put_parent_ino(sfp, zero);
 			*dino_dirty = 1;
 			*repair = 1;
 		} else  {
@@ -528,8 +529,8 @@ _("bad .. entry in directory inode %" PRIu64 ", points to self, "),
 			ino);
 		if (!no_modify)  {
 			do_warn(_("clearing inode number\n"));
-
-			libxfs_dir2_sf_put_parent_ino(sfp, zero);
+			if (!ino_discovery)
+				libxfs_dir2_sf_put_parent_ino(sfp, zero);
 			*dino_dirty = 1;
 			*repair = 1;
 		} else  {
diff --git a/repair/phase6.c b/repair/phase6.c
index beceea9a..613ca578 100644
--- a/repair/phase6.c
+++ b/repair/phase6.c
@@ -1104,7 +1104,7 @@ mv_orphanage(
 					(unsigned long long)ino, ++incr);
 
 	/* Orphans may not have a proper parent, so use custom ops here */
-	err = -libxfs_iget(mp, NULL, ino, 0, &ino_p, &phase6_ifork_ops);
+	err = -libxfs_iget(mp, NULL, ino, 0, &ino_p, &xfs_default_ifork_ops);
 	if (err)
 		do_error(_("%d - couldn't iget disconnected inode\n"), err);
 
@@ -2875,7 +2875,7 @@ process_dir_inode(
 
 	ASSERT(!is_inode_refchecked(irec, ino_offset) || dotdot_update);
 
-	error = -libxfs_iget(mp, NULL, ino, 0, &ip, &phase6_ifork_ops);
+	error = -libxfs_iget(mp, NULL, ino, 0, &ip, &xfs_default_ifork_ops);
 	if (error) {
 		if (!no_modify)
 			do_error(


  reply	other threads:[~2020-05-07 16:28 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-01  8:14 dinode reading cleanups Christoph Hellwig
2020-05-01  8:14 ` [PATCH 01/12] xfs: xfs_bmapi_read doesn't take a fork id as the last argument Christoph Hellwig
2020-05-01 13:33   ` Brian Foster
2020-05-01  8:14 ` [PATCH 02/12] xfs: call xfs_iformat_fork from xfs_inode_from_disk Christoph Hellwig
2020-05-01 13:33   ` Brian Foster
2020-05-01  8:14 ` [PATCH 03/12] xfs: split xfs_iformat_fork Christoph Hellwig
2020-05-01 13:34   ` Brian Foster
2020-05-07 12:27     ` Christoph Hellwig
2020-05-07 13:40       ` Brian Foster
2020-05-07 13:42         ` Christoph Hellwig
2020-05-01  8:14 ` [PATCH 04/12] xfs: handle unallocated inodes in xfs_inode_from_disk Christoph Hellwig
2020-05-01 13:34   ` Brian Foster
2020-05-01  8:14 ` [PATCH 05/12] xfs: call xfs_dinode_verify from xfs_inode_from_disk Christoph Hellwig
2020-05-01 13:34   ` Brian Foster
2020-05-01  8:14 ` [PATCH 06/12] xfs: don't reset i_delayed_blks in xfs_iread Christoph Hellwig
2020-05-01 13:34   ` Brian Foster
2020-05-01  8:14 ` [PATCH 07/12] xfs: remove xfs_iread Christoph Hellwig
2020-05-01 15:56   ` Brian Foster
2020-05-01  8:14 ` [PATCH 08/12] xfs: remove xfs_ifork_ops Christoph Hellwig
2020-05-01 15:56   ` Brian Foster
2020-05-01 16:08     ` Darrick J. Wong
2020-05-01 16:38       ` Christoph Hellwig
2020-05-01 16:50         ` Christoph Hellwig
2020-05-01 18:23           ` Brian Foster
2020-05-07 12:34             ` Christoph Hellwig
2020-05-07 13:43               ` Brian Foster
2020-05-07 16:28                 ` Brian Foster [this message]
2020-05-07 17:18                   ` Christoph Hellwig
2020-05-12 23:50                     ` Darrick J. Wong
2020-05-01  8:14 ` [PATCH 09/12] xfs: refactor xfs_inode_verify_forks Christoph Hellwig
2020-05-01 15:57   ` Brian Foster
2020-05-01 16:40     ` Christoph Hellwig
2020-05-01 17:02       ` Brian Foster
2020-05-01 17:08         ` Christoph Hellwig
2020-05-01  8:14 ` [PATCH 10/12] xfs: improve local fork verification Christoph Hellwig
2020-05-01  8:14 ` [PATCH 11/12] xfs: remove the special COW fork handling in xfs_bmapi_read Christoph Hellwig
2020-05-01 15:57   ` Brian Foster
2020-05-01  8:14 ` [PATCH 12/12] xfs: remove the NULL " Christoph Hellwig
2020-05-01 15:58   ` Brian Foster
2020-05-08  6:34 dinode reading cleanups v2 Christoph Hellwig
2020-05-08  6:34 ` [PATCH 08/12] xfs: remove xfs_ifork_ops Christoph Hellwig
2020-05-08 15:05   ` Brian Foster
2020-05-09  8:17     ` Christoph Hellwig
2020-05-09 11:13       ` Brian Foster
2020-05-16 17:48         ` Darrick J. Wong
2020-05-18 13:35           ` Brian Foster
2020-05-18 16:07             ` 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=20200507162846.GG9003@bfoster \
    --to=bfoster@redhat.com \
    --cc=darrick.wong@oracle.com \
    --cc=hch@lst.de \
    --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.