Christian Brauner <[email protected]> wrote:
> Besides that - and probably irrelevant from the perspective of a
> cachefiles developer - it also makes things simpler for a variety of
> other vfs features. One concrete example is fanotify.
What about cachefilesd? That walks over the tree regularly, stats things and
maybe deletes things. Should that be in a private mount/namespace too?
> This seems a rather desirable property as the underlying path can't e.g.
> suddenly go from read-write to read-only and in general it means that
> cachefiles is always in full control of the underlying mount after the
> user has allowed it to be used as a cache.
That's not entirely true, but I guess that emergency R/O conversion isn't a
case that's worrisome - and, in any case, only affects the superblock.
> ret = -EINVAL;
> - if (mnt_user_ns(path.mnt) != &init_user_ns) {
> + if (mnt_user_ns(cache->mnt) != &init_user_ns) {
> pr_warn("File cache on idmapped mounts not supported");
> goto error_unsupported;
> }
Is it worth doing this check before calling clone_private_mount()?
> + cache_path = path;
> + cache_path.mnt = cache->mnt;
Seems pointless to copy all of path into cache_path rather than just
path.dentry.
Apart from that, looks okay.
David
--
Linux-cachefs mailing list
[email protected]
https://listman.redhat.com/mailman/listinfo/linux-cachefs
