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