aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2019-04-29arm64: mmap: Ensure file offset is treated as unsignedBoyang Zhou1-1/+1
The file offset argument to the arm64 sys_mmap() implementation is scaled from bytes to pages by shifting right by PAGE_SHIFT. Unfortunately, the offset is passed in as a signed 'off_t' type and therefore large offsets (i.e. with the top bit set) are incorrectly sign-extended by the shift. This has been observed to cause false mmap() failures when mapping GPU doorbells on an arm64 server part. Change the type of the file offset argument to sys_mmap() from 'off_t' to 'unsigned long' so that the shifting scales the value as expected. Cc: <[email protected]> Signed-off-by: Boyang Zhou <[email protected]> [will: rewrote commit message] Signed-off-by: Will Deacon <[email protected]>
2019-04-29arm64: Kconfig: Tidy up errata workaround help textWill Deacon1-16/+13
The nature of silicon errata means that the Kconfig help text for our various software workarounds has been written by many different people. Along the way, we've accumulated typos and inconsistencies which make the options needlessly difficult to read. Fix up minor issues with the help text. Signed-off-by: Will Deacon <[email protected]>
2019-04-25arm64: sysreg: Make mrs_s and msr_s macros work with Clang and LTOKees Cook3-19/+38
Clang's integrated assembler does not allow assembly macros defined in one inline asm block using the .macro directive to be used across separate asm blocks. LLVM developers consider this a feature and not a bug, recommending code refactoring: https://bugs.llvm.org/show_bug.cgi?id=19749 As binutils doesn't allow macros to be redefined, this change uses UNDEFINE_MRS_S and UNDEFINE_MSR_S to define corresponding macros in-place and workaround gcc and clang limitations on redefining macros across different assembler blocks. Specifically, the current state after preprocessing looks like this: asm volatile(".macro mXX_s ... .endm"); void f() { asm volatile("mXX_s a, b"); } With GCC, it gives macro redefinition error because sysreg.h is included in multiple source files, and assembler code for all of them is later combined for LTO (I've seen an intermediate file with hundreds of identical definitions). With clang, it gives macro undefined error because clang doesn't allow sharing macros between inline asm statements. I also seem to remember catching another sort of undefined error with GCC due to reordering of macro definition asm statement and generated asm code for function that uses the macro. The solution with defining and undefining for each use, while certainly not elegant, satisfies both GCC and clang, LTO and non-LTO. Co-developed-by: Alex Matveev <[email protected]> Co-developed-by: Yury Norov <[email protected]> Co-developed-by: Sami Tolvanen <[email protected]> Reviewed-by: Nick Desaulniers <[email protected]> Reviewed-by: Mark Rutland <[email protected]> Signed-off-by: Kees Cook <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2019-04-23arm64: Expose SVE2 features for userspaceDave Martin9-1/+108
This patch provides support for reporting the presence of SVE2 and its optional features to userspace. This will also enable visibility of SVE2 for guests, when KVM support for SVE-enabled guests is available. Signed-off-by: Dave Martin <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2019-04-23arm64: Kconfig: Make CONFIG_COMPAT a menuconfig entryWill Deacon1-55/+58
Make CONFIG_COMPAT a menuconfig entry so that we can place CONFIG_KUSER_HELPERS and CONFIG_ARMV8_DEPRECATED underneath it. Signed-off-by: Will Deacon <[email protected]>
2019-04-23arm64: compat: Add KUSER_HELPERS config optionVincenzo Frascino4-5/+39
When kuser helpers are enabled the kernel maps the relative code at a fixed address (0xffff0000). Making configurable the option to disable them means that the kernel can remove this mapping and any access to this memory area results in a sigfault. Add a KUSER_HELPERS config option that can be used to disable the mapping when it is turned off. This option can be turned off if and only if the applications are designed specifically for the platform and they do not make use of the kuser helpers code. Cc: Catalin Marinas <[email protected]> Cc: Will Deacon <[email protected]> Signed-off-by: Vincenzo Frascino <[email protected]> Reviewed-by: Catalin Marinas <[email protected]> [will: Use IS_ENABLED() instead of #ifdef] Signed-off-by: Will Deacon <[email protected]>
2019-04-23arm64: compat: Refactor aarch32_alloc_vdso_pages()Vincenzo Frascino1-26/+26
aarch32_alloc_vdso_pages() needs to be refactored to make it easier to disable kuser helpers. Divide the function in aarch32_alloc_kuser_vdso_page() and aarch32_alloc_sigreturn_vdso_page(). Cc: Catalin Marinas <[email protected]> Cc: Will Deacon <[email protected]> Signed-off-by: Vincenzo Frascino <[email protected]> Reviewed-by: Catalin Marinas <[email protected]> [will: Inlined sigpage allocation to simplify error paths] Signed-off-by: Will Deacon <[email protected]>
2019-04-23arm64: compat: Split kuser32Vincenzo Frascino3-57/+50
To make it possible to disable kuser helpers in aarch32 we need to divide the kuser and the sigreturn functionalities. Split the current version of kuser32 in kuser32 (for kuser helpers) and sigreturn32 (for sigreturn helpers). Cc: Catalin Marinas <[email protected]> Cc: Will Deacon <[email protected]> Signed-off-by: Vincenzo Frascino <[email protected]> Reviewed-by: Catalin Marinas <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2019-04-23arm64: compat: Alloc separate pages for vectors and sigpageVincenzo Frascino4-34/+93
For AArch32 tasks, we install a special "[vectors]" page that contains the sigreturn trampolines and kuser helpers, which is mapped at a fixed address specified by the kuser helpers ABI. Having the sigreturn trampolines in the same page as the kuser helpers makes it impossible to disable the kuser helpers independently. Follow the Arm implementation, by moving the signal trampolines out of the "[vectors]" page and into their own "[sigpage]". Cc: Catalin Marinas <[email protected]> Cc: Will Deacon <[email protected]> Signed-off-by: Vincenzo Frascino <[email protected]> Reviewed-by: Catalin Marinas <[email protected]> [will: tweaked comments and fixed sparse warning] Signed-off-by: Will Deacon <[email protected]>
2019-04-16ACPI/IORT: Reject platform device creation on NUMA node mapping failureKefeng Wang1-5/+14
In a system where, through IORT firmware mappings, the SMMU device is mapped to a NUMA node that is not online, the kernel bootstrap results in the following crash: Unable to handle kernel paging request at virtual address 0000000000001388 Mem abort info: ESR = 0x96000004 Exception class = DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 Data abort info: ISV = 0, ISS = 0x00000004 CM = 0, WnR = 0 [0000000000001388] user address but active_mm is swapper Internal error: Oops: 96000004 [#1] SMP Modules linked in: CPU: 5 PID: 1 Comm: swapper/0 Not tainted 5.0.0 #15 pstate: 80c00009 (Nzcv daif +PAN +UAO) pc : __alloc_pages_nodemask+0x13c/0x1068 lr : __alloc_pages_nodemask+0xdc/0x1068 ... Process swapper/0 (pid: 1, stack limit = 0x(____ptrval____)) Call trace: __alloc_pages_nodemask+0x13c/0x1068 new_slab+0xec/0x570 ___slab_alloc+0x3e0/0x4f8 __slab_alloc+0x60/0x80 __kmalloc_node_track_caller+0x10c/0x478 devm_kmalloc+0x44/0xb0 pinctrl_bind_pins+0x4c/0x188 really_probe+0x78/0x2b8 driver_probe_device+0x64/0x110 device_driver_attach+0x74/0x98 __driver_attach+0x9c/0xe8 bus_for_each_dev+0x84/0xd8 driver_attach+0x30/0x40 bus_add_driver+0x170/0x218 driver_register+0x64/0x118 __platform_driver_register+0x54/0x60 arm_smmu_driver_init+0x24/0x2c do_one_initcall+0xbc/0x328 kernel_init_freeable+0x304/0x3ac kernel_init+0x18/0x110 ret_from_fork+0x10/0x1c Code: f90013b5 b9410fa1 1a9f0694 b50014c2 (b9400804) ---[ end trace dfeaed4c373a32da ]-- Change the dev_set_proximity() hook prototype so that it returns a value and make it return failure if the PXM->NUMA-node mapping corresponds to an offline node, fixing the crash. Acked-by: Lorenzo Pieralisi <[email protected]> Signed-off-by: Kefeng Wang <[email protected]> Link: https://lore.kernel.org/linux-arm-kernel/[email protected]/ Signed-off-by: Will Deacon <[email protected]>
2019-04-16arm64: vdso: Fix clock_getres() for CLOCK_REALTIMEVincenzo Frascino4-5/+8
clock_getres() in the vDSO library has to preserve the same behaviour of posix_get_hrtimer_res(). In particular, posix_get_hrtimer_res() does: sec = 0; ns = hrtimer_resolution; where 'hrtimer_resolution' depends on whether or not high resolution timers are enabled, which is a runtime decision. The vDSO incorrectly returns the constant CLOCK_REALTIME_RES. Fix this by exposing 'hrtimer_resolution' in the vDSO datapage and returning that instead. Reviewed-by: Catalin Marinas <[email protected]> Signed-off-by: Vincenzo Frascino <[email protected]> [will: Use WRITE_ONCE(), move adr off COARSE path, renumber labels, use 'w' reg] Signed-off-by: Will Deacon <[email protected]>
2019-04-16arm64: Use the correct style for SPDX License IdentifierNishad Kamdar4-4/+4
This patch corrects the SPDX License Identifier style in the arm64 Hardware Architecture related files. Suggested-by: Joe Perches <[email protected]> Signed-off-by: Nishad Kamdar <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2019-04-16arm64: instrument smp_{load_acquire,store_release}Mark Rutland1-9/+15
Our __smp_store_release() and __smp_load_acquire() macros use inline assembly, which is opaque to kasan. This means that kasan can't catch erroneous use of these. This patch adds kasan instrumentation to both. Cc: Catalin Marinas <[email protected]> Signed-off-by: Mark Rutland <[email protected]> [will: consistently use *p as argument to sizeof] Signed-off-by: Will Deacon <[email protected]>
2019-04-16arm64: mm: check virtual addr in virt_to_page() if CONFIG_DEBUG_VIRTUAL=yMiles Chen1-1/+1
This change uses the original virt_to_page() (the one with __pa()) to check the given virtual address if CONFIG_DEBUG_VIRTUAL=y. Recently, I worked on a bug: a driver passes a symbol address to dma_map_single() and the virt_to_page() (called by dma_map_single()) does not work for non-linear addresses after commit 9f2875912dac ("arm64: mm: restrict virt_to_page() to the linear mapping"). I tried to trap the bug by enabling CONFIG_DEBUG_VIRTUAL but it did not work - bacause the commit removes the __pa() from virt_to_page() but CONFIG_DEBUG_VIRTUAL checks the virtual address in __pa()/__virt_to_phys(). A simple solution is to use the original virt_to_page() (the one with__pa()) if CONFIG_DEBUG_VIRTUAL=y. Cc: Ard Biesheuvel <[email protected]> Acked-by: Catalin Marinas <[email protected]> Signed-off-by: Miles Chen <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2019-04-16arm64: Advertise ARM64_HAS_DCPODP cpu featureAndrew Murray2-1/+12
Advertise ARM64_HAS_DCPODP when both DC CVAP and DC CVADP are supported. Even though we don't use this feature now, we provide it for consistency with DCPOP and anticipate it being used in the future. Signed-off-by: Andrew Murray <[email protected]> Reviewed-by: Dave Martin <[email protected]> Reviewed-by: Suzuki K Poulose <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2019-04-16arm64: add CVADP support to the cache maintenance helperAndrew Murray1-0/+4
Allow users of dcache_by_line_op to specify cvadp as an op. Signed-off-by: Andrew Murray <[email protected]> Reviewed-by: Dave Martin <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2019-04-16arm64: Expose DC CVADP to userspaceAndrew Murray5-0/+12
ARMv8.5 builds upon the ARMv8.2 DC CVAP instruction by introducing a DC CVADP instruction which cleans the data cache to the point of deep persistence. Let's expose this support via the arm64 ELF hwcaps. Signed-off-by: Andrew Murray <[email protected]> Reviewed-by: Dave Martin <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2019-04-16arm64: Handle trapped DC CVADPAndrew Murray2-1/+5
The ARMv8.5 DC CVADP instruction may be trapped to EL1 via SCTLR_EL1.UCI therefore let's provide a handler for it. Just like the CVAP instruction we use a 'sys' instruction instead of the 'dc' alias to avoid build issues with older toolchains. Signed-off-by: Andrew Murray <[email protected]> Reviewed-by: Mark Rutland <[email protected]> Reviewed-by: Dave Martin <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2019-04-16arm64: HWCAP: encapsulate elf_hwcapAndrew Murray3-17/+38
The introduction of AT_HWCAP2 introduced accessors which ensure that hwcap features are set and tested appropriately. Let's now mandate access to elf_hwcap via these accessors by making elf_hwcap static within cpufeature.c. Signed-off-by: Andrew Murray <[email protected]> Reviewed-by: Dave Martin <[email protected]> Reviewed-by: Suzuki K Poulose <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2019-04-16arm64: HWCAP: add support for AT_HWCAP2Andrew Murray15-63/+130
As we will exhaust the first 32 bits of AT_HWCAP let's start exposing AT_HWCAP2 to userspace to give us up to 64 caps. Whilst it's possible to use the remaining 32 bits of AT_HWCAP, we prefer to expand into AT_HWCAP2 in order to provide a consistent view to userspace between ILP32 and LP64. However internal to the kernel we prefer to continue to use the full space of elf_hwcap. To reduce complexity and allow for future expansion, we now represent hwcaps in the kernel as ordinals and use a KERNEL_HWCAP_ prefix. This allows us to support automatic feature based module loading for all our hwcaps. We introduce cpu_set_feature to set hwcaps which complements the existing cpu_have_feature helper. These helpers allow us to clean up existing direct uses of elf_hwcap and reduce any future effort required to move beyond 64 caps. For convenience we also introduce cpu_{have,set}_named_feature which makes use of the cpu_feature macro to allow providing a hwcap name without a {KERNEL_}HWCAP_ prefix. Signed-off-by: Andrew Murray <[email protected]> [will: use const_ilog2() and tweak documentation] Signed-off-by: Will Deacon <[email protected]>
2019-04-12arm64: ptrace: Add function argument access APIMasami Hiramatsu2-0/+23
Add regs_get_argument() which returns N th argument of the function call. On arm64, it supports up to 8th argument. Note that this chooses most probably assignment, in some case it can be incorrect (e.g. passing data structure or floating point etc.) This enables ftrace kprobe events to access kernel function arguments via $argN syntax. Signed-off-by: Masami Hiramatsu <[email protected]> [will: tidied up the comment a bit] Signed-off-by: Will Deacon <[email protected]>
2019-04-11arm64: vdso: use $(LD) instead of $(CC) to link VDSOMasahiro Yamada1-10/+3
We use $(LD) to link vmlinux, modules, decompressors, etc. VDSO is the only exceptional case where $(CC) is used as the linker driver, but I do not know why we need to do so. VDSO uses a special linker script, and does not link standard libraries at all. I changed the Makefile to use $(LD) rather than $(CC). I tested this, and VDSO worked for me. Users will be able to use their favorite linker (e.g. lld instead of of bfd) by passing LD= from the command line. My plan is to rewrite all VDSO Makefiles to use $(LD), then delete cc-ldoption. Signed-off-by: Masahiro Yamada <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2019-04-10arm64: compat: Reduce address limitVincenzo Frascino1-0/+8
Currently, compat tasks running on arm64 can allocate memory up to TASK_SIZE_32 (UL(0x100000000)). This means that mmap() allocations, if we treat them as returning an array, are not compliant with the sections 6.5.8 of the C standard (C99) which states that: "If the expression P points to an element of an array object and the expression Q points to the last element of the same array object, the pointer expression Q+1 compares greater than P". Redefine TASK_SIZE_32 to address the issue. Cc: Catalin Marinas <[email protected]> Cc: Will Deacon <[email protected]> Cc: Jann Horn <[email protected]> Cc: <[email protected]> Reported-by: Jann Horn <[email protected]> Signed-off-by: Vincenzo Frascino <[email protected]> [will: fixed typo in comment] Signed-off-by: Will Deacon <[email protected]>
2019-04-09arm64: Save and restore OSDLR_EL1 across suspend/resumeJean-Philippe Brucker1-16/+18
When the CPU comes out of suspend, the firmware may have modified the OS Double Lock Register. Save it in an unused slot of cpu_suspend_ctx, and restore it on resume. Cc: <[email protected]> Signed-off-by: Jean-Philippe Brucker <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2019-04-09arm64: Clear OSDLR_EL1 on CPU bootJean-Philippe Brucker1-0/+1
Some firmwares may reboot CPUs with OS Double Lock set. Make sure that it is unlocked, in order to use debug exceptions. Cc: <[email protected]> Signed-off-by: Jean-Philippe Brucker <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2019-04-09arm64: mm: Consolidate early page table allocationWill Deacon1-11/+7
The logic for early allocation of page tables is duplicated between pgd_kernel_pgtable_alloc() and pgd_pgtable_alloc(). Drop the duplication by calling one from the other and renaming pgd_kernel_pgtable_alloc() accordingly. Signed-off-by: Will Deacon <[email protected]>
2019-04-09arm64: mm: enable per pmd page table lockYu Zhao3-2/+18
Switch from per mm_struct to per pmd page table lock by enabling ARCH_ENABLE_SPLIT_PMD_PTLOCK. This provides better granularity for large system. I'm not sure if there is contention on mm->page_table_lock. Given the option comes at no cost (apart from initializing more spin locks), why not enable it now. We only do so when pmd is not folded, so we don't mistakenly call pgtable_pmd_page_ctor() on pud or p4d in pgd_pgtable_alloc(). Signed-off-by: Yu Zhao <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2019-04-09KVM: ARM: Remove pgtable page standard functions from stage-2 page tablesAnshuman Khandual3-5/+5
ARM64 standard pgtable functions are going to use pgtable_page_[ctor|dtor] or pgtable_pmd_page_[ctor|dtor] constructs. At present KVM guest stage-2 PUD|PMD|PTE level page tabe pages are allocated with __get_free_page() via mmu_memory_cache_alloc() but released with standard pud|pmd_free() or pte_free_kernel(). These will fail once they start calling into pgtable_ [pmd]_page_dtor() for pages which never originally went through respective constructor functions. Hence convert all stage-2 page table page release functions to call buddy directly while freeing pages. Reviewed-by: Suzuki K Poulose <[email protected]> Acked-by: Yu Zhao <[email protected]> Acked-by: Marc Zyngier <[email protected]> Signed-off-by: Anshuman Khandual <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2019-04-09arm64: mm: don't call page table ctors for init_mmYu Zhao1-2/+13
init_mm doesn't require page table lock to be initialized at any level. Add a separate page table allocator for it, and the new one skips page table ctors. The ctors allocate memory when ALLOC_SPLIT_PTLOCKS is set. Not calling them avoids memory leak in case we call pte_free_kernel() on init_mm. Acked-by: Mark Rutland <[email protected]> Signed-off-by: Yu Zhao <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2019-04-09arm64: mm: use appropriate ctors for page tablesYu Zhao1-12/+24
For pte page, use pgtable_page_ctor(); for pmd page, use pgtable_pmd_page_ctor(); and for the rest (pud, p4d and pgd), don't use any. For now, we don't select ARCH_ENABLE_SPLIT_PMD_PTLOCK and pgtable_pmd_page_ctor() is a nop. When we do in patch 3, we make sure pmd is not folded so we won't mistakenly call pgtable_pmd_page_ctor() on pud or p4d. Acked-by: Mark Rutland <[email protected]> Signed-off-by: Yu Zhao <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2019-04-09arm64: debug: Clean up brk_handler()Will Deacon1-6/+4
brk_handler() now looks pretty strange and can be refactored to drop its funny 'handler_found' local variable altogether. Reviewed-by: Mark Rutland <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2019-04-09arm64: probes: Move magic BRK values into brk-imm.hWill Deacon7-12/+11
kprobes and uprobes reserve some BRK immediates for installing their probes. Define these along with the other reservations in brk-imm.h and rename the ESR definitions to be consistent with the others that we already have. Reviewed-by: Mark Rutland <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2019-04-09arm64: debug: Remove redundant user_mode(regs) checks from debug handlersWill Deacon4-27/+5
Now that the debug hook dispatching code takes the triggering exception level into account, there's no need for the hooks themselves to poke around with user_mode(regs). Reviewed-by: Mark Rutland <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2019-04-09arm64: kprobes: Avoid calling kprobes debug handlers explicitlyWill Deacon3-14/+14
Kprobes bypasses our debug hook registration code so that it doesn't get tangled up with recursive debug exceptions from things like lockdep: http://lists.infradead.org/pipermail/linux-arm-kernel/2015-February/324385.html However, since then, (a) the hook list has become RCU protected and (b) the kprobes hooks were found not to filter out exceptions from userspace correctly. On top of that, the step handler is invoked directly from single_step_handler(), which *does* use the debug hook list, so it's clearly not the end of the world. For now, have kprobes use the debug hook registration API like everybody else. We can revisit this in the future if this is found to limit coverage significantly. Reviewed-by: Mark Rutland <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2019-04-09arm64: debug: Separate debug hooks based on target exception levelWill Deacon6-58/+95
Mixing kernel and user debug hooks together is highly error-prone as it relies on all of the hooks to figure out whether the exception came from kernel or user, and then to act accordingly. Make our debug hook code a little more robust by maintaining separate hook lists for user and kernel, with separate registration functions to force callers to be explicit about the exception levels that they care about. Reviewed-by: Mark Rutland <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2019-04-09arm64: debug: Remove meaningless commentWill Deacon1-5/+0
The comment next to the definition of our 'break_hook' list head is at best wrong but mainly just meaningless. Rip it out. Reviewed-by: Mark Rutland <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2019-04-09arm64: debug: Rename addr parameter for non-watchpoint exception hooksWill Deacon1-2/+2
Since the 'addr' parameter contains an UNKNOWN value for non-watchpoint debug exceptions, rename it to 'unused' for those hooks so we don't get tempted to use it in the future. Reviewed-by: Mark Rutland <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2019-04-09arm64: debug: Remove unused return value from do_debug_exception()Will Deacon1-10/+4
do_debug_exception() goes out of its way to return a value that isn't ever used, so just make the thing void. Reviewed-by: Mark Rutland <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2019-04-09kasan: Makefile: Replace -pg with CC_FLAGS_FTRACETorsten Duwe1-3/+3
In preparation for arm64 supporting ftrace built on other compiler options, let's have Makefiles remove the $(CC_FLAGS_FTRACE) flags, whatever these may be, rather than assuming '-pg'. There should be no functional change as a result of this patch. Reviewed-by: Mark Rutland <[email protected]> Acked-by: Andrey Ryabinin <[email protected]> Signed-off-by: Torsten Duwe <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2019-04-09efi/arm/arm64: Makefile: Replace -pg with CC_FLAGS_FTRACETorsten Duwe1-3/+3
In preparation for arm64 supporting ftrace built on other compiler options, let's have Makefiles remove the $(CC_FLAGS_FTRACE) flags, whatever these maybe, rather than assuming '-pg'. While at it, fix arm32 as well. There should be no functional change as a result of this patch. Reviewed-by: Mark Rutland <[email protected]> Acked-by: Ard Biesheuvel <[email protected]> Signed-off-by: Torsten Duwe <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2019-04-09arm64: Makefile: Replace -pg with CC_FLAGS_FTRACETorsten Duwe2-4/+4
In preparation for arm64 supporting ftrace built on other compiler options, let's have the arm64 Makefiles remove the $(CC_FLAGS_FTRACE) flags, whatever these may be, rather than assuming '-pg'. There should be no functional change as a result of this patch. Reviewed-by: Mark Rutland <[email protected]> Signed-off-by: Torsten Duwe <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2019-04-05arm64: Use defines instead of magic numbersAlexandru Elisei2-7/+7
Following assembly code is not trivial; make it slightly easier to read by replacing some of the magic numbers with the defines which are already present in sysreg.h. Reviewed-by: Dave Martin <[email protected]> Signed-off-by: Alexandru Elisei <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2019-04-03arm64: vdso: fix and clean-up MakefileMasahiro Yamada1-5/+3
- $(call if_changed,...) must have FORCE as a prerequisite - vdso.lds is a generated file, so it should be prefixed with $(obj)/ instead of $(src)/. - cmd_vdsosym is a one-liner rule, so the assignment with '=' is simpler. Signed-off-by: Masahiro Yamada <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2019-04-03arm64: mm: Ensure we ignore the initrd if it is placed out of rangeWill Deacon1-1/+1
If the initrd payload isn't completely accessible via the linear map, then we print a warning during boot and nobble the virtual address of the payload so that we ignore it later on. Unfortunately, since commit c756c592e442 ("arm64: Utilize phys_initrd_start/phys_initrd_size"), the virtual address isn't initialised until later anyway, so we need to nobble the size of the payload to ensure that we don't try to use it later on. Fixes: c756c592e442 ("arm64: Utilize phys_initrd_start/phys_initrd_size") Reported-by: Pierre Kuo <[email protected]> Acked-by: Florian Fainelli <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2019-04-03arm64: cpu_ops: fix a leaked reference by adding missing of_node_putWen Yang1-0/+1
The call to of_get_next_child returns a node pointer with refcount incremented thus it must be explicitly decremented after the last usage. Detected by coccinelle with the following warnings: ./arch/arm64/kernel/cpu_ops.c:102:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 69, but without a corresponding object release within this function. Signed-off-by: Wen Yang <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Cc: Catalin Marinas <[email protected]> Cc: Will Deacon <[email protected]> Cc: [email protected] Cc: [email protected] Signed-off-by: Will Deacon <[email protected]>
2019-04-03arm64: mm: Make show_pte() a static functionWill Deacon2-2/+1
show_pte() doesn't have any external callers, so make it static. Signed-off-by: Will Deacon <[email protected]>
2019-04-03arm64/vdso: don't leak kernel addressesMatteo Croce1-2/+0
Since commit ad67b74d2469d9b8 ("printk: hash addresses printed with %p"), two obfuscated kernel pointer are printed at every boot: vdso: 2 pages (1 code @ (____ptrval____), 1 data @ (____ptrval____)) Remove the the print completely, as it's useless without the addresses. Fixes: ad67b74d2469d9b8 ("printk: hash addresses printed with %p") Acked-by: Mark Rutland <[email protected]> Signed-off-by: Matteo Croce <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2019-04-03arm64: setup min_low_pfnMiles Chen1-0/+1
When debugging with CONFIG_PAGE_OWNER, I noticed that the min_low_pfn on arm64 is always zero and the page owner scanning has to start from zero. We have to loop a while before we see the first valid pfn. (see: read_page_owner()) Setup min_low_pfn to save some loops. Before setting min_low_pfn: [ 21.265602] min_low_pfn=0, *ppos=0 Page allocated via order 0, mask 0x100cca(GFP_HIGHUSER_MOVABLE) PFN 262144 type Movable Block 512 type Movable Flags 0x8001e referenced|uptodate|dirty|lru|swapbacked) prep_new_page+0x13c/0x140 get_page_from_freelist+0x254/0x1068 __alloc_pages_nodemask+0xd4/0xcb8 After setting min_low_pfn: [ 11.025787] min_low_pfn=262144, *ppos=0 Page allocated via order 0, mask 0x100cca(GFP_HIGHUSER_MOVABLE) PFN 262144 type Movable Block 512 type Movable Flags 0x8001e referenced|uptodate|dirty|lru|swapbacked) prep_new_page+0x13c/0x140 get_page_from_freelist+0x254/0x1068 __alloc_pages_nodemask+0xd4/0xcb8 shmem_alloc_page+0x7c/0xa0 shmem_alloc_and_acct_page+0x124/0x1e8 shmem_getpage_gfp.isra.7+0x118/0x878 shmem_write_begin+0x38/0x68 Signed-off-by: Miles Chen <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2019-04-03arm64/mm: fix kernel-doc commentsQian Cai1-13/+12
Building a kernel with W=1 generates several warnings due to abuse of kernel-doc comments: | arch/arm64/mm/numa.c:281: warning: Cannot understand * | on line 281 - I thought it was a doc line Tidy up the comments to remove the warnings. Fixes: 1a2db300348b ("arm64, numa: Add NUMA support for arm64 platforms.") Signed-off-by: Qian Cai <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2019-04-01arm64: mm: fix incorrect assignment of 'max_mapnr'Muchun Song1-1/+1
Although we don't actually make use of the 'max_mapnr' global variable, we do set it to a junk value for !CONFIG_FLATMEM configurations that leave mem_map uninitialised. To avoid somebody tripping over this in future, set 'max_mapnr' using max_pfn, which is calculated directly from the memblock information. Reviewed-by: Catalin Marinas <[email protected]> Signed-off-by: Muchun Song <[email protected]> Signed-off-by: Will Deacon <[email protected]>