Re: [linux-next:master 2078/2633] include/linux/hugetlb.h:340:30: error: variable has incomplete type 'enum mcopy_atomic_mode'

[Axel Rasmussen <axelrasmussen@google.com>]

On Wed, May 12, 2021 at 11:56 AM Hugh Dickins <hughd@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@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/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@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)
>  {