4:55 a.m.
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(a)intel.com> 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/commi...
> 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(a)intel.com>
>
> 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)
{