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

From: Mike Rapoport

Date: Tue Jul 28 2026 - 12:57:57 EST


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.