Thorsten Leemhuis (acct. 1/4)

#Linux 7.1-rc3, 7.0.6 and 6.18.29 are out with a fix for the second half of the #DirtyFrag vulnerability:

* https://git.kernel.org/torvalds/c/aa54b1d27fe0c2b78e664a34fd0fdf7cd1960d71
* https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-7.0.y&id=d45179f8795222ce858770dc619abe51f9d24411
* https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-6.18.y&id=3eae0f4f9f7206a4801efa5e0235c25bbd5a412c

Thing is: it seems that the fix might have some problems, so a fix for the fix is in the works:

* https://lore.kernel.org/all/2026051008[email protected]/t/#u
* https://lore.kernel.org/all/agDTmXM2wXnJflYc@v4bel/

#LinuxKernel #kernel

#Linux 7.1-rc3 is out:

https://lore.kernel.org/lkml/CAHk-=wgC[email protected]/

Linus writes: ""[…] this [rc] answers the "is 7.1 continuing the larger size pattern that we saw with 7.0?" question, and the answer is yes: that wasn't a fluke brought on by a .0 release - it simply seems to be the new normal.""

#LinuxKernel #kernel

Quick reminder in light of the recent #LinuxKernel vulnerabilities:

In case you want to protect yourself against vulnerabilities in #Linux #Kernel modules you don't need, disable module loading completely by running:

echo 1 | sudo tee /proc/sys/kernel/modules_disabled

Of course you want to load all modules you need before running that command, as otherwise you will have to reboot to load them. 😄

More details on this:

* https://dfir.ch/posts/today_i_learned_lkm_kernel.modules_disabled/
* https://linux-audit.com/kernel/increase-kernel-integrity-with-disabled-linux-kernel-modules-loading/
* https://www.heise.de/select/ct/2020/1/1577462303523965 [German]

RE: https://fedi.lwn.net/@lwn/116538328401421358

The patch to fix the second half of #DirtyFrag is at its third iteration now: https://lore.kernel.org/all/af2kdW2F1gJ9U-Gg@v4bel/

#LinuxKernel #kernel #Linux

2/ for more details about the new autonomous self healing of filesystems in #xfs merged for Linux 7.0, see https://git.kernel.org/torvalds/c/04a65666a69508fa0022c7343026c5a3d41d166d

""This patchset builds new functionality to deliver live information about filesystem health events to userspace. This is done by creating an anonymous file that can be read() for events by userspace programs. Events are captured by hooking various parts of XFS and iomap so that metadata health failures, file I/O errors, and major changes in filesystem state (unmounts, shutdowns, etc.) can be observed by programs.

When an event occurs, the hook functions queue an event object to each event anonfd for later processing. Programs must have CAP_SYS_ADMIN to open the anonfd and there's a maximum event lag to prevent resource overconsumption. The events themselves can be read() from the anonfd as C structs for the xfs_healer daemon.

In userspace, we create a new daemon program that will read the event objects and initiate repairs automatically. This daemon is managed entirely by systemd and will not block unmounting of the filesystem unless repairs are ongoing. They are auto-started by a starter service that uses fanotify.""

#Kernel #LinuxKernel

Half of the support for the #initrd (not to be confused with #initramfs!) was removed from #Linux 7.0 through a #vfs merge from @brauner:

https://git.kernel.org/torvalds/c/996812c453cafa042f2e674738dbf8fa495661f3 and https://git.kernel.org/torvalds/c/ef12d0573a7f5e7a495e81d773ae5f3e98230cd4

""Remove the deprecated linuxrc-based initrd code path and related dead code. The linuxrc initrd path was deprecated in 2020 and this series completes its removal. If we see real-life regressions we'll revert. […]

The no-op load_ramdisk= and prompt_ramdisk= parameters are dropped, and noinitrd and ramdisk_start= gain deprecation warnings.

Initramfs is entirely unaffected. The non-linuxrc initrd path (root=/dev/ram0) is preserved but now carries a deprecation warning targeting January 2027 removal""

#Kernel #LinuxKernel

Highlights from the main #acpi merge for #Linux 7.0:

""This one is significantly larger than previous ACPI support pull requests because several significant updates have coincided in it.

First, there is a routine ACPICA code update, to upstream version 20251212, but this time it covers new ACPI 6.6 material that has not been covered yet. Among other things, it includes definitions of a few new ACPI tables and updates of some others, like the GICv5 MADT structures and ARM IORT IWB node definitions that are used for adding GICv5 ACPI probing on ARM (that technically is IRQ subsystem material, but it depends on the ACPICA changes, so it is included here). The latter alone adds a few hundred lines of new code.

Second, there is an update of ACPI _OSC handling including a fix that prevents failures from occurring in some corner cases due to careless handling of _OSC error bits.

On top of that, the "system resource" ACPI device objects with the PNP0C01 and PNP0C02 are now going to be handled by the ACPI core device enumeration code instead of handing them over to the legacy PNP system driver which causes device enumeration issues to occur. Some of those issues have been worked around in device drivers and elsewhere and those workarounds should not be necessary any more, so they are going away.

Moreover, the time has come to convert all "core ACPI" device drivers that were still using struct acpi_driver objects for device binding into proper platform drivers that use struct platform_driver for this purpose. These updates are accompanied by some requisite core ACPI device enumeration code changes.

Next, there are ACPI APEI updates, including changes to avoid excess overhead in the NMI handler and in SEA on the ARM side, changes to unify ACPI-based HW error tracing and logging, and changes to prevent APEI code from reaching out of its allocated memory.

There are also some ACPI power management updates, mostly related to the ACPI cpuidle support in the processor driver, suspend-to-idle handling on systems with ACPI support and to ACPI PM of devices.

In addition to the above, bugs are fixed and the code is cleaned up in assorted places all over.

[…] ""

https://git.kernel.org/torvalds/c/d84e173311c4f0b0300755e6445f3224d252eeed

#Kernel #LinuxKernel

Support for bounce buffering of DirectIO for stable pages was merged for #Linux 7.0 via @axboe

https://git.kernel.org/torvalds/c/4adc13ed7c281c16152a700e47b65d17de07321a

""This series tries to address the problem that under I/O pages can be modified during direct I/O, even when the device or file system require stable pages during I/O to calculate checksums, parity or data operations. It does so by adding block layer helpers to bounce buffer an iov_iter into a bio, then wires that up in iomap and ultimately XFS.

The reason that the file system even needs to know about it, is because reads need a user context to copy the data back, and the infrastructure to defer ioends to a workqueue currently sits in #XFS. I'm going to look into moving that into ioend and enabling it for other file systems. Additionally #btrfs already has it's own infrastructure for this, and actually an urgent need to bounce buffer, so this should be useful there and could be wire up easily. In fact the idea comes from patches by Qu that did this in btrfs. […]""

#Kernel #LinuxKernel

#io_uring #bpf filter support was merged for #Linux 7.0 by @axboe

https://git.kernel.org/torvalds/c/591beb0e3a03258ef9c01893a5209845799a7c33 [update] see also: https://lwn.net/Articles/1054225/ and for the liburing side (which has both man pages and an extensive test case that also demonstrate how to use it) https://git.kernel.org/pub/scm/linux/kernel/git/axboe/liburing.git/commit/ [/update]

""This adds support for both cBPF filters for io_uring, as well as task inherited restrictions and filters. […]

seccomp and io_uring don't play along nicely, […] As a result, things like containers and systemd that apply seccomp filters, can't filter io_uring operations.

That leaves them with just one choice if filtering is critical - filter the actual io_uring_setup(2) system call to simply disallow io_uring. That's rather unfortunate, and has limited us because of it.

io_uring already has some filtering support. […] This first adds support for cBPF filters for opcodes, which enables tighter control over what exactly a specific opcode may do. […] These filters are run post the init phase of the request […] On top of that support is added for per-task filters , meaning that any ring created with a task that has a per-task filter will get those filters applied when it's created.[…]""

#Kernel #LinuxKernel

Highlights from the main #xfs merge for #Linux 7.0:

https://git.kernel.org/torvalds/c/56feb532bb927ae1c26726e2e7c0de95f54a3d67

