[PATCH] include/linux/hugetlb.h: Convert to use vm_fault_t

[PATCH] include/linux/hugetlb.h: Convert to use vm_fault_t

[Souptick Joarder]

kbuild produces the below warning ->

tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
head:   5453a3df2a5eb49bc24615d4cf0d66b2aae05e5f
commit 3d3539018d2c ("mm: create the new vm_fault_t type")
reproduce:
        # apt-get install sparse
        git checkout 3d3539018d2cbd12e5af4a132636ee7fd8d43ef0
        make ARCH=x86_64 allmodconfig
        make C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__'

>> mm/memory.c:3968:21: sparse: incorrect type in assignment (different
>> base types) @@    expected restricted vm_fault_t [usertype] ret @@
>> got e] ret @@
   mm/memory.c:3968:21:    expected restricted vm_fault_t [usertype] ret
   mm/memory.c:3968:21:    got int

This patch will convert to return vm_fault_t type for hugetlb_fault()
when CONFIG_HUGETLB_PAGE =n.

Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com>
---
 include/linux/hugetlb.h | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index 087fd5f4..0ee502a 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -203,7 +203,6 @@ static inline void hugetlb_show_meminfo(void)
 #define pud_huge(x)	0
 #define is_hugepage_only_range(mm, addr, len)	0
 #define hugetlb_free_pgd_range(tlb, addr, end, floor, ceiling) ({BUG(); 0; })
-#define hugetlb_fault(mm, vma, addr, flags)	({ BUG(); 0; })
 #define hugetlb_mcopy_atomic_pte(dst_mm, dst_pte, dst_vma, dst_addr, \
 				src_addr, pagep)	({ BUG(); 0; })
 #define huge_pte_offset(mm, address, sz)	0
