On Mon, Mar 23, 2020 at 2:24 PM Amir Goldstein <amir73il@xxxxxxxxx> wrote: > > 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. Yeah, needs a comment: both ovl_remove_upper() and ovl_remove_and_whiteout() unhash the dentry before returning, so d_find_alias() will find another hashed dentry or none. > 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. Okay. Thanks, Miklos
