On Sat, Jul 22, 2017 at 01:49:23PM +1000, Oliver wrote:
> On Sat, Jul 22, 2017 at 9:13 AM, Andrew Morton
> <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
> > On Mon, 26 Jun 2017 16:38:33 +1000 "Oliver O'Halloran" <oohall@xxxxxxxxx> wrote:
> >
> >> These functions are the only bits of generic code that use
> >> {pud,pmd}_pfn() without checking for CONFIG_TRANSPARENT_HUGEPAGE.
> >> This works fine on x86, the only arch with devmap support, since the
> >> *_pfn() functions are always defined there, but this isn't true for
> >> every architecture.
> >>
> >> Signed-off-by: Oliver O'Halloran <oohall@xxxxxxxxx>
> >> ---
> >> mm/gup.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/mm/gup.c b/mm/gup.c
> >> index d9e6fddcc51f..04cf79291321 100644
> >> --- a/mm/gup.c
> >> +++ b/mm/gup.c
> >> @@ -1287,7 +1287,7 @@ static int gup_pte_range(pmd_t pmd, unsigned long addr, unsigned long end,
> >> }
> >> #endif /* __HAVE_ARCH_PTE_SPECIAL */
> >>
> >> -#ifdef __HAVE_ARCH_PTE_DEVMAP
> >> +#if defined(__HAVE_ARCH_PTE_DEVMAP) && defined(CONFIG_TRANSPARENT_HUGEPAGE)
> >> static int __gup_device_huge(unsigned long pfn, unsigned long addr,
> >> unsigned long end, struct page **pages, int *nr)
> >> {
> >
> > (cc Kirill)
> >
> > Please provide a full description of the bug which is being fixed. I
> > assume it's a build error. What are the error messages and under what
> > circumstances.
> >
> > Etcetera. Enough info for me (and others) to decide which kernel
> > version(s) need the fix.
>
> It fixes a build breakage that you will only ever see when enabling
> the devmap pte bit for another architecture. Given it requires new
> code to hit the bug I don't see much point in backporting it to 4.12,
> but taking it as a fix for 4.13 wouldn't hurt.
>
> The root problem is that the arch doesn't need to provide pmd_pfn()
> and friends when THP is disabled. They're provided unconditionally by
> x86 and ppc, but I did a cursory check and found that mips only
> defines pmd_pfn() when THP is enabled so I figured this should be
> fixed. Making each arch provide them unconditionally might be a better
> idea, but that seemed like it'd be a lot of churn for a minor bug.
This makes sense to me.
Assuming updated commit message,
Acked-by: Kirill A. Shutemov <kirill.shutemov@xxxxxxxxxxxxxxx>
--
Kirill A. Shutemov
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
