[PATCH v2] mm: vmalloc: make vmalloc_to_page() deal with PMD/PUD mappings

[PATCH v2] mm: vmalloc: make vmalloc_to_page() deal with PMD/PUD mappings

[Ard Biesheuvel]

While vmalloc() itself strictly uses page mappings only on all
architectures, some of the support routines are aware of the possible
existence of PMD or PUD size mappings inside the VMALLOC region.
This is necessary given that vmalloc() shares this region and the
unmap routines with ioremap(), which may use huge pages on some
architectures (HAVE_ARCH_HUGE_VMAP).

On arm64 running with 4 KB pages, VM_MAP mappings will exist in the
VMALLOC region that are mapped to some extent using PMD size mappings.
As reported by Zhong Jiang, this confuses the kcore code, given that
vread() does not expect having to deal with PMD mappings, resulting
in oopses.

Even though we could work around this by special casing kcore or vmalloc
code for the VM_MAP mappings used by the arm64 kernel, the fact is that
there is already a precedent for dealing with PMD/PUD mappings in the
VMALLOC region, and so we could update the vmalloc_to_page() routine to
deal with such mappings as well. This solves the problem, and brings us
a step closer to huge page support in vmalloc/vmap, which could well be
in our future anyway.

Reported-by: Zhong Jiang <zhongjiang@huawei.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
v2:
- simplify so we can get rid of #ifdefs (drop huge_ptep_get(), which seems
  unnecessary given that p?d_huge() can be assumed to imply p?d_present())
- use HAVE_ARCH_HUGE_VMAP Kconfig define as indicator whether huge mappings
  in the vmalloc range are to be expected, and VM_BUG_ON() otherwise

 mm/vmalloc.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 34a1c3e46ed7..451cd5cafedc 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -12,6 +12,7 @@
 #include <linux/mm.h>
 #include <linux/module.h>
 #include <linux/highmem.h>
+#include <linux/hugetlb.h>
 #include <linux/sched/signal.h>
 #include <linux/slab.h>
 #include <linux/spinlock.h>
@@ -289,9 +290,17 @@ struct page *vmalloc_to_page(const void *vmalloc_addr)
 	pud = pud_offset(p4d, addr);
 	if (pud_none(*pud))
 		return NULL;
+	if (pud_huge(*pud)) {
+		VM_BUG_ON(!IS_ENABLED(CONFIG_HAVE_ARCH_HUGE_VMAP));
+		return pud_page(*pud) + ((addr & ~PUD_MASK) >> PAGE_SHIFT);
+	}
 	pmd = pmd_offset(pud, addr);
 	if (pmd_none(*pmd))
 		return NULL;
+	if (pmd_huge(*pmd)) {
+		VM_BUG_ON(!IS_ENABLED(CONFIG_HAVE_ARCH_HUGE_VMAP));
+		return pmd_page(*pmd) + ((addr & ~PMD_MASK) >> PAGE_SHIFT);
+	}
 
 	ptep = pte_offset_map(pmd, addr);
 	pte = *ptep;
-- 
2.9.3

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

[PATCH v2] mm: vmalloc: make vmalloc_to_page() deal with PMD/PUD mappings

[Ard Biesheuvel]

While vmalloc() itself strictly uses page mappings only on all
architectures, some of the support routines are aware of the possible
existence of PMD or PUD size mappings inside the VMALLOC region.
This is necessary given that vmalloc() shares this region and the
unmap routines with ioremap(), which may use huge pages on some
architectures (HAVE_ARCH_HUGE_VMAP).

On arm64 running with 4 KB pages, VM_MAP mappings will exist in the
VMALLOC region that are mapped to some extent using PMD size mappings.
As reported by Zhong Jiang, this confuses the kcore code, given that
vread() does not expect having to deal with PMD mappings, resulting
in oopses.

Even though we could work around this by special casing kcore or vmalloc
code for the VM_MAP mappings used by the arm64 kernel, the fact is that
there is already a precedent for dealing with PMD/PUD mappings in the
VMALLOC region, and so we could update the vmalloc_to_page() routine to
deal with such mappings as well. This solves the problem, and brings us
a step closer to huge page support in vmalloc/vmap, which could well be
in our future anyway.

Reported-by: Zhong Jiang <zhongjiang@huawei.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
v2:
- simplify so we can get rid of #ifdefs (drop huge_ptep_get(), which seems
  unnecessary given that p?d_huge() can be assumed to imply p?d_present())
- use HAVE_ARCH_HUGE_VMAP Kconfig define as indicator whether huge mappings
  in the vmalloc range are to be expected, and VM_BUG_ON() otherwise

 mm/vmalloc.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 34a1c3e46ed7..451cd5cafedc 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -12,6 +12,7 @@
 #include <linux/mm.h>
 #include <linux/module.h>
 #include <linux/highmem.h>
+#include <linux/hugetlb.h>
 #include <linux/sched/signal.h>
 #include <linux/slab.h>
 #include <linux/spinlock.h>
@@ -289,9 +290,17 @@ struct page *vmalloc_to_page(const void *vmalloc_addr)
 	pud = pud_offset(p4d, addr);
 	if (pud_none(*pud))
 		return NULL;
+	if (pud_huge(*pud)) {
+		VM_BUG_ON(!IS_ENABLED(CONFIG_HAVE_ARCH_HUGE_VMAP));
+		return pud_page(*pud) + ((addr & ~PUD_MASK) >> PAGE_SHIFT);
+	}
 	pmd = pmd_offset(pud, addr);
 	if (pmd_none(*pmd))
 		return NULL;
+	if (pmd_huge(*pmd)) {
+		VM_BUG_ON(!IS_ENABLED(CONFIG_HAVE_ARCH_HUGE_VMAP));
+		return pmd_page(*pmd) + ((addr & ~PMD_MASK) >> PAGE_SHIFT);
+	}
 
 	ptep = pte_offset_map(pmd, addr);
 	pte = *ptep;
-- 
2.9.3

Re: [PATCH v2] mm: vmalloc: make vmalloc_to_page() deal with PMD/PUD mappings

[Mark Rutland]

On Fri, Jun 02, 2017 at 03:54:16PM +0000, Ard Biesheuvel wrote:
> While vmalloc() itself strictly uses page mappings only on all
> architectures, some of the support routines are aware of the possible
> existence of PMD or PUD size mappings inside the VMALLOC region.
> This is necessary given that vmalloc() shares this region and the
> unmap routines with ioremap(), which may use huge pages on some
> architectures (HAVE_ARCH_HUGE_VMAP).
> 
> On arm64 running with 4 KB pages, VM_MAP mappings will exist in the
> VMALLOC region that are mapped to some extent using PMD size mappings.
> As reported by Zhong Jiang, this confuses the kcore code, given that
> vread() does not expect having to deal with PMD mappings, resulting
> in oopses.
> 
> Even though we could work around this by special casing kcore or vmalloc
> code for the VM_MAP mappings used by the arm64 kernel, the fact is that
> there is already a precedent for dealing with PMD/PUD mappings in the
> VMALLOC region, and so we could update the vmalloc_to_page() routine to
> deal with such mappings as well. This solves the problem, and brings us
> a step closer to huge page support in vmalloc/vmap, which could well be
> in our future anyway.
> 
> Reported-by: Zhong Jiang <zhongjiang@huawei.com>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
> v2:
> - simplify so we can get rid of #ifdefs (drop huge_ptep_get(), which seems
>   unnecessary given that p?d_huge() can be assumed to imply p?d_present())
> - use HAVE_ARCH_HUGE_VMAP Kconfig define as indicator whether huge mappings
>   in the vmalloc range are to be expected, and VM_BUG_ON() otherwise

[...]

