Changes in failfs.c

cd051cfe1e35a471fc2cdf6d32fae6ee23305ecb - Merge tag 'vfs-7.3-rc1.failfs' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs

Mon, 17 Aug 2026 18:15:52 +0200

Merge tag 'vfs-7.3-rc1.failfs' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfsPull failfs filesystem from Christian Brauner: "Add failfs and expose a FD_FAILFS_ROOT sentinel. This allows userspace to shed their filesystem state completely. A process with its root or working directory in failfs must anchor every path lookup at an explicit file descriptor. Absolute paths, absolute symlinks and AT_FDCWD-relative lookups simply fail. Failfs is the counterpart to nullfs. nullfs says adds a permanently empty, immutable directory whose lookups fail with ENOENT but which can be opened, read, stat'd and mounted upon. Failfs on the other hand fails every operation. The root cannot be opened at all. A single instance is mounted during early boot via kern_mount(), which makes it logically distinct from every mount namespace. This is accompanied by a new fchroot() system call which makes chrooting via a file descriptor a first class concept. It's possible to chroot into failfs as an unprivileged user provided the task has no new privileges set"* tag 'vfs-7.3-rc1.failfs' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs: Documentation: add failfs documentation selftests/filesystems: add failfs selftests arch: hookup fchroot() system call fs: support FD_FAILFS_ROOT in fchroot() fs: add fchroot() fs: support FD_FAILFS_ROOT in fchdir() fs: add failfs List of files: /linux/fs/failfs.c

1d38e750a389e919c1608dbc61cd5c93cd4915dc - Merge patch series "fs: add failfs"

Mon, 27 Jul 2026 11:49:54 +0200

Merge patch series "fs: add failfs"Christian Brauner says:nullfs provides a permanently empty and immutable directory. Lookupsfail with ENOENT. The directory can be opened, read, stat, mounted upon.It behaves like nothing is there.Add its counterpart failfs where the semantics are not "there isnothing here" but "nothing is supported here". Every operation thatreaches the filesystem fails with EOPNOTSUPP. Even statfs()/fstatfs()fail so the filesystem cannot be discovered through an fd to it.EOPNOTSUPP rather than a permission errno keeps that coherent. Thereis no permission model in which anything could ever be allowed andEACCES or EPERM would merely suggest that different credentials mightsucceed while EIO would suggest corruption. It also makes hitting thefailfs boundary mostly quite dinstinguishable. A task anchoring itslookups at real directory file descriptors may be able to tell a failfsrefusal from an ordinary permission failure. I wouldn't go so far asguaranteeing that but it should mostly work.The root cannot be opened at all not even with O_PATH. It is neverreached by a lookup in a parent directory. The only way to a path-walkterminal at the root is a jump through a /proc//{root,cwd} magiclink or by mountpoint traversal. The root also refuses->d_weak_revalidate() which the VFS calls for jumped terminals. Thatcloses every remaining way to reference it. An O_PATHopen is refused and name_to_handle_at() cannot encode it into a filehandle, and following a magic link into it fails. A plain readlink() ofsuch a link still works and shows "failfs:/".There is a single instance of failfs mounted during early boot viakern_mount() making it logically distinct from every mount namespace.Since the mount is a member of no mount namespace mounting onto itfails. So nothing can ever be mounted on top of it. It cannot be clonedvia OPEN_TREE_CLONE and it does not show up in statmount()/listmount()or /proc//mountinfo. The filesystem is not registered so it isnot visible in /proc/filesystems and cannot be mounted from userspace.This lets tasks shed their filesystem state completely. A process withits root directory or working directory in failfs must anchor every pathlookup at an explicit file descriptor or is doomed to fail any lookup.Absolute paths, absolute symlinks, and AT_FDCWD-relative lookupssimply fail. Followup patches will expose it via a new FD_FAILFS_ROOTfile descriptor sentinel understood by fchdir() and the new fchroot()system call.Fun fact, because of how dynamic binary execution work with PT_INTERPthis also currently prevents execution of dynamic binaries becauseloaders have absolute paths (see selftests).* patches from https://patch.msgid.link/20260724-work-failfs-v2-0-485dabbae185@kernel.org: Documentation: add failfs documentation selftests/filesystems: add failfs selftests arch: hookup fchroot() system call fs: support FD_FAILFS_ROOT in fchroot() fs: add fchroot() fs: support FD_FAILFS_ROOT in fchdir() fs: add failfsLink: https://patch.msgid.link/20260724-work-failfs-v2-0-485dabbae185@kernel.orgSigned-off-by: Christian Brauner (Amutable) List of files: /linux/fs/failfs.c

