Problem in current -stable kernels caused by 1064f874abc0

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