kernel.git/arch/arm64/Makefile, branch linux-4.16.y

arm64: ftrace: emit ftrace-mod.o contents through code

2017-12-01T13:04:59Z

When building the arm64 kernel with both CONFIG_ARM64_MODULE_PLTS and CONFIG_DYNAMIC_FTRACE enabled, the ftrace-mod.o object file is built with the kernel and contains a trampoline that is linked into each module, so that modules can be loaded far away from the kernel and still reach the ftrace entry point in the core kernel with an ordinary relative branch, as is emitted by the compiler instrumentation code dynamic ftrace relies on. In order to be able to build out of tree modules, this object file needs to be included into the linux-headers or linux-devel packages, which is undesirable, as it makes arm64 a special case (although a precedent does exist for 32-bit PPC). Given that the trampoline essentially consists of a PLT entry, let's not bother with a source or object file for it, and simply patch it in whenever the trampoline is being populated, using the existing PLT support routines. Cc: Signed-off-by: Ard Biesheuvel Signed-off-by: Will Deacon

arm64: support __int128 on gcc 5+

2017-11-03T15:24:21Z

Versions of gcc prior to gcc 5 emitted a __multi3 function call when dealing with TI types, resulting in failures when trying to link to libgcc, and more generally, bad performance. However, since gcc 5, the compiler supports actually emitting fast instructions, which means we can at long last enable this option and receive the speedups. The gcc commit that added proper Aarch64 support is: https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=d1ae7bb994f49316f6f63e6173f2931e837a351d This commit appears to be part of the gcc 5 release. There are still a few instructions, __ashlti3 and __ashrti3, which require libgcc, which is fine. Rather than linking to libgcc, we simply provide them ourselves, since they're not that complicated. Signed-off-by: Jason A. Donenfeld Signed-off-by: Will Deacon

arm64: prevent regressions in compressed kernel image size when upgrading to binutils 2.27

2017-10-30T13:45:12Z

Upon upgrading to binutils 2.27, we found that our lz4 and gzip compressed kernel images were significantly larger, resulting is 10ms boot time regressions. As noted by Rahul: "aarch64 binaries uses RELA relocations, where each relocation entry includes an addend value. This is similar to x86_64. On x86_64, the addend values are also stored at the relocation offset for relative relocations. This is an optimization: in the case where code does not need to be relocated, the loader can simply skip processing relative relocations. In binutils-2.25, both bfd and gold linkers did this for x86_64, but only the gold linker did this for aarch64. The kernel build here is using the bfd linker, which stored zeroes at the relocation offsets for relative relocations. Since a set of zeroes compresses better than a set of non-zero addend values, this behavior was resulting in much better lz4 compression. The bfd linker in binutils-2.27 is now storing the actual addend values at the relocation offsets. The behavior is now consistent with what it does for x86_64 and what gold linker does for both architectures. The change happened in this upstream commit: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=1f56df9d0d5ad89806c24e71f296576d82344613 Since a bunch of zeroes got replaced by non-zero addend values, we see the side effect of lz4 compressed image being a bit bigger. To get the old behavior from the bfd linker, "--no-apply-dynamic-relocs" flag can be used: $ LDFLAGS="--no-apply-dynamic-relocs" make With this flag, the compressed image size is back to what it was with binutils-2.25. If the kernel is using ASLR, there aren't additional runtime costs to --no-apply-dynamic-relocs, as the relocations will need to be applied again anyway after the kernel is relocated to a random address. If the kernel is not using ASLR, then presumably the current default behavior of the linker is better. Since the static linker performed the dynamic relocs, and the kernel is not moved to a different address at load time, it can skip applying the relocations all over again." Some measurements: $ ld -v GNU ld (binutils-2.25-f3d35cf6) 2.25.51.20141117 ^ $ ls -l vmlinux -rwxr-x--- 1 ndesaulniers eng 300652760 Oct 26 11:57 vmlinux $ ls -l Image.lz4-dtb -rw-r----- 1 ndesaulniers eng 16932627 Oct 26 11:57 Image.lz4-dtb $ ld -v GNU ld (binutils-2.27-53dd00a1) 2.27.0.20170315 ^ pre patch: $ ls -l vmlinux -rwxr-x--- 1 ndesaulniers eng 300376208 Oct 26 11:43 vmlinux $ ls -l Image.lz4-dtb -rw-r----- 1 ndesaulniers eng 18159474 Oct 26 11:43 Image.lz4-dtb post patch: $ ls -l vmlinux -rwxr-x--- 1 ndesaulniers eng 300376208 Oct 26 12:06 vmlinux $ ls -l Image.lz4-dtb -rw-r----- 1 ndesaulniers eng 16932466 Oct 26 12:06 Image.lz4-dtb By Siqi's measurement w/ gzip: binutils 2.27 with this patch (with --no-apply-dynamic-relocs): Image 41535488 Image.gz 13404067 binutils 2.27 without this patch (without --no-apply-dynamic-relocs): Image 41535488 Image.gz 14125516 Any compression scheme should be able to get better results from the longer runs of zeros, not just GZIP and LZ4. 10ms boot time savings isn't anything to get excited about, but users of arm64+compression+bfd-2.27 should not have to pay a penalty for no runtime improvement. Reported-by: Gopinath Elanchezhian Reported-by: Sindhuri Pentyala Reported-by: Wei Wang Suggested-by: Ard Biesheuvel Suggested-by: Rahul Chaudhry Suggested-by: Siqi Lin Suggested-by: Stephen Hines Signed-off-by: Nick Desaulniers Reviewed-by: Ard Biesheuvel [will: added comment to Makefile] Signed-off-by: Will Deacon