cdf930a00949af72fbe9a22da2a8efa77981baa7 - fs: support FD_FAILFS_ROOT in fchdir()

Fri, 24 Jul 2026 15:41:18 +0200

fs: support FD_FAILFS_ROOT in fchdir()Add a new file descriptor sentinel FD_FAILFS_ROOT followingFD_PIDFS_ROOT and FD_NSFS_ROOT and teach fchdir() to accept it. Aprocess calling fchdir(FD_FAILFS_ROOT) moves its working directoryinto failfs. Every AT_FDCWD-relative lookup afterwards fails withEOPNOTSUPP including "." and ".." and getcwd() reports the workingdirectory as unreachable from the process root by returning a pathprefixed with "(unreachable)". Lookups relative to explicit directoryfile descriptors are unaffected.The sentinel is the only way in. No privilege or gating is required.Setting the working directory to a directory in which every operationfails grants nothing and loses nothing that closing file descriptorscouldn't lose. An unlinked working directory behaves the same way todaymodulo errno. The working directory also plays no role in confining ".."resolution so no boundary is weakened.Link: https://patch.msgid.link/20260724-work-failfs-v2-2-485dabbae185@kernel.orgSigned-off-by: Christian Brauner (Amutable) List of files: /linux/fs/failfs.c

fa0d6d945e5ce96cff14b114eec7527f13d7f23a - fs: add failfs

Fri, 24 Jul 2026 15:41:17 +0200

fs: add failfsnullfs provides a permanently empty and immutable directory. Lookupsfail with ENOENT. The directory can be opened, read, stat, mounted upon.It behaves like nothing is there.Add its counterpart failfs where the semantics are not "there isnothing here" but "nothing is supported here". Every operation thatreaches the filesystem fails with EOPNOTSUPP. Even statfs()/fstatfs()fail so the filesystem cannot be discovered through an fd to it.EOPNOTSUPP rather than a permission errno keeps that coherent. Thereis no permission model in which anything could ever be allowed andEACCES or EPERM would merely suggest that different credentials mightsucceed while EIO would suggest corruption. It also makes hitting thefailfs boundary mostly quite dinstinguishable. A task anchoring itslookups at real directory file descriptors may be able to tell a failfsrefusal from an ordinary permission failure. I wouldn't go so far asguaranteeing that but it should mostly work.No path lookup can open the root, not even with O_PATH. It is neverreached by a lookup in a parent directory. The only way to a path-walkterminal at the root is a jump through a /proc//{root,cwd} magiclink or by mountpoint traversal. The root also refuses->d_weak_revalidate() which the VFS calls for jumped terminals. Thatcovers the jump-based references too: an O_PATH open is refused,name_to_handle_at() cannot encode it into a file handle, and following amagic link into it fails. A plain readlink() of such a link still worksand shows "failfs:/".There is a single instance of failfs mounted during early boot viakern_mount() making it logically distinct from every mount namespace.Since the mount is a member of no mount namespace mounting onto itfails. So nothing can ever be mounted on top of it. It cannot be clonedvia OPEN_TREE_CLONE and it does not show up in statmount()/listmount()or /proc//mountinfo. The filesystem is not registered so it isnot visible in /proc/filesystems and cannot be mounted from userspace.This lets tasks shed their filesystem state completely. A process withits root directory or working directory in failfs must anchor every pathlookup at an explicit file descriptor or is doomed to fail any lookup.Absolute paths, absolute symlinks, and AT_FDCWD-relative lookupssimply fail. Followup patches will expose it via a new FD_FAILFS_ROOTfile descriptor sentinel understood by fchdir() and the new fchroot()system call.Link: https://patch.msgid.link/20260724-work-failfs-v2-1-485dabbae185@kernel.orgSigned-off-by: Christian Brauner (Amutable) List of files: /linux/fs/failfs.c