On Wed, May 12, 2021 at 11:56 AM Hugh Dickins <hughd(a)google.com> wrote:
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,
Yeah, I would want to do some more testing first on various compilers
and things. My understanding is that the C standard says enums may be
as small as a char or as big as an int depending on the value(s) they
can have, so with just a forward declaration we can't know the size
which I think is needed even for just a function signature. But, GCC
seems to do something to make this "work" (at least without
-pedantic).
Another small cleanup I'd like to do is, after our other code review,
I think "enum mcopy_atomic_mode" should rather be named "enum
mfill_atomic_mode" - since Andrea intended "mcopy" to refer
specifically to copy_from_user, and "mfill" to refer to the more
general operation. So, I think we drop this patch for now, and I'll
keep this in mind for some future cleanup series.
>
> --- 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)
> {