Re: [linux-next:master] BUILD REGRESSION 10207e3a840b47b5eae573486a88fb6e29884f77

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 10 Feb 2022 11:09:55 +1100 Alistair Popple <apopple@xxxxxxxxxx> wrote:

> On Thursday, 10 February 2022 6:34:46 AM AEDT Andrew Morton wrote:
> > On Thu, 10 Feb 2022 02:51:05 +0800 kernel test robot <lkp@xxxxxxxxx> wrote:
> > 
> > > tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> > > branch HEAD: 10207e3a840b47b5eae573486a88fb6e29884f77  Add linux-next specific files for 20220209
> > > 
> > > Error/Warning reports:
> > > 
> > > https://lore.kernel.org/linux-mm/202201251833.Hon4gcuF-lkp@xxxxxxxxx
> > > https://lore.kernel.org/linux-mm/202201290705.x0MS0OCH-lkp@xxxxxxxxx
> > > https://lore.kernel.org/llvm/202202092059.9gegO2oq-lkp@xxxxxxxxx
> > >
> > > ...
> > >
> > > ld: gup.c:(.text+0x1eff): undefined reference to `migrate_vma_pages'
> > > ld: gup.c:(.text+0x1f44): undefined reference to `migrate_vma_finalize'
> > 
> > Presumably CONFIG_MIGRATION=y, CONFIG_DEVICE_PRIVATE=n, so these
> > functions aren't built.
> > 
> > Methinks Alistair's "mm/gup.c: migrate device coherent pages when
> > pinning instead of failing" needs some repair, please.
> 
> Yes, that's the cause. The fix[1] from SeongJae looks correct.

Yup.

> What's easier
> for you - taking that fix or me posting a v3 of my series including that now?
> 
> [1] - https://lore.kernel.org/linux-mm/20220209094158.21941-3-sj@xxxxxxxxxx/
> 

Grabbing the little fixup is much simpler and easier, thanks.




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux