diff mbox series

x86/mm/kaiser: avoid 32-bit/PAE build warning

Message ID 20171206141627.688219-1-arnd@arndb.de
State New
Headers show
Series x86/mm/kaiser: avoid 32-bit/PAE build warning | expand

Commit Message

Arnd Bergmann Dec. 6, 2017, 2:15 p.m. UTC
The new kaiser_add_mapping() function is provided globally and
called from x86 code that can be used in configurations without
KAISER but with 64-bit page flags, in particular _PAGE_NX, which
uses bit 63, leading to a compiler warning:

arch/x86/kernel/ldt.c: In function 'alloc_ldt_struct':
arch/x86/include/asm/pgtable_types.h:183:24: error: conversion from 'long long unsigned int' to 'long unsigned int' changes value from '9223372036854776163' to '355' [-Werror=overflow]
 #define __PAGE_KERNEL  (__PAGE_KERNEL_EXEC | _PAGE_NX)
                        ^
arch/x86/kernel/ldt.c:104:6: note: in expansion of macro '__PAGE_KERNEL'
      __PAGE_KERNEL | _PAGE_GLOBAL);
arch/x86/kernel/ldt.c: In function 'alloc_ldt_struct':
arch/x86/include/asm/pgtable_types.h:183:24: error: conversion from 'long long unsigned int' to 'long unsigned int' changes value from '9223372036854776163' to '355' [-Werror=overflow]
 #define __PAGE_KERNEL  (__PAGE_KERNEL_EXEC | _PAGE_NX)
                        ^
arch/x86/kernel/ldt.c:104:6: note: in expansion of macro '__PAGE_KERNEL'
      __PAGE_KERNEL | _PAGE_GLOBAL);

This changes the type to u64 in the architecture-independent dummy,
and to pteval_t in the x86 specific portion that is used when KAISER
is enabled, ensuring that the flags can always fit. Unfortunately,
pteval_t is not provided by most other architectures, so we are
a little bit inconsistent here.

Fixes: efd9d1a6b30b ("x86/mm/kaiser: Unmap kernel mappings from userspace page tables, core patch")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>

---
I only started building linux-next again today, so this probably
got noticed by others already, and it's possible someone had a better
fix for it. If so, please just ignore my version.
---
 arch/x86/include/asm/kaiser.h | 2 +-
 arch/x86/mm/kaiser.c          | 6 +++---
 include/linux/kaiser.h        | 2 +-
 3 files changed, 5 insertions(+), 5 deletions(-)

-- 
2.9.0

Comments

Arnd Bergmann Dec. 6, 2017, 3:03 p.m. UTC | #1
On Wed, Dec 6, 2017 at 3:15 PM, Arnd Bergmann <arnd@arndb.de> wrote:

> This changes the type to u64 in the architecture-independent dummy,

> and to pteval_t in the x86 specific portion that is used when KAISER

> is enabled, ensuring that the flags can always fit. Unfortunately,

> pteval_t is not provided by most other architectures, so we are

> a little bit inconsistent here.


I ran into a new regression with my patch applied, after doing more randconfig
builds:

In file included from /git/arm-soc/include/linux/kaiser.h:5,
                 from /git/arm-soc/arch/x86/events/intel/ds.c:4:
arch/x86/include/asm/kaiser.h:34:10: error: unknown type name
'pteval_t'; did you mean 'dev_t'?

Maybe it's better to just to the last one-line change in include/linux/kaiser.h.

       Arnd
Dave Hansen Dec. 6, 2017, 3:08 p.m. UTC | #2
On 12/06/2017 07:03 AM, Arnd Bergmann wrote:
> On Wed, Dec 6, 2017 at 3:15 PM, Arnd Bergmann <arnd@arndb.de> wrote:

> 

>> This changes the type to u64 in the architecture-independent dummy,

>> and to pteval_t in the x86 specific portion that is used when KAISER

>> is enabled, ensuring that the flags can always fit. Unfortunately,

>> pteval_t is not provided by most other architectures, so we are

>> a little bit inconsistent here.

> 

> I ran into a new regression with my patch applied, after doing more randconfig

> builds:

> 

> In file included from /git/arm-soc/include/linux/kaiser.h:5,

>                  from /git/arm-soc/arch/x86/events/intel/ds.c:4:

> arch/x86/include/asm/kaiser.h:34:10: error: unknown type name

> 'pteval_t'; did you mean 'dev_t'?

> 

> Maybe it's better to just to the last one-line change in include/linux/kaiser.h.


Hi Arnd,

Are you hitting this in -next?

The newest version of this code has a single kpti_init() function that
shouldn't have any of these problems.
Arnd Bergmann Dec. 6, 2017, 4:36 p.m. UTC | #3
On Wed, Dec 6, 2017 at 4:08 PM, Dave Hansen <dave.hansen@linux.intel.com> wrote:
> On 12/06/2017 07:03 AM, Arnd Bergmann wrote:

>> On Wed, Dec 6, 2017 at 3:15 PM, Arnd Bergmann <arnd@arndb.de> wrote:

>>

>> Maybe it's better to just to the last one-line change in include/linux/kaiser.h.

>

> Hi Arnd,

>

> Are you hitting this in -next?

>

> The newest version of this code has a single kpti_init() function that

> shouldn't have any of these problems.


Yes, this is next-20171206, apparently it came in through tip/auto-latest,
which still has the same version.

       Arnd
Ingo Molnar Dec. 6, 2017, 5:16 p.m. UTC | #4
* Arnd Bergmann <arnd@arndb.de> wrote:

> On Wed, Dec 6, 2017 at 4:08 PM, Dave Hansen <dave.hansen@linux.intel.com> wrote:

> > On 12/06/2017 07:03 AM, Arnd Bergmann wrote:

> >> On Wed, Dec 6, 2017 at 3:15 PM, Arnd Bergmann <arnd@arndb.de> wrote:

> >>

> >> Maybe it's better to just to the last one-line change in include/linux/kaiser.h.

> >

> > Hi Arnd,

> >

> > Are you hitting this in -next?

> >

> > The newest version of this code has a single kpti_init() function that

> > shouldn't have any of these problems.

> 

> Yes, this is next-20171206, apparently it came in through tip/auto-latest,

> which still has the same version.


I'll update the -next version probably later today.

Thanks,

	Ingo
Arnd Bergmann Dec. 6, 2017, 8:47 p.m. UTC | #5
On Wed, Dec 6, 2017 at 6:16 PM, Ingo Molnar <mingo@kernel.org> wrote:
>

> * Arnd Bergmann <arnd@arndb.de> wrote:

>

>> On Wed, Dec 6, 2017 at 4:08 PM, Dave Hansen <dave.hansen@linux.intel.com> wrote:

>> > On 12/06/2017 07:03 AM, Arnd Bergmann wrote:

>> >> On Wed, Dec 6, 2017 at 3:15 PM, Arnd Bergmann <arnd@arndb.de> wrote:

>> >>

>> >> Maybe it's better to just to the last one-line change in include/linux/kaiser.h.

>> >

>> > Hi Arnd,

>> >

>> > Are you hitting this in -next?

>> >

>> > The newest version of this code has a single kpti_init() function that

>> > shouldn't have any of these problems.

>>

>> Yes, this is next-20171206, apparently it came in through tip/auto-latest,

>> which still has the same version.

>

> I'll update the -next version probably later today.


Thanks!

 I just ran into another build error with KAISER:

arch/x86/mm/kaiser.c:173:28: error: '__GFP_NOTRACK' undeclared (first
use in this function); did you mean '__GFP_NOFAIL'?

When you do the update, can you check that it doesn't reference __GFP_NOTRACK?
Apparently the flag got removed in 4.15-rc1.

     Arnd
Ingo Molnar Dec. 6, 2017, 9:02 p.m. UTC | #6
* Arnd Bergmann <arnd@arndb.de> wrote:

> On Wed, Dec 6, 2017 at 6:16 PM, Ingo Molnar <mingo@kernel.org> wrote:

> >

> > * Arnd Bergmann <arnd@arndb.de> wrote:

> >

> >> On Wed, Dec 6, 2017 at 4:08 PM, Dave Hansen <dave.hansen@linux.intel.com> wrote:

> >> > On 12/06/2017 07:03 AM, Arnd Bergmann wrote:

> >> >> On Wed, Dec 6, 2017 at 3:15 PM, Arnd Bergmann <arnd@arndb.de> wrote:

> >> >>

> >> >> Maybe it's better to just to the last one-line change in include/linux/kaiser.h.

> >> >

> >> > Hi Arnd,

> >> >

> >> > Are you hitting this in -next?

> >> >

> >> > The newest version of this code has a single kpti_init() function that

> >> > shouldn't have any of these problems.

> >>

> >> Yes, this is next-20171206, apparently it came in through tip/auto-latest,

> >> which still has the same version.

> >

> > I'll update the -next version probably later today.

> 

> Thanks!

> 

>  I just ran into another build error with KAISER:

> 

> arch/x86/mm/kaiser.c:173:28: error: '__GFP_NOTRACK' undeclared (first

> use in this function); did you mean '__GFP_NOFAIL'?

> 

> When you do the update, can you check that it doesn't reference __GFP_NOTRACK?

> Apparently the flag got removed in 4.15-rc1.


Yeah, saw it too and fixed this one as well.

Thanks,

	Ingo
Arnd Bergmann Feb. 15, 2018, 3:37 p.m. UTC | #7
On Thu, Feb 15, 2018 at 6:43 AM, Greg KH <gregkh@linuxfoundation.org> wrote:
> On Wed, Feb 14, 2018 at 11:12:24PM +0100, Arnd Bergmann wrote:

>> On Wed, Dec 6, 2017 at 4:08 PM, Dave Hansen <dave.hansen@linux.intel.com> wrote:


>>

>> I also saw another warning:

>>

>> /git/arm-soc/arch/x86/mm/kaiser.c: In function 'kaiser_init':

>> /git/arm-soc/arch/x86/mm/kaiser.c:347:8: error: 'vsyscall_pgprot'

>> undeclared (first use in this function); did you mean

>> 'massage_pgprot'?

>>

>> I can send this as proper patches for inclusion in 4.9-stable, unless

>> someone has a better idea or finds a problem

>

> proper patches would be good :)


Sent two patches now. I want to make sure I haven't missed anything there,
especially as my first approach at fixing it ended up causing other build
failures.

In order to test this, I backported some 35 other (mostly trivial) patches later
kernels, and now I have a 4.9.80 based tree that produces a clean randconfig
build every time on arm64 and x86_64. If you want, I'll send you the list
of the required backports as well. From what I can tell, they are all
harmless (unused functions, missing Kconfig dependencies etc), but
being able to do randconfig builds reliable gives us an additional tool for
regression testing the stable kernels.

For 4.14-stable, we only need a handful of patches, but only one of those
is upstream, I'll try my best to get the others merged with a Cc stable tag
so 4.14 randconfig should build cleanly soon.

I suspect 4.4 would require even more patches, but I have not looked.

      Arnd
Greg KH Feb. 15, 2018, 4:43 p.m. UTC | #8
On Thu, Feb 15, 2018 at 04:37:10PM +0100, Arnd Bergmann wrote:
> On Thu, Feb 15, 2018 at 6:43 AM, Greg KH <gregkh@linuxfoundation.org> wrote:

> > On Wed, Feb 14, 2018 at 11:12:24PM +0100, Arnd Bergmann wrote:

> >> On Wed, Dec 6, 2017 at 4:08 PM, Dave Hansen <dave.hansen@linux.intel.com> wrote:

> 

> >>

> >> I also saw another warning:

> >>

> >> /git/arm-soc/arch/x86/mm/kaiser.c: In function 'kaiser_init':

