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

["Edgecombe, Rick P" <rick.p.edgecombe@intel.com>]

On Mon, 2026-11-02 at 17:32 +0000, Kiryl Shutsemau wrote:
> 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.

Hmm, I'd wonder if the fixes tag is appropriate then. Should it be the safe ret
commits?

> 
> > > 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.

Otherwise it's effectively a duplicate check.