I'll throw in the towel after this email, I promise :)

On Tue, Jun 30, 2026, at 3:14 AM, Christian Brauner wrote:

quoted

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 ;).)

quoted

I agree with the sentiment

Thanks, I appreciate it :).

quoted

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.

quoted

I disagree with the details of this

You mean the unergonomics of making a valid `optional_path`, right?

quoted

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.