Al Viro <viro@xxxxxxxxxxxxxxxxxx> 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
