6.17 Merge window, part 1 [LWN.net]

By Jonathan Corbet
July 31, 2025

As of this writing, just over 4,000 non-merge changesets have been pulled into the mainline repository during the 6.17 merge window. When he announced the merge-window opening, Linus Torvalds let it be known that, due to a busy personal schedule, he was likely to pull changes more quickly than usual this time around; that has been borne out to some extent. Changes merged so far are focused on core-kernel and filesystem work; read on for the details.

The most significant changes merged so far include:

Architecture-specific

The nolibc library is now supported on the SuperH, x32, and MIPS n32 and n34 architectures.
The rest of the x86 attack-vector controls work has been merged for the x86 architecture; it gives better control over which mitigations for hardware vulnerabilities should be enabled in the kernel. See Documentation/admin-guide/hw-vuln/attack_vector_controls.rst for more information.
Arm systems can now make use of the Arm v9.2 branch record buffer extension in the perf events subsystem.
Live patching is now supported on 64-bit Arm systems.
System-call tracepoints are now supported in User-mode Linux kernels.

Core kernel

The core-dump socket functionality added in 6.16 has been enhanced with a protocol that allows the core-dump server to control how dumps are handled for each task. This commit describes how the protocol works and the options that are available. There is also an experimental server implementation available that exercises this interface.
There have been a number of changes to the pidfd functionality. The associated kernel-internal information created with a pidfd is now tied to the process itself rather than the pidfd, allowing it to continue to exist between opens of same process. It is now possible for user space to attach extended attributes to a pidfd; those, too, will exist for the life of the process. File handles for pidfds can now be opened (using open_by_handle_at()) without needing a file descriptor for the containing filesystem. This merge message has more information about these changes.
The new bpf_cgroup_read_xattr() kfunc allows BPF programs to read extended attributes from the control-group filesystem.
The kernel's timekeeping system has grown the notion of "auxiliary clocks" that are not tied in any way to the normal system clocks. Until now, all clocks advanced at the same rate and differed only in their offsets; auxiliary clocks march to their own drummer. Documentation is scarce, but there is some information in this merge message.
Support for uniprocessor configurations has been removed from the scheduler; even single-processor machines will run a kernel built for SMP systems.
Initial support for proxy execution, which is meant to mitigate priority-inversion problems, has been merged. Proxy execution allows a task waiting for a lock to donate its execution context to the lock holder, speeding the release of that lock; in 6.17, it only works if both tasks are running on the same CPU.

Filesystems and block I/O

Btrfs has gained large-folio support, though it is still deemed experimental for this release.
Defragmentation of Btrfs filesystems now offers more control over the use of compression in the defragmented extents.
The EROFS filesystem now supports metadata compression.
The NFS server can offer write delegations to clients that open files in write-only mode. From the merge message: "We're expecting this to accelerate a few interesting corner cases".
The ext4 filesystem has gained support for buffered I/O with the RWF_DONTCACHE (originally proposed as RWF_UNCACHED) flag, which will cause the data to be dropped from the page cache once the operation is complete.
The inode number for the root of the /proc filesystem is now an acknowledged part of the kernel ABI; it is called PROCFS_ROOT_INO. User-space can check this number to ensure that /proc files have not been replaced, using a bind mount, by an attacker; see this merge message for more information.
The fallocate() system call has a new option, FALLOC_FL_WRITE_ZEROES, that causes the allocated range to be initialized to zeroes in the most efficient way possible. With recent solid-state devices, this initialization can be done efficiently within the device, with no I/O required. See this changelog for a bit more information; the ext4 filesystem now supports this operation.
Two new system calls, file_getattr() and file_setattr(), support the manipulation of a file's inode attributes. See this commit for an overview and basic manual page. Documentation of the actual operations supported is scarce, but this XFS manual page gives a good overview.
The "pktcdvd" packet-writing optical-media driver has been marked as deprecated since 2016. There was an attempt to remove it in 2023 that was reverted. In 6.17 it has been removed again, and will likely stay out this time.
Thus far, the bcachefs pull request has not been acted upon.

Hardware support

