From: <cheng.lin130@zte.com.cn>
To: <david@fromorbit.com>
Cc: <djwong@kernel.org>, <linux-xfs@vger.kernel.org>,
<linux-kernel@vger.kernel.org>, <jiang.yong5@zte.com.cn>,
<wang.liang82@zte.com.cn>, <liu.dong3@zte.com.cn>
Subject: Re: [PATCH] xfs: introduce protection for drop nlink
Date: Fri, 25 Aug 2023 17:09:20 +0800 (CST) [thread overview]
Message-ID: <202308251709208292077@zte.com.cn> (raw)
In-Reply-To: <ZOfhoLql0TYiD5JW@dread.disaster.area>
> On Thu, Aug 24, 2023 at 03:43:52PM +0800, cheng.lin130@zte.com.cn wrote:
>> From: Cheng Lin <cheng.lin130@zte.com.cn>
>> An dir nlinks overflow which down form 0 to 0xffffffff, cause the
>> directory to become unusable until the next xfs_repair run.
> Hmmm. How does this ever happen?
> IMO, if it does happen, we need to fix whatever bug that causes it
> to happen, not issue a warning and do nothing about the fact we
> just hit a corrupt inode state...
Yes, I'm very agree with your opinion. But I don't know how it happened,
and how to reproduce it.
>> Introduce protection for drop nlink to reduce the impact of this.
>> And produce a warning for directory nlink error during remove.
>>
>> Signed-off-by: Cheng Lin <cheng.lin130@zte.com.cn>
>> ---
>> fs/xfs/xfs_inode.c | 16 +++++++++++++++-
>> 1 file changed, 15 insertions(+), 1 deletion(-)
>>
>> diff --git a/fs/xfs/xfs_inode.c b/fs/xfs/xfs_inode.c
>> index 9e62cc5..536dbe4 100644
>> --- a/fs/xfs/xfs_inode.c
>> +++ b/fs/xfs/xfs_inode.c
>> @@ -919,6 +919,15 @@ STATIC int xfs_iunlink_remove(struct xfs_trans *tp, struct xfs_perag *pag,
>> xfs_trans_t *tp,
>> xfs_inode_t *ip)
>> {
>> + xfs_mount_t *mp;
>> +
>> + if (VFS_I(ip)->i_nlink == 0) {
>> + mp = ip->i_mount;
>> + xfs_warn(mp, "%s: Deleting inode %llu with no links.",
>> + __func__, ip->i_ino);
>> + return 0;
>> + }
> This is obviously incorrect - whiteout inodes (RENAME_WHITEOUT) have an
> i_nlink of zero when they are removed from the unlinked list. As do
> O_TMPFILE inodes - when they are linked into the filesystem, we
> explicitly check for i_nlink being zero before calling
> xfs_iunlink_remove().
I am not familiar with the above process. You means there is such a
scenario, even if it is (i_nlink==0), it still needs to run drop_nlink()
in xfs_droplink()? But this will cause i_nlink to underflow to 0xffffffff.
>> +
>> xfs_trans_ichgtime(tp, ip, XFS_ICHGTIME_CHG);
>>
>> drop_nlink(VFS_I(ip));
> Wait a second - this code doesn't match an upstream kernel. What
> kernel did you make this patch against?
It's kernel mainline linux-6.5-rc7
Thanks.
> -Dave.
> --
> Dave Chinner
> david@fromorbit.com
next prev parent reply other threads:[~2023-08-25 9:10 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-24 7:43 [PATCH] xfs: introduce protection for drop nlink cheng.lin130
2023-08-24 16:12 ` Darrick J. Wong
2023-08-25 8:32 ` cheng.lin130
2023-08-25 18:02 ` Darrick J. Wong
2023-08-26 14:54 ` cheng.lin130
2023-08-26 21:28 ` Dave Chinner
2023-08-28 3:29 ` cheng.lin130
2023-08-28 5:21 ` Dave Chinner
[not found] ` <202309041042177773780@zte.com.cn>
2023-09-04 22:49 ` Dave Chinner
2023-08-24 23:02 ` Dave Chinner
2023-08-25 9:09 ` cheng.lin130 [this message]
2023-08-25 17:56 ` Darrick J. Wong
2023-08-26 3:08 ` Dave Chinner
2023-08-26 15:08 ` cheng.lin130
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=202308251709208292077@zte.com.cn \
--to=cheng.lin130@zte.com.cn \
--cc=david@fromorbit.com \
--cc=djwong@kernel.org \
--cc=jiang.yong5@zte.com.cn \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=liu.dong3@zte.com.cn \
--cc=wang.liang82@zte.com.cn \
/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