@@ -234,6 +233,13 @@ static inline void __unmap_hugepage_range(struct mmu_gather *tlb,
 {
 	BUG();
 }
+static inline vm_fault_t hugetlb_fault(struct mm_struct *mm,
+				struct vm_area_struct *vma, unsigned long address,
+				unsigned int flags)
+{
+	BUG();
+	return 0;
+}
 
 #endif /* !CONFIG_HUGETLB_PAGE */
 /*
-- 
1.9.1

Re: [PATCH] include/linux/hugetlb.h: Convert to use vm_fault_t

[Mike Kravetz]

On 3/18/19 9:26 AM, Souptick Joarder wrote:
> kbuild produces the below warning ->
> 
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> head:   5453a3df2a5eb49bc24615d4cf0d66b2aae05e5f
> commit 3d3539018d2c ("mm: create the new vm_fault_t type")
> reproduce:
>         # apt-get install sparse
>         git checkout 3d3539018d2cbd12e5af4a132636ee7fd8d43ef0
>         make ARCH=x86_64 allmodconfig
>         make C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__'
> 
>>> mm/memory.c:3968:21: sparse: incorrect type in assignment (different
>>> base types) @@    expected restricted vm_fault_t [usertype] ret @@
>>> got e] ret @@
>    mm/memory.c:3968:21:    expected restricted vm_fault_t [usertype] ret
>    mm/memory.c:3968:21:    got int
> 
> This patch will convert to return vm_fault_t type for hugetlb_fault()
> when CONFIG_HUGETLB_PAGE =n.
> 
> Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com>

Thanks for fixing this.

The BUG() here and in several other places in this file is unnecessary
and IMO should be cleaned up.  But that is beyond the scope of this fix.
Added to my to do list.

Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
-- 
Mike Kravetz

Re: [PATCH] include/linux/hugetlb.h: Convert to use vm_fault_t

[Souptick Joarder]

On Tue, Mar 19, 2019 at 5:47 AM Mike Kravetz <mike.kravetz@oracle.com> wrote:
>
>
> On 3/18/19 9:26 AM, Souptick Joarder wrote:
> > kbuild produces the below warning ->
> >
> > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> > head:   5453a3df2a5eb49bc24615d4cf0d66b2aae05e5f
> > commit 3d3539018d2c ("mm: create the new vm_fault_t type")
> > reproduce:
> >         # apt-get install sparse
> >         git checkout 3d3539018d2cbd12e5af4a132636ee7fd8d43ef0
> >         make ARCH=x86_64 allmodconfig
> >         make C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__'
> >
> >>> mm/memory.c:3968:21: sparse: incorrect type in assignment (different
> >>> base types) @@    expected restricted vm_fault_t [usertype] ret @@
> >>> got e] ret @@
> >    mm/memory.c:3968:21:    expected restricted vm_fault_t [usertype] ret
> >    mm/memory.c:3968:21:    got int
> >
> > This patch will convert to return vm_fault_t type for hugetlb_fault()
> > when CONFIG_HUGETLB_PAGE =n.
> >
> > Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com>
>
> Thanks for fixing this.
>
> The BUG() here and in several other places in this file is unnecessary
> and IMO should be cleaned up.  But that is beyond the scope of this fix.
> Added to my to do list.

I can clean it up if you are fine ;-)
>
> Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
> --
> Mike Kravetz

Re: [PATCH] include/linux/hugetlb.h: Convert to use vm_fault_t

[Matthew Wilcox]

On Mon, Mar 18, 2019 at 09:56:05PM +0530, Souptick Joarder wrote:
> >> mm/memory.c:3968:21: sparse: incorrect type in assignment (different
> >> base types) @@    expected restricted vm_fault_t [usertype] ret @@
> >> got e] ret @@
>    mm/memory.c:3968:21:    expected restricted vm_fault_t [usertype] ret
>    mm/memory.c:3968:21:    got int

I think this may be a sparse bug.

Compare:

+++ b/mm/memory.c
@@ -3964,6 +3964,9 @@ vm_fault_t handle_mm_fault(struct vm_area_struct *vma, unsigned long address,
        if (flags & FAULT_FLAG_USER)
                mem_cgroup_enter_user_fault();
 
+       ret = 0;
+       ret = ({ BUG(); 0; });
+       ret = 1;
        if (unlikely(is_vm_hugetlb_page(vma)))
                ret = hugetlb_fault(vma->vm_mm, vma, address, flags);
        else

../mm/memory.c:3968:13: sparse: warning: incorrect type in assignment (different base types)
../mm/memory.c:3968:13: sparse:    expected restricted vm_fault_t [assigned] [usertype] ret
../mm/memory.c:3968:13: sparse:    got int
../mm/memory.c:3969:13: sparse: warning: incorrect type in assignment (different base types)
../mm/memory.c:3969:13: sparse:    expected restricted vm_fault_t [assigned] [usertype] ret
../mm/memory.c:3969:13: sparse:    got int

vm_fault_t is __bitwise:

include/linux/mm_types.h:typedef __bitwise unsigned int vm_fault_t;

so simply assigning 0 to ret should work (and does on line 3967), but
sparse doesn't seem to like it as part of a ({ .. }) expression.

Re: [PATCH] include/linux/hugetlb.h: Convert to use vm_fault_t

[Luc Van Oostenryck]

On Mon, Mar 18, 2019 at 08:20:22PM -0700, Matthew Wilcox wrote:
> On Mon, Mar 18, 2019 at 09:56:05PM +0530, Souptick Joarder wrote:
> > >> mm/memory.c:3968:21: sparse: incorrect type in assignment (different
> > >> base types) @@    expected restricted vm_fault_t [usertype] ret @@
> > >> got e] ret @@
> >    mm/memory.c:3968:21:    expected restricted vm_fault_t [usertype] ret
> >    mm/memory.c:3968:21:    got int
> 
> I think this may be a sparse bug.
> 
> Compare:
> 
> +++ b/mm/memory.c
> @@ -3964,6 +3964,9 @@ vm_fault_t handle_mm_fault(struct vm_area_struct *vma, unsigned long address,
>         if (flags & FAULT_FLAG_USER)
>                 mem_cgroup_enter_user_fault();
>  
> +       ret = 0;
> +       ret = ({ BUG(); 0; });
> +       ret = 1;
>         if (unlikely(is_vm_hugetlb_page(vma)))
>                 ret = hugetlb_fault(vma->vm_mm, vma, address, flags);
>         else
> 
> ../mm/memory.c:3968:13: sparse: warning: incorrect type in assignment (different base types)
> ../mm/memory.c:3968:13: sparse:    expected restricted vm_fault_t [assigned] [usertype] ret
> ../mm/memory.c:3968:13: sparse:    got int
> ../mm/memory.c:3969:13: sparse: warning: incorrect type in assignment (different base types)
> ../mm/memory.c:3969:13: sparse:    expected restricted vm_fault_t [assigned] [usertype] ret
> ../mm/memory.c:3969:13: sparse:    got int
> 
> vm_fault_t is __bitwise:
> 
> include/linux/mm_types.h:typedef __bitwise unsigned int vm_fault_t;
> 
> so simply assigning 0 to ret should work (and does on line 3967), but
> sparse doesn't seem to like it as part of a ({ .. }) expression.

This is the expected behaviour. The constant 0 is magic regarding
bitwise types but ({ ...; 0; }) is not, it is just an ordinary expression
of type 'int'.

So, IMHO, Souptick's patch is the right thing to do.


Best regards,
-- Luc Van Oostenryck