Clock: Raspberry Pi RP1-based clocks.
GPIO and pin control: Apple Mac SMC GPIO controllers and Raspberry Pi RP1 pin controllers.
Industrial I/O: Analog Devices AD4080 high speed analog-to-digital converters, Analog Device AD7405 and AD4170-4 analog-to-digital converters, ChromeOS EC activity sensors, and Nicera D3-323-AA passive infrared sensors.
Miscellaneous: HiSilicon uncore frequency-scaling controllers, Analog Devices ADP558x keypads, Apple silicon system management controllers, Apple SMC reset/power-off controllers, Raspberry Pi 7-inch touchscreen panel V2 regulators, Argon40 Fan HAT controllers, Lenovo GameZone WMI interfaces, Intel Platform Monitoring Technology interfaces, Qualcomm Milos interconnects, Renesas RZ/T2H serial interfaces, Canaan Kendryte K230 SoC reset controllers, NXP IMX Secure AHB to IP Slave bus (AIPSTZ) bridges, Allwinner A523 PCK-600 power domain controllers, Loongson-2K SD/SDIO/eMMC host interfaces, and AMD heterogeneous core hardware feedback interfaces.
Sound: Richtek RTQ9124 mono class-D amplifiers.
SPI: Amlogic SPISG controllers and Renesas RZ/V2H RSPI controllers.

Security-related

The new FS_IOC_GETLBMD_CAP ioctl() command allows user space to retrieve information about the integrity protections that apply to a given file. In 6.17 it is only supported by block devices, but the plan is to support it within filesystems as well. See this commit for an overview of this new API.
The kernel can now use the stack-depth tracking provided by Clang 21 to implement kernel-stack erasing, along the lines of what STACKLEAK provides with GCC.
The deprecation of the /sys/fs/selinux/user API continues; attempts to access it will now result in a five-second delay along with a logged warning.

Internal kernel changes

The longstanding mmap() method in the file_operations structure is slowly being deprecated in favor of mmap_prepare(), which offers fewer opportunities for bugs and security problems. In 6.17, a number of filesystems are moving over to this new interface; see this merge message for a description of this work and its motivation.
The kernel's CRC code has been heavily reworked; see this merge message for some more information. There are also new APIs for SHA-1 and SHA-2 generation.
New Rust abstractions have been added for the regulator subsystem, firmware properties, I/O resources, and I/O memory.

The 6.17 merge window can be expected to close on August 10, but Torvalds has made it clear that he wants to see all significant pull requests well ahead of that date. Given that, as of this writing, there are still over 7,500 commits sitting in linux-next, it is evident that quite a few of those requests are yet to be acted on. As always, LWN will provide a summary of the remaining changes once the merge window closes.

Index entries for this article
Kernel	Releases/6.17

to post comments

bcachefs

