Re: [PATCHv7 03/16] x86/alternatives: Disable LASS when patching kernel alternatives

[Kirill A. Shutemov]

On Thu, Jun 26, 2025 at 07:18:59AM -0700, Dave Hansen wrote:
> On 6/26/25 06:49, Peter Zijlstra wrote:
> >> +static __always_inline void lass_enable_enforcement(void)
> >> +{
> >> +	alternative("", "clac", X86_FEATURE_LASS);
> >> +}
> >> +
> >> +static __always_inline void lass_disable_enforcement(void)
> >> +{
> >> +	alternative("", "stac", X86_FEATURE_LASS);
> >> +}
> > Much hate for this naming. WTH was wrong with lass_{clac,stac}()?
> > 
> > We're not calling those other functions smap_{en,dis}able_enforcement()
> > either (and please don't take that as a suggestion, its terrible
> > naming).
> 
> It was a response to a comment from Sohil about the delta between
> lass_{cl,st}ac() and plain {cl,st}ac() being subtle. They are subtle,
> but I don't think it's fixable with naming.
> 
> There are lots of crazy gymnastics we could do. But there are so few
> sites where AC is twiddled for LASS that I don't think it's worth it.
> 
> Let's just use the lass_{cl,st}ac() and comment both variants. First,
> the existing stac()/clac():
> 
> /*
>  * Use these when accessing userspace (_PAGE_USER)
>  * mappings, regardless of location.
>  */
> 
> and the new ones:
> 
> /*
>  * Use these when accessing kernel mappings (!_PAGE_USER)
>  * in the lower half of the address space.
>  */
> 
> Any objections to doing that?

Looks good. Will update the patch.

-- 
  Kiryl Shutsemau / Kirill A. Shutemov