On Mon, 2018-02-12 at 16:04 -0800, Andi Kleen wrote: > From: Andi Kleen <a...@linux.intel.com> > > An earlier patch moved the RSB filling out of line, ending > it with a return. This results in the return buffer filling > only giving 15 instead of 16 usable returns because > the return from fill_rsb already uses one up. > > Since the kernel call chains can be quite deep that's > somewhat dangerous and better avoided.
This only matters for Skylake, right? In conjunction with the call depth counting stuff that Ingo and Thomas looked at and seem to have given up on? On non-Skylake we don't care about underflow, and all that matters is that we get rid of any *bogus* entries in the RSB? However... that was supposed to be a 'clear RSB' operation, with 32 CALLs in sequence. And Boris changed it to 16 by calling __fill_rsb() instead of __clear_rsb(): - asm volatile (ANNOTATE_NOSPEC_ALTERNATIVE - ALTERNATIVE("jmp 910f", - __stringify(__FILL_RETURN_BUFFER(%0, RSB_CLEAR_LOOPS, %1)), - X86_FEATURE_RETPOLINE) - "910:" - : "=r" (loops), ASM_CALL_CONSTRAINT - : : "memory" ); + alternative_input("", + "call __fill_rsb", + X86_FEATURE_RETPOLINE, + ASM_NO_INPUT_CLOBBER(_ASM_BX, "memory")); I think we do need to revert that patch. And perhaps stop accepting any more similar bikeshedding.
Description: S/MIME cryptographic signature