Re: [PATCH 6.12 000/385] 6.12.75-rc1 review

[Sasha Levin <sashal@kernel.org>]

On Mon, Mar 02, 2026 at 09:21:49AM -0500, Greg KH wrote:
>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/patch/?id=linux-6.12.y&id2=v6.12.74
>> > > > 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                  @ 237000995817
>> > >
>> > > 5.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 :)

For those curious, try running the following in your terminal:

  $ /bin/sh -c 'echo "hello \0 world"' | xxd | head -1

With a dash shell, you'll see:

  00000000: 6865 6c6c 6f20 0020 776f 726c 640a       hello . world.

With a bash shell, you'll see:

  00000000: 6865 6c6c 6f20 5c30 2077 6f72 6c64 0a    hello \0 world.

-- 
Thanks,
Sasha