Re: [fuse-devel] Proxmox + NFS w/ exported FUSE = EIO

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

 



On Sun, 25 Feb 2024 at 21:58, Antonio SJ Musumeci <trapexit@xxxxxxxxxx> wrote:

> I've resolved the issue and I believe I know why I couldn't reproduce
> with current libfuse examples. The fact root node has a generation of 0
> is implicit in the examples and as a result when the request came in the
> lookup on ".." of a child node to root it would return 0. However, in my
> server I start the generation value of everything at different non-zero
> value per instance of the server as at one point I read that ensuring
> different nodeid + gen pairs for different filesystems was better/needed
> for NFS support. I'm guessing the increase in reports I've had was
> happenstance of people upgrading to kernels past 5.14.
>
> In retrospect it makes sense that the nodeid and gen are assumed to be 1
> and 0 respectively, and don't change, but due to the symptoms I had it
> wasn't clicking till I saw the stale check.
>
> Not sure if there is any changes to the kernel code that would make
> sense. A log entry indicating root was tagged as bad and why would have
> helped but not sure it needs more than a note in some docs. Which I'll
> likely add to libfuse.
>
> Thanks for everyone's help. Sorry for the goose chase.

Looking deeper this turned out to be a regression, introduced in v5.14
by commit 15db16837a35 ("fuse: fix illegal access to inode with reused
nodeid").  Prior to this commit the generation number would be ignored
and things would work fine.

The attached patch reverts this behavior for the root inode (which
wasn't intended, since the generation number is not supplied by the
server), but with an added warn_on_once() so this doesn't remain
hidden in the future.

Can you please test with both the fixed and unfixed server?

Thanks,
Miklos
From: Miklos Szeredi <mszeredi@xxxxxxxxxx>
Subject: fuse: fix root lookup with nonzero generation

The root inode has a fixed nodeid and generation (1, 0).

Prior to the commit 15db16837a35 ("fuse: fix illegal access to inode with
reused nodeid") generation number on lookup was ignored.  After this commit
lookup with the wrong generation number resulted in the inode being
unhashed.  This is correct for non-root inodes, but replacing the root
inode is wrong and results in weird behavior.

Fix by reverting to the old behavior if ignoring the generation for the
root inode, but issuing a warning in dmesg.

Reported-by: Antonio SJ Musumeci <trapexit@xxxxxxxxxx>
Fixes: 15db16837a35 ("fuse: fix illegal access to inode with reused nodeid")
Cc: <stable@xxxxxxxxxxxxxxx> # v5.14
Signed-off-by: Miklos Szeredi <mszeredi@xxxxxxxxxx>
---
 fs/fuse/dir.c    |    4 ++++
 fs/fuse/fuse_i.h |    2 ++
 2 files changed, 6 insertions(+)

--- a/fs/fuse/dir.c
+++ b/fs/fuse/dir.c
@@ -391,6 +391,10 @@ int fuse_lookup_name(struct super_block
 	err = -EIO;
 	if (fuse_invalid_attr(&outarg->attr))
 		goto out_put_forget;
+	if (outarg->nodeid == FUSE_ROOT_ID && outarg->generation != 0) {
+		pr_warn_once("root generation should be zero\n");
+		outarg->generation = 0;
+	}
 
 	*inode = fuse_iget(sb, outarg->nodeid, outarg->generation,
 			   &outarg->attr, ATTR_TIMEOUT(outarg),

[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