Re: [PATCH RFC v2 12/20] x86: mm: define pudp_set_access_flags() when CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD is enabled only.

On Mon, Jul 27, 2026 at 05:02:00PM +0200, David Hildenbrand (Arm) wrote:
> On 7/22/26 19:27, Yeoreum Yun wrote:
> > Hi Dave,
> > 
> >>> diff --git a/arch/x86/mm/pgtable.c b/arch/x86/mm/pgtable.c
> >>> index f32facdb3035..edad847a2ecd 100644
> >>> --- a/arch/x86/mm/pgtable.c
> >>> +++ b/arch/x86/mm/pgtable.c
> >>> @@ -411,6 +411,7 @@ int pmdp_set_access_flags(struct vm_area_struct *vma,
> >>>  	return changed;
> >>>  }
> >>>  
> >>> +#ifdef CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD
> >>>  int pudp_set_access_flags(struct vm_area_struct *vma, unsigned long address,
> >>>  			  pud_t *pudp, pud_t entry, int dirty)
> >>>  {
> >>> @@ -430,6 +431,7 @@ int pudp_set_access_flags(struct vm_area_struct *vma, unsigned long address,
> >>>  
> >>>  	return changed;
> >>>  }
> >>> +#endif /* CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD */
> >>>  #endif
> >>>  
> >>>  bool ptep_test_and_clear_young(struct vm_area_struct *vma,
> >>
> >> #ifdefs in .c files are evil.
> >>
> >> The changelog doesn't make a strong enough case for why this evil should
> >> be tolerated.
> >>
> >> These are also _precisely_ the kind of #ifdefs that cause compilation
> >> problems. This one is:
> >>
> >> #ifdef CONFIG_TRANSPARENT_HUGEPAGE
> >> /// function here
> >> #ifdef CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD
> >> /// another function here
> >> #endif
> >> #endif
> >>
> >> So there end up being a couple of dependent config options in play. If
> >> there are compile problems, this makes them harder to find.
> >>
> >> What is the _actual_ goal here? Saving 50 bytes of kernel text?
> > 
> > TBH, this came from for v1's change of behavior set_pud() where
> > triggered compiliation problem with v2 this change wouldn't require.
> 
> If the patch is not required right now, let's drop it.
> 
> I agree that it's the right thing to do: just look at pudp_invalidate() in the
> very same file, but if we can reduce the churn and leave the cleanups to x86
> folks, that seems to be preferred.

Yes. I'll drop in next version.

-- 
Sincerely,
Yeoreum Yun

_______________________________________________
linux-riscv mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-riscv