arm64: ensure the kernel is compiled for LP64

2017-09-18T10:20:20Z

The kernel needs to be compiled as a LP64 binary for ARM64, even when using a compiler that defaults to code-generation for the ILP32 ABI. Consequently, we need to explicitly pass '-mabi=lp64' (supported on gcc-4.9 and newer). Signed-off-by: Andrew Pinski Signed-off-by: Philipp Tomsich Signed-off-by: Christoph Muellner Signed-off-by: Yury Norov Reviewed-by: David Daney Signed-off-by: Catalin Marinas

arm64: pass endianness info to sparse

2017-06-26T09:15:06Z

ARM64 depends on the macro __AARCH64EB__ being defined or not to correctly select or define endian-specific macros, structures or pieces of code. This macro is predefined by the compiler but sparse knows nothing about it and thus may pre-process files differently from what gcc would. Fix this by passing '-D__AARCH64EL__' or '-D__AARCH64EB__' to sparse depending of the endianness of the kernel, like defined by GCC. Note: In most case it won't change anything since most arm64 use little-endian (but an allyesconfig would use big-endian!). CC: Catalin Marinas CC: Will Deacon CC: linux-arm-kernel@lists.infradead.org Signed-off-by: Luc Van Oostenryck Signed-off-by: Will Deacon

arm64: pass machine size to sparse

2017-06-20T15:47:16Z

When using sparse on the arm64 tree we get many thousands of warnings like 'constant ... is so big it is unsigned long long' or 'shift too big (32) for type unsigned long'. This happens because by default sparse considers the machine as 32bit and defines the size of the types accordingly. Fix this by passing the '-m64' flag to sparse so that sparse can correctly define longs as being 64bit. CC: Catalin Marinas CC: Will Deacon CC: linux-arm-kernel@lists.infradead.org Signed-off-by: Luc Van Oostenryck Signed-off-by: Will Deacon

arm64: ftrace: add support for far branches to dynamic ftrace

2017-06-07T10:52:02Z

Currently, dynamic ftrace support in the arm64 kernel assumes that all core kernel code is within range of ordinary branch instructions that occur in module code, which is usually the case, but is no longer guaranteed now that we have support for module PLTs and address space randomization. Since on arm64, all patching of branch instructions involves function calls to the same entry point [ftrace_caller()], we can emit the modules with a trampoline that has unlimited range, and patch both the trampoline itself and the branch instruction to redirect the call via the trampoline. Signed-off-by: Ard Biesheuvel [will: minor clarification to smp_wmb() comment] Signed-off-by: Will Deacon

Merge tag 'kbuild-misc-v4.12' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild

2017-05-11T03:41:43Z

Pull misc Kbuild updates from Masahiro Yamada: - clean up builddeb script - use full path for KBUILD_IMAGE to fix rpm-pkg build - fix objdiff tool to ignore debug info * tag 'kbuild-misc-v4.12' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: builddeb: fix typo builddeb: Update a few outdated and hardcoded strings deb-pkg: Remove the KBUILD_IMAGE workaround unicore32: Use full path in KBUILD_IMAGE definition sh: Use full path in KBUILD_IMAGE definition arc: Use full path in KBUILD_IMAGE definition arm: Use full path in KBUILD_IMAGE definition arm64: Use full path in KBUILD_IMAGE definition scripts: objdiff: Ignore debug info when comparing

arm64: Silence spurious kbuild warning on menuconfig

2017-04-12T08:48:03Z

Since bbb56c27228d ("arm64: Add detection code for broken .inst support in binutils"), running any make target that doesn't involve the cross compiler results in a spurious warning: $ make ARCH=arm64 menuconfig arch/arm64/Makefile:43: Detected assembler with broken .inst; disassembly will be unreliable while $ make ARCH=arm64 CROSS_COMPILE=aarch64-arm-linux- menuconfig is silent (assuming your compiler is not affected). That's because the code that tests for the workaround is always run, irrespective of the current configuration being available or not. An easy fix is to make the detection conditional on CONFIG_ARM64 being defined, which is only the case when actually building something. Fixes: bbb56c27228d ("arm64: Add detection code for broken .inst support in binutils") Reviewed-by: Robin Murphy Signed-off-by: Marc Zyngier Signed-off-by: Catalin Marinas

arm64: Use full path in KBUILD_IMAGE definition

2017-03-20T13:42:12Z

The KBUILD_IMAGE variable is used by the rpm and deb-pkg targets, which expect it to point to the image file in the build directory. The builddeb script has a workaround for architectures which only provide the basename, but let's provide a clean interface for packaging tools. Cc: Catalin Marinas Cc: linux-arm-kernel@lists.infradead.org Signed-off-by: Michal Marek Acked-by: Will Deacon Signed-off-by: Masahiro Yamada