From: Dave Chinner <david@fromorbit.com>
To: "Darrick J. Wong" <djwong@kernel.org>
Cc: xfs <linux-xfs@vger.kernel.org>
Subject: Re: [PATCH] xfs: reset child dir '..' entry when unlinking child
Date: Tue, 6 Jul 2021 08:09:25 +1000 [thread overview]
Message-ID: <20210705220925.GN664593@dread.disaster.area> (raw)
In-Reply-To: <20210703030233.GD24788@locust>
On Fri, Jul 02, 2021 at 08:02:33PM -0700, Darrick J. Wong wrote:
> From: Darrick J. Wong <djwong@kernel.org>
>
> While running xfs/168, I noticed a second source of post-shrink
> corruption errors causing shutdowns.
>
> Let's say that directory B has a low inode number and is a child of
> directory A, which has a high number. If B is empty but open, and
> unlinked from A, B's dotdot link continues to point to A. If A is then
> unlinked and the filesystem shrunk so that A is no longer a valid inode,
> a subsequent AIL push of B will trip the inode verifiers because the
> dotdot entry points outside of the filesystem.
So we have a directory inode that is empty and unlinked but held
open, with a back pointer to an invalid inode number? Which can
never be followed, because the directory has been unlinked.
Can't this be handled in the inode verifier? This seems to me to
be a pretty clear cut case where the ".." back pointer should
always be considered invalid (because the parent dir has no
existence guarantee once the child has been removed from it), not
just in the situation where the filesystem has been shrunk...
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2021-07-05 22:09 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-03 3:02 [PATCH] xfs: reset child dir '..' entry when unlinking child Darrick J. Wong
2021-07-05 8:20 ` Gao Xiang
2021-07-05 8:41 ` Christoph Hellwig
2021-07-06 18:35 ` Darrick J. Wong
2021-07-05 22:09 ` Dave Chinner [this message]
2021-07-05 23:20 ` Gao Xiang
2021-07-06 21:49 ` Darrick J. Wong
2021-07-06 23:07 ` Dave Chinner
2021-07-07 1:36 ` Gao Xiang
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=20210705220925.GN664593@dread.disaster.area \
--to=david@fromorbit.com \
--cc=djwong@kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox