Bug 216777 - [nfs4] unexported mountpoint of automount is visible in nfsv4 pseudo-filesystem
Summary: [nfs4] unexported mountpoint of automount is visible in nfsv4 pseudo-filesystem
Status: ASSIGNED
Alias: None
Product: File System
Classification: Unclassified
Component: NFS (show other bugs)
Hardware: All Linux
: P1 high
Assignee: Chuck Lever
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-12-06 11:46 UTC by JianhongYin
Modified: 2022-12-13 18:11 UTC (History)
3 users (show)

See Also:
Kernel Version: 6.1.0
Tree: Mainline
Regression: No


Attachments
reproducer.sh (748 bytes, text/plain)
2022-12-06 13:03 UTC, JianhongYin
Details

Description JianhongYin 2022-12-06 11:46:31 UTC
Description of problem:
  unexported mountpoint of automount is visible in nfsv4 pseudo-filesystem

How reproducible:
  always

Steps to Reproduce:
  1. echo "/expdir *(rw,no_root_squash)" >/etc/exports
     systemctl restart nfs-server
  2. create a systemd automount target and start
  3. mount localhost:/  /mnt/nfsmp
  4. ls -l /mnt/nfsmp

Actual results:
'''
~]# 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
'''



Reproducer:
'''
yum install -y nfs-utils
mkdir /home2 /expdir /mnt/nfsmp
cat <<EOF >/etc/systemd/system/home2.automount
[Unit]
Description=EFI System Partition Automount
Documentation=TBD
[Automount]
Where=/home2
TimeoutIdleSec=120
EOF
cat <<EOF >/etc/systemd/system/home2.mount
[Unit]
Description=EFI System Partition Automount
Documentation=TBD

[Mount]
What=/home
Where=/home2
Type=$(stat -f -c %T /home)
Options=ro,bind
EOF
systemctl start home2.automount

echo "expdir *(rw,no_root_squash)" >/etc/exports
systemctl enable nfs-server
systemctl start nfs-server
showmount -e localhost
mount localhost:/  /mnt/nfsmp
ls -l /mnt/nfsmp

umount /mnt/nfsmp
systemctl stop home2.automount
systemctl start home2.automount
'''
Comment 1 JianhongYin 2022-12-06 13:03:49 UTC
Created attachment 303368 [details]
reproducer.sh
Comment 2 Ian Kent 2022-12-06 23:55:03 UTC
(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?
Comment 3 Chuck Lever 2022-12-07 15:42:30 UTC
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.
Comment 4 Ian Kent 2022-12-07 23:35:49 UTC
(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 ...
Comment 5 Jeff Layton 2022-12-13 17:02:58 UTC
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?
Comment 6 Jeff Layton 2022-12-13 18:11:29 UTC
Kernel patch posted here:

https://lore.kernel.org/linux-nfs/20221213180826.216690-1-jlayton@kernel.org/T/#u

Note You need to log in before you can comment on or make changes to this bug.