""This contains several improvements to zoned device support, performance improvements for the parent pointers, and a new health monitoring feature [for more about the latter, see https://lwn.net/Articles/1055062/].""

#Kernel #LinuxKernel

#VFS support for generic I/O error reporting was merged for #Linux 7.0 by @brauner

https://git.kernel.org/torvalds/c/dd466ea0029961ee0ee6e8e468faa1506275c8a9

""Filesystems currently have no standard mechanism for reporting metadata corruption and file I/O errors to userspace via fsnotify. Each filesystem (xfs, ext4, erofs, f2fs, etc.) privately defines EFSCORRUPTED, and error reporting to fanotify is inconsistent or absent entirely.

This introduces a generic fserror infrastructure built around struct super_block that gives filesystems a standard way to queue metadata and file I/O error reports for delivery to fsnotify.

Errors are queued via mempools and queue_work to avoid holding filesystem locks in the notification path; unmount waits for pending events to drain. A new super_operations::report_error callback lets filesystem drivers respond to file I/O errors themselves (to be used by an upcoming XFS self-healing patchset).

On the uapi side, EFSCORRUPTED and EUCLEAN are promoted from private per-filesystem definitions to canonical errno.h values across all architectures""

#Kernel #LinuxKernel

Support for non-blocking timestamp updates in the #vfs was merged for #Linux 7.0 by @brauner:

https://git.kernel.org/torvalds/c/74554251dfc9374ebf1a9dfc54d6745d56bb9265

""[…] commit 66fa3cedf16a [made] non-blocking direct writes impossible on file systems with granular enough timestamps, which in practice means all of them.

This reworks the timestamp update path to propagate IOCB_NOWAIT through ->update_time so that file systems which can update timestamps without blocking are no longer penalized. […]

XFS implements non-blocking timestamp updates by using the new ->sync_lazytime and […]""

#Kernel #LinuxKernel

TIL: The #Linux #kernel has #Klingon language support:

https://docs.kernel.org/admin-guide/unicode.html#klingon-language-support

Qapla'!

#LinuxKernel #StarTrek

@thelinuxcast this post from https://who-t.blogspot.com/2016/01/xorg-project-vs-xorg-foundation.html is old, but explain the different things that X.org can mean (the foundation, the project) and how they relate to #Wayland (and other things around GPU drivers).

Maybe @whot should re-publish it yearly. 😄

Sadly the post does not mention that #Xorg (without a Dot after the X!) is something different (it's the older and once widespread of two popular X-Servers the X.org project publishes these days; the other one is #Xwayland).

#Glibc 2.43 is out:

https://inbox.sourceware.org/libc-alpha/13932477.uLZWGnKmhe@pinacolada/

A few highlights:

* Experimental support for building with #clang has been added.

* [a bunch of ISO C23 stuff]

* Support for mseal and openat2 on #Linux

* Additional optimized and correctly rounded mathematical functions have been imported from the CORE-MATH project […]

* Unicode support has been updated to Unicode 17.0.0.

These two @lwn articles are prime examples of why good journalism matters and why you should pay money to make sure it thrives:

They both look beyond the shiny statements from the different parties involved and outside commentators such as @torvalds in this case and explain just how it is from a mostly neutral[1] point of view so that you can make your own judgments.

* GPLv2 and installation requirements – https://lwn.net/Articles/1052842/

* SFC v. VIZIO: who can enforce the GPL? – https://lwn.net/Articles/1052734/

[1] We are humans, and even if we try, we are never completely neutral – and a publication like #LWN that targets the FLOSS community obviously will somewhat look at things from the view of its target audience.

#gpl #Linux #kernel #VIZIO #sfc

xfsprogs: v6.18.0 released https://lore.kernel.org/all/jzrly2kwodtwgrwltlkhsskoprvi5prntfcfmgbkktmzgsymnm@sggavy2z7uon/

* Refactoring the discard and reset zones code in mkfs allowing skipping discard of data section for zoned fs.

*Enable parent pointer by default in mkfs; see https://blogs.oracle.com/linux/xfs-directory-parent-pointers-in-uek8 (partly screenshotted below) for the problems this addresses

#xfs #Linux #kernel #LinuxKernel #filesystem

Sebastian Aaltonen writes:

""[…]Modern graphics API have improved gradually in the past 10 years. […] As of today, there’s no single API that meets all our requirements, but if we combine their best bits together, we can build the perfect API for modern hardware.

10 years ago, modern APIs were designed for CPU-driven binding models. New bindless features were presented as optional features and extensions. A clean break would improve the usability and reduce the API bloat and driver complexity significantly. It’s extremely difficult to get the whole industry behind a brand new API. I am hoping that vendors are willing to drop backwards compatibility in their new major API versions (Vulkan 2.0, DirectX 13) to embrace the fully bindless GPU architecture we have today. […]

https://www.sebastianaaltonen.com/blog/no-graphics-api

#Linux #Graphics #Drivers #API #Vulkan #directx #opengl

The Input Stack on Linux – An End-To-End Architecture Overview

https://venam.net/blog/unix/2025/11/27/input_devices_linux.html

Patrick Louis writes: ""Let’s explore and deobfuscate the input stack on #Linux. Our aim is to understand its components and what each does. Input handling can be divided into two parts, separated by a common layer:

#Kernel-level handling: It deals with what happens in the kernel and how events are exposed to user-space
[…]
Exposed layer (middle)
[…]
User-space handling:
[…]
The Widgets, #XServer, #X11 window managers, and #Wayland compositors, which rely on everything else

We’ll try to make sense of all this, one thing at a time, with a logical and coherent approach.""

#LinuxKernel #evdev

Really wondering what "upstream" actually refers to in "built-in #Debian #Linux environment with upstream support"

* Qualcomm?

* Debian? [Edit: stable or testing?]

* Upstream #LinuxKernel, #Mesa, et. al.?

Screenshot from https://docs.arduino.cc/hardware/uno-q/

#arduino #unoq #kernel

""Dumping packets from a network interface is a common debugging step. […] excessive and uncontrolled dumping can quickly become overwhelming, in terms of the amount of data and the impact on the inspected system. […] In this article, we will explore Retis[1] filtering capabilities, highlighting the differences, similarities, and expectations compared to other existing tools.""

https://developers.redhat.com/articles/2025/10/02/filtering-packets-anywhere-networking-stack

[1] from https://github.com/retis-org/retis "Retis – #Tracing (filtered) packets in the #Linux #networking stack, using #eBPF probes and interfacing with control and data paths such as #OvS or #Netfilter."

#Linux #Kernel #eBPF #networking #LinuxKernel #tracing

"An explanation of how #Linux handles system calls on x86-64 and why they show up as expensive operations in performance profiles

https://blog.codingconfessions.com/p/what-makes-system-calls-expensive – from Abhinav Upadhyay

#LinuxKernel #Kernel #syscalls

""The name sure sounds like “mutex”, and that is where the name comes from: “fast, user space mutex”. But, it isn’t really, it’s a building block for concurrency primitives that ushered in a modern world of concurrent performance […]

t was immediately clear that the futex was a huge improvement in highly concurrent environments. Just in that original paper, their tests with 1000 parallel tasks ran 20-120 times faster than sysv locks..🤯

Needless to say, other common operating systems followed suit, including Windows in 2012 and macOS by 2016.

These days, any good locking primitive is going to be based on a futex. […]""

https://h4x0r.org/futex/

#Linux #LinuxKernel #Kernel #Futex

Introduction to VirtIO, Part 2: Vhost

https://blogs.oracle.com/linux/post/introduction-to-virtio-part-2-vhost

Jonah Palmer writes: ""[…] #Vhost is a key optimization to #VirtIO that was created to offload data-plane processing from #Qemu into more efficient components.

We’ll start off by taking a more in-depth look into the causes of overhead in the data plane of a pure VirtIO configuration. We’ll talk about the costly operations that are involved, such as VM exits, VM entries, context switches, and userspace processing by Qemu. Then we’ll introduce vhost and elaborate on how it addresses these issues by moving data-plane operations either into the kernel (kernel-based vhost) or into a specialized userspace process (via vhost-user).

We’ll then dive into both #kernel-based vhost and vhost-user architectures, examining each in detail—including their advantages, drawbacks, typical use cases, and how they affect performance. […]"

#Linux #LinuxKernel

Some highlights from various #VFS merges for #Linux 6.17 where @brauner submitted the PR:

https://git.kernel.org/torvalds/c/278c7d9b5e0ca73a75e5151c22fb05c91cb4495f: fallocate() updates bringing support for the BLK_FEAT_WRITE_ZEROES_UNMAP feature and BLK_FLAG_WRITE_ZEROES_UNMAP_DISABLED flag for SCSI, NVMe and device-mapper drivers, and add the FALLOC_FL_WRITE_ZEROES and for ext4 and raw bdev devices; this enables preventing numerous metadata changes and journal I/O, which may lead to significant write amplification and performance degradation in synchronous write mode.

https://git.kernel.org/torvalds/c/57fcb7d930d8f00f383e995aeebdcd2b416a187a: support for the the new file_getattr() and file_setattr() system calls (after lengthy discussions), which allow userspace to set filesystem inode attributes on special files (One of the usage examples is the XFS quota projects.)

https://git.kernel.org/torvalds/c/7879d7aff0ffd969fcb1a59e3f87ebb353e47b7f: ext4 IOCB_DONTCACHE support

https://git.kernel.org/torvalds/c/117eab5c6e31815649d952f6da03f67aa247d29b: An extension to the coredump socket and a proper rework of the coredump code.

#kernel #LinuxKernel

From the main #ntfs3 merge for #Linux 6.17[1]:

"Added:
- sanity check for file name
- mark live inode as bad and avoid any operations

Fixed:
- handling of symlinks created in windows
- creation of symlinks for relative path

Changed:
- cancel setting inode as bad after removing name fails
- revert 'replace inode_trylock with inode_lock'"

[1] https://git.kernel.org/torvalds/c/a11b4fa602ed3b744aa075f34bee82c12aa3553a

#kernel #LinuxKernel

Using machine learning to optimize/fine-tune the #Linux #kernel at runtime to the needs of the workload – this is something I guess we'll see way more often in the future.

The recent #ossna25 talk "Improve Load Balancing With Machine Learning Techniques Based on the #sched_ext Framework" from Ching-Chun ("Jim") Huang gives a glimpse into such a future.

@lwn write-up: https://lwn.net/Articles/1027096/

Recording: https://www.youtube.com/watch?v=5VXemIXAOrI

Slides: https://static.sched.com/hosted_files/ossna2025/d2/Improve-Load-Balancing-With-Machine-Learning-Techniques-based-on-sched_ext.pdf

'"[…] The default dialect in #GCC 15 is still -std=gnu++17. You can use the -std=c++23 or -std=gnu++23 command-line options to enable C++23 features, and similarly for C++26 and others. […] C++26 features in #GCC15 include pack indexing, attributes for structured bindings, enhanced support for functions whose definition consists of =delete, and more. […] A number of defect reports were resolved in GCC 15. A few examples follow. […] C++11 attributes in C++98 […]"'

https://developers.redhat.com/articles/2025/04/24/new-c-features-gcc-15

"[…] Let's take a look at 6 improvements to look forward to in the upcoming #GCC 15.

1. Prettier execution paths

2. A new look for C++ template errors

3. Machine-readable diagnostics

4. An easier transition to C23

5. A revamped color scheme

6. libgdiagnostics

We're still fixing bugs, but we hope that GCC 15 will be ready to officially release (as 15.1) sometime later this month. […]"'

https://developers.redhat.com/articles/2025/04/10/6-usability-improvements-gcc-15 – by David Malcolm #gcc15

Have you heard the claim "Changing 30 lines of code in the #Linux #kernel could cut energy use at some data centers by up to 30 percent" that made the news two or three weeks ago?

Did you wonder if it is really that simple as it sounds in many stories? Then you want to read the following article from @LWN. It describes things in a more nuanced and technical way, as yes, it is not that simple:

https://lwn.net/Articles/1008399/ #LinuxKernel #networking #powerefficiency

GNU #Binutils 2.44 is out:

https://lists.gnu.org/archive/html/info-gnu/2025-02/msg00001.html

Some highlights:

* Assembler:
- Support for new architecture extensions for AArch64, Risc-V and x86.

* Linker:

- This now supports mixed LTO and non-LTO object files in relocatable output.
- The ELF forms of the linker support a --image-base=<ADDR> option for compatibility with LLD.

[…] does not contain the sources for the gold linker […] now deprecated and will eventually be removed unless volunteers step forward […]

Wanna know what's in store for Linux 6.13, which is expected to be released on January 19 or 26?

Then check out these articles from #LWNnet now freely available:

* The beginning of the 6.13 merge window – https://lwn.net/Articles/998623/

* The rest of the 6.13 merge window – https://lwn.net/Articles/998990/

#kernel #LinuxKernel

And with "reiserfs: The last commit", #reiserfs is now gone from #Linux for 6.13:

https://git.kernel.org/torvalds/c/fb6f20ecb121cef4d7946f834a6ee867c4e21b4a

63 files changed, 12 insertions, 32804 deletions

Bye bye! 👋

#LinuxKernel #Kernel #FileSystem

2/ Side note for users of #Fedora #Linux:

#LinuxKernel 6.12 is now available for all Fedora releases in the "stable" #copr of my #kernel vanilla repositories.

For install instructions, see https://copr.fedorainfracloud.org/coprs/g/kernel-vanilla/stable/ and https://fedoraproject.org/wiki/Kernel_Vanilla_Repositories

In addition to the regular kernel package that copr as of today started shipping a dedicated #realtime kernel which has #PREEMPT_RT enabled. Install it by running:

$ sudo dnf install kernel-rt

Jan plans to remove #reiserfs with #LinuxKernel 6.13:

"Deprecation period of reiserfs ends with the end of this year so it is time to remove it from the #kernel."

63 files changed, 12 insertions, 32804 deletions

https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=7f571dbace211fd7a8d679f61ff9fbee46687b6b #Linux

#Linux v6.12-rc1-rt1 is out:

https://lore.kernel.org/all/2024093015[email protected]/

If you wonder what's still in the RT-Tree now that #PREEMPT_RT support is upstream, checkout https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel.git/log/?h=linux-6.12.y-rt

In short: about 40 patches that among others switch 8250 to nbcon console, add support for ARM and PowerPC, or fix some drivers (like i915).

#Realtime #kernel #LinuxKernel

#Linux 6.12-rc1 is out:

https://lore.kernel.org/lkml/CAHk-=wiw[email protected]/

'"Despite conference travel (both for me and several maintainers), things seemed to go mostly fairly normally. There's a couple of notable new features in here: For one thing, #PREEMPT_RT is now mainlined and enabled as a config option (you do need to enable "EXPERT" to get the question). For another, #sched_ext also got merged.

[…]

Let's get the testing and calming down period started, ok?

Linus"'

#kernel #LinuxKernel

#sched_ext, which allows scheduling policies to be implemented as #BPF programs, has been merged for #Linux 6.12:

https://git.kernel.org/torvalds/c/88264981f2082248e892a706b2c5004650faac54

See https://lwn.net/Articles/922405/ for a description of what it does and https://lwn.net/Articles/972710/ for the controversy it caused that is the reason why it took so long to land in mainline.

2/ It's done! 🥳

A few minutes ago #PREEMPT_RT (aka: #realtime support) support landed in #Linux mainline, as Linus honored the PR that Tglx handed him yesterday in person (see first toot in thread): https://git.kernel.org/torvalds/c/baeb9a7d8b60b021d907127509c44507539c15e5

Congrats and thx to everyone who was involved in this 20 year long journey!

#Kernel #LinuxKernel

The #Linux 6.12 pull request for #PREEMPT_RT is handed to Linus. Likely the first PR ever submitted in printed form. #kernel #LinuxKernel #Realtime

#PREEMPT_RT aka the #realtime support for #LinuxKernel hit #linux-next today! 🥳 👏

https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/log/?qt=grep&q=PREEMPT_RT

Still remains to be seen if those changes really makes it upstream during the 6.12 merge window and stick:

* It afaics is still unclear if some #printk prerequisites will be submitted for 6.12: https://lore.kernel.org/all/87ed5za2oj[email protected]/

* Troublemaking changes sometimes are reverted before the final, which in fact happened to some of printk prerequisites a while ago: https://lore.kernel.org/lkml/202206231[email protected]/

#kernel

#Linux #kernel patches to allow enabling #PREEMPT_RT (aka proper #realtime support) for x86, ARM64, and Risc-V were posted for review:

https://lore.kernel.org/lkml/202409061[email protected]/

"The printk bits required for PREEMPT_RT are sitting in linux-next. This was the last known roadblock for PREEMPT_RT. The RT queue has additionally the "atomic console" for the 8250 UART which is not yet in linux-next.[…]"

See also these earlier other related toots:

https://fosstodon.org/@kernellogger/113084762433941141
https://fosstodon.org/@kernellogger/113085326251565367

v6 of the patch-set "add threaded printing + the rest" which "provides the remaining pieces of the #printk rework."[1] is now in #Linux-next – but as of now it's not yet clear if this will be merged for #kernel 6.12.

https://lore.kernel.org/all/ZthvGoJE26[email protected]/

[1] e.g. the last big missing piece for #Realtime support through #PREEMPT_RT in the mainline #LinuxKernel. But note, this series does *not* provide an nbcon console driver. That will come in a follow-up series.

Wedson Almeida Filho steps down as one of the maintainers of
the #RustForLinux project:

'"[…] After almost 4 years, I find myself lacking the energy and enthusiasm I once had to respond to some of the nontechnical nonsense, so it's best to leave it up to those who still have it in them.

To the Rust for Linux team: thank you, you are great. It was a pleasure working with you all; […]"'

https://lore.kernel.org/lkml/202408282[email protected]/

#Linux #Rust #Kernel #LinuxKernel #RustLang

John posted v4 of the patch-set "threaded console printing as well as some other minor pieces" which "provides the remaining pieces of the #printk rework." -- e.g. the last big missing piece for #Realtime support through #PREEMPT_RT in the mainline #Linux #Kernel. But note, "this series does *not* provide an nbcon console driver. That will come in a follow-up series."

https://lore.kernel.org/all/2024082704[email protected]/

This comes hot on the heels of the "write_atomic() printing" entering -next: https://fosstodon.org/@kernellogger/113003819326920850

The improved #printk series "wire up write_atomic() printing" is now in -next again and thus slated for inclusion in #Linux 6.12. This is one of the last important bits for proper #REALTIME support with #PREEMPT_RT in mainline – but not the last, as this series does not include threaded printing or nbcon drivers, as those will come later: https://lore.kernel.org/all/ZsWxpVG8uZ[email protected]/

A earlier version of the patch set was supposed to go into #kernel 6.11, but Linus was unhappy: https://lore.kernel.org/lkml/CAHk-=whU[email protected]/

'"the Trusted Platform Module (TPM) […] allows an unattended auto-unlock, providing a pass is no longer required. That completely fits to secure disks that have been put in a machine in a safe location. With FDE [Full Disk Encryption] and TPM, your data becomes protected and cannot be read outside of your machine."'

https://www.suse.com/c/full-disk-encryption-grub2-tpm/ #grub #tpm #FullDiskEncryption

FWIW, the PR with the BPF extensible scheduler class aka #sched_ext for #Linux 6.11 is out for 10 days now, but Linus did not merge it yet. Peterz and @qyousef also raised a few issues in between. Remains to be seen if Linus nevertheless will merge sched_ext in the next few days.

For details, see:

https://lore.kernel.org/all/2024072316[email protected]/t/#u

https://lore.kernel.org/all/20240725011907.3f5ropfai3xoy3l3@airbuntu/t/#u

#kernel #LinuxKernel #scheduler

Linus did not pull the latest printk changes for #Linux 6.11, as he did not like the what some of the changes required for proper #Realtime aka #PREEMPT_RT support do:

https://lore.kernel.org/all/CAHk-%3Dwh%[email protected]/

"'
> The messages are flushed at the end of the emergency section to allow storing the full log (backtrace) first.

What? No.

One of the historically problematic situations is when a recursive oops or a deadlock occurs *during* the first oops.

[…]
'" #kernel #LinuxKernel

John posted v3 of the patch-set with the "remaining pieces of the #printk rework" to support threaded console printing, which is last big missing piece missing to support #realtime with the mainline #Linux #kernel through #PREEMPT_RT:

https://lore.kernel.org/all/2024072217[email protected]/