[RFC] MNT_LOCKED vs. finish_automount()

[Al Viro <viro@zeniv.linux.org.uk>]

	Back in 2011, when ->d_automount() had been introduced,
we went with "stepping on NFS referral, etc., has the submount
inherit the flags of parent one" (with the obvious exceptions
for internal-only flags).  Back then MNT_LOCKED didn't exist.

	Two years later, when MNT_LOCKED had been added, an explicit
"don't set MNT_LOCKED on expirable mounts when propagating across
the userns boundary; their underlying mountpoints can be exposed
whenever the original expires anyway".  Same went for root of
subtree attached by explicit mount --[r]bind - the mountpoint
had been exposed before the call, after all and for roots of
any propagation copies created by such (same reason).  Normal mount
(created by do_new_mount()) could never get MNT_LOCKED to start with.

	However, mounts created by finish_automount() bloody well
could - if the parent mount had MNT_LOCKED on it, submounts would
inherited it.  Even if they had been expirable.  Moreover, all their
propagation copies would have MNT_LOCKED stripped out.

	IMO this inconsistency is a bug; MNT_LOCKED should not
be inherited in finish_automount().

	Eric, is there something subtle I'm missing here?