#Linux 6.7.12 is out, which is the "LAST 6.7.y #kernel to be released. This branch is now end-of-life. Please move to the 6.8.y branch at this point in time."
"I spotted that FPS was around 122 in the Shadow of the Tomb Raider benchmark at commit f6cef5f8c37f but after moving to commit 4ae3dc83b047 ("ALSA: timer: Fix missing irq-disable at closing") it decreased to 84".
"'"Neither snow nor rain nor heat nor gloom of night stays kernel rc releases.
Nor does Easter.
So here we are. Another week has passed, and rc2 is out. Nothing here look all that remarkable, and the fixes are fairly evenly spread out (so mostly drivers, because that's the bulk of the code).
#Linux 6.9-rc2 is now available for public testing at https://kernel.org and Linus Torvalds says that "nothing here look all that remarkable, and the fixes are fairly evenly spread out (so mostly drivers, because that's the bulk of the code)." Happy testing!
Lasse Collin's patch-series updating the #LinuxKernel's #xz code that a few days ago hit #linux-next was dropped for now until backdooring of upstream xz is understood better:
A tale about exploiting KernelCTF Mitigation, Debian, and Ubuntu instances with a double-free in nf_tables in the #Linuxkernel, using novel techniques like Dirty Pagedirectory. All without even having to recompile the exploit for different #kernel targets once.
When #Linux#kernel developers file bugs in bugzilla.kernel.org against subsystems that do not use the bug tracker[1]: it seems even they are not aware that the bug most likely won't be forwarded to the responsible developers and thus not be acted upon.
[1] reminder, only a very small fraction of the #LinuxKernel's subsystems use it; how many exactly is hard to say, but only 20 out of 2500+ entries in the MAINTAINERS file point to it.
Go and take a look – and let me know if you spot any mistakes or something else that could be improved!
And thx again to everyone (especially @ptesarik and @corbet) who helped getting this reviewed and merged into the #LinuxKernel's documentation: much appreciated!
"[…] The other day I was implementing multi-threaded stat() calls in bfs. When I ran some benchmarks, I saw something that made my heart skip a beat: […]
I searched Google for that "corrupted node" message and found that it had happened to someone else recently too: Linus Torvalds, just after merging a #Btrfs pull request. (This was not the first time Linus and I had hit the same bug. We both have the same CPU in our desktops. […]"
Interesting detail in the description of the main EFI changes merged for #Linux 6.9[1]:
"'"Avoid creating mappings that are both writable and executable while running in the EFI boot services. This is a prerequisite for getting the x86 #shim loader signed by MicroSoft again, which allows the distros to install on x86 PCs that ship with EFI secure boot enabled."'"
Pondering about changes for #Linux' reporting-issues.rst text and wonder if it would be wise to include what I wrote yesterday:
"The #LinuxKernel development model differs in a few important aspects from most other Open Source projects. Especially two of those peculiarities complicate bug reporting:
Developers are free to solely focus on mainline.
There is no central bug tracker.
Due to the first aspect a few kernel developers ignore or react coldly […]" (see screenshot for the rest)
"As a device mapper target, it can add these features to the storage stack, compatible with any file system. The vdo target does not protect against data corruption, relying instead on […]"
Just released version 0.9.10 of #kcbench, as simple benchmark script that compiles #Linux a few times in a row and measure the time it takes (either in default config or in a allmodconfig):
"'"Introduce a new LSM called Clavis (Latin word meaning key). The motivation behind this LSM is to provide access control for system keys. Before spending more time on this LSM, I am sending this as an RFC to start a discussion to see if the current direction taken has a possibility of being accepted in the future."'"
Seems these days about two-thirds of the #Linux development cycles are nine weeks long and just one-third are ten; it used to be round about 50/50 after #LinuxKernel 3.13 for a while, but seems since about #kernel 5.4 in November 2019 the cadence slightly increased: