On Mon, Mar 23, 2020 at 2:53 PM Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > > On Mon, Mar 23, 2020 at 9:50 AM Phasip <phasip@xxxxxxxxx> 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.
