Re: [RFC] separate the internal mount flags from the rest

["Eric W. Biederman" <ebiederm@xmission.com>]

Al Viro <viro@zeniv.linux.org.uk> writes:

> 	Currently we use ->mnt_flags for all kinds of things, including
> the ones only fs/{namespace,pnode}.c care about.
>
> 	That wouldn't be a problem if not for the locking.  ->mnt_flags is
> protected by mount_lock.  All writers MUST grab that.  Having lockless
> readers is unsurprising - after all, for something like noexec we want
> the current state of mount, whatever it happens to be.  If userland
> remounts something noexec and that races with execve(2), there's nothing
> to be done - it is a race, but not the kernel one.


In general I don't have a problem.

I see one possible complication I haven't seen mentioned.
Which mnt_flags get exposed to userspace?

I know it was the expectation that MNT_LOCKED would be visible to
userspace, as it's effects are visible to userspace (it isn't just some
accounting thing).

I may just be objecting to the name of the macro MNT_INTERNAL_FLAGS,
and the making of the decision about flags based on the
internal/external state.

Your patch to change make MNT_LOCKED an internal flag in combination
with this proposed change make me wonder about our classification
of flags as internal/external and how much that matters.

Eric