[PATCH] [RFC] ARM: modify pgd_t definition for TRANSPARENT_HUGEPAGE_PUD

[PATCH] [RFC] ARM: modify pgd_t definition for TRANSPARENT_HUGEPAGE_PUD

[Arnd Bergmann]

I ran into build errors on ARM after Willy's newly added generic
TRANSPARENT_HUGEPAGE_PUD support. We don't support this feature
on ARM at all, but the patch causes a build error anyway:

In file included from ../kernel/memremap.c:17:0:
../include/linux/pfn_t.h:108:7: error: 'pud_mkdevmap' declared as function returning an array
 pud_t pud_mkdevmap(pud_t pud);

We don't use a PUD on ARM, so pud_t is defined as pmd_t, which
in turn is defined as

typedef unsigned long pgd_t[2];

on NOMMU and on 2-level MMU configurations. There is an (unused)
other definition using a struct around the array, which happens to
work fine here.

There is a comment in the file about the fact the other version
is "easier on the compiler", and I've traced that version back
to linux-2.1.80 when ARM support was first merged back in 1998.

It's probably a safe assumption that this is no longer necessary:
The same logic existed in asm-i386 at the time but was removed
a year later in 2.3.23pre3. The STRICT_MM_TYPECHECKS logic
also ended up getting copied into these files:

arch/alpha/include/asm/page.h
arch/arc/include/asm/page.h
arch/arm/include/asm/pgtable-3level-types.h
arch/arm64/include/asm/pgtable-types.h
arch/ia64/include/asm/page.h
arch/parisc/include/asm/page.h
arch/powerpc/include/asm/page.h
arch/sparc/include/asm/page_32.h
arch/sparc/include/asm/page_64.h
arch/tile/include/asm/page.h
arch/unicore32/include/asm/page.h

We should probably remove it everywhere, but for the moment,
this minimal patch gets things to compile on linux-next.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: a27da20ed50e ("mm: add support for PUD-sized transparent hugepages")

diff --git a/arch/arm/include/asm/page-nommu.h b/arch/arm/include/asm/page-nommu.h
index d1b162a18dcb..3db1ca22fecb 100644
--- a/arch/arm/include/asm/page-nommu.h
+++ b/arch/arm/include/asm/page-nommu.h
@@ -31,12 +31,12 @@
  */
 typedef unsigned long pte_t;
 typedef unsigned long pmd_t;
-typedef unsigned long pgd_t[2];
+typedef struct { unsigned long pgd[2]; } pgd_t;
 typedef unsigned long pgprot_t;
 
 #define pte_val(x)      (x)
 #define pmd_val(x)      (x)
-#define pgd_val(x)	((x)[0])
+#define pgd_val(x)	((x).pgd[0])
 #define pgprot_val(x)   (x)
 
 #define __pte(x)        (x)
diff --git a/arch/arm/include/asm/pgtable-2level-types.h b/arch/arm/include/asm/pgtable-2level-types.h
index 66cb5b0e89c5..9b9815d5ebd6 100644
--- a/arch/arm/include/asm/pgtable-2level-types.h
+++ b/arch/arm/include/asm/pgtable-2level-types.h
@@ -24,6 +24,9 @@
 typedef u32 pteval_t;
 typedef u32 pmdval_t;
 
+typedef struct { pmdval_t pgd[2]; } pgd_t;
+#define pgd_val(x)	((x).pgd[0])
+
 #undef STRICT_MM_TYPECHECKS
 
 #ifdef STRICT_MM_TYPECHECKS
@@ -32,12 +35,10 @@ typedef u32 pmdval_t;
  */
 typedef struct { pteval_t pte; } pte_t;
 typedef struct { pmdval_t pmd; } pmd_t;
-typedef struct { pmdval_t pgd[2]; } pgd_t;
 typedef struct { pteval_t pgprot; } pgprot_t;
 
 #define pte_val(x)      ((x).pte)
 #define pmd_val(x)      ((x).pmd)
-#define pgd_val(x)	((x).pgd[0])
 #define pgprot_val(x)   ((x).pgprot)
 
 #define __pte(x)        ((pte_t) { (x) } )
@@ -50,12 +51,10 @@ typedef struct { pteval_t pgprot; } pgprot_t;
  */
 typedef pteval_t pte_t;
 typedef pmdval_t pmd_t;
-typedef pmdval_t pgd_t[2];
 typedef pteval_t pgprot_t;
 
 #define pte_val(x)      (x)
 #define pmd_val(x)      (x)
-#define pgd_val(x)	((x)[0])
 #define pgprot_val(x)   (x)
 
 #define __pte(x)        (x)

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

