> > R/O bind mounts patches have been reviewed numerous times. Still a
> > relatively large number of places remained where checking for R/O
> > mounts was missed.
>
> In all the other... erm... interesting discussion, I missed this point.
>
> Were there some bits outside of the nfsd code where I missed the r/o
> mount checks?
Yes, the removexattr syscalls. Al fixed those in the final
submission.
And the whole of ecryptfs was missed as a source of filesystem
modification. How that's supposed to get fixed, along with nfsd is
arguable.
But regardless of all that, I think the path_* interface is a good
one, even if it has just a couple of users that actually _require_ the
r/o bracketing. It's good because:
- it's consistent
- it provides some (not all) guarantees, i.e. it's easier to prove
that all callers play by the rules
- for the syscall case it has zero cost
- for all the other cases it has either zero, or minimal cost
Yes, it does require the caller to have a vfsmount available, but it's
hard to imagine that the caller does not have it:
- most userspace calls do have it, as they are either operating on a
path or a file descriptor. There are some exceptions like sync(2)
and ustat(2), the latter not being a very exemplary interface, and
neither of them being relevant to this discussion.
- all kernel callers (nfs export, stacking) should have it, as they
need it for open() anyway
And even if some theoretical caller didn't have the vfsmount, it still
should be easy to allocate one, providing a clean way to do the r/o
bracketing, and not requiring another mechanism to be exported that
provides the same functionality on the superblock.
Sorry for the claptrap. I'm going to resubmit this one more time
with some slight modifications and additions, and it'd be really nice
if you or other interested parties would provide comments and opinions
(either way), because I don't think me and Al have anything new to say
to each other.
Thanks,
Miklos
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
