Re: [PATCH v7 03/10] x86/bhi: Rename clear_bhb_loop() to clear_bhb_loop_nofence()

[Pawan Gupta]

On Mon, Mar 23, 2026 at 04:44:24PM +0200, Nikolay Borisov wrote:
> 
> 
> On 19.03.26 г. 17:40 ч., Pawan Gupta wrote:
> > To reflect the recent change that moved LFENCE to the caller side.
> > 
> > Suggested-by: Borislav Petkov <bp@xxxxxxxxx>
> > Signed-off-by: Pawan Gupta <pawan.kumar.gupta@xxxxxxxxxxxxxxx>
> 
> 
> Nit: I think having the _nofence in the function name is leaking an
> implementation detail into the name/interface. I.e things change and we
> decide that the implementation of a particular function must change so we
> just do the change and substantiate it in the commit message or in a
> comment. Especially that we don't have a "with an lfence" version.

The explicit "_nofence" is because the series changes the implementation of
clear_bhb_loop() from lfence. If new call sites miss to add an lfence when
it is required could lead to a security issue. Having the "_nofence" in the
name helps avoid it.

Apart from the name, the commit message of patch 1/10 and the comment in
clear_bhb_loop() implementation covers this.

> What's more I'd consider this a "private" function, that's called via the
> CLEAR_BRANCH_HISTORY macros, the only place it's called directly is in the
> bpf jit code, but that's more of an exception.

Another place where the explicit "_nofence" in the name could help is while
applying the mitigation in vmscape_apply_mitigation(), which sets the
static call:

vmscape_apply_mitigation()
{
...
    if (vmscape_mitigation == VMSCAPE_MITIGATION_IBPB_EXIT_TO_USER)
        static_call_update(vmscape_predictor_flush, write_ibpb);
    else if (vmscape_mitigation == VMSCAPE_MITIGATION_BHB_CLEAR_EXIT_TO_USER)
        static_call_update(vmscape_predictor_flush, clear_bhb_loop_nofence);

> Still,
> 
> Reviewed-by: Nikolay Borisov <nik.borisov@xxxxxxxx>

Thank you.