summaryrefslogtreecommitdiffstats
path: root/net/switchdev
diff options
context:
space:
mode:
authorBenjamin Coddington <bcodding@redhat.com>2018-10-03 10:18:33 -0400
committerEric W. Biederman <ebiederm@xmission.com>2018-11-12 01:02:34 -0600
commit1e9c75fb9c47a75a9aec0cd17db5f6dc36b58e00 (patch)
tree2a733b754464fc47febe6fe332b9cdf75427b0fc /net/switchdev
parent9c8e0a1b683525464a2abe9fb4b54404a50ed2b4 (diff)
downloadlinux-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