> @@ -289,9 +290,17 @@ struct page *vmalloc_to_page(const void *vmalloc_addr)
>  	pud = pud_offset(p4d, addr);
>  	if (pud_none(*pud))
>  		return NULL;
> +	if (pud_huge(*pud)) {
> +		VM_BUG_ON(!IS_ENABLED(CONFIG_HAVE_ARCH_HUGE_VMAP));
> +		return pud_page(*pud) + ((addr & ~PUD_MASK) >> PAGE_SHIFT);
> +	}
>  	pmd = pmd_offset(pud, addr);
>  	if (pmd_none(*pmd))
>  		return NULL;
> +	if (pmd_huge(*pmd)) {
> +		VM_BUG_ON(!IS_ENABLED(CONFIG_HAVE_ARCH_HUGE_VMAP));
> +		return pmd_page(*pmd) + ((addr & ~PMD_MASK) >> PAGE_SHIFT);
> +	}

I don't think that it's correct to use the *_huge() helpers. Those
account for huge user mappings, and not arbitrary kernel space block
mappings.

You can disable CONFIG_HUGETLB_PAGE by deselecting  HUGETLBFS and
CGROUP_HUGETLB, in which cases the *_huge() helpers always return false,
even though the kernel may use block mappings.

Thanks,
Mark.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

[PATCH v2] mm: vmalloc: make vmalloc_to_page() deal with PMD/PUD mappings

[Mark Rutland]

On Fri, Jun 02, 2017 at 03:54:16PM +0000, Ard Biesheuvel wrote:
> While vmalloc() itself strictly uses page mappings only on all
> architectures, some of the support routines are aware of the possible
> existence of PMD or PUD size mappings inside the VMALLOC region.
> This is necessary given that vmalloc() shares this region and the
> unmap routines with ioremap(), which may use huge pages on some
> architectures (HAVE_ARCH_HUGE_VMAP).
> 
> On arm64 running with 4 KB pages, VM_MAP mappings will exist in the
> VMALLOC region that are mapped to some extent using PMD size mappings.
> As reported by Zhong Jiang, this confuses the kcore code, given that
> vread() does not expect having to deal with PMD mappings, resulting
> in oopses.
> 
> Even though we could work around this by special casing kcore or vmalloc
> code for the VM_MAP mappings used by the arm64 kernel, the fact is that
> there is already a precedent for dealing with PMD/PUD mappings in the
> VMALLOC region, and so we could update the vmalloc_to_page() routine to
> deal with such mappings as well. This solves the problem, and brings us
> a step closer to huge page support in vmalloc/vmap, which could well be
> in our future anyway.
> 
> Reported-by: Zhong Jiang <zhongjiang@huawei.com>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
> v2:
> - simplify so we can get rid of #ifdefs (drop huge_ptep_get(), which seems
>   unnecessary given that p?d_huge() can be assumed to imply p?d_present())
> - use HAVE_ARCH_HUGE_VMAP Kconfig define as indicator whether huge mappings
>   in the vmalloc range are to be expected, and VM_BUG_ON() otherwise

[...]

> @@ -289,9 +290,17 @@ struct page *vmalloc_to_page(const void *vmalloc_addr)
>  	pud = pud_offset(p4d, addr);
>  	if (pud_none(*pud))
>  		return NULL;
> +	if (pud_huge(*pud)) {
> +		VM_BUG_ON(!IS_ENABLED(CONFIG_HAVE_ARCH_HUGE_VMAP));
> +		return pud_page(*pud) + ((addr & ~PUD_MASK) >> PAGE_SHIFT);
> +	}
>  	pmd = pmd_offset(pud, addr);
>  	if (pmd_none(*pmd))
>  		return NULL;
> +	if (pmd_huge(*pmd)) {
> +		VM_BUG_ON(!IS_ENABLED(CONFIG_HAVE_ARCH_HUGE_VMAP));
> +		return pmd_page(*pmd) + ((addr & ~PMD_MASK) >> PAGE_SHIFT);
> +	}

I don't think that it's correct to use the *_huge() helpers. Those
account for huge user mappings, and not arbitrary kernel space block
mappings.

You can disable CONFIG_HUGETLB_PAGE by deselecting  HUGETLBFS and
CGROUP_HUGETLB, in which cases the *_huge() helpers always return false,
even though the kernel may use block mappings.

Thanks,
Mark.

Re: [PATCH v2] mm: vmalloc: make vmalloc_to_page() deal with PMD/PUD mappings

[kbuild test robot]

[-- Attachment #1: Type: text/plain, Size: 2442 bytes --]

Hi Ard,

[auto build test ERROR on mmotm/master]
[also build test ERROR on v4.12-rc3 next-20170602]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]

url:    https://github.com/0day-ci/linux/commits/Ard-Biesheuvel/mm-vmalloc-make-vmalloc_to_page-deal-with-PMD-PUD-mappings/20170603-021745
base:   git://git.cmpxchg.org/linux-mmotm.git master
config: frv-defconfig (attached as .config)
compiler: frv-linux-gcc (GCC) 6.2.0
reproduce:
        wget https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # save the attached .config to linux build tree
        make.cross ARCH=frv 

All error/warnings (new ones prefixed by >>):

   In file included from arch/frv/include/asm/page.h:70:0,
                    from include/linux/vmalloc.h:8,
                    from mm/vmalloc.c:11:
   mm/vmalloc.c: In function 'vmalloc_to_page':
>> mm/vmalloc.c:295:19: error: incompatible types when initializing type 'long unsigned int' using type 'pud_t {aka struct <anonymous>}'
      return pud_page(*pud) + ((addr & ~PUD_MASK) >> PAGE_SHIFT);
                      ^
   include/asm-generic/memory_model.h:32:41: note: in definition of macro '__pfn_to_page'
    #define __pfn_to_page(pfn) (mem_map + ((pfn) - ARCH_PFN_OFFSET))
                                            ^~~
>> arch/frv/include/asm/pgtable.h:367:36: note: in expansion of macro 'pmd_val'
    #define pmd_page(pmd) (pfn_to_page(pmd_val(pmd) >> PAGE_SHIFT))
                                       ^~~~~~~
>> arch/frv/include/asm/pgtable.h:247:27: note: in expansion of macro 'pmd_page'
    #define pud_page(pud)    (pmd_page((pmd_t){ pud }))
                              ^~~~~~~~
   mm/vmalloc.c:295:10: note: in expansion of macro 'pud_page'
      return pud_page(*pud) + ((addr & ~PUD_MASK) >> PAGE_SHIFT);
             ^~~~~~~~

vim +295 mm/vmalloc.c

   289			return NULL;
   290		pud = pud_offset(p4d, addr);
   291		if (pud_none(*pud))
   292			return NULL;
   293		if (pud_huge(*pud)) {
   294			VM_BUG_ON(!IS_ENABLED(CONFIG_HAVE_ARCH_HUGE_VMAP));
 > 295			return pud_page(*pud) + ((addr & ~PUD_MASK) >> PAGE_SHIFT);
   296		}
   297		pmd = pmd_offset(pud, addr);
   298		if (pmd_none(*pmd))

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation

[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 8869 bytes --]

[PATCH v2] mm: vmalloc: make vmalloc_to_page() deal with PMD/PUD mappings

[kbuild test robot]

Hi Ard,

[auto build test ERROR on mmotm/master]
[also build test ERROR on v4.12-rc3 next-20170602]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]

url:    https://github.com/0day-ci/linux/commits/Ard-Biesheuvel/mm-vmalloc-make-vmalloc_to_page-deal-with-PMD-PUD-mappings/20170603-021745
base:   git://git.cmpxchg.org/linux-mmotm.git master
config: frv-defconfig (attached as .config)
compiler: frv-linux-gcc (GCC) 6.2.0
reproduce:
        wget https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # save the attached .config to linux build tree
        make.cross ARCH=frv 

All error/warnings (new ones prefixed by >>):

   In file included from arch/frv/include/asm/page.h:70:0,
                    from include/linux/vmalloc.h:8,
                    from mm/vmalloc.c:11:
   mm/vmalloc.c: In function 'vmalloc_to_page':
