Re: [PATCH v6 1/9] x86/bhi: x86/vmscape: Move LFENCE out of clear_bhb_loop()

[Borislav Petkov]

On Mon, Dec 01, 2025 at 10:18:59PM -0800, Pawan Gupta wrote:
> In preparation for adding the support for BHB sequence (without LFENCE) on
> newer CPUs, move the LFENCE to the caller side after clear_bhb_loop() is
> executed. This allows callers to decide whether they need the LFENCE or

s/This allows/Allow/

> not. This does adds a few extra bytes to the call sites, but it obviates

s/This does adds/This adds/

> diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
> index ed04a968cc7d0095ab0185b2e3b5beffb7680afd..886f86790b4467347031bc27d3d761d5cc286da1 100644
> --- a/arch/x86/entry/entry_64.S
> +++ b/arch/x86/entry/entry_64.S
> @@ -1528,6 +1528,9 @@ SYM_CODE_END(rewind_stack_and_make_dead)
>   * refactored in the future if needed. The .skips are for safety, to ensure
>   * that all RETs are in the second half of a cacheline to mitigate Indirect
>   * Target Selection, rather than taking the slowpath via its_return_thunk.
> + *
> + * Note, callers should use a speculation barrier like LFENCE immediately after
> + * a call to this function to ensure BHB is cleared before indirect branches.
>   */

Comments do get missed. So, I'd call the function clear_bhb_loop_unfenced or
something to that effect so that it is perfectly clear that !BHI_DIS_S parts
will need the LFENCE at the end. This way it is in the name and should make
people think what they're calling. I'd hope...

>  SYM_FUNC_START(clear_bhb_loop)
>  	ANNOTATE_NOENDBR

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette