Message-ID: <20250926-vfs-618-e880cf3b910f@brauner>
Date: Fri, 26 Sep 2025 16:18:54 +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/12 for v6.18] vfs 6.18

Hey Linus,

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

This was a pretty usual cycle. Not light, not particularly heavy.

There are a few minor filesystem specific changes such as afs and pidfs
but nothing that's really worth mentioning. Same goes for iomap and
rust. There are some changes around clone3() and copy_process() that
lead to some cleanups.

There's some workqueue chagnes that affect all of fs but it's not all
that exciting and we don't have to care once all the cleanup is done and
the semantics for per-cpu and unbounded workqueues are simplified and
clarified.

There's a pretty interesting writeback series by Jan Kara that fixes a
nasty issue causing lockups reported by users when a systemd unit
reading lots of files from a filesystem mounted with the lazytime mount
option exits.

With the lazytime mount option enabled we can be switching many dirty
inodes on cgroup exit to the parent cgroup. The numbers observed in
practice when a systemd slice of a large cron job exits can easily reach
hundreds of thousands or millions.

The overall time complexity of switching all the inodes to the correct
wb is quadratic leading to workers being pegged for hours consuming 100%
of the CPU and switching inodes to the parent wb.

That issue should be gone.

We also have a series that shrinks struct inode by 16 bytes. This is
really something I care about because struct inode in contrast to struct
file and struct dentry both of which are meticulously clean by now (I
mean, it could alwasy be better, but you know...) struct inode is still
a giant dumping ground where everyone is made to pay for features that
only 3 filesystems actually end up using. First step, I've moved fscrpt
and fsverity pointers out of struct inode and into the individual
filesystems that care about this. Hopefully more to come in that area.

There's also some preliminary cleanup related to the inode lifetime
rework that is currently under way leading to less open-coded accesses
to internal inode members and some simplifications for iput_final().

Last but not least there's a bunch of namespace related rework this cycle.
This specifically also addresses a complaint you had a few weeks back
about ns_alloc_inum(). That's now completely gone and so is the
special-casing of the init network namespace initialization.

Initialization, reference counting, and cleanup are now unified and
statically derived from the namespace type allowing the compiler to
catch obvious bugs.

The namespace iterator infrastructure I did for the mount namespace some
time back is now extended and generalized to cover all other namespace
types. As a first step this allows the implemenation of namespace file
handles.

As with pidfs file handles, namespace file handles are exhaustive,
meaning it is not required to actually hold a reference to nsfs to be
able to decode aka open_by_handle_at() a namespace file handle. It has
the same advantage as pidfs file handles have. It's possible to reliably
and for the lifetime of the system refer to a namespace without pinning
any resources and to compare them trivially.

The namespace file handle layout is exposed as uapi and has a stable and
extensible format. The stable format means that userspace may construct
its own namespace file handles without going through name_to_handle_at().

Thanks!
Christian

Powered by blists - more mailing lists