It's been a while in between point releases, but we have Linux 6.13.3 today. I think they are spending more time testing now, they have "rc1" and list a bunch of testers at the top of changelogs nowadays.
https://cdn.kernel.org/pub/linux/kernel ... Log-6.13.3
I'm scrolling through the substantial changelog and there are a lot of little fixes and cleanups, mostly for stuff that wouldn't concern us. A few interesting commits though.
Changes for gcc 15
x86/boot: Use '-std=gnu11' to fix build with GCC 15
commit ee2ab467bddfb2d7f68d996dbab94d7b88f8eaf7 upstream.
GCC 15 changed the default C standard version to C23, which should not
have impacted the kernel because it requests the gnu11 standard via
'-std=' in the main Makefile. However, the x86 compressed boot Makefile
uses its own set of KBUILD_CFLAGS without a '-std=' value (i.e., using
the default), resulting in errors from the kernel's definitions of bool,
true, and false in stddef.h, which are reserved keywords under C23.
./include/linux/stddef.h:11:9: error: expected identifier before ‘false’
11 | false = 0,
./include/linux/types.h:35:33: error: two or more data types in declaration specifiers
35 | typedef _Bool bool;
Set '-std=gnu11' in the x86 compressed boot Makefile to resolve the
error and consistently use the same C standard version for the entire
kernel.
A fix for Clang 19 warnings, well not actually a fix (just not making it break on -Werror). I do compile the kernel with Clang 19.x but this won't bother me because I disable -Werror
kbuild: Move -Wenum-enum-conversion to W=2
commit 8f6629c004b193d23612641c3607e785819e97ab upstream.
-Wenum-enum-conversion was strengthened in clang-19 to warn for C, which
caused the kernel to move it to W=1 in commit 75b5ab134bb5 ("kbuild:
Move -Wenum-{compare-conditional,enum-conversion} into W=1") because
there were numerous instances that would break builds with -Werror.
Unfortunately, this is not a full solution, as more and more developers,
subsystems, and distributors are building with W=1 as well, so they
continue to see the numerous instances of this warning.
Since the move to W=1, there have not been many new instances that have
appeared through various build reports and the ones that have appeared
seem to be following similar existing patterns, suggesting that most
instances of this warning will not be real issues. The only alternatives
for silencing this warning are adding casts (which is generally seen as
an ugly practice) or refactoring the enums to macro defines or a unified
enum (which may be undesirable because of type safety in other parts of
the code).
Move the warning to W=2, where warnings that occur frequently but may be
relevant should reside.
An interesting fix for ACPI APIC parsing order:
x86/acpi: Fix LAPIC/x2APIC parsing order
commit 0141978ae75bd48bac13fca6de131a5071c32011 upstream.
On some systems, the same CPU (with the same APIC ID) is assigned a
different logical CPU id after commit ec9aedb2aa1a ("x86/acpi: Ignore
invalid x2APIC entries").
This means that Linux enumerates the CPUs in a different order, which
violates ACPI specification[1] that states:
"OSPM should initialize processors in the order that they appear in
the MADT"
The problematic commit parses all LAPIC entries before any x2APIC
entries, aiming to ignore x2APIC entries with APIC ID < 255 when valid
LAPIC entries exist. However, it disrupts the CPU enumeration order on
systems where x2APIC entries precede LAPIC entries in the MADT.
Fix this problem by:
1) Parsing LAPIC entries first without registering them in the
topology to evaluate whether valid LAPIC entries exist.
2) Restoring the MADT in order parser which invokes either the LAPIC
or the X2APIC parser function depending on the entry type.
The X2APIC parser still ignores entries < 0xff in case that #1 found
valid LAPIC entries independent of their position in the MADT table.
Most of the amdgpu /display fixes seem to be for GFX12 (8000 series)
Obligatory btrfs fixes.
Enough changelog, time to get at it. I'm also going to upgrade firmware to this month's distribution (linux-firmware-20250211.tar.xz). I don't use much of it (and only copy what I need), just the amdgpu blobs and one for my onboard realtek NIC that I build in the kernel image with the driver.
