---

Linux 4.9 rc1

I usually do the releases on a Sunday afternoon, but occasionally cut
the merge window short by a day just to keep people on their toes, and
make sure people learn not to send in last-minute pull requests. No
gaming the merge window to the last day. This is one such release.

To be fair, the reason I did it a day early this time around is less
to stop people from trying to time their pull requests, and mostly
because this has been a pretty big merge window, and not hugely
enjoyable. I ended up stopping doing pulls twice during the merge
window just because I was chasing down some random problem. That tends
to turn my busy merge window time from "busy" to "somewhat stressful".

But hey, it's all good now, and while 4.9 looks to be a big release
and we had a couple of hiccups, on the whole things look normal. The
big new thing is the greybus addition, which Greg swears is actually
getting used. But the bulk of the changes by far is actually a lot of
small details under the hood, as usual.

My own favorite "small detail under the hood" happens to be Andy
Lutomirski's new virtually mapped kernel stack allocations. They make
it easier to find and recover from stack overflows, but the effort
also cleaned up some code, and added a kernel stack mapping cache to
avoid any performance downsides. Al has also been working on some vfs
and uaccess cleanups (particularly a goo splice model cleanup) that I
follow. But realistically, what _I_ consider cool small details is
just my own personal thing, there's things all over.

The virtual stack mapping also happens to mean that people who try to
do DMA from temporary buffers on the stack ("Don't do it!") now really
need to change their evil ways. So there is some fallout from this,
and I expect a couple of drivers to need minor fixes. But it's all for
a good cause, really (and it isn't all that common, because doing DMA
from the stack really has never been a good idea, and is generally not
even workable in most situations).

But there really is a lot of other things going on, and the shortlog
that I do for other releases is much too big during rc1. So as usual,
I'm appending my "mergelog" instead, which gives a very high-level
view of what I merged and from whom. And as usual, I want to point out
that the person I merge from is not necessarily the person who did the
work: we had 1500 people involved in this release, only the top-level
maintainers get credited in my mergelog.

Go forth and test,

Linus

Get the Free Newsletter!

Subscribe to Developer Insider for top news, trends, & analysis