Linux next build for arm64 failed due to numa.c:34:10: fatal error: asm/kaslr.h: No such file or directory
On Wed, 3 Oct 2018 at 19:52, tip-bot for Peter Zijlstra (Intel) tipbot@zytor.com wrote:
Commit-ID: 3a387c6d96e69f1710a3804eb68e1253263298f2 Gitweb: https://git.kernel.org/tip/3a387c6d96e69f1710a3804eb68e1253263298f2 Author: Peter Zijlstra (Intel) peterz@infradead.org AuthorDate: Wed, 3 Oct 2018 14:41:27 +0200 Committer: Borislav Petkov bp@suse.de CommitDate: Wed, 3 Oct 2018 16:15:49 +0200
x86/kaslr, ACPI/NUMA: Fix KASLR build error
There is no point in trying to compile KASLR-specific code when there is no KASLR.
[ bp: Move the whole crap into kaslr.c and make rand_mem_physical_padding static. ]
Signed-off-by: Peter Zijlstra (Intel) peterz@infradead.org
<trim>
diff --git a/drivers/acpi/numa.c b/drivers/acpi/numa.c index 3d69834c692f..4408e37600ef 100644 --- a/drivers/acpi/numa.c +++ b/drivers/acpi/numa.c @@ -32,7 +32,7 @@ #include <linux/numa.h> #include <linux/nodemask.h> #include <linux/topology.h> -#include <asm/setup.h> +#include <asm/kaslr.h>
kernel-source/drivers/acpi/numa.c:34:10: fatal error: asm/kaslr.h: No such file or directory #include <asm/kaslr.h> ^~~~~~~~~~~~~ compilation terminated. kernel-source/scripts/Makefile.build:295: recipe for target 'drivers/acpi/numa.o' failed make[4]: *** [drivers/acpi/numa.o] Error 1 make[4]: *** Waiting for unfinished jobs.... CC lib/win_minmax.o CC drivers/base/soc.o kernel-source/scripts/Makefile.build:520: recipe for target 'drivers/acpi' failed make[3]: *** [drivers/acpi] Error 2
On Mon, Oct 08, 2018 at 04:33:29PM +0530, Naresh Kamboju wrote:
Linux next build for arm64 failed due to numa.c:34:10: fatal error: asm/kaslr.h: No such file or directory
Thanks for letting me know, I guess we could fix that with a weak function:
--- arch/x86/include/asm/kaslr.h | 2 -- drivers/acpi/numa.c | 4 +++- 2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/x86/include/asm/kaslr.h b/arch/x86/include/asm/kaslr.h index 95ef3fc01d12..db7ba2feb947 100644 --- a/arch/x86/include/asm/kaslr.h +++ b/arch/x86/include/asm/kaslr.h @@ -6,10 +6,8 @@ unsigned long kaslr_get_random_long(const char *purpose);
#ifdef CONFIG_RANDOMIZE_MEMORY void kernel_randomize_memory(void); -void kaslr_check_padding(void); #else static inline void kernel_randomize_memory(void) { } -static inline void kaslr_check_padding(void) { } #endif /* CONFIG_RANDOMIZE_MEMORY */
#endif diff --git a/drivers/acpi/numa.c b/drivers/acpi/numa.c index 4408e37600ef..ba62004f4d86 100644 --- a/drivers/acpi/numa.c +++ b/drivers/acpi/numa.c @@ -32,7 +32,6 @@ #include <linux/numa.h> #include <linux/nodemask.h> #include <linux/topology.h> -#include <asm/kaslr.h>
static nodemask_t nodes_found_map = NODE_MASK_NONE;
@@ -433,6 +432,9 @@ acpi_table_parse_srat(enum acpi_srat_type id, handler, max_entries); }
+/* To be overridden by architectures */ +void __init __weak kaslr_check_padding(void) { } + int __init acpi_numa_init(void) { int cnt = 0;
On Mon, Oct 8, 2018 at 3:01 PM Borislav Petkov bp@suse.de wrote:
On Mon, Oct 08, 2018 at 04:33:29PM +0530, Naresh Kamboju wrote:
Linux next build for arm64 failed due to numa.c:34:10: fatal error: asm/kaslr.h: No such file or directory
Thanks for letting me know, I guess we could fix that with a weak function:
+/* To be overridden by architectures */ +void __init __weak kaslr_check_padding(void) { }
int __init acpi_numa_init(void) { int cnt = 0;
I think __weak functions are too fragile, when you do this and it turns out that another architecture does need to do something, you won't ever get any indication of it.
If we know that arm64 doesn't need to do anything here, just add an arch/arm64/include/asm/kaslr.h with an empty function there.
Arnd
On Mon, Oct 08, 2018 at 03:48:28PM +0200, Arnd Bergmann wrote:
I think __weak functions are too fragile, when you do this and it turns out that another architecture does need to do something, you won't ever get any indication of it.
If we know that arm64 doesn't need to do anything here, just add an arch/arm64/include/asm/kaslr.h with an empty function there.
I'm looking at fs/proc/vmcore.c and all those other weak functions there and just doing the same.
Also, judging by
$ git grep CONFIG_PROC_VMCORE
output, ia64, mips and powerpc would need that include too.
-
Arnd Bergmann -
Borislav Petkov -
Naresh Kamboju