Re: [PATCH] [RFC] ARM: modify pgd_t definition for TRANSPARENT_HUGEPAGE_PUD

[Sam Ravnborg]

On Wed, Feb 03, 2016 at 02:21:48PM +0100, Arnd Bergmann wrote:
> I ran into build errors on ARM after Willy's newly added generic
> TRANSPARENT_HUGEPAGE_PUD support. We don't support this feature
> on ARM at all, but the patch causes a build error anyway:
> 
> In file included from ../kernel/memremap.c:17:0:
> ../include/linux/pfn_t.h:108:7: error: 'pud_mkdevmap' declared as function returning an array
>  pud_t pud_mkdevmap(pud_t pud);
> 
> We don't use a PUD on ARM, so pud_t is defined as pmd_t, which
> in turn is defined as
> 
> typedef unsigned long pgd_t[2];
> 
> on NOMMU and on 2-level MMU configurations. There is an (unused)
> other definition using a struct around the array, which happens to
> work fine here.
> 
> There is a comment in the file about the fact the other version
> is "easier on the compiler", and I've traced that version back
> to linux-2.1.80 when ARM support was first merged back in 1998.
> 
> It's probably a safe assumption that this is no longer necessary:
> The same logic existed in asm-i386 at the time but was removed
> a year later in 2.3.23pre3. The STRICT_MM_TYPECHECKS logic
> also ended up getting copied into these files:
> 
> arch/alpha/include/asm/page.h
> arch/arc/include/asm/page.h
> arch/arm/include/asm/pgtable-3level-types.h
> arch/arm64/include/asm/pgtable-types.h
> arch/ia64/include/asm/page.h
> arch/parisc/include/asm/page.h
> arch/powerpc/include/asm/page.h
> arch/sparc/include/asm/page_32.h
> arch/sparc/include/asm/page_64.h

For the sparc32 case we use the simpler variants.
According to the comment this is due to limitation in
the way we pass arguments in the sparc32 ABI.
But I have not tried to compare a kernel for sparc32 with
and without the use of structs.

For sparc64 we use the stricter types (structs).
I did not check other architectures - but just wanted to
tell that the right choice may be architecture dependent.

	Sam

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

Re: [PATCH] [RFC] ARM: modify pgd_t definition for TRANSPARENT_HUGEPAGE_PUD

[Arnd Bergmann]

On Wednesday 03 February 2016 17:39:46 Sam Ravnborg wrote:
> On Wed, Feb 03, 2016 at 02:21:48PM +0100, Arnd Bergmann wrote:
> > arch/alpha/include/asm/page.h
> > arch/arc/include/asm/page.h
> > arch/arm/include/asm/pgtable-3level-types.h
> > arch/arm64/include/asm/pgtable-types.h
> > arch/ia64/include/asm/page.h
> > arch/parisc/include/asm/page.h
> > arch/powerpc/include/asm/page.h
> > arch/sparc/include/asm/page_32.h
> > arch/sparc/include/asm/page_64.h
> 
> For the sparc32 case we use the simpler variants.
> According to the comment this is due to limitation in
> the way we pass arguments in the sparc32 ABI.
> But I have not tried to compare a kernel for sparc32 with
> and without the use of structs.
> 
> For sparc64 we use the stricter types (structs).
> I did not check other architectures - but just wanted to
> tell that the right choice may be architecture dependent.
> 

I see. I was assuming that they all (wrongly) default to the simple
definitions.

It seems we have these categories:

* both defined, but using strict:
arch/alpha/include/asm/page.h:#define STRICT_MM_TYPECHECKS
arch/sparc/include/asm/page_64.h:#define STRICT_MM_TYPECHECKS
arch/ia64/include/asm/page.h:#  define STRICT_MM_TYPECHECKS
arch/parisc/include/asm/page.h:#define STRICT_MM_TYPECHECKS

* both defined, but using non-strict:
arch/arc/include/asm/page.h:#undef STRICT_MM_TYPECHECKS
arch/arm/include/asm/pgtable-2level-types.h:#undef STRICT_MM_TYPECHECKS
arch/arm/include/asm/pgtable-3level-types.h:#undef STRICT_MM_TYPECHECKS
arch/arm64/include/asm/pgtable-types.h:#undef STRICT_MM_TYPECHECKS
arch/sparc/include/asm/page_32.h:/* #define STRICT_MM_TYPECHECKS */
arch/unicore32/include/asm/page.h:#undef STRICT_MM_TYPECHECKS

* Kconfig option:
arch/powerpc/Kconfig.debug:config STRICT_MM_TYPECHECKS
			 	default n

* only strict defined:
everything else


	Arnd

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