On Wed, 12 May 2021, Axel Rasmussen wrote: > Andrew, the straightforward fix is just to drop this commit, which is > currently in the mm tree (not in v5.13-rc1): Yes, that's easiest. > > 09ff184a3eb1c9 userfaultfd/hugetlbfs: avoid including userfaultfd_k.h > in hugetlb.h > > (Happy to send a revert patch, but I suspect it's easier for you to > drop than to revert + squash later?) > > Adding Hugh as well, since he suggested this cleanup and might prefer > doing something else instead. Yes, sorry for dropping you in it. > > On Wed, May 12, 2021 at 7:45 AM kernel test robot <lkp@xxxxxxxxx> wrote: > > > > tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master > > head: ec85c95b0c90a17413901b018e8ade7b9eae7cad > > commit: 09ff184a3eb1c9cb42f64325ca4a51e36206f4f5 [2078/2633] userfaultfd/hugetlbfs: avoid including userfaultfd_k.h in hugetlb.h > > config: s390-randconfig-r023-20210512 (attached as .config) > > compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project a0fed635fe1701470062495a6ffee1c608f3f1bc) > > reproduce (this is a W=1 build): > > wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross > > chmod +x ~/bin/make.cross > > # install s390 cross compiling tool for clang build I was puzzled, thinking it was something special to s390 or to clang; until noticing that it says s390-randconfig above. > > # apt-get install binutils-s390x-linux-gnu > > # https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=09ff184a3eb1c9cb42f64325ca4a51e36206f4f5 > > git remote add linux-next https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git > > git fetch --no-tags linux-next master > > git checkout 09ff184a3eb1c9cb42f64325ca4a51e36206f4f5 > > # save the attached .config to linux build tree > > COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 ARCH=s390 > > > > If you fix the issue, kindly add following tag as appropriate > > Reported-by: kernel test robot <lkp@xxxxxxxxx> > > > > All errors (new ones prefixed by >>): > > > > In file included from arch/s390/mm/fault.c:33: > > >> include/linux/hugetlb.h:340:30: error: variable has incomplete type 'enum mcopy_atomic_mode' > > enum mcopy_atomic_mode mode, > > ^ > > include/linux/hugetlb.h:18:6: note: forward declaration of 'enum mcopy_atomic_mode' > > enum mcopy_atomic_mode; > > ^ And line 340 is not the first, usual use of mcopy_atomic_mode in hugetlb.h, but its use in the CONFIG_USERFAULTFD=y CONFIG_HUGETLB_PAGE=n static inline stub. Right, the compiler would probably want to compile that before optimizing it away; and want to know more about the enum to do so. My actual preference would be to keep the "enum mcopy_atomic_mode;" patch, and fix it with the patch below: since the only call to hugetlb_mcopy_atomic_pte() is under #ifdef CONFIG_HUGETLB_PAGE anyway. But since I have not even tried building with this patch on x86_64 gcc, in any configuration at all, I expect you all to be rather wary of my suggestions by now, and prefer to just drop the troublesome patch. But in case anyone is tempted, now or later, --- mmotm/include/linux/hugetlb.h 2021-05-11 08:33:39.987553392 -0700 +++ linux/include/linux/hugetlb.h 2021-05-12 11:20:52.385063935 -0700 @@ -331,20 +331,6 @@ static inline void hugetlb_free_pgd_rang BUG(); } -#ifdef CONFIG_USERFAULTFD -static inline int hugetlb_mcopy_atomic_pte(struct mm_struct *dst_mm, - pte_t *dst_pte, - struct vm_area_struct *dst_vma, - unsigned long dst_addr, - unsigned long src_addr, - enum mcopy_atomic_mode mode, - struct page **pagep) -{ - BUG(); - return 0; -} -#endif /* CONFIG_USERFAULTFD */ - static inline pte_t *huge_pte_offset(struct mm_struct *mm, unsigned long addr, unsigned long sz) {
