linux-kernel - Re: mm/memory.c:3968:21: sparse: incorrect type in assignment (different base types)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAFqt6za4x8DCoRdyFDcmR8A+CczebqNRKDKhvkz06JRN5_Hnrg@mail.gmail.com>
Date:   Sat, 16 Mar 2019 00:35:37 +0530
From:   Souptick Joarder <jrdr.linux@...il.com>
To:     Matthew Wilcox <willy@...radead.org>
Cc:     kbuild test robot <lkp@...el.com>, kbuild-all@...org,
        linux-kernel@...r.kernel.org,
        William Kucharski <william.kucharski@...cle.com>,
        Mike Rapoport <rppt@...ux.ibm.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Linux Memory Management List <linux-mm@...ck.org>
Subject: Re: mm/memory.c:3968:21: sparse: incorrect type in assignment
 (different base types)

Hi Matthew,

On Thu, Mar 14, 2019 at 9:30 PM Matthew Wilcox <willy@...radead.org> wrote:
>
> On Thu, Mar 14, 2019 at 03:10:19PM +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
> >
> > Looking into https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> > hugetlb_fault() is converted to return vm_fault_t. Not sure, why sparse is
> > still throwing warnings.
>
> Because there are two definitions of hugetlb_fault():
>
> $ git grep -wn hugetlb_fault
> include/linux/hugetlb.h:108:vm_fault_t hugetlb_fault(struct mm_struct *mm, struct vm_area_struct *vma,
> include/linux/hugetlb.h:206:#define hugetlb_fault(mm, vma, addr, flags) ({ BUG(); 0; })

make ARCH=x86_64 allmodconfig will set CONFIG_HUGETLB_PAGE =y
which means it shouldn't use the hugetlb_fault() macro in this case.
With *make ARCH=x86_64 allmodconfig* I am unable to reproduce the issue.

But consider the warnings, does the below change is fine ?

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 */