Re: Kernel warnings in fs/inode.c:302 drop_nlink+0x28/0x40

[Amir Goldstein <amir73il@gmail.com>]

On Mon, Mar 23, 2020 at 2:53 PM Miklos Szeredi <miklos@szeredi.hu> wrote:
>
> On Mon, Mar 23, 2020 at 9:50 AM Phasip <phasip@gmail.com> wrote:
> >
> > Hello!
> >
> > I have stumbled upon two ways of producing kernel warnings when using the overlayfs, both seem to be results of the same issue.
> >
> > The issue seems to be related to handling of hard links that are created directly in the upperdir.
> > Below is my system details and then two samples with a list of commands to reproduce and the corresponding kernel warning
>
> Hi,
>
> Thanks for the report.
>
> The problem is that i_nlink is not kept in sync with changes to
> underlying layers.   That would not in itself be an issue, since
> modification of the underlying layers may result in
> undefined/unexpected behavior.  The problem is that this manifests
> itself as a kernel warning.
>
> Since unlink/rename is synchronized on the victim inode (the one that
> is getting removed) it is possible to detect this condition and
> prevent drop_nlink() from being called.
>
> Attached patch fixes both of your testcases.

IDGI. coming from vfs_unlink() and vfs_rename() it doesn't look like
it is possible for victim inode not to have a hashed alias, so the
alias test seems futile.

We better replace the WARN_ON() with pr_warn_ratelimited().

>
> We'll need an xfstests case for this as well.
>

Please forward the part of the email with the test case to the list.

Thanks,
Amir.