Linux 7.3 Looks Like It Will Upstream FailFS

NULLFS is providing a permanently empty and immutable directory where lookups fail with ENOENT as the error code for no such file/directory. With the forthcoming FailFS, every operation reaching the filesystem returns EOPNOTSUPP, the Linux error code for operation not supported.
Christian Brauner explained in the merge queuing up FailFS Into the VFS.git's "vfs-7.3.failfs" Git branch:
"There is a single instance of failfs mounted during early boot via kern_mount() making it logically distinct from every mount namespace.
Since the mount is a member of no mount namespace mounting onto it fails. So nothing can ever be mounted on top of it. It cannot be cloned via OPEN_TREE_CLONE and it does not show up in statmount()/listmount() or /proc//mountinfo. The filesystem is not registered so it is not visible in /proc/filesystems and cannot be mounted from userspace.
This lets tasks shed their filesystem state completely. A process with its root directory or working directory in failfs must anchor every path lookup at an explicit file descriptor or is doomed to fail any lookup. Absolute paths, absolute symlinks, and AT_FDCWD-relative lookups simply fail. Followup patches will expose it via a new FD_FAILFS_ROOT file descriptor sentinel understood by fchdir() and the new fchroot() system call.
Fun fact, because of how dynamic binary execution work with PT_INTERP this also currently prevents execution of dynamic binaries because loaders have absolute paths (see selftests)."
FailFS cannot be cloned, cannot be mounted from user-space, and nothing can be mounted on top of it. The FailFS driver comes in at under two hundred lines of code for the actual driver portion.
With Brauner having queued FailFS into a VFS.git branch and it even being marked for "7.3", expect FailFS to be submitted for the Linux 7.3 merge window later this month -- permitting no objections from Linus Torvalds or other prominent kernel developers.
20 Comments
