From: Dave Chinner <david@fromorbit.com>
To: "Darrick J. Wong" <djwong@kernel.org>
Cc: cheng.lin130@zte.com.cn, 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: Sat, 26 Aug 2023 13:08:44 +1000 [thread overview]
Message-ID: <ZOlsvPa2imANAzRu@dread.disaster.area> (raw)
In-Reply-To: <20230825175627.GK17912@frogsfrogsfrogs>
On Fri, Aug 25, 2023 at 10:56:27AM -0700, Darrick J. Wong wrote:
> On Fri, Aug 25, 2023 at 05:09:20PM +0800, cheng.lin130@zte.com.cn wrote:
> > > 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.
>
> Wait, is this the result of a customer problem? Or static analysis?
>
> > >> 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,
>
> I'm not sure why your diff program thinks this hunk is from
> xfs_iunlink_remove, seeing as the line numbers of the chunk point to
> xfs_droplink. Maybe that's what's going on in this part of the thread?
Yes.
I don't expect patches to be mangled like this - I generally
take the hunk prefix to indicate what code is being modified when
reading patches, not expecting that the hunk is modifying code over
a thousand lines prior to the function in the prefix...
So, yeah, something went very wrong with the generation of this
patch...
-Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2023-08-26 3:09 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
2023-08-25 17:56 ` Darrick J. Wong
2023-08-26 3:08 ` Dave Chinner [this message]
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=ZOlsvPa2imANAzRu@dread.disaster.area \
--to=david@fromorbit.com \
--cc=cheng.lin130@zte.com.cn \
--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.