> >> /git/arm-soc/arch/x86/mm/kaiser.c:347:8: error: 'vsyscall_pgprot'

> >> undeclared (first use in this function); did you mean

> >> 'massage_pgprot'?

> >>

> >> I can send this as proper patches for inclusion in 4.9-stable, unless

> >> someone has a better idea or finds a problem

> >

> > proper patches would be good :)

> 

> Sent two patches now. I want to make sure I haven't missed anything there,

> especially as my first approach at fixing it ended up causing other build

> failures.

> 

> In order to test this, I backported some 35 other (mostly trivial) patches later

> kernels, and now I have a 4.9.80 based tree that produces a clean randconfig

> build every time on arm64 and x86_64. If you want, I'll send you the list

> of the required backports as well. From what I can tell, they are all

> harmless (unused functions, missing Kconfig dependencies etc), but

> being able to do randconfig builds reliable gives us an additional tool for

> regression testing the stable kernels.


Sure, I'll be glad to take those.

> For 4.14-stable, we only need a handful of patches, but only one of those

> is upstream, I'll try my best to get the others merged with a Cc stable tag

> so 4.14 randconfig should build cleanly soon.


Again, I'll be glad to take them as well.

> I suspect 4.4 would require even more patches, but I have not looked.


If the above doesn't clean up 4.4 as well, that would be surprising :)

Anyway, 4.4 might be nice to have "clean" if possible, and it's not too
much trouble.

thanks,

greg k-h
diff mbox series

Patch

diff --git a/arch/x86/include/asm/kaiser.h b/arch/x86/include/asm/kaiser.h
index 7c636cd25d65..5fcb9f81e615 100644
--- a/arch/x86/include/asm/kaiser.h
+++ b/arch/x86/include/asm/kaiser.h
@@ -31,7 +31,7 @@ 
  *  table.
  */
 extern int kaiser_add_mapping(unsigned long addr, unsigned long size,
-			      unsigned long flags);
+			      pteval_t flags);
 
 /**
  *  kaiser_add_mapping_cpu_entry - map the cpu entry area
diff --git a/arch/x86/mm/kaiser.c b/arch/x86/mm/kaiser.c
index 0ff502fa655b..2e2d340edbf0 100644
--- a/arch/x86/mm/kaiser.c
+++ b/arch/x86/mm/kaiser.c
@@ -261,7 +261,7 @@  static pte_t *kaiser_shadow_pagetable_walk(unsigned long address,
  * table pages.
  */
 int kaiser_add_user_map(const void *__start_addr, unsigned long size,
-			unsigned long flags)
+			pteval_t flags)
 {
 	unsigned long start_addr = (unsigned long)__start_addr;
 	unsigned long address = start_addr & PAGE_MASK;
@@ -312,7 +312,7 @@  int kaiser_add_user_map(const void *__start_addr, unsigned long size,
 
 int kaiser_add_user_map_ptrs(const void *__start_addr,
 			     const void *__end_addr,
-			     unsigned long flags)
+			     pteval_t flags)
 {
 	return kaiser_add_user_map(__start_addr,
 				   __end_addr - __start_addr,
@@ -470,7 +470,7 @@  static int __init kaiser_boottime_control(void)
 subsys_initcall(kaiser_boottime_control);
 
 int kaiser_add_mapping(unsigned long addr, unsigned long size,
-		       unsigned long flags)
+		       pteval_t flags)
 {
 	return kaiser_add_user_map((const void *)addr, size, flags);
 }
diff --git a/include/linux/kaiser.h b/include/linux/kaiser.h
index 77db4230a0dd..795fccf76849 100644
--- a/include/linux/kaiser.h
+++ b/include/linux/kaiser.h
@@ -20,7 +20,7 @@  static inline void kaiser_remove_mapping(unsigned long start, unsigned long size
 }
 
 static inline int kaiser_add_mapping(unsigned long addr, unsigned long size,
-				     unsigned long flags)
+				     u64 flags)
 {
 	return 0;
 }