https://lkml.org/lkml/2018/1/23/25
It looks like Ingo Molnar, Andi Kleen, and others are coming up with a pure-software alternative to IBRS, which could be much faster (rather similar in spirit to the retpoline trick)
Leverage CONFIG_DYNAMIC_FTRACE. This is an OS only fix resulting in effectively zero overhead for chips other than Skylake.
https://lkml.org/lkml/2018/1/23/25
There's another possible method to avoid deep stacks on Skylake, without
compiler support:
- Use the existing mcount based function tracing live patching machinery
(CONFIG_FUNCTION_TRACER=y) to install a _very_ fast and simple stack depth
tracking tracer which would issue a retpoline when stack depth crosses
boundaries of ~16 entries.
The overhead of that would _still_ very likely be much cheaper than a hundreds
(thousands) of cycle expensive MSR write at every kernel entry
(syscall entry, IRQ entry, etc.).
In this case, old processors simply does not predict the jump and stalls. But Skylake instead uses the generic indirect branch predictor, since after all RET is an indirect branch! Except the idea behind retpolines was to avoid the generic branch predictor, and now every single RET can use it! So, if you don't want to use IBRS you need to find a different way to protect the kernel from someone forcing undesired speculative execution after the RET.
Is AMD similar to Intel pre-Skylake, for the purpose of Spectre mitigation?
Could Intel and OEMs restart sales of Broadwell hardware, until they can reverse the Skylake/KabyLake/KabyLakeRefresh changes (in Cannon Lake? Ice Lake)?
This isn't a general fix or "pure-software alternative to IBRS" - it is specific to handling the 16 stack depth ret being vulnerable on skylake+ processors, as it falls back to an indirect branch prediction. The zero overhead for non-skylake+ chips isn't that it is a zero-overhead general IBRS solution, it's that it does not incur additional overhead on non-skylake+ chips as it is not doing any work to mitigate the issue on non-skylake chips.
This is because all of the major distros already compile their kernels with the CONFIG_FUNCTION_TRACER=y option set, so no additional work is being done unless the conditions appear and it is on a skylake+ chip.
I've always found it really frustrating that lkml.org seems to be the canonical web link that comes up for kernel mailing list discussions because of this, as I really find the threading there frustrating; it's nearly impossible to determine whether you've read the entire (sub-)thread.
Back when Gmane was alive I usually gravitated there as an alternative.
Suggestions (or working links to what you like better) are welcome!
In particular I'd like to be able to, starting with a particular post, repeatedly hit "next" and be assured that once I hit the next sibling post to the original I've read that entire subthread. Gmane let you do this just by whacking the space bar; if you weren't at the bottom of a post it would page down, if you were it would go to the next one.
In other words I'd like it to behave as much like a good NNTP newsreader as possible.
That's lost technology from the golden age of our ancestors, who were so much greater than any of us now ;-)
Today this innovation has moved to the myriad of proprietary alternatives (like Slack or our very own HN) but they are closed worlds so not only can nobody create a new client, we also loose all the contents if the company dies (which isn't rare).
--grumpy greybeard
there is plenty of active usenet groups, comp.arch being one of the best places where the greybeards meet.
I just tried again, still didn't show any children. Then I did a force-refresh. Now it shows them ...
So due to past terrible performance of lkml.org, it had aggressive long-term caching. So since I happened to see this message a couple days ago, it wasn't showing a newer version of the reply tree for me, I only found them in the top-messages list on the lkml.org main page.