Bug 216777
Summary: | [nfs4] unexported mountpoint of automount is visible in nfsv4 pseudo-filesystem | ||
---|---|---|---|
Product: | File System | Reporter: | JianhongYin (yin-jianhong) |
Component: | NFS | Assignee: | Chuck Lever (cel) |
Status: | RESOLVED CODE_FIX | ||
Severity: | high | CC: | jlayton, raven, steved |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 6.1.0 | Subsystem: | |
Regression: | No | Bisected commit-id: | |
Attachments: | reproducer.sh |
Description
JianhongYin
2022-12-06 11:46:31 UTC
Created attachment 303368 [details]
reproducer.sh
(In reply to JianhongYin from comment #0) > Description of problem: > unexported mountpoint of automount is visible in nfsv4 pseudo-filesystem snip ... > ''' > ~]# ls -l /mnt/nfsmp > ls: cannot access '/mnt/nfsmp/efi': No such file or directory > ls: cannot access '/mnt/nfsmp/home2': No such file or directory > total 0 > ??????????? ? ? ? ? ? efi > drwxr-xr-x. 2 root root 6 Dec 6 05:45 expdir > ??????????? ? ? ? ? ? home2 > ''' > > Expected results: > ''' > ~]# ls -l /mnt/nfsmp > total 0 > drwxr-xr-x. 2 root root 6 Dec 6 05:45 expdir > ''' So your asking where did the (apparently invalid) directories efi and home2 come from? I'm not familiar with how that shadow directory tree of exports is constructed and maintained. I think it's tied in with nfs-utils. Perhaps Steve Dixon can help? Noting that these aren't automounter mounts, they are systemd-mounted local mounts. Sorry for the noise, Ian, I misread the bug description. I just checked on my v6.1-rc server, and actual automounted NFS mounts do not appear in that server's pseudofs. (In reply to Chuck Lever from comment #3) > Noting that these aren't automounter mounts, they are systemd-mounted local > mounts. Sorry for the noise, Ian, I misread the bug description. I just > checked on my v6.1-rc server, and actual automounted NFS mounts do not > appear in that server's pseudofs. LOL, yeah but it has a systemd automount unit there too. But directories like that are usually just stale dentries that haven't been correctly identified and listed by readdir aren't they ... The root cause seems to be that mountd is occasionally triggering automounts. We never want it to do that. Patch posted here: https://lore.kernel.org/linux-nfs/20221213160104.198237-1-jlayton@kernel.org/T/#u I think though that this may also demonstrate a problem in the kernel too: What we see on the wire is that the READDIR response includes the automounted directory, but it sets the rdattr_error attribute to NFS4ERR_DELAY. So, while that patch fixes the immediate issue with mountd, I think we need to consider how best to handle an -ETIMEDOUT response in this situation. Skipping the entry seems wrong. Wnat if it actually is a legit export and it's delayed for some other reason? Maybe we should fail the entire READDIR op with NFS4ERR_DELAY instead? Kernel patch posted here: https://lore.kernel.org/linux-nfs/20221213180826.216690-1-jlayton@kernel.org/T/#u Fix in v6.2. |