On Mon, Mar 02, 2026 at 09:10:11AM -0500, Greg KH wrote:
On Mon, Mar 02, 2026 at 08:52:19AM -0500, Sasha Levin wrote:
On Sun, Mar 01, 2026 at 10:05:02PM -0800, Barry K. Nathan wrote:
On 2/28/26 10:00, Sasha Levin wrote:
This is the start of the stable review cycle for the 6.12.75 release. There are 385 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Mon Mar 2 05:59:55 PM UTC 2026. Anything received after that time might be too late.
The whole patch series can be found in one patch at: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/p... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.12.y and the diffstat can be found below.
Thanks, Sasha
I just now noticed a sizable discrepancy between what's in the stable-queue and what's in -rc1, for 5.10.y through 6.12.y. (6.18.y and 6.19.y appear unaffected.)
To make sure this is an apples-to-apples comparison, I'll compare with the stable-queue as of commit 2370009958172f632d48973387e7b6ae116086b1 ("Drop a broken ACPI patch"); I'd expect the queue as of that commit to match the -rc1 patches, if I'm not mistaken.
# of patches in # of patches in stable mailing list stable-queue git thread @ 2370009958175.10.252-rc1 147 334 5.15.202-rc1 164 411 6.1.165-rc1 232 533 6.6.128-rc1 283 683 6.12.75-rc1 385 953 6.18.16-rc1 752 751 6.19.6-rc1 844 843
The off-by-one difference for 6.18.y/6.19.y is expected, since (unlike the stable-queue itself) the -rc1 patch and the mailing list thread include a Makefile patch to update the version number.
For the other kernels, though, it looks to me like something went wrong somewhere. Of course I could be mistaken, but that's how it appears to me.
In any case, I figured I should bring this to your attention.
Barry, this is a great catch. Thank you!
The root cause turned out to be a bug in git-quiltimport. One of the patches queued has the literal text "\0" in its subject line:
selftests: tc_actions: don't dump 2MB of \0 to stdout
git-quiltimport constructs commit messages using echo(1):
commit=$( { echo "$SUBJECT"; echo; cat "$tmp_msg"; } | git commit-tree $tree -p $commit)
The problem is that echo interprets backslash escape sequences, so "\0" gets expanded into an actual NUL byte (0x00). git commit-tree then rejects the commit with:
error: a NUL byte in commit log message not allowed.
This caused git-quiltimport to bail out mid-way through building several trees during -rc construction. The trees that had this patch queued (5.10 through 6.12) only got a partial set of patches into the -rc branch, while 6.18 and 6.19 were unaffected because they hadn't hit the problematic patch yet.
6.18 and 6.19 were also previously released by Greg, who uses actual quilt rather than git-quiltimport, so he wouldn't have run into this.
But I use git-quiltimport when creating the releases, so did I somehow not apply things properly when that happens, skipping patches in the releaase?
As we talked about this on irc, turns out it's a bash vs. dash issue. Bash works fine, dash does not, hence the problem only showing up for one of us.
Glad that's figured out :)
greg k-h