Re: [PATCH] x86/mm: Define the zapped-entry checks only with CONFIG_DEBUG_VM

[Kiryl Shutsemau <kas@kernel.org>]

On Mon, Nov 02, 2026 at 04:53:17PM +0000, Edgecombe, Rick P wrote:
> Do you happen to know if this performance impact is relevant at all in the non
> Safe RET case?

Yes, both sides of the comparison are the same kernel with Safe RET on,
with and without the patch.

Without Safe RET (spec_rstack_overflow=off, same two kernels) the call
and return predict fine: branch misses are the same with and without the
patch, and the gain is under 2%, within noise.

> > diff --git a/arch/x86/mm/pgtable.c b/arch/x86/mm/pgtable.c
> > index 4a105f283cfb..3352bc6904f3 100644
> > --- a/arch/x86/mm/pgtable.c
> > +++ b/arch/x86/mm/pgtable.c
> > @@ -798,6 +798,7 @@ pmd_t pmd_mkwrite(pmd_t pmd, struct vm_area_struct *vma)
> >  	return pmd_clear_saveddirty(pmd);
> >  }
> >  
> > +#ifdef CONFIG_DEBUG_VM
> >  void arch_check_zapped_pte(struct vm_area_struct *vma, pte_t pte)
> >  {
> >  	/*
> > @@ -823,3 +824,4 @@ void arch_check_zapped_pud(struct vm_area_struct *vma,
> > pud_t pud)
> >  	/* See note in arch_check_zapped_pte() */
> >  	VM_WARN_ON_ONCE(!(vma->vm_flags & VM_SHADOW_STACK) &&
> > pud_shstk(pud));
> 
> I guess all of these don't need to be the "VM_WARN_" varieties if they are
> compiled out in the other case.

I can do either way. It is functionally equivalent.

-- 
  Kiryl Shutsemau / Kirill A. Shutemov