Re: [PATCH 2/2] ovl: support encoding fid from inode with no alias

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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





[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux