Kernel: btrfs, BPF, pidfds

posted by Roy Schestowitz on Mar 22, 2024

• Barry Kauler ☛ btrfs-progs with fscrypt take-2

  I posted yesterday about compiling Josef Bacik's fscrypt branch of 'btrfs-progs':

  https://bkhome.org/news/202403/btrfs-progs-with-fscrypt-patches.html

  There were some things that I didn't understand, and sent an inquiry email to Josef. Here is part of my email: [...]

• Barry Kauler ☛ btrfs-progs with fscrypt patches

  Recent posts about btrfs:

  https://bkhome.org/news/202403/kernel-681-with-btrfs-fscrypt.html

  https://bkhome.org/news/202403/improved-support-for-btrfs.html

  However, to support fscrypt, patches need to ba applied to 'btrfs-progs'. One of the main developers of btrfs is Josef Bacik, and he is the primary implementer of fscrypt support in btrfs. He has fscrypt patches for btrfs-progs: [...]

• LWN ☛ Better linked-list traversal in BPF

  Before loading a BPF program, the kernel must verify that the program is safe to run; among other things, that verification includes ensuring that the program will terminate within a bounded time. That requirement has long made writing loops in BPF a challenging task. The situation has improved over the years for some types of loops, but others — including linked-list traversal — are still awkward in BPF programs. A new set of BPF primitives aims to make life easier for this use case through the installation of what can be seen as a sort of circuit breaker.

• LWN ☛ A new filesystem for pidfds

  The pidfd abstraction is a Linux-specific way of referring to processes that avoids the race conditions inherent in Unix process ID numbers. Since a pidfd is a file descriptor, it needs a filesystem to implement the usual operations performed on files. As the use of pidfds has grown, they have stressed the limits of the simple filesystem that was created for them. Christian Brauner has created a new filesystem for pidfds that seems likely to debut in the 6.9 kernel, but it ran into a little bump along the way, demonstrating that things you cannot see can still hurt you.

  In this case, the pidfd filesystem is indeed invisible; it cannot be mounted and accessed like most other filesystems. A pidfd is created with a system call like pidfd_open() or clone3(), so there is no need for a visible filesystem. (One could imagine such a filesystem as a way of showing all of the existing processes in the system, but /proc already exists for that purpose). Since there was no need to implement many of the usual filesystem operations, pidfds were implemented using anon_inode_getfile(), a helper that creates file descriptors for simple, virtual filesystems. Over time, though, this filesystem has proved to be a bit too simple, leading to Brauner's pidfdfs proposal as a replacement.