From: Arnd Bergmann <arnd@arndb.de>
To: x86@kernel.org
Cc: Arnd Bergmann <arnd@arndb.de>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
Peter Zijlstra <peterz@infradead.org>,
linux-kernel@vger.kernel.org
Subject: [PATCH] x86/mm/kaiser: avoid 32-bit/PAE build warning
Date: Wed, 6 Dec 2017 15:15:41 +0100 [thread overview]
Message-ID: <20171206141627.688219-1-arnd@arndb.de> (raw)
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(-)
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;
}
--
2.9.0
next reply other threads:[~2017-12-06 14:18 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-06 14:15 Arnd Bergmann [this message]
2017-12-06 15:03 ` [PATCH] x86/mm/kaiser: avoid 32-bit/PAE build warning Arnd Bergmann
2017-12-06 15:08 ` Dave Hansen
2017-12-06 16:36 ` Arnd Bergmann
2017-12-06 17:16 ` Ingo Molnar
2017-12-06 20:47 ` Arnd Bergmann
2017-12-06 21:02 ` Ingo Molnar
2018-02-14 22:12 ` Arnd Bergmann
2018-02-15 5:43 ` Greg KH
2018-02-15 15:37 ` Arnd Bergmann
2018-02-15 16:43 ` Greg KH
2018-02-15 21:00 ` Arnd Bergmann
2018-02-19 10:04 ` Arnd Bergmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20171206141627.688219-1-arnd@arndb.de \
--to=arnd@arndb.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox