No surprises this week, although it is probably worth pointing out how the 0day robot has been getting even better (it was very useful before, but Fengguang has been working on making it even better, and reporting the problems it has found).
Sure, some of the new reports turned out to be just 0day doing things that just don't work (ie KASAN with old gcc versions, but also doing things like loading old ISA drivers in situations that just don't make sense - remember when you couldn't even ask if the hardware existed or not, and just had to know), but even then it's been all good.
The appended shortlog is obviously only for the (small) haul since rc8, and it really is tiny. Not very many commits, and they are small. The biggest thing that stands out in the diffstat is the "leaking_addresses" perl script, which is actually under active development, but I put the first version in for 4.14 just so that people could see that initial state and start looking at the end result and perhaps ask themselves "should my code make these kernel addresses visible to user space".
The actual changes will hopefully start percolating into 4.15, with one notable llikely early change (which has been discussed extensively on the list) being to just hash any "%p" addresses by default. We used to have strict modes that just zeroed the address out, but that was actually counter-productive, in that often people use the address as a "kernel object identity" for debugging (or fro cross-correlation - think network sockets), and so just clearing the pointer value makes those kinds of uses pointless. But using a secure hash allows for those kinds of identity uses, while not actually leaking the address itself.
(Other situations where the actual address is relevant then need other approaches - we'll be restricting /proc/kallsyms only to entities that actually need them etc etc).
Anyway, apart from that one script, the rest of it really is one-liners or "few-liners".
The most noticeable last-minute change is probably that we had to revert the code that showed a good MHz value in /proc/cpuinfo even for the modern "CPU picks frequency dynamically" case. It worked fine, but it was much too expensive on machines with tens or hundreds of CPU cores. There's a cunning plan, but it didn't make 4.14, so we'll get it working and then back-port.
Anything else is pretty esoteric, you can just read the changelog..
And with this, the merge window for 4.15 is obviously open. As mentioned in the late rc announcements, the extra week for rc8 means that now Thanksgiving week ends up happening during the second half of the merge window, and I'll be off on a family vacation.
We'll see how that goes.
I might decide that I'll extend the merge window if I feel that I can't be responsive enough.
Or maybe you guys won't even notice, because I _will_ have my laptop and internet access.
Or maybe I will just decide that 4.14 was a painful release, and any late stragglers for 4.15 are not worth _another_ painful release, and I'll just say "tough luck, you were late to the merge window, and I felt more like being out in the sun than taking your second-week pull request".
Because it really would be lovely to have a smaller and calmer release for 4.15.
Anyway, go out and test the new 4.14 release, that is slated to be the next LTS kernel - and start sending me pull request for the 4.15 merge window.
Some of the products that appear on this site are from companies from which QuinStreet receives compensation. This compensation may impact how and where products appear on this site including, for example, the order in which they appear. QuinStreet does not include all companies or all types of products available in the marketplace.