TL,DR;

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.).

Pretty damn cool if it works.

I think there's some misunderstanding in this discussion thread on what Ingo is working on.

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.

What do we want for post-Kaby Lake systems? Should Intel return future hardware to pre-Skylake behavior?

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)?

I couldn't find much about this 16 entries stack depth issue. Does anyone have more information?

It's explained in the thread. Basically, the RET instruction has its own tiny branch predictor, the return address stack (also known as RSB) which is only 16 or 32 entries deep. If your call stack is deeper than that, sooner or later the stack becomes empty.

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.

RSB! Thank you, now I know what to focus on.

as a skylake user I hope I'll be able to turn those protections off

It is linked at the left of the screen where it says "Messages in this thread"

For me, when I click the link in TFA, that message is shown as the last message in the tree, with no children.

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.

Semi off-topic: What is up with the lkml.org threading interface and why is it so ridiculously inconsistent?

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.

lkml.org owner here; let me explain the current behaviour: If available, it shows you the grandparent message and all its descendants for up to four levels (so n-2 to n+2), and if you navigate to another message it will just do that again - which means that the whole tree will change.

Suggestions (or working links to what you like better) are welcome!

A simple enhancement would be to show (for instance with "...") if there are more levels, that is, if there's a n-3 or n+3, put a ... where it would be. That would make it at least a little bit easier to navigate, by making it explicit when you're seeing an incomplete view of the thread.

Personally I would like some way to navigate through the whole thread in some sort of reasonable order. My preference would be depth-first with the leaves sorted by the most recent post /in that subtree/. This matches how tools like newsreaders and Mutt will sort threads, and I believe how Gmane worked as well. (Though I will admit that for something like a web site that does not keep the state of whether posts are read or not, reordering leaves like that may be confusing. In a tool like Mutt it is useful behavior as when new posts come in they will naturally gravitate to the bottom [or top, depending on your sort order] of your message list).

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.

> like a good NNTP newsreader

That's lost technology from the golden age of our ancestors, who were so much greater than any of us now ;-)

I can't tell if you are being sarcastic, but because the format and transport were fixed, it enabled the creation of many clients, some of which had some incredible useful innovations.

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

it's not lost - it's just not in the spotlight due to these young person's webs.. facebook, twatter or whatever .)

there is plenty of active usenet groups, comp.arch being one of the best places where the greybeards meet.

How about just show the whole thread? If it is a huge thread, so be it, we want to know.

As I just noted above, my problem was apparently with caching. I saw the message linked in TFA a couple days ago, when it had no replies yet. Multiple days later, I still saw it as having no replies, until I force-refreshed.

Something like google groups will be great. You can expand/see all replies though not in threaded mode (just linear).

Sounds like you didn't read Andi's reply.