Re: [RFC] Null Namespaces

[H. Peter Anvin]

On June 30, 2026 10:20:05 AM PDT, John Ericson <mail@xxxxxxxxxxxxxx> wrote:
>I'll throw in the towel after this email, I promise :)
>
>On Tue, Jun 30, 2026, at 3:14 AM, Christian Brauner wrote:
>> I think Al is about to have a stroke reading this... and I might too.
>
>Hahaha. Alas, C does have a longstanding beef with discriminated unions
>--- I can't do anything about that! (Well, other than wait 15 years for
>this stuff to eventually be rewritten in Rust, that is ;).)
>
>> I agree with the sentiment
>
>Thanks, I appreciate it :).
>
>> You know what the easy solution is: don't allow a struct path to be
>> empty...
>
>Just so we're clear, my quibble here is purely behavioral: the nullfs
>directory can be opened, right? And that open directory can also be
>getdents64ed (yielding no entries, since it is empty), right? If I am
>wrong about these things then sure, no objections from me --- let's ship
>nullfs FDs right away!
>
>My reasoning for being a bit of a weenie on that behavior is just that I
>think "fail fast" is good. A lot of userspace programs crawl the file
>space pretty willy-nilly (e.g. they are doing some caching thing, or
>they are looking for something, etc.). I suspect the nullfs approach is
>going to result in more "red herring" error messages and google searches
>about "why can't I write to the working directory, not even as root"
>etc. I just think "no directory" vs "immutable empty directory" sends a
>clearer message to userspace, and will align mental models more rapidly.
>
>Put another way, if there were no implementation downsides to either
>approach, I assume everyone else would also slightly prefer "no
>directory" over "immutable empty directory".
>
>From that premise, I am further presuming that any non-empty `struct
>path` to a directory that doesn't exist would be a real VFS crime, and
>so making `optional_path` one way or another is the proper way to
>implement this behavior.
>
>If I am wrong about either step of my reasoning --- that nullfs like
>every sort of FS ought to be openable/readdirable with sufficient perms
>at the root, that a valid `struct path` to a "non-object" is bad design
>--- do say so, and I'll drop the `optional_path` stuff completely.
>
>> I disagree with the details of this
>
>You mean the unergonomics of making a valid `optional_path`, right?
>
>> and touching the whole kernel for this.
>
>I want to make sure this is a difference in opinion and not a difference
>in the view of the facts.
>
>The linchpin of my prior email was that very little of the kernel cares
>about these fields in `struct fs_struct`, or even cares about `struct
>fs_struct` at all, so this is *not* a "whole kernel" change. Yes, thanks
>to `current`, a bunch of code *could* look at this stuff if it wants to.
>But it should *not* want to, regardless of what we do.
>
>If there were a way to make parts of `struct task_struct` opaque
>(without including another header) to enforce this design principle, I
>would definitely go contribute that. (I remember the desire for
>something like this coming up with the "fast headers" patches, but there
>wasn't a good implementation strategy in C, alas.)
>
>Likewise, for the tiny few usages outside of `fs/namei.c` that I found,
>I would be happy to more creatively look at that code to see if I can
>indeed avoid `struct fs_struct` altogether.
>
>Cheers,
>
>John
>
>P.S. The "regardless of what we do" part was key to my earlier code
>review argument that gave you "mixture of amusement and slight anger":
>of course I don't expect other maintainers to keep abreast of subtle
>null pointer invariants, but the simple rule that nothing but
>`fs/namei.c` really ought to be consuming these `struct fs_struct`
>fields is, I believe, all three of: good, already true, and intuitive.

15 years? 

Don't make me laugh...