>> mm/vmalloc.c:295:19: error: incompatible types when initializing type 'long unsigned int' using type 'pud_t {aka struct <anonymous>}'
      return pud_page(*pud) + ((addr & ~PUD_MASK) >> PAGE_SHIFT);
                      ^
   include/asm-generic/memory_model.h:32:41: note: in definition of macro '__pfn_to_page'
    #define __pfn_to_page(pfn) (mem_map + ((pfn) - ARCH_PFN_OFFSET))
                                            ^~~
>> arch/frv/include/asm/pgtable.h:367:36: note: in expansion of macro 'pmd_val'
    #define pmd_page(pmd) (pfn_to_page(pmd_val(pmd) >> PAGE_SHIFT))
                                       ^~~~~~~
>> arch/frv/include/asm/pgtable.h:247:27: note: in expansion of macro 'pmd_page'
    #define pud_page(pud)    (pmd_page((pmd_t){ pud }))
                              ^~~~~~~~
   mm/vmalloc.c:295:10: note: in expansion of macro 'pud_page'
      return pud_page(*pud) + ((addr & ~PUD_MASK) >> PAGE_SHIFT);
             ^~~~~~~~

vim +295 mm/vmalloc.c

   289			return NULL;
   290		pud = pud_offset(p4d, addr);
   291		if (pud_none(*pud))
   292			return NULL;
   293		if (pud_huge(*pud)) {
   294			VM_BUG_ON(!IS_ENABLED(CONFIG_HAVE_ARCH_HUGE_VMAP));
 > 295			return pud_page(*pud) + ((addr & ~PUD_MASK) >> PAGE_SHIFT);
   296		}
   297		pmd = pmd_offset(pud, addr);
   298		if (pmd_none(*pmd))

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 8869 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170603/69cf0667/attachment.gz>

Re: [PATCH v2] mm: vmalloc: make vmalloc_to_page() deal with PMD/PUD mappings

[kbuild test robot]

[-- Attachment #1: Type: text/plain, Size: 2669 bytes --]

Hi Ard,

[auto build test ERROR on mmotm/master]
[also build test ERROR on v4.12-rc3 next-20170602]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]

url:    https://github.com/0day-ci/linux/commits/Ard-Biesheuvel/mm-vmalloc-make-vmalloc_to_page-deal-with-PMD-PUD-mappings/20170603-021745
base:   git://git.cmpxchg.org/linux-mmotm.git master
config: parisc-allmodconfig (attached as .config)
compiler: hppa-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
        wget https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # save the attached .config to linux build tree
        make.cross ARCH=parisc 

All error/warnings (new ones prefixed by >>):

   In file included from arch/parisc/include/asm/pgtable.h:4:0,
                    from include/linux/mm.h:70,
                    from mm/vmalloc.c:12:
   mm/vmalloc.c: In function 'vmalloc_to_page':
>> include/asm-generic/4level-fixup.h:26:25: error: implicit declaration of function 'pgd_page' [-Werror=implicit-function-declaration]
    #define pud_page(pud)   pgd_page(pud)
                            ^
>> mm/vmalloc.c:295:10: note: in expansion of macro 'pud_page'
      return pud_page(*pud) + ((addr & ~PUD_MASK) >> PAGE_SHIFT);
             ^~~~~~~~
>> mm/vmalloc.c:295:25: warning: return makes pointer from integer without a cast [-Wint-conversion]
      return pud_page(*pud) + ((addr & ~PUD_MASK) >> PAGE_SHIFT);
                             
   cc1: some warnings being treated as errors

