Re: [RFC PATCH] fs: introduce check for drop/inc_nlink

[<cheng.lin130@zte.com.cn>]

> On Fri, Oct 13, 2023 at 05:40:57PM +0800, cheng.lin130@zte.com.cn wrote:
> > > On Fri, Oct 13, 2023 at 03:27:30PM +0800, cheng.lin130@zte.com.cn wrote:
> > > > From: Cheng Lin <cheng.lin130@zte.com.cn>
> > > >
> > > > Avoid inode nlink overflow or underflow.
> > > >
> > > > Signed-off-by: Cheng Lin <cheng.lin130@zte.com.cn>
> > > > ---
> > > I'm very confused. There's no explanation why that's needed. As it
> > > stands it's not possible to provide a useful review.
> > > I'm not saying it's wrong. I just don't understand why and even if this
> > > should please show up in the commit message.
> > In an xfs issue, there was an nlink underflow of a directory inode. There
> > is a key information in the kernel messages, that is the WARN_ON from
> > drop_nlink(). However, VFS did not prevent the underflow. I'm not sure
> > if this behavior is inadvertent or specifically designed. As an abnormal
> > situation, perhaps prohibiting nlink overflow or underflow is a better way
> > to handle it.
> > Request for your comment.
> I was trying to steer you towards modifying vfs_rmdir and vfs_unlink to
> check that i_nlink of the files involved aren't somehow already zero
> and returning -EFSCORRUPTED if they are.  Not messing around with
> drop_nlink.
> --D
It seems that VFS is not very concerned about the values of filesystem,
such as inode nlinks. And the defination of whether it is correct or incorrect
is left to the specific filesystem. However, in some places do have limit
up to s_max_links. Perhaps the limit down to zero is also reasonable.
Is that right？