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?
