[RFC PATCH 0/8] namespace-aware configfs

Christian Brauner brauner at kernel.org
Wed Jun 17 04:58:36 PDT 2026


> Open Issues:
> - I've added a new function 'mnt_clone_direct()' to clone the vfsmount
>   entry (the original code just did a simple_pin_fs()). Not sure if
>   that's correct. Christian?

I think we can put that issue aside for a second as there are a few
bigger design questions.

> - The current cloning mechanism is not really a hierarchy, but rather
>   always using the default namespace to find registered subsystems.
>   Meaning you can only call 'register_subsystem()' for the default
>   namespace. But then one shouldn't call modprobe in a container, so
>   that's okay I guess.

I'm not sure I follow what this is trying to say, sorry.

> - The original content of the configfs remains visible even from
>   within the container, and the new 'mount' will just overlay that.

I again fail to understand what precisely this means.

>   Ideally I would have the container start off with an empty
>   /sys/kernel/config to avoid configuration issues. But again I've
>   no idea how to do that (or if it's even possible).

Shouldn't be a problem to implement this. Just means more work.

So the rough concept in my head would be that configfs is a
multi-instance filesystem that remembers the namespaces it was mounted
similar to how kernfs allows to be tagged with namespaces. It then only
shows/allows registration of subsystems that match the relevant
namespace tags.

The challenge I see is that configfs shows subsystems that may be tied
to different namespaces.



More information about the Linux-nvme mailing list