Posted Aug 1, 2025 3:29 UTC (Fri) by jmalcolm (subscriber, #8876) [Link] (9 responses)

> Thus far, the bcachefs pull request has not been acted upon.

As a bcachefs user, I obviously do not like the sound of that.

That said, am I correct that bcachefs has not been removed? Perhaps there is still hope.

bcachefs

Posted Aug 1, 2025 13:36 UTC (Fri) by daroc (editor, #160859) [Link]

As of right now, bcachefs has not yet been removed. We're all keeping an eye out here to see if that situation changes, so you can expect an article about the situation when/if anything happens.

bcachefs

Posted Aug 1, 2025 14:07 UTC (Fri) by koverstreet (subscriber, #4296) [Link] (6 responses)

Regardless, 6.16 is looking like a very solid release for bcachefs. Everyone please be patient, the world won't end regardless of which way it goes.

bcachefs

Posted Aug 3, 2025 10:30 UTC (Sun) by jmalcolm (subscriber, #8876) [Link] (5 responses)

If kernel 6.17 from my distro ships without bcachefs (and presumably without bcachefs-tools), I will have to migrate several systems away from bcachefs (which will make me sad).

I use multiple distros with bcachefs and not all of them support dkms. One of them uses clang, musl, a custom memory allocator, and several kernel patches. I waited for bcachefs to be in the mainline kernel before I started using it. I did this because I am not going to manage the kernels and tools for multiple distros myself.

For me, the journey will end. Every time I read "support my users" I think to myself, "I guess he does not mean me". I doubt I am the only one.

I really like bcachefs (even though I got hit by the "docker bug"). So thank you to Kent for the filesystem even if I get left behind.

bcachefs

Posted Aug 3, 2025 15:35 UTC (Sun) by koverstreet (subscriber, #4296) [Link] (4 responses)

People keep acting like I'm the only one who has control over this, and I'm not. I'm just trying to do the best I can with what I have.

Getting bugfixes out and supporting users is what we should all be doing; when we lost sight of that we're not engineering anymore. The whole point of what we do is to ship stuff that works.

But bcachefs is still in tree last I checked.

bcachefs

Posted Aug 4, 2025 22:16 UTC (Mon) by jmalcolm (subscriber, #8876) [Link] (3 responses)

> Getting bugfixes out...is what we should all be doing

Sure. But those fixes cannot be submitted after the merge window.

I love bcachefs but I do not believe it is the most critical code in the kernel. Linux and Linus have responsibilities to MANY other users and lots of other code. I cannot think of any reason bcachefs would be the only code not to follow the rules (software engineering rules).

If they are critical, patches can be made available via other channels.

> we're not engineering anymore

Even an LLM will tell me that software engineering is about good design and effective process. I have never seen a definition that says it is about reactive bug fixing or emergency process exceptions.

I see that the current pull request contains a couple dozen bug fixes and a statement that the experimental flag is coming off. Honestly when I read that, my heart sank and I had to hold my head in my hands a while. Are we going to be requiring emergency bug fixes for a non-experimental file system now? Putting that in the pull request is like pinky-swearing Linus that bcachefs will continue to be a nightmare in the future if he keeps it in.

The experimental flag should come off after a couple of kernel releases with few important bugs and no breaking changes. We have not seen that yet. The last on-disk format change was so recent that I cannot fall back to an LTS kernel because bcachefs differs between kernels. And I have a couple bcachefs systems that I have had to stop using entirely while I wait for the container fix. Taking "experimental" off now may be good marketing but it is not good engineering. At least, that is my view.

> supporting users

Let me thank you again for bcachefs. Until recently, I was a vocal advocate. I dearly hope it finds a path to wider adoption. And let me emphasize that you do not owe me a damn thing. But if you are going to put "supporting users" in every message you write, you are talking about me and I get a voice.

First, the filesystem being set as "experimental" is a social contract that we users agree to. Bugs are expected and we users must be prepared for them. I have systems that have been rendered effectively unusable due to the bcachefs container bug. But I knew what I signed-up for. I must admit, it blindsided me a little as I was ready for data loss but not a multi-release loss in system functionality like that. I can prepare for and handle data loss though.

Second, being accepted into the mainline kernel is also a social contract. In addition to the rules pre-existing, being well-known, and therefore definitely something you agreed to, I feel like you implicitly made certain promises to your users. I watched bcachefs for a long time but did not start deploying it until it was accepted into the mainline. I knew it was not stable but there were a number of other things I could start to depend on at that point (I thought). In my view, getting kicked out of the kernel will be a breach of the social contract you made with users like me. Your repeated statements do not make it feel like you see it that way at all. Once bitten I guess.

> supporting users

One more time, bcachefs the tech is great. And again, you owe me nothing. And I actually like "the words". I want to use tech built by devs that are passionate, user focussed, and proud of their code. But if you are going to keep throwing that phrase up as a defense or justification, you should know that not all of your users feel supported by your actions. I feel abandoned and betrayed. Again, you owe me nothing. But this is real information you can use to decide if you are actually "supporting users" as much as you say you are.

> People keep acting like I'm the only one who has control over this

People are acting like it is your fault? Or that you bear more than half of the responsibility? That is what I see in the messages I have read. When everybody thinks one thing and you think something else, what does that generally mean?

> bcachefs is still in tree last I checked.

Yes, it appears that perhaps Mr. "don't break user space" is trying to support his users and meet his end of the social contract for accepting bcachefs into the kernel. I hope so. But few of "his" users are bcachefs users. Most of the rest of them may be better supported by kicking us out. There is still hope. Fingers crossed.

> I'm not

Sigh. Perhaps not.

bcachefs

Posted Aug 5, 2025 1:42 UTC (Tue) by koverstreet (subscriber, #4296) [Link] (2 responses)

> I have systems that have been rendered effectively unusable due to the bcachefs container bug. But I knew what I signed-up for. I must admit, it blindsided me a little as I was ready for data loss but not a multi-release loss in system functionality like that. I can prepare for and handle data loss though.

Are you referring to the overlayfs/docker issue?

That's an overlayfs issue, with an overlayfs fix coming in 6.17, but bcachefs in 6.16 has a workaround - you can mount with -o casefold_disabled.

I find it interesting that you're here complaining about your own issue, while saying it's perfectly fine for everyone else to wait on their bugfixes.

Where have I heard that before... :)

bcachefs

Posted Aug 5, 2025 22:36 UTC (Tue) by jmalcolm (subscriber, #8876) [Link] (1 responses)

> I find it interesting that you're here complaining about your own issue

Completely wrong and I hope that most readers see that clearly. Maybe not. After all this thread is about self-blindness and I guarantee that I am not immune to that.

As you quoted me, "But I knew what I signed-up for". That is me taking accountability for my actions and explicitly not blaming bcachefs at all (and not you either). Sorry you misunderstood that. Accountability. You know, exactly the thing I am trying to highlight for you. If you misunderstood that, let me be clear: I am praising bcachefs (thank you again for it) and being critical of your lack of accountability*.

I am not the only one. The majority of the messages on your most recent Patreon post say the same thing. As do other forums I have seen. There, as here, you have a different take. But none of those Patreons want to fight. We all want to be on the same side (us with you)--in the kernel.

I will say one last thing only because I want bcachefs to stay in the kernel.

Here is my main posit for you:

On the LKML you have engaged in a battle with one of the most famously blunt, aggressive, dismissive, abrasive, and inflexible people in the Open Source world. Yet, the consensus is that you are the one having trouble playing well with others. That gives you no pause at all?

Perhaps a light-bulb will come on and you will put less energy into getting bcachefs kicked out of the kernel. Then again, I believe that weaknesses are over applications of a strength. So, perhaps I should leave you alone and be careful what I wish for.

No more from me. I will go back to being thankful for bcachefs (even if I can personally no longer use it) and leave you to be you. bcachefs is nice work. Good luck.

* In case this is still not clear, my criticism is of your LKML behaviour only, not an attack on you generally. I do not know you at all beyond some public messages. Well, I know that you gifted us a great fs and that would seem to make you a pretty great guy overall. I just want bcachefs to stay in the kernel. If I have taken the totally wrong approach here, know that what I am really trying to say to you Kent is "please help". Please. And thank you.

bcachefs

Posted Aug 6, 2025 17:39 UTC (Wed) by koverstreet (subscriber, #4296) [Link]

This isn't about blame.

You had an issue with bcachefs that kept you from running it; that's a legitimate thing to bring up. But I do - often - have to point out that there are things outside of my control.

Regarding the casefolding/overlayfs issue, it was bad form for one subsystem to be depending on global configuration of another subsystem unnecessarily. I only found out about that and started getting reports very late in the 6.15 cycle, and then I almost immediately started working on a proper vfs/overlayfs fix, because we don't want to be telling people "you can use your filesystem for docker, or Windows games - but not both". Doh.

When it turned out the overlayfs fix wasn't going to go in until the 6.17 merge window, I pushed a workaround in bcachefs (that I would have rather not added; it won't be needed when the real fix landed and those things are hard to remove) mid way during the 6.16 cycle.

So if docker/overlayfs was your issue, you should be good to go in 6.16. I apologize for the inconvenience, but when things cross subsystem boundaries it becomes more complicated.

(Side note: the number of reports I got about docker breakage when 6.15 came out was a data point that caused me to revise my estimate of bcachefs usage upwards. I did not expect quite so many reports; most of the people I talk to are running it on fileservers).

Now, I want bcachefs to stay in the kernel too, but I cannot control what Linus does.

I have to focus on my responsibilities: making sure that within bcachefs we're prioritizing robustness, reliability, and user support.

Admiral Rickover (father of the nuclear navy) had a lot of good stuff to say about engineering - one of them was, "if you cannot identify the person who was truly responsible, then no one was". I am responsible for the bcachefs code; what happens outside of my tree is a different story.

We are pushing back here against a culture and an environment which has not had this same attitude of responsibility - if it had, bcachefs would not need to exist.

And that's been the fundamental conflict here; we've had far too many pull request arguments over just getting in bugfixes for bugs that were affecting users, with no justification other than "bcachefs is experimental garbage that no one should be running" - while I'm talking to and supporting those users who supposedly do not exist every day. That's a situation where conflict is inevitable.

So, if you want bcachefs to stay in tree, and users like you to be supported, you're talking to the wrong person.

bcachefs

Posted Aug 15, 2025 16:09 UTC (Fri) by Spudd86 (guest, #51683) [Link]

Linus really needs to make a statement on this. It's not fair to users to just be silent.

Obviously bcachefs has no path forward in mainline if Linus is entirely unwilling to take code from Kent. If he'd be willing to work with someone else as maintainer in the kernel who can be a buffer between him and Kent he should say so, if not he should say bcachefs is being removed and post a patch removing it.

It's also completely unacceptable to keep Kent listed as a maintainer if Linus is going to ignore him completely, Kent obviously can't act as a maintainer if he can't talk to Linus.

Linus needs to make it clear what he is and is not willing to do and what is happening to bachefs in mainline Linux. If he doesn't want to work with Kent, that's entirely understandable, but he should say so and make it clear someone else can act as maintainer in mainline. If he doesn't want Kent's code he should remove it.

Speed of merging

Posted Aug 1, 2025 11:23 UTC (Fri) by sfr (subscriber, #7761) [Link]

As of now the next-20250801 release, Linus has merged 9755 non-merge commits and there are 2132 left in linux-next.
At the same time last merge window (next-20250530), these numbers were 7776 and 4950.