On Tue, Jan 7, 2025 at 1:24 AM Dmitry Safonov <dima@xxxxxxxxxx> wrote: > > Hi Amir, > > On Sun, Jan 5, 2025 at 4:24 PM Amir Goldstein <amir73il@xxxxxxxxx> wrote: > > > > Dmitry Safonov reported that a WARN_ON() assertion can be trigered by > > userspace when calling inotify_show_fdinfo() for an overlayfs watched > > inode, whose dentry aliases were discarded with drop_caches. > > > > The WARN_ON() assertion in inotify_show_fdinfo() was removed, because > > it is possible for encoding file handle to fail for other reason, but > > the impact of failing to encode an overlayfs file handle goes beyond > > this assertion. > > > > As shown in the LTP test case mentioned in the link below, failure to > > encode an overlayfs file handle from a non-aliased inode also leads to > > failure to report an fid with FAN_DELETE_SELF fanotify events. > > > > As Dmitry notes in his analyzis of the problem, ovl_encode_fh() fails > > if it cannot find an alias for the inode, but this failure can be fixed. > > ovl_encode_fh() seldom uses the alias and in the case of non-decodable > > file handles, as is often the case with fanotify fid info, > > ovl_encode_fh() never needs to use the alias to encode a file handle. > > > > Defer finding an alias until it is actually needed so ovl_encode_fh() > > will not fail in the common case of FAN_DELETE_SELF fanotify events. > > > > Fixes: 16aac5ad1fa9 ("ovl: support encoding non-decodable file handles") > > Reported-by: Dmitry Safonov <dima@xxxxxxxxxx> > > Closes: https://lore.kernel.org/linux-fsdevel/CAOQ4uxiie81voLZZi2zXS1BziXZCM24nXqPAxbu8kxXCUWdwOg@xxxxxxxxxxxxxx/ > > Signed-off-by: Amir Goldstein <amir73il@xxxxxxxxx> > > Thank you for such a quick and proper fix, even though it was the > holiday season :-) > > FWIW, I've pushed the patches locally. In two or three days I should > have some hundreds of test results from the duts where the issue was > hitting originally. Judging by code changes, I hardly doubt the > original issue would reproduce, but might be worth getting more > coverage of this code. The kernel with your patches has run some ~500 tests on different duts that previously hit the reported issue. It's not hitting anymore (obviously) and there aren't any other new issues on those tests. Tested-by: Dmitry Safonov <dima@xxxxxxxxxx> Thank you once again, Dmitry