Re: [akpm-mm:mm-unstable 115/141] mm/gup.c:536:29: error: implicit declaration of function 'pud_pfn'; did you mean 'pmd_pfn'?

[Peter Xu <peterx@redhat.com>]

On Sat, Mar 23, 2024 at 03:12:08PM +0800, kernel test robot wrote:
> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-unstable
> head:   af520f81c51001f7ccdf0579fc73df282b26292d
> commit: 529f3b89b7333564792458ca7be06f5bff258d23 [115/141] mm/gup: handle huge pud for follow_pud_mask()
> config: sh-defconfig (https://download.01.org/0day-ci/archive/20240323/202403231529.HRev1zcD-lkp@intel.com/config)
> compiler: sh4-linux-gcc (GCC) 13.2.0
> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240323/202403231529.HRev1zcD-lkp@intel.com/reproduce)
> 
> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot <lkp@intel.com>
> | Closes: https://lore.kernel.org/oe-kbuild-all/202403231529.HRev1zcD-lkp@intel.com/
> 
> All errors (new ones prefixed by >>):
> 
>    mm/gup.c: In function 'follow_huge_pud':
> >> mm/gup.c:536:29: error: implicit declaration of function 'pud_pfn'; did you mean 'pmd_pfn'? [-Werror=implicit-function-declaration]
>      536 |         unsigned long pfn = pud_pfn(pud);
>          |                             ^~~~~~~
>          |                             pmd_pfn
>    cc1: some warnings being treated as errors

This is a HUGETLB_PAGE && !THP setup, where on SH there's no huge mappings
at all, actually it seems to only use a similar cont ptes concept.. which I
didn't notice before.

We should have tackled similar issue with pmd_pfn() in 2022, where
7106c51ee9a1 ("arch: Add pmd_pfn() where it is missing") defined pmd_pfn
for all archs.

Instead of doing that (archs using pud_pfn is still not much; defining it
all across sounds like an overkill), and instead of providing a fixup
patch, I think it'll make more sense I provide a standalone patch to
provide pud_pfn() globally with a fallback.  Ideally such patch can be put
before this problematic commit if we care about per-commit compilations.

I'll post a formal patch soon.

-- 
Peter Xu