Linux 4.14 Released

No surprises this week, although it is probably worth pointing out howthe 0day robot has been getting even better (it was very usefulbefore, but Fengguang has been working on making it even better, andreporting the problems it has found).Sure, some of the new reports turned out to be just 0day doing thingsthat just don't work (ie KASAN with old gcc versions, but also doingthings like loading old ISA drivers in situations that just don't makesense - remember when you couldn't even ask if the hardware existed ornot, and just had to know), but even then it's been all good.The appended shortlog is obviously only for the (small) haul sincerc8, 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 activedevelopment, but I put the first version in for 4.14 just so thatpeople could see that initial state and start looking at the endresult and perhaps ask themselves "should my code make these kerneladdresses visible to user space".The actual changes will hopefully start percolating into 4.15, withone notable llikely early change (which has been discussed extensivelyon the list) being to just hash any "%p" addresses by default. We usedto have strict modes that just zeroed the address out, but that wasactually 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 makesthose kinds of uses pointless. But using a secure hash allows forthose kinds of identity uses, while not actually leaking the addressitself.(Other situations where the actual address is relevant then need otherapproaches - we'll be restricting /proc/kallsyms only to entities thatactually need them etc etc).Anyway, apart from that one script, the rest of it really isone-liners or "few-liners".The most noticeable last-minute change is probably that we had torevert the code that showed a good MHz value in /proc/cpuinfo even forthe modern "CPU picks frequency dynamically" case. It worked fine, butit was much too expensive on machines with tens or hundreds of CPUcores. There's a cunning plan, but it didn't make 4.14, so we'll getit 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. Asmentioned in the late rc announcements, the extra week for rc8 meansthat now Thanksgiving week ends up happening during the second half ofthe 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 Ican't be responsive enough.Or maybe you guys won't even notice, because I _will_ have my laptopand internet access.Or maybe I will just decide that 4.14 was a painful release, and anylate stragglers for 4.15 are not worth _another_ painful release, andI'll just say "tough luck, you were late to the merge window, and Ifelt more like being out in the sun than taking your second-week pullrequest".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 thenext LTS kernel - and start sending me pull request for the 4.15 mergewindow.                Linus