vim +/pud_page +295 mm/vmalloc.c

   279		/*
   280		 * XXX we might need to change this if we add VIRTUAL_BUG_ON for
   281		 * architectures that do not vmalloc module space
   282		 */
   283		VIRTUAL_BUG_ON(!is_vmalloc_or_module_addr(vmalloc_addr));
   284	
   285		if (pgd_none(*pgd))
   286			return NULL;
   287		p4d = p4d_offset(pgd, addr);
   288		if (p4d_none(*p4d))
   289			return NULL;
   290		pud = pud_offset(p4d, addr);
   291		if (pud_none(*pud))
   292			return NULL;
   293		if (pud_huge(*pud)) {
   294			VM_BUG_ON(!IS_ENABLED(CONFIG_HAVE_ARCH_HUGE_VMAP));
 > 295			return pud_page(*pud) + ((addr & ~PUD_MASK) >> PAGE_SHIFT);
   296		}
   297		pmd = pmd_offset(pud, addr);
   298		if (pmd_none(*pmd))
   299			return NULL;
   300		if (pmd_huge(*pmd)) {
   301			VM_BUG_ON(!IS_ENABLED(CONFIG_HAVE_ARCH_HUGE_VMAP));
   302			return pmd_page(*pmd) + ((addr & ~PMD_MASK) >> PAGE_SHIFT);
   303		}

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation

[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 50008 bytes --]

[PATCH v2] mm: vmalloc: make vmalloc_to_page() deal with PMD/PUD mappings

[kbuild test robot]

Hi Ard,

[auto build test ERROR on mmotm/master]
[also build test ERROR on v4.12-rc3 next-20170602]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]

url:    https://github.com/0day-ci/linux/commits/Ard-Biesheuvel/mm-vmalloc-make-vmalloc_to_page-deal-with-PMD-PUD-mappings/20170603-021745
base:   git://git.cmpxchg.org/linux-mmotm.git master
config: parisc-allmodconfig (attached as .config)
compiler: hppa-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
        wget https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # save the attached .config to linux build tree
        make.cross ARCH=parisc 

All error/warnings (new ones prefixed by >>):

   In file included from arch/parisc/include/asm/pgtable.h:4:0,
                    from include/linux/mm.h:70,
                    from mm/vmalloc.c:12:
   mm/vmalloc.c: In function 'vmalloc_to_page':
>> include/asm-generic/4level-fixup.h:26:25: error: implicit declaration of function 'pgd_page' [-Werror=implicit-function-declaration]
    #define pud_page(pud)   pgd_page(pud)
                            ^
>> mm/vmalloc.c:295:10: note: in expansion of macro 'pud_page'
      return pud_page(*pud) + ((addr & ~PUD_MASK) >> PAGE_SHIFT);
             ^~~~~~~~
>> mm/vmalloc.c:295:25: warning: return makes pointer from integer without a cast [-Wint-conversion]
      return pud_page(*pud) + ((addr & ~PUD_MASK) >> PAGE_SHIFT);
                             
   cc1: some warnings being treated as errors

vim +/pud_page +295 mm/vmalloc.c

   279		/*
   280		 * XXX we might need to change this if we add VIRTUAL_BUG_ON for
   281		 * architectures that do not vmalloc module space
   282		 */
   283		VIRTUAL_BUG_ON(!is_vmalloc_or_module_addr(vmalloc_addr));
   284	
   285		if (pgd_none(*pgd))
   286			return NULL;
   287		p4d = p4d_offset(pgd, addr);
   288		if (p4d_none(*p4d))
   289			return NULL;
   290		pud = pud_offset(p4d, addr);
   291		if (pud_none(*pud))
   292			return NULL;
   293		if (pud_huge(*pud)) {
   294			VM_BUG_ON(!IS_ENABLED(CONFIG_HAVE_ARCH_HUGE_VMAP));
 > 295			return pud_page(*pud) + ((addr & ~PUD_MASK) >> PAGE_SHIFT);
   296		}
   297		pmd = pmd_offset(pud, addr);
   298		if (pmd_none(*pmd))
   299			return NULL;
   300		if (pmd_huge(*pmd)) {
   301			VM_BUG_ON(!IS_ENABLED(CONFIG_HAVE_ARCH_HUGE_VMAP));
   302			return pmd_page(*pmd) + ((addr & ~PMD_MASK) >> PAGE_SHIFT);
   303		}

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 50008 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170603/92e31e12/attachment-0001.gz>