All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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 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.