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
(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
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