Message-ID: <20250725-vfs-617-1bcbd4ae2ea6@brauner>
Date: Fri, 25 Jul 2025 13:27:13 +0200
From: Christian Brauner <brauner@...nel.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Christian Brauner <brauner@...nel.org>,
	linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: [GIT PULL 00/14 for v6.17] vfs 6.17

Hey Linus,

This is the batch of pull requests for the v6.17 merge window!

I'm trying something new where I'm attaching a cover letter with a short
summary of all the various pull requests flowing to you during this
cycle.

Lucky for me the v6.17 merge window coincides with me moving. IOW, I'm
currently getting squashed by moving boxes and disassembled furniture.
I'm just happy that I did find my laptop in this mess and I hope there's
no notable effects due to the last couple of weeks.

In any case, this cycle was pretty usual for us given the past years.
We have two new system call additions in core vfs file_getattr() and
file_setattr() which are exensible successors to the legacy ioctl()s.

There's further work in the form of preparatory changes to the directory
locking scheme we currently have; both on the vfs level and for
overlayfs specificall. I want to stress that no actual locking changes
have happened yet and that there's not yet any commitment by us to
actually land any of this.

We have a new bpf kfunc extension for reading extended attributes from
cgroups. This is the first time we're routing bpf patches but I will do
this for all future vfs bpf extensions so we know exactly how and when
something is happening.

There's another round of extensive coredump work. Not just an extension
to the coredump socket but also a rework of the coredump code to just be
more readable and maintainable. I'm somewhat afraid of what I've gotten
myself into by touching that code but hey, that's part of the deal.

We have some work at the intersection of the block and vfs layer in the
form of the new FS_IOC_GETLBMD_CAP ioctl() which returns information
about the files integrity profile for userspace applications that need
to understand a files end-to-end data protection support and configure
the I/O accordingly.

Iomap has been quite active as well with some refactoring and changes to
the infrastucture to extend the abilities of fuse and support large
folios. Hell, if this keeps going on every filesystem will move to fuse
and we'll all be out of a job soon.

There's the usual pile of miscellaneous changes to the vfs layer and
filesystems. No need to cover this in detail here.

We also have some work at the intersection of mm and the vfs by porting
a good chunk of filesystems from f_op->mmap() to the new and better
f_op->mmap_prepare(). I'm going to haunt the relevant developers to
finish this conversion asap because I have no appetite of running around
with yet more duplicated methods than we already have. I mean, we've
just gotten rid of f_op->readdir() last year or so - actually you did.

I'm also routing the usual namespace work. This time in the form of some
minor nsfs extensions by exposing a bunch of uapi symbols that a lot of
userspace already relies on and so we can't change those constants
anyway. That's the root inode number of procfs and the inode numbers of
the initial set of namespaces.

We've also been very active in pidfs which gains a bunch of new features
such as persisent exit and coredump information, extended attributes,
autonomous file handles, and pidfd for reaped task from SCM_PDIFD
messages.

A few minor Rust updates are also in there but they're really not that
interesting at all.

And at last a new struct super_operations method that allows
multi-device filesystems such as btrfs to be informed when a block
device is removed. Since btrfs can survive surprise device removal this
complements the usual ->shutdown() call nicely.

That's all! Expect some slight delay in responses as I'm going to be
preoccupied with the move over the weekend.

Thanks!
Christian

Powered by blists - more mailing lists