On Sun, Sep 05, 2021 at 10:08:33AM +0300, Amir Goldstein wrote: > [ Upstream commit 15db16837a35d8007cb8563358787412213db25e ] > > Server responds to LOOKUP and other ops (READDIRPLUS/CREATE/MKNOD/...) > with ourarg containing nodeid and generation. > > If a fuse inode is found in inode cache with the same nodeid but different > generation, the existing fuse inode should be unhashed and marked "bad" and > a new inode with the new generation should be hashed instead. > > This can happen, for example, with passhrough fuse filesystem that returns > the real filesystem ino/generation on lookup and where real inode numbers > can get recycled due to real files being unlinked not via the fuse > passthrough filesystem. > > With current code, this situation will not be detected and an old fuse > dentry that used to point to an older generation real inode, can be used to > access a completely new inode, which should be accessed only via the new > dentry. > > Note that because the FORGET message carries the nodeid w/o generation, the > server should wait to get FORGET counts for the nlookup counts of the old > and reused inodes combined, before it can free the resources associated to > that nodeid. > > Stable backport notes: > * This is not a regression. The bug has been in fuse forever, but only > a certain class of low level fuse filesystems can trigger this bug > * Because there is no way to check if this fix is applied in runtime, > libfuse test_examples.py tests this fix with hardcoded check for > kernel version >= 5.14 > * After backport to stable kernel(s), the libfuse test can be updated > to also check minimal stable kernel version(s) > * Depends on "fuse: fix bad inode" which is already applied to stable > kernels v5.4.y and v5.10.y > * Required backporting helper inode_wrong_type() All now queued up, thanks! greg k-h
