On Wed, Mar 19, 2025 at 06:46:35PM -0400, Peter Xu wrote: > On Wed, Mar 19, 2025 at 04:22:04PM -0600, Keith Busch wrote: > > On Mon, Aug 26, 2024 at 04:43:52PM -0400, Peter Xu wrote: > > > +#ifdef CONFIG_ARCH_SUPPORTS_PUD_PFNMAP > > > +#define pud_special(pte) pte_special(pud_pte(pud)) > > > +#define pud_mkspecial(pte) pte_pud(pte_mkspecial(pud_pte(pud))) > > > +#endif > > > > Sorry for such a late reply, but this looked a bit weird as I'm doing > > some backporting. Not that I'm actually interested in this arch, so I > > can't readily test this, but I believe the intention was to name the > > macro argument "pud", not "pte". > > Probably no way to test it from anyone yet, as I don't see aarch64 selects > HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD, which means IIUC this two lines (before > PUD being enabled on aarch64) won't be compiled.. which also matches with > the test results in the cover letter, that we only tried pmd on arm. > > The patch will still be needed though for pmd to work. > > I can draft a patch to change this, but considering arm's PUD support isn't > there anyway.. maybe I should instead draft a change to remove these as > they're dead code so far, and see if anyone would like to collect it. > > Thanks for reporting this. I'll prepare something soon and keep you > posted. Thanks, good to know it wasn't reachable. The reason I was conerned is because the only caller, insert_pfn_pud(), just so happens to have a variable named "pud" in scope, but it's not the pud passed into the macro. So if this macro was used, it would just so happen to compile by that coincidence, but its using the wrong pud.
