diff options
author | Benjamin Coddington <bcodding@redhat.com> | 2018-10-03 10:18:33 -0400 |
---|---|---|
committer | Eric W. Biederman <ebiederm@xmission.com> | 2018-11-12 01:02:34 -0600 |
commit | 1e9c75fb9c47a75a9aec0cd17db5f6dc36b58e00 (patch) | |
tree | 2a733b754464fc47febe6fe332b9cdf75427b0fc /net/switchdev | |
parent | 9c8e0a1b683525464a2abe9fb4b54404a50ed2b4 (diff) | |
download | linux-1e9c75fb9c47a75a9aec0cd17db5f6dc36b58e00.tar.gz linux-1e9c75fb9c47a75a9aec0cd17db5f6dc36b58e00.tar.bz2 linux-1e9c75fb9c47a75a9aec0cd17db5f6dc36b58e00.zip |
mnt: fix __detach_mounts infinite loop
Since commit ff17fa561a04 ("d_invalidate(): unhash immediately")
immediately unhashes the dentry, we'll never return the mountpoint in
lookup_mountpoint(), which can lead to an unbreakable loop in
d_invalidate().
I have reports of NFS clients getting into this condition after the server
removes an export of an existing mount created through follow_automount(),
but I suspect there are various other ways to produce this problem if we
hunt down users of d_invalidate(). For example, it is possible to get into
this state by using XFS' d_invalidate() call in xfs_vn_unlink():
truncate -s 100m img{1,2}
mkfs.xfs -q -n version=ci img1
mkfs.xfs -q -n version=ci img2
mkdir -p /mnt/xfs
mount img1 /mnt/xfs
mkdir /mnt/xfs/sub1
mount img2 /mnt/xfs/sub1
cat > /mnt/xfs/sub1/foo &
umount -l /mnt/xfs/sub1
mount img2 /mnt/xfs/sub1
mount --make-private /mnt/xfs
mkdir /mnt/xfs/sub2
mount --move /mnt/xfs/sub1 /mnt/xfs/sub2
rmdir /mnt/xfs/sub1
Fix this by moving the check for an unlinked dentry out of the
detach_mounts() path.
Fixes: ff17fa561a04 ("d_invalidate(): unhash immediately")
Cc: stable@vger.kernel.org
Reviewed-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Benjamin Coddington <bcodding@redhat.com>
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Diffstat (limited to 'net/switchdev')
0 files changed, 0 insertions, 0 deletions