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
