Re: [PATCH 1/5] x86/mm/pat: introcude cpa_lock() and cpa_unlock()

On Tue, Jul 28, 2026 at 05:16:33PM +0200, Peter Zijlstra wrote:
> On Tue, Jul 28, 2026 at 04:07:44PM +0300, Mike Rapoport (Microsoft) wrote:
> 
> >  arch/x86/mm/pat/set_memory.c | 33 +++++++++++++++++++++++++--------
> >  1 file changed, 25 insertions(+), 8 deletions(-)
> > 
> > diff --git a/arch/x86/mm/pat/set_memory.c b/arch/x86/mm/pat/set_memory.c
> > index b1e780a465b5..4c8922695fd3 100644
> > --- a/arch/x86/mm/pat/set_memory.c
> > +++ b/arch/x86/mm/pat/set_memory.c
> > @@ -65,8 +65,25 @@ static const int cpa_warn_level = CPA_PROTECT;
> >   * Serialize cpa() using cpa_lock so that we don't allow any other cpu, with
> >   * stale large tlb entries, to change the page attribute in parallel to some
> >   * other cpu splitting a large page entry along with changing the attribute.
> > + *
> > + * When debug_pagealloc_enabled(), page attributes could be changed in atomic
> > + * context that would warrant disabling IRQs. But since debug_pagealloc always
> > + * uses 4k pages in the direct map there are no races for splits and collapses
> > + * and locking can be just skipped altogether.
> >   */
> > -static DEFINE_SPINLOCK(cpa_lock);
> > +static DEFINE_SPINLOCK(_cpa_lock);
> > +
> > +static inline void cpa_lock(void)
> > +{
> > +	if (!debug_pagealloc_enabled())
> > +		spin_lock(&_cpa_lock);
> > +}
> > +
> > +static inline void cpa_unlock(void)
> > +{
> > +	if (!debug_pagealloc_enabled())
> > +		spin_unlock(&_cpa_lock);
> > +}
> 
> If this lives, we should probably stick an assertion in both the split
> and alloc cases for holding _cpa_lock. That debug thing seems to rely on
> never hitting those, but having that be implicit is asking for pain.

I'd rather stick an assert for !debug_pagealloc_enabled() there.

-- 
Sincerely yours,
Mike.