gemini://gemini.tuxmachines.org/n/2023/05/07/Linus_Torvalds_Announces_First_Linux_Kernel_6_4_Release

Posted by Marius Nestor on May 07, 2023,

The two-week merge window for Linux kernel 6.4 is now closed and the first Release Candidate is available to download from the kernel.org website or from Linus Torvalds’ git tree for early adopters, system integrators, and bleeding-edge users who want to get a glimpse of what’s about to be included in the final release.

Linus Torvalds writes in his announcement post that the Linux 6.4-rc1 patch consists of about 55 percent updated and new drivers, about 20 percent architecture updates, and the rest is the usual random mix of documentation, tooling, networking, filesystem, and core kernel stuff.

LWN and the original message:

> This is just one more back in the long-running shadow-stack story; see this article for some background.

> In the end, 13,044 non-merge changesets were pulled during this merge window.

> So here we are, two weeks later, with the merge window over, and -rc1

Things look pretty normal - the only somewhat unusual thing for me

personally was that we had two different pull requests that ended up

with me doing my own little series of updates on top.

So both the ITER_UBUF update from Jens, and the x86 LAM support from

Dave Hansen (really Kirill, but I see the pull from Dave) caused me to

do some extra x86 user access cleanups.

The reason I mention that isn't so much "oh, I got to code a bit

again", but that this actually caused me to *finally* switch to a more

modern default 'git diff' algorithm. The default git diff algorithm is

the very traditional one (aka 'Myers algorithm'), and while it works

just fine, there's been various heuristics updates to make for nicer

So I'm now using the 'histogram' algorithm, that takes the

"uniqueness" of a line into account when deciding on longest common

subsequence, because some of my patches were just an unreadable mess

with the plain Myers diff. Not that histogram always helps, but it

does often make things more legible.

Now, this shouldn't really impact anybody else, and I know some people

were already using either the patience of histogram algorithms, but I

mention it because it does occasionally cause line number differences

in the diffstats, and thus affects the pull-request output.

I'm already used to small differences, but *if* you send me pull

requests, this does mean that it might be just slightly easier on me

if you follow my lead on picking a diff algorithm, and do

git config diff.algorithm histogram

in your kernel tree. Or, if you find that you prefer it over-all,

maybe add "--global" there to do it in your main gitconfig to affect

[ Or just edit your .gitconfig files manually, it's actually what I

do, but when telling others "you might want to do this", it's simpler

to just give the "git config" command line ]

Anyway, this is absolutely *not* a requirement, and honestly, in 95%

of all cases it probably won't even change the diff output at all. But

I thought I might just mention it to make people aware (and to maybe

minimize the number of pull requests where I go "ok, let's figure out

why my end result isn't exactly the same as the one in the PR").

As to the actual changes in this merge window: the mergelog below

gives the high-level view. The diffstat is completely dominated by AMD

GPU hardware description files once again, and this time the 'perf'

tool has followed suite, and so the other big area ends up being all

the perf event JSON file descriptions. Ugh.

But if you ignore those two "massive, but uninteresting" parts of the

changes, everything else looks fairly normal. Lots of development all

over, with "that's interesting" mainly depending on the reader.

Drivers, architecture updates, filesystems, networking, memory

management - there's a bit of everything.

The one feature that didn't make it was the x86 shadow stack code.

That side was probably a bit unlucky, in that it came in as I was

looking at x86 issues anyway, and so I looked at it quite a bit, and

had enough reservations that I asked for a couple of fairly big

We'll get to that at a later date, possibly the next release.

Anyway, please do go test it all out,

Linus Torvalds Announces First Linux Kernel 6.4 Release Candidate

Kernel prepatch 6.4-rc1

Linux 6.4-rc1