From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: sandeen@redhat.com, linux-xfs@vger.kernel.org
Subject: Re: [PATCH 09/11] xfs_repair: don't assert if we run across a dir entry with null ino ptr
Date: Fri, 4 May 2018 15:45:18 -0700 [thread overview]
Message-ID: <20180504224518.GX26569@magnolia> (raw)
In-Reply-To: <724f18e7-147d-4c24-ba06-559a5b057e4f@sandeen.net>
On Fri, May 04, 2018 at 05:33:35PM -0500, Eric Sandeen wrote:
>
>
> On 4/17/18 9:47 PM, Darrick J. Wong wrote:
> > From: Darrick J. Wong <darrick.wong@oracle.com>
> >
> > If we encounter a directory with an entry that points to inode zero,
> > we'll crash due to an ASSERT during process_inode_chunk. Instead, just
> > set the in-core parent to NULLFSINO so that phase 6 will reset it for
> > us.
> >
> > Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
>
> So .... this is .... probably ok? but the ASSERT makes me think that
> process_dinode is never supposed to return a 0 parent if isa_dir is set,
> and so I'm a little worried about breaking that assumption up and just
> catching it later, here. Usually the asserts mean "the code should never
> let this happen and if it does, some prior code is wrong"
>
> Looking at the calls below it, it seems like we generally call verify_inum
> which would set NULLFSINO if the inum is bad.
>
> But in process_dir2_data
>
> [17:25] <sandeen> } else if (verify_inum(mp, ent_ino)) {
> [17:25] <sandeen> clearreason = _("invalid");
> [17:26] <sandeen> so we probably saw that it's bad, but:
> [17:26] <sandeen> * We have a special dot & dotdot fixer-upper below which can
> [17:26] <sandeen> * sort out the proper inode number, so don't clear it.
> [17:26] <sandeen> clearreason = NULL;
> [17:26] <sandeen> and then:
> [17:26] <sandeen> * Special .. entry processing.
> [17:26] <sandeen> *parent = ent_ino;
> [17:26] <sandeen> \o/
>
> so ... I wonder if it wouldn't be more consistent to find the place under
> process_inode() where we willingly/wrongly set *parent to an invalid value,
> and handle the problem there? Do you know what path you were on to hit this?
/me doesn't remember, it was either the sf dir scrub or the dir block
offline repair fuzztest setting the parent pointer to zero.
--D
> -Eric
> > ---
> > repair/dino_chunks.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> >
> > diff --git a/repair/dino_chunks.c b/repair/dino_chunks.c
> > index 17de95f..2d34079 100644
> > --- a/repair/dino_chunks.c
> > +++ b/repair/dino_chunks.c
> > @@ -874,7 +874,8 @@ process_inode_chunk(
> > * be solid then.
> > */
> > if (!ino_discovery) {
> > - ASSERT(parent != 0);
> > + if (parent == 0)
> > + parent = NULLFSINO;
> > set_inode_parent(ino_rec, irec_offset, parent);
> > ASSERT(parent ==
> > get_inode_parent(ino_rec, irec_offset));
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2018-05-04 22:45 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-18 2:46 [PATCH 00/11] xfsprogs-4.17: xfs_repair fixes Darrick J. Wong
2018-04-18 2:46 ` [PATCH 01/11] xfs_repair: examine all remote attribute blocks Darrick J. Wong
2018-05-04 18:20 ` Eric Sandeen
2018-05-04 19:23 ` Darrick J. Wong
2018-05-23 3:15 ` [PATCH v2 " Darrick J. Wong
2018-05-23 3:47 ` Allison Henderson
2018-04-18 2:46 ` [PATCH 02/11] xfs_repair: don't leak buffer on xattr remote buf verifier error Darrick J. Wong
2018-05-04 19:16 ` Eric Sandeen
2018-04-18 2:46 ` [PATCH 03/11] xfs_repair: validate some of the log space information Darrick J. Wong
2018-05-04 19:29 ` Eric Sandeen
2018-05-04 20:25 ` Darrick J. Wong
2018-05-04 20:54 ` Eric Sandeen
2018-05-23 3:15 ` [PATCH v2 " Darrick J. Wong
2018-05-23 3:52 ` Allison Henderson
2018-04-18 2:46 ` [PATCH 04/11] xfs_repair: zap corrupt remote symlink Darrick J. Wong
2018-05-04 19:46 ` Eric Sandeen
2018-05-04 20:22 ` Darrick J. Wong
2018-04-18 2:47 ` [PATCH 05/11] xfs_repair: treat zero da btree pointers as corruption Darrick J. Wong
2018-05-04 19:59 ` Eric Sandeen
2018-04-18 2:47 ` [PATCH 06/11] xfs_repair: invalidate dirty dir buffers when we zap a directory Darrick J. Wong
2018-05-04 20:13 ` Eric Sandeen
2018-04-18 2:47 ` [PATCH 07/11] xfs_repair: only update in-core extent state after scanning full extent Darrick J. Wong
2018-05-04 21:52 ` Eric Sandeen
2018-04-18 2:47 ` [PATCH 08/11] xfs_repair: don't crash if da btree is corrupt Darrick J. Wong
2018-05-04 22:00 ` Eric Sandeen
2018-04-18 2:47 ` [PATCH 09/11] xfs_repair: don't assert if we run across a dir entry with null ino ptr Darrick J. Wong
2018-05-04 22:33 ` Eric Sandeen
2018-05-04 22:45 ` Darrick J. Wong [this message]
2018-05-08 16:07 ` Darrick J. Wong
2018-05-08 16:31 ` [PATCH v2 09/11] xfs_repair: actually fix .. entries that point to inode zero Darrick J. Wong
2018-04-18 2:47 ` [PATCH 10/11] xfs_repair: check inode nsec for obviously garbage values Darrick J. Wong
2018-05-04 22:38 ` Eric Sandeen
2018-04-18 2:47 ` [PATCH 11/11] xfs_repair: don't assert on bad '.' entry in no-modify mode Darrick J. Wong
2018-05-04 22:41 ` Eric Sandeen
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=20180504224518.GX26569@magnolia \
--to=darrick.wong@oracle.com \
--cc=linux-xfs@vger.kernel.org \
--cc=sandeen@redhat.com \
--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