Problem in current -stable kernels caused by 1064f874abc0

Problem in current -stable kernels caused by 1064f874abc0

[Phil Oester]

Commit 1064f874abc0 ("mnt: Tuck mounts under others instead of
creating shadow/side mounts") was backported to various stable
kernels (4.4, 4.9, and 4.10 at least).  Unfortunately that patch
causes autofs mounts to fail with this error:

ls: cannot open directory '<automounted dir>': Too many levels of symbolic links

AFAICT, this was first reported here: https://lkml.org/lkml/2017/6/16/227.  

It seems these 8 additional upstream commits are required to prevent
such failure:

fb5f51c7425e: vfs: change d_manage() to take a struct path
c6609c0a1c34: vfs: add path_is_mountpoint() helper
01619491a5f0: vfs: add path_has_submounts()
74f504cff50b: autofs: change autofs4_expire_wait()/do_expire_wait() to take struct path
dd36a882e7ad: autofs: change autofs4_wait() to take struct path
cfaf86ab6ccd: autofs: use path_is_mountpoint() to fix unreliable d_mountpoint() checks
603597414734: autofs: use path_has_submounts() to fix unreliable have_submount() checks
f74e7b33c37e: vfs: remove unused have_submounts() function

These apply cleanly on top of 4.9.53, and solve the problem for me.

Interestingly, this was not a problem for us in CentOS 7.3, but only
became a problem in CentOS 7.4 when the chrony systemd service was changed
to use "ProtectHome=yes" in the service file.  We then started seeing
the symbolic link error on our autofs mounted /home.  If we start
chronyd after autofs, it works fine.  If we start chronyd before autofs
we get the error.  Similar for any other systemd service with that
systemd option enabled.  The relationship between that option and
these commits is baffling.

Can these please be backported to relevant -stable kernels?

Thanks,
Phil Oester