Re: [RFC] Null Namespaces
From: John Ericson <hidden>
Date: 2026-06-25 18:24:05
Also in:
linux-arch, linux-fsdevel, lkml
On Thu, Jun 25, 2026, at 11:51 AM, Andy Lutomirski wrote:
On Wed, Jun 24, 2026 at 8:41 PM John Ericson [off-list ref] wrote: It's sort of a combination -- read the data structures :) Other than the propagation part, they're really not that bad.
Are you saying path resolution *does* depend on the mount namespace that the task belongs to? I certainly hope not! I did look over the data structures along with my patches and I didn't see an example of this --- just path resolution depending on the CWD and root directories (as one would expect it to).
In any event, I think this discussion is sort of immaterial to the proposed API change. No one is about to remove the concept of a mount namespace. But maybe it makes sense to have a way to have a task that doesn't actually belong to a mount namespace. A mount namespace is certainly going to exist.
I am not sure if that is addressed more to Al or me? I certainly do agree with all that, in any case. Mount namespaces are absolutely here to stay, and I'm just trying to make a process that does not belong to one; that's exactly correct. Sorry if my motivation by way of historical analysis veered off topic.
There will definitely be subtleties. For example, what happens if a task with "no mount namespace" tries to do OPEN_TREE_CLONE? In some logical sense it ought to work but it ought to be impossible to actually mount the resulting tree anywhere, but this risks running afoul of all kinds of checks. Maybe you get a whole new mount namespace (that does not become your current mnt_ns) if you OPEN_TREE_CLONE? This stuff is complex and it probably makes more sense to keep changes simple.
Yes it is subtle; I definitely don't claim to fully understand the permission model with mount namespace modifications yet, for one. Should we switch gears to just discussing the null CWD and root directories, then, and return to mount namespaces later? I have started to rework my patch series accordingly, so I have a new draft first patch for just that, before changing anything else. I could (after some testing) submit that next; it's pretty small. John