linux 4 内核 新特性,Linux内核4.14发布：快来看看Linus的总结和超多新特性

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.

Linus