summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)Author
2021-02-14Merge tag 'kbuild-fixes-v5.11-3' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild Pull Kbuild fixes from Masahiro Yamada: - Fix CONFIG_TRIM_UNUSED_KSYMS build for ppc64 - Use pkg-config for scripts/sign-file.c CFLAGS * tag 'kbuild-fixes-v5.11-3' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: scripts: set proper OpenSSL include dir also for sign-file sparc: remove wrong comment from arch/sparc/include/asm/Kbuild kbuild: fix CONFIG_TRIM_UNUSED_KSYMS build for ppc64
2021-02-14Merge tag 'x86_urgent_for_v5.11' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 fixes from Borislav Petkov: "I kinda knew while typing 'I hope this is the last batch of x86/urgent updates' last week, Murphy was reading too and uttered 'Hold my beer!'. So here's more fixes... Thanks Murphy. Anyway, three more x86/urgent fixes for 5.11 final. We should be finally ready (famous last words). :-) - An SGX use after free fix - A fix for the fix to disable CET instrumentation generation for kernel code. We forgot 32-bit, which we seem to do very often nowadays - A Xen PV fix to irqdomain init ordering" * tag 'x86_urgent_for_v5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/pci: Create PCI/MSI irqdomain after x86_init.pci.arch_init() x86/build: Disable CET instrumentation in the kernel for 32-bit too x86/sgx: Maintain encl->refcount for each encl->mm_list entry
2021-02-15sparc: remove wrong comment from arch/sparc/include/asm/KbuildMasahiro Yamada
These are NOT exported to userspace. The headers listed in arch/sparc/include/uapi/asm/Kbuild are exported. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2021-02-13Merge branch 'akpm' (patches from Andrew)Linus Torvalds
Merge fixes from Andrew Morton: "6 patches. Subsystems affected by this patch series: mm/pagemap, scripts, MAINTAINERS, and h8300" * emailed patches from Andrew Morton <akpm@linux-foundation.org>: h8300: fix PREEMPTION build, TI_PRE_COUNT undefined MAINTAINERS: add Andrey Konovalov to KASAN reviewers MAINTAINERS: update Andrey Konovalov's email address MAINTAINERS: update KASAN file list scripts/recordmcount.pl: support big endian for ARCH sh m68k: make __pfn_to_phys() and __phys_to_pfn() available for !MMU
2021-02-13h8300: fix PREEMPTION build, TI_PRE_COUNT undefinedRandy Dunlap
Fix a build error for undefined 'TI_PRE_COUNT' by adding it to asm-offsets.c. h8300-linux-ld: arch/h8300/kernel/entry.o: in function `resume_kernel': (.text+0x29a): undefined reference to `TI_PRE_COUNT' Link: https://lkml.kernel.org/r/20210212021650.22740-1-rdunlap@infradead.org Fixes: df2078b8daa7 ("h8300: Low level entry") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Reported-by: kernel test robot <lkp@intel.com> Cc: Yoshinori Sato <ysato@users.sourceforge.jp> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-02-13m68k: make __pfn_to_phys() and __phys_to_pfn() available for !MMUMike Rapoport
Recent changes that obsoleted DISCONTIGMEM on m68k switched the MMU variant to use generic definitions of __pfn_to_phys() and __phys_to_pfn(), but missed the !MMU variant which caused a build failure: drivers/media/common/videobuf2/videobuf2-dma-contig.c: In function 'vb2_dc_get_userptr': drivers/media/common/videobuf2/videobuf2-dma-contig.c:509:5: error: implicit declaration of function '__pfn_to_phys' [-Werror=implicit-function-declaration] 509 | __pfn_to_phys(nums[0]), size, buf->dma_dir, 0); | ^~~~~~~~~~~~~ cc1: some warnings being treated as errors Enable __pfn_to_phys() and __phys_to_pfn() on !MMU builds. Link: https://lkml.kernel.org/r/20210211232202.GS299309@linux.ibm.com Fixes: 4bfc848e0981 ("m68k/mm: enable use of generic memory_model.h for !DISCONTIGMEM") Signed-off-by: Mike Rapoport <rppt@linux.ibm.com> Reported-by: kernel test robot <lkp@intel.com> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Greg Ungerer <gerg@linux-m68k.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-02-12Merge tag 'for-linus-5.11-rc8-tag' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip Pull xen fix from Juergen Gross: "A single fix for an issue introduced this development cycle: when running as a Xen guest on Arm systems the kernel will hang during boot" * tag 'for-linus-5.11-rc8-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip: arm/xen: Don't probe xenbus as part of an early initcall
2021-02-12Merge tag 'riscv-for-linus-5.11-rc8' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux Pull RISC-V fix from Palmer Dabbelt: "A single fix this week: the removal of the GPIO reset method for the Ethernet phy on the HiFive Unleashed. This returns to relying on the bootloader's phy reset sequence, which we'll have to continue doing until we can sort out how to get the Linux phy driver to perform the special reset dance required for this phy" * tag 'riscv-for-linus-5.11-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux: Revert "dts: phy: add GPIO number and active state used for phy reset"
2021-02-12Merge tag 'arm64-fixes' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux Pull arm64 fix from Catalin Marinas: "Fix PTRACE_PEEKMTETAGS access to an mmapped region before the first write" * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: arm64: mte: Allow PTRACE_PEEKMTETAGS access to the zero page
2021-02-12arm64: mte: Allow PTRACE_PEEKMTETAGS access to the zero pageCatalin Marinas
The ptrace(PTRACE_PEEKMTETAGS) implementation checks whether the user page has valid tags (mapped with PROT_MTE) by testing the PG_mte_tagged page flag. If this bit is cleared, ptrace(PTRACE_PEEKMTETAGS) returns -EIO. A newly created (PROT_MTE) mapping points to the zero page which had its tags zeroed during cpu_enable_mte(). If there were no prior writes to this mapping, ptrace(PTRACE_PEEKMTETAGS) fails with -EIO since the zero page does not have the PG_mte_tagged flag set. Set PG_mte_tagged on the zero page when its tags are cleared during boot. In addition, to avoid ptrace(PTRACE_PEEKMTETAGS) succeeding on !PROT_MTE mappings pointing to the zero page, change the __access_remote_tags() check to (vm_flags & VM_MTE) instead of PG_mte_tagged. Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Fixes: 34bfeea4a9e9 ("arm64: mte: Clear the tags when a page is mapped in user-space with PROT_MTE") Cc: <stable@vger.kernel.org> # 5.10.x Cc: Will Deacon <will@kernel.org> Reported-by: Luis Machado <luis.machado@linaro.org> Tested-by: Luis Machado <luis.machado@linaro.org> Reviewed-by: Vincenzo Frascino <vincenzo.frascino@arm.com> Link: https://lore.kernel.org/r/20210210180316.23654-1-catalin.marinas@arm.com
2021-02-11Merge tag 'powerpc-5.11-8' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux Pull powerpc fix from Michael Ellerman: "One fix for a regression seen in io_uring, introduced by our support for KUAP (Kernel User Access Prevention) with the Hash MMU. Thanks to Aneesh Kumar K.V, and Zorro Lang" * tag 'powerpc-5.11-8' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux: powerpc/kuap: Allow kernel thread to access userspace after kthread_use_mm
2021-02-11arm/xen: Don't probe xenbus as part of an early initcallJulien Grall
After Commit 3499ba8198cad ("xen: Fix event channel callback via INTX/GSI"), xenbus_probe() will be called too early on Arm. This will recent to a guest hang during boot. If the hang wasn't there, we would have ended up to call xenbus_probe() twice (the second time is in xenbus_probe_initcall()). We don't need to initialize xenbus_probe() early for Arm guest. Therefore, the call in xen_guest_init() is now removed. After this change, there is no more external caller for xenbus_probe(). So the function is turned to a static one. Interestingly there were two prototypes for it. Cc: stable@vger.kernel.org Fixes: 3499ba8198cad ("xen: Fix event channel callback via INTX/GSI") Reported-by: Ian Jackson <iwj@xenproject.org> Signed-off-by: Julien Grall <jgrall@amazon.com> Reviewed-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> Link: https://lore.kernel.org/r/20210210170654.5377-1-julien@xen.org Signed-off-by: Juergen Gross <jgross@suse.com>
2021-02-10Revert "dts: phy: add GPIO number and active state used for phy reset"Palmer Dabbelt
VSC8541 phys need a special reset sequence, which the driver doesn't currentlny support. As a result enabling the reset via GPIO essentially guarnteees that the device won't work correctly. We've been relying on bootloaders to reset the device for years, with this revert we'll go back to doing so until we can sort out how to get the reset sequence into the kernel. This reverts commit a0fa9d727043da2238432471e85de0bdb8a8df65. Fixes: a0fa9d727043 ("dts: phy: add GPIO number and active state used for phy reset") Cc: stable@vger.kernel.org Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
2021-02-10x86/pci: Create PCI/MSI irqdomain after x86_init.pci.arch_init()Thomas Gleixner
Invoking x86_init.irqs.create_pci_msi_domain() before x86_init.pci.arch_init() breaks XEN PV. The XEN_PV specific pci.arch_init() function overrides the default create_pci_msi_domain() which is obviously too late. As a consequence the XEN PV PCI/MSI allocation goes through the native path which runs out of vectors and causes malfunction. Invoke it after x86_init.pci.arch_init(). Fixes: 6b15ffa07dc3 ("x86/irq: Initialize PCI/MSI domain at PCI init time") Reported-by: Juergen Gross <jgross@suse.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Juergen Gross <jgross@suse.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/87pn18djte.fsf@nanos.tec.linutronix.de
2021-02-09x86/build: Disable CET instrumentation in the kernel for 32-bit tooBorislav Petkov
Commit 20bf2b378729 ("x86/build: Disable CET instrumentation in the kernel") disabled CET instrumentation which gets added by default by the Ubuntu gcc9 and 10 by default, but did that only for 64-bit builds. It would still fail when building a 32-bit target. So disable CET for all x86 builds. Fixes: 20bf2b378729 ("x86/build: Disable CET instrumentation in the kernel") Reported-by: AC <achirvasub@gmail.com> Signed-off-by: Borislav Petkov <bp@suse.de> Acked-by: Josh Poimboeuf <jpoimboe@redhat.com> Tested-by: AC <achirvasub@gmail.com> Link: https://lkml.kernel.org/r/YCCIgMHkzh/xT4ex@arch-chirva.localdomain
2021-02-08x86/sgx: Maintain encl->refcount for each encl->mm_list entryJarkko Sakkinen
This has been shown in tests: [ +0.000008] WARNING: CPU: 3 PID: 7620 at kernel/rcu/srcutree.c:374 cleanup_srcu_struct+0xed/0x100 This is essentially a use-after free, although SRCU notices it as an SRCU cleanup in an invalid context. == Background == SGX has a data structure (struct sgx_encl_mm) which keeps per-mm SGX metadata. This is separate from struct sgx_encl because, in theory, an enclave can be mapped from more than one mm. sgx_encl_mm includes a pointer back to the sgx_encl. This means that sgx_encl must have a longer lifetime than all of the sgx_encl_mm's that point to it. That's usually the case: sgx_encl_mm is freed only after the mmu_notifier is unregistered in sgx_release(). However, there's a race. If the process is exiting, sgx_mmu_notifier_release() can be called in parallel with sgx_release() instead of being called *by* it. The mmu_notifier path keeps encl_mm alive past when sgx_encl can be freed. This inverts the lifetime rules and means that sgx_mmu_notifier_release() can access a freed sgx_encl. == Fix == Increase encl->refcount when encl_mm->encl is established. Release this reference when encl_mm is freed. This ensures that encl outlives encl_mm. [ bp: Massage commit message. ] Fixes: 1728ab54b4be ("x86/sgx: Add a page reclaimer") Reported-by: Haitao Huang <haitao.huang@linux.intel.com> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Borislav Petkov <bp@suse.de> Acked-by: Dave Hansen <dave.hansen@linux.intel.com> Link: https://lkml.kernel.org/r/20210207221401.29933-1-jarkko@kernel.org
2021-02-08cpufreq: ACPI: Update arch scale-invariance max perf ratio if CPPC is not thereRafael J. Wysocki
If the maximum performance level taken for computing the arch_max_freq_ratio value used in the x86 scale-invariance code is higher than the one corresponding to the cpuinfo.max_freq value coming from the acpi_cpufreq driver, the scale-invariant utilization falls below 100% even if the CPU runs at cpuinfo.max_freq or slightly faster, which causes the schedutil governor to select a frequency below cpuinfo.max_freq. That frequency corresponds to a frequency table entry below the maximum performance level necessary to get to the "boost" range of CPU frequencies which prevents "boost" frequencies from being used in some workloads. While this issue is related to scale-invariance, it may be amplified by commit db865272d9c4 ("cpufreq: Avoid configuring old governors as default with intel_pstate") from the 5.10 development cycle which made it extremely easy to default to schedutil even if the preferred driver is acpi_cpufreq as long as intel_pstate is built too, because the mere presence of the latter effectively removes the ondemand governor from the defaults. Distro kernels are likely to include both intel_pstate and acpi_cpufreq on x86, so their users who cannot use intel_pstate or choose to use acpi_cpufreq may easily be affectecd by this issue. If CPPC is available, it can be used to address this issue by extending the frequency tables created by acpi_cpufreq to cover the entire available frequency range (including "boost" frequencies) for each CPU, but if CPPC is not there, acpi_cpufreq has no idea what the maximum "boost" frequency is and the frequency tables created by it cannot be extended in a meaningful way, so in that case make it ask the arch scale-invariance code to to use the "nominal" performance level for CPU utilization scaling in order to avoid the issue at hand. Fixes: db865272d9c4 ("cpufreq: Avoid configuring old governors as default with intel_pstate") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Giovanni Gherdovich <ggherdovich@suse.cz> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
2021-02-07Merge tag 'core_urgent_for_v5.11_rc7' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull syscall entry fixes from Borislav Petkov: - For syscall user dispatch, separate prctl operation from syscall redirection range specification before the API has been made official in 5.11. - Ensure tasks using the generic syscall code do trap after returning from a syscall when single-stepping is requested. * tag 'core_urgent_for_v5.11_rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: entry: Use different define for selector variable in SUD entry: Ensure trap after single-step on system call return
2021-02-07Merge tag 'x86_urgent_for_v5.11_rc7' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 fixes from Borislav Petkov: "I hope this is the last batch of x86/urgent updates for this round: - Remove superfluous EFI PGD range checks which lead to those assertions failing with certain kernel configs and LLVM. - Disable setting breakpoints on facilities involved in #DB exception handling to avoid infinite loops. - Add extra serialization to non-serializing MSRs (IA32_TSC_DEADLINE and x2 APIC MSRs) to adhere to SDM's recommendation and avoid any theoretical issues. - Re-add the EPB MSR reading on turbostat so that it works on older kernels which don't have the corresponding EPB sysfs file. - Add Alder Lake to the list of CPUs which support split lock. - Fix %dr6 register handling in order to be able to set watchpoints with gdb again. - Disable CET instrumentation in the kernel so that gcc doesn't add ENDBR64 to kernel code and thus confuse tracing" * tag 'x86_urgent_for_v5.11_rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/efi: Remove EFI PGD build time checks x86/debug: Prevent data breakpoints on cpu_dr7 x86/debug: Prevent data breakpoints on __per_cpu_offset x86/apic: Add extra serialization for non-serializing MSRs tools/power/turbostat: Fallback to an MSR read for EPB x86/split_lock: Enable the split lock feature on another Alder Lake CPU x86/debug: Fix DR6 handling x86/build: Disable CET instrumentation in the kernel
2021-02-07Merge tag 'kbuild-fixes-v5.11-2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild Pull Kbuild fixes from Masahiro Yamada: - Use the 'python3' command to invoke python scripts because some distributions do not provide the 'python' command any more. - Clean-up and update documents - Use pkg-config to search libcrypto - Fix duplicated debug flags - Ignore some more stubs in scripts/kallsyms.c * tag 'kbuild-fixes-v5.11-2' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: kallsyms: fix nonconverging kallsyms table with lld kbuild: fix duplicated flags in DEBUG_CFLAGS scripts/clang-tools: switch explicitly to Python 3 kbuild: remove PYTHON variable Documentation/llvm: Add a section about supported architectures Revert "checkpatch: add check for keyword 'boolean' in Kconfig definitions" scripts: use pkg-config to locate libcrypto kconfig: mconf: fix HOSTCC call doc: gcc-plugins: update gcc-plugins.rst kbuild: simplify GCC_PLUGINS enablement in dummy-tools/gcc Documentation/Kbuild: Remove references to gcc-plugin.sh scripts: switch explicitly to Python 3
2021-02-06Merge tag 'riscv-for-linus-5.11-rc7' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux Pull RISC-V fixes from Palmer Dabbelt: "A handful of fixes for this week: - A fix to avoid evalating the VA twice in virt_addr_valid, which fixes some WARNs under DEBUG_VIRTUAL. - Two fixes related to STRICT_KERNEL_RWX: one that fixes some permissions when strict is disabled, and one to fix some alignment issues when strict is enabled. - A fix to disallow the selection of MAXPHYSMEM_2GB on RV32, which isn't valid any more but may still show up in some oldconfigs. We still have the HiFive Unleashed ethernet phy reset regression, so there will likely be something coming next week" * tag 'riscv-for-linus-5.11-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux: RISC-V: Define MAXPHYSMEM_1GB only for RV32 riscv: Align on L1_CACHE_BYTES when STRICT_KERNEL_RWX RISC-V: Fix .init section permission update riscv: virt_addr_valid must check the address belongs to linear mapping
2021-02-06Merge tag 'powerpc-5.11-7' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux Pull powerpc fixes from Michael Ellerman: - A fix for a change we made to __kernel_sigtramp_rt64() which confused glibc's backtrace logic, and also changed the semantics of that symbol, which was arguably an ABI break. - A fix for a stack overwrite in our VSX instruction emulation. - A couple of fixes for the Makefile logic in the new C VDSO. Thanks to Masahiro Yamada, Naveen N. Rao, Raoni Fassina Firmino, and Ravi Bangoria. * tag 'powerpc-5.11-7' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux: powerpc/64/signal: Fix regression in __kernel_sigtramp_rt64() semantics powerpc/vdso64: remove meaningless vgettimeofday.o build rule powerpc/vdso: fix unnecessary rebuilds of vgettimeofday.o powerpc/sstep: Fix array out of bound warning
2021-02-06Merge tag 'for-linus' of git://git.armlinux.org.uk/~rmk/linux-armLinus Torvalds
Pull ARM fixes from Russell King: - Fix latent bug with DC21285 (Footbridge PCI bridge) configuration accessors that affects GCC >= 4.9.2 - Fix misplaced tegra_uart_config in decompressor - Ensure signal page contents are initialised - Fix kexec oops * tag 'for-linus' of git://git.armlinux.org.uk/~rmk/linux-arm: ARM: kexec: fix oops after TLB are invalidated ARM: ensure the signal page contains defined contents ARM: 9043/1: tegra: Fix misplaced tegra_uart_config in decompressor ARM: footbridge: fix dc21285 PCI configuration accessors
2021-02-06x86/efi: Remove EFI PGD build time checksBorislav Petkov
With CONFIG_X86_5LEVEL, CONFIG_UBSAN and CONFIG_UBSAN_UNSIGNED_OVERFLOW enabled, clang fails the build with x86_64-linux-ld: arch/x86/platform/efi/efi_64.o: in function `efi_sync_low_kernel_mappings': efi_64.c:(.text+0x22c): undefined reference to `__compiletime_assert_354' which happens due to -fsanitize=unsigned-integer-overflow being enabled: -fsanitize=unsigned-integer-overflow: Unsigned integer overflow, where the result of an unsigned integer computation cannot be represented in its type. Unlike signed integer overflow, this is not undefined behavior, but it is often unintentional. This sanitizer does not check for lossy implicit conversions performed before such a computation (see -fsanitize=implicit-conversion). and that fires when the (intentional) EFI_VA_START/END defines overflow an unsigned long, leading to the assertion expressions not getting optimized away (on GCC they do)... However, those checks are superfluous: the runtime services mapping code already makes sure the ranges don't overshoot EFI_VA_END as the EFI mapping range is hardcoded. On each runtime services call, it is switched to the EFI-specific PGD and even if mappings manage to escape that last PGD, this won't remain unnoticed for long. So rip them out. See https://github.com/ClangBuiltLinux/linux/issues/256 for more info. Reported-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Acked-by: Ard Biesheuvel <ardb@kernel.org> Tested-by: Nick Desaulniers <ndesaulniers@google.com> Tested-by: Nathan Chancellor <nathan@kernel.org> Link: http://lkml.kernel.org/r/20210107223424.4135538-1-arnd@kernel.org
2021-02-06powerpc/kuap: Allow kernel thread to access userspace after kthread_use_mmAneesh Kumar K.V
This fix the bad fault reported by KUAP when io_wqe_worker access userspace. Bug: Read fault blocked by KUAP! WARNING: CPU: 1 PID: 101841 at arch/powerpc/mm/fault.c:229 __do_page_fault+0x6b4/0xcd0 NIP [c00000000009e7e4] __do_page_fault+0x6b4/0xcd0 LR [c00000000009e7e0] __do_page_fault+0x6b0/0xcd0 .......... Call Trace: [c000000016367330] [c00000000009e7e0] __do_page_fault+0x6b0/0xcd0 (unreliable) [c0000000163673e0] [c00000000009ee3c] do_page_fault+0x3c/0x120 [c000000016367430] [c00000000000c848] handle_page_fault+0x10/0x2c --- interrupt: 300 at iov_iter_fault_in_readable+0x148/0x6f0 .......... NIP [c0000000008e8228] iov_iter_fault_in_readable+0x148/0x6f0 LR [c0000000008e834c] iov_iter_fault_in_readable+0x26c/0x6f0 interrupt: 300 [c0000000163677e0] [c0000000007154a0] iomap_write_actor+0xc0/0x280 [c000000016367880] [c00000000070fc94] iomap_apply+0x1c4/0x780 [c000000016367990] [c000000000710330] iomap_file_buffered_write+0xa0/0x120 [c0000000163679e0] [c00800000040791c] xfs_file_buffered_aio_write+0x314/0x5e0 [xfs] [c000000016367a90] [c0000000006d74bc] io_write+0x10c/0x460 [c000000016367bb0] [c0000000006d80e4] io_issue_sqe+0x8d4/0x1200 [c000000016367c70] [c0000000006d8ad0] io_wq_submit_work+0xc0/0x250 [c000000016367cb0] [c0000000006e2578] io_worker_handle_work+0x498/0x800 [c000000016367d40] [c0000000006e2cdc] io_wqe_worker+0x3fc/0x4f0 [c000000016367da0] [c0000000001cb0a4] kthread+0x1c4/0x1d0 [c000000016367e10] [c00000000000dbf0] ret_from_kernel_thread+0x5c/0x6c The kernel consider thread AMR value for kernel thread to be AMR_KUAP_BLOCKED. Hence access to userspace is denied. This of course not correct and we should allow userspace access after kthread_use_mm(). To be precise, kthread_use_mm() should inherit the AMR value of the operating address space. But, the AMR value is thread-specific and we inherit the address space and not thread access restrictions. Because of this ignore AMR value when accessing userspace via kernel thread. current_thread_amr/iamr() are updated, because we use them in the below stack. .... [ 530.710838] CPU: 13 PID: 5587 Comm: io_wqe_worker-0 Tainted: G D 5.11.0-rc6+ #3 .... NIP [c0000000000aa0c8] pkey_access_permitted+0x28/0x90 LR [c0000000004b9278] gup_pte_range+0x188/0x420 --- interrupt: 700 [c00000001c4ef3f0] [0000000000000000] 0x0 (unreliable) [c00000001c4ef490] [c0000000004bd39c] gup_pgd_range+0x3ac/0xa20 [c00000001c4ef5a0] [c0000000004bdd44] internal_get_user_pages_fast+0x334/0x410 [c00000001c4ef620] [c000000000852028] iov_iter_get_pages+0xf8/0x5c0 [c00000001c4ef6a0] [c0000000007da44c] bio_iov_iter_get_pages+0xec/0x700 [c00000001c4ef770] [c0000000006a325c] iomap_dio_bio_actor+0x2ac/0x4f0 [c00000001c4ef810] [c00000000069cd94] iomap_apply+0x2b4/0x740 [c00000001c4ef920] [c0000000006a38b8] __iomap_dio_rw+0x238/0x5c0 [c00000001c4ef9d0] [c0000000006a3c60] iomap_dio_rw+0x20/0x80 [c00000001c4ef9f0] [c008000001927a30] xfs_file_dio_aio_write+0x1f8/0x650 [xfs] [c00000001c4efa60] [c0080000019284dc] xfs_file_write_iter+0xc4/0x130 [xfs] [c00000001c4efa90] [c000000000669984] io_write+0x104/0x4b0 [c00000001c4efbb0] [c00000000066cea4] io_issue_sqe+0x3d4/0xf50 [c00000001c4efc60] [c000000000670200] io_wq_submit_work+0xb0/0x2f0 [c00000001c4efcb0] [c000000000674268] io_worker_handle_work+0x248/0x4a0 [c00000001c4efd30] [c0000000006746e8] io_wqe_worker+0x228/0x2a0 [c00000001c4efda0] [c00000000019d994] kthread+0x1b4/0x1c0 Fixes: 48a8ab4eeb82 ("powerpc/book3s64/pkeys: Don't update SPRN_AMR when in kernel mode.") Reported-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20210206025634.521979-1-aneesh.kumar@linux.ibm.com
2021-02-06entry: Ensure trap after single-step on system call returnGabriel Krisman Bertazi
Commit 299155244770 ("entry: Drop usage of TIF flags in the generic syscall code") introduced a bug on architectures using the generic syscall entry code, in which processes stopped by PTRACE_SYSCALL do not trap on syscall return after receiving a TIF_SINGLESTEP. The reason is that the meaning of TIF_SINGLESTEP flag is overloaded to cause the trap after a system call is executed, but since the above commit, the syscall call handler only checks for the SYSCALL_WORK flags on the exit work. Split the meaning of TIF_SINGLESTEP such that it only means single-step mode, and create a new type of SYSCALL_WORK to request a trap immediately after a syscall in single-step mode. In the current implementation, the SYSCALL_WORK flag shadows the TIF_SINGLESTEP flag for simplicity. Update x86 to flip this bit when a tracer enables single stepping. Fixes: 299155244770 ("entry: Drop usage of TIF flags in the generic syscall code") Suggested-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Gabriel Krisman Bertazi <krisman@collabora.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Kyle Huey <me@kylehuey.com> Link: https://lore.kernel.org/r/87h7mtc9pr.fsf_-_@collabora.com
2021-02-05x86/debug: Prevent data breakpoints on cpu_dr7Lai Jiangshan
local_db_save() is called at the start of exc_debug_kernel(), reads DR7 and disables breakpoints to prevent recursion. When running in a guest (X86_FEATURE_HYPERVISOR), local_db_save() reads the per-cpu variable cpu_dr7 to check whether a breakpoint is active or not before it accesses DR7. A data breakpoint on cpu_dr7 therefore results in infinite #DB recursion. Disallow data breakpoints on cpu_dr7 to prevent that. Fixes: 84b6a3491567a("x86/entry: Optimize local_db_save() for virt") Signed-off-by: Lai Jiangshan <laijs@linux.alibaba.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20210204152708.21308-2-jiangshanlai@gmail.com
2021-02-05x86/debug: Prevent data breakpoints on __per_cpu_offsetLai Jiangshan
When FSGSBASE is enabled, paranoid_entry() fetches the per-CPU GSBASE value via __per_cpu_offset or pcpu_unit_offsets. When a data breakpoint is set on __per_cpu_offset[cpu] (read-write operation), the specific CPU will be stuck in an infinite #DB loop. RCU will try to send an NMI to the specific CPU, but it is not working either since NMI also relies on paranoid_entry(). Which means it's undebuggable. Fixes: eaad981291ee3("x86/entry/64: Introduce the FIND_PERCPU_BASE macro") Signed-off-by: Lai Jiangshan <laijs@linux.alibaba.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20210204152708.21308-1-jiangshanlai@gmail.com
2021-02-05Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvmLinus Torvalds
Pull KVM fixes from Paolo Bonzini: "x86 has lots of small bugfixes, mostly one liners. It's quite late in 5.11-rc but none of them are related to this merge window; it's just bugs coming in at the wrong time. Of note among the others is "KVM: x86: Allow guests to see MSR_IA32_TSX_CTRL even if tsx=off" that fixes a live migration failure seen on distros that hadn't switched to tsx=off right away. ARM: - Avoid clobbering extra registers on initialisation" [ Sean Christopherson notes that commit 943dea8af21b ("KVM: x86: Update emulator context mode if SYSENTER xfers to 64-bit mode") should have had authorship credited to Jonny Barker, not to him. - Linus ] * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: KVM: x86: Set so called 'reserved CR3 bits in LM mask' at vCPU reset KVM: x86/mmu: Fix TDP MMU zap collapsible SPTEs KVM: x86: cleanup CR3 reserved bits checks KVM: SVM: Treat SVM as unsupported when running as an SEV guest KVM: x86: Update emulator context mode if SYSENTER xfers to 64-bit mode KVM: x86: Supplement __cr4_reserved_bits() with X86_FEATURE_PCID check KVM/x86: assign hva with the right value to vm_munmap the pages KVM: x86: Allow guests to see MSR_IA32_TSX_CTRL even if tsx=off Fix unsynchronized access to sev members through svm_register_enc_region KVM: Documentation: Fix documentation for nested. KVM: x86: fix CPUID entries returned by KVM_GET_CPUID2 ioctl KVM: arm64: Don't clobber x4 in __do_hyp_init
2021-02-05ARM: kexec: fix oops after TLB are invalidatedRussell King
Giancarlo Ferrari reports the following oops while trying to use kexec: Unable to handle kernel paging request at virtual address 80112f38 pgd = fd7ef03e [80112f38] *pgd=0001141e(bad) Internal error: Oops: 80d [#1] PREEMPT SMP ARM ... This is caused by machine_kexec() trying to set the kernel text to be read/write, so it can poke values into the relocation code before copying it - and an interrupt occuring which changes the page tables. The subsequent writes then hit read-only sections that trigger a data abort resulting in the above oops. Fix this by copying the relocation code, and then writing the variables into the destination, thereby avoiding the need to make the kernel text read/write. Reported-by: Giancarlo Ferrari <giancarlo.ferrari89@gmail.com> Tested-by: Giancarlo Ferrari <giancarlo.ferrari89@gmail.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2021-02-05ARM: ensure the signal page contains defined contentsRussell King
Ensure that the signal page contains our poison instruction to increase the protection against ROP attacks and also contains well defined contents. Acked-by: Will Deacon <will@kernel.org> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2021-02-04x86/apic: Add extra serialization for non-serializing MSRsDave Hansen
Jan Kiszka reported that the x2apic_wrmsr_fence() function uses a plain MFENCE while the Intel SDM (10.12.3 MSR Access in x2APIC Mode) calls for MFENCE; LFENCE. Short summary: we have special MSRs that have weaker ordering than all the rest. Add fencing consistent with current SDM recommendations. This is not known to cause any issues in practice, only in theory. Longer story below: The reason the kernel uses a different semantic is that the SDM changed (roughly in late 2017). The SDM changed because folks at Intel were auditing all of the recommended fences in the SDM and realized that the x2apic fences were insufficient. Why was the pain MFENCE judged insufficient? WRMSR itself is normally a serializing instruction. No fences are needed because the instruction itself serializes everything. But, there are explicit exceptions for this serializing behavior written into the WRMSR instruction documentation for two classes of MSRs: IA32_TSC_DEADLINE and the X2APIC MSRs. Back to x2apic: WRMSR is *not* serializing in this specific case. But why is MFENCE insufficient? MFENCE makes writes visible, but only affects load/store instructions. WRMSR is unfortunately not a load/store instruction and is unaffected by MFENCE. This means that a non-serializing WRMSR could be reordered by the CPU to execute before the writes made visible by the MFENCE have even occurred in the first place. This means that an x2apic IPI could theoretically be triggered before there is any (visible) data to process. Does this affect anything in practice? I honestly don't know. It seems quite possible that by the time an interrupt gets to consume the (not yet) MFENCE'd data, it has become visible, mostly by accident. To be safe, add the SDM-recommended fences for all x2apic WRMSRs. This also leaves open the question of the _other_ weakly-ordered WRMSR: MSR_IA32_TSC_DEADLINE. While it has the same ordering architecture as the x2APIC MSRs, it seems substantially less likely to be a problem in practice. While writes to the in-memory Local Vector Table (LVT) might theoretically be reordered with respect to a weakly-ordered WRMSR like TSC_DEADLINE, the SDM has this to say: In x2APIC mode, the WRMSR instruction is used to write to the LVT entry. The processor ensures the ordering of this write and any subsequent WRMSR to the deadline; no fencing is required. But, that might still leave xAPIC exposed. The safest thing to do for now is to add the extra, recommended LFENCE. [ bp: Massage commit message, fix typos, drop accidentally added newline to tools/arch/x86/include/asm/barrier.h. ] Reported-by: Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Signed-off-by: Borislav Petkov <bp@suse.de> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Thomas Gleixner <tglx@linutronix.de> Cc: <stable@vger.kernel.org> Link: https://lkml.kernel.org/r/20200305174708.F77040DD@viggo.jf.intel.com
2021-02-04Revert "x86/setup: don't remove E820_TYPE_RAM for pfn 0"Mike Rapoport
This reverts commit bde9cfa3afe4324ec251e4af80ebf9b7afaf7afe. Changing the first memory page type from E820_TYPE_RESERVED to E820_TYPE_RAM makes it a part of "System RAM" resource rather than a reserved resource and this in turn causes devmem_is_allowed() to treat is as area that can be accessed but it is filled with zeroes instead of the actual data as previously. The change in /dev/mem output causes lilo to fail as was reported at slakware users forum, and probably other legacy applications will experience similar problems. Link: https://www.linuxquestions.org/questions/slackware-14/slackware-current-lilo-vesa-warnings-after-recent-updates-4175689617/#post6214439 Signed-off-by: Mike Rapoport <rppt@linux.ibm.com> Cc: stable@kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-02-04KVM: x86: Set so called 'reserved CR3 bits in LM mask' at vCPU resetSean Christopherson
Set cr3_lm_rsvd_bits, which is effectively an invalid GPA mask, at vCPU reset. The reserved bits check needs to be done even if userspace never configures the guest's CPUID model. Cc: stable@vger.kernel.org Fixes: 0107973a80ad ("KVM: x86: Introduce cr3_lm_rsvd_bits in kvm_vcpu_arch") Signed-off-by: Sean Christopherson <seanjc@google.com> Message-Id: <20210204000117.3303214-2-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-02-04KVM: x86/mmu: Fix TDP MMU zap collapsible SPTEsBen Gardon
There is a bug in the TDP MMU function to zap SPTEs which could be replaced with a larger mapping which prevents the function from doing anything. Fix this by correctly zapping the last level SPTEs. Cc: stable@vger.kernel.org Fixes: 14881998566d ("kvm: x86/mmu: Support disabling dirty logging for the tdp MMU") Signed-off-by: Ben Gardon <bgardon@google.com> Message-Id: <20210202185734.1680553-11-bgardon@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-02-03Merge tag 'for-linus-5.11-rc7' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/rw/uml Pull UML fixes from Richard Weinberger: - Make sure to set a default console, otherwise ttynull is selected - Revert initial ARCH_HAS_SET_MEMORY support, this needs more work - Fix a regression due to ubd refactoring - Various small fixes * tag 'for-linus-5.11-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/rw/uml: um: time: fix initialization in time-travel mode um: fix os_idle_sleep() to not hang Revert "um: support some of ARCH_HAS_SET_MEMORY" Revert "um: allocate a guard page to helper threads" um: virtio: free vu_dev only with the contained struct device um: kmsg_dumper: always dump when not tty console um: stdio_console: Make preferred console um: return error from ioremap() um: ubd: fix command line handling of ubd
2021-02-03Merge tag 'arm64-fixes' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux Pull arm64 fixes from Catalin Marinas: "Fix the arm64 linear map range detection for tagged addresses and replace the bitwise operations with subtract (virt_addr_valid(), __is_lm_address(), __lm_to_phys())" * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: arm64: Use simpler arithmetics for the linear map macros arm64: Do not pass tagged addresses to __is_lm_address()
2021-02-03Merge tag 'arm-soc-fixes-v5.11-3' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc Pull ARM SoC fixes from Arnd Bergmann: "The code fixes in this round are all for the Texas Instruments OMAP platform, addressing several regressions related to the ti-sysc interconnect changes that was merged in linux-5.11 and one recently introduced RCU usage warning. Tero Kristo updates his maintainer file entries as he is changing to a new employer. The other changes are for devicetree files across eight different platforms: TI OMAP: - multiple gpio related one-line fixes Allwinner/sunxi: - ARM: dts: sun7i: a20: bananapro: Fix ethernet phy-mode - soc: sunxi: mbus: Remove DE2 display engine compatibles NXP lpc32xx: - ARM: dts: lpc32xx: Revert set default clock rate of HCLK PLL STMicroelectronics stm32 - multiple minor fixes for DHCOM/DHCOR boards NXP Layerscape: - Fix DCFG address range on LS1046A SoC Amlogic meson: - fix reboot issue on odroid C4 - revert an ethernet change that caused a regression - meson-g12: Set FL-adj property value Rockchip: - multiple minor fixes on 64-bit rockchip machines Qualcomm: - Regression fixes for Lenovo Yoga touchpad and for interconnect configuration - Boot fixes for 'LPASS' clock configuration on two machines" * tag 'arm-soc-fixes-v5.11-3' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (31 commits) ARM: dts: lpc32xx: Revert set default clock rate of HCLK PLL ARM: dts: sun7i: a20: bananapro: Fix ethernet phy-mode arm64: dts: ls1046a: fix dcfg address range soc: sunxi: mbus: Remove DE2 display engine compatibles arm64: dts: meson: switch TFLASH_VDD_EN pin to open drain on Odroid-C4 Revert "arm64: dts: amlogic: add missing ethernet reset ID" arm64: dts: rockchip: Disable display for NanoPi R2S ARM: dts: omap4-droid4: Fix lost keypad slide interrupts for droid4 arm64: dts: rockchip: remove interrupt-names property from rk3399 vdec node drivers: bus: simple-pm-bus: Fix compatibility with simple-bus for auxdata ARM: OMAP2+: Fix booting for am335x after moving to simple-pm-bus ARM: OMAP2+: Fix suspcious RCU usage splats for omap_enter_idle_coupled ARM: dts: stm32: Fix GPIO hog flags on DHCOM DRC02 ARM: dts: stm32: Fix GPIO hog flags on DHCOM PicoITX ARM: dts: stm32: Fix GPIO hog names on DHCOM ARM: dts: stm32: Disable optional TSC2004 on DRC02 board ARM: dts: stm32: Disable WP on DHCOM uSD slot ARM: dts: stm32: Connect card-detect signal on DHCOM ARM: dts: stm32: Fix polarity of the DH DRC02 uSD card detect arm64: dts: qcom: sdm845: Reserve LPASS clocks in gcc ...
2021-02-03Merge tag 'sunxi-fixes-for-5.11-2' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux into arm/fixes One fix for a phy-mode ethernet issue, and one to fix the display output on SoCs with the Display Engine 2 * tag 'sunxi-fixes-for-5.11-2' of git://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux: ARM: dts: sun7i: a20: bananapro: Fix ethernet phy-mode soc: sunxi: mbus: Remove DE2 display engine compatibles Link: https://lore.kernel.org/r/f8298059-f9ca-43b4-9e29-35bc0e0c9b15.lettre@localhost Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2021-02-03ARM: dts: lpc32xx: Revert set default clock rate of HCLK PLLAlexandre Belloni
This reverts commit c17e9377aa81664d94b4f2102559fcf2a01ec8e7. The lpc32xx clock driver is not able to actually change the PLL rate as this would require reparenting ARM_CLK, DDRAM_CLK, PERIPH_CLK to SYSCLK, then stop the PLL, update the register, restart the PLL and wait for the PLL to lock and finally reparent ARM_CLK, DDRAM_CLK, PERIPH_CLK to HCLK PLL. Currently, the HCLK driver simply updates the registers but this has no real effect and all the clock rate calculation end up being wrong. This is especially annoying for the peripheral (e.g. UARTs, I2C, SPI). Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Tested-by: Gregory CLEMENT <gregory.clement@bootlin.com> Link: https://lore.kernel.org/r/20210203090320.GA3760268@piout.net' Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2021-02-03ARM: dts: sun7i: a20: bananapro: Fix ethernet phy-modeHermann Lauer
BPi Pro needs TX and RX delay for Gbit to work reliable and avoid high packet loss rates. The realtek phy driver overrides the settings of the pull ups for the delays, so fix this for BananaPro. Fix the phy-mode description to correctly reflect this so that the implementation doesn't reconfigure the delays incorrectly. This happened with commit bbc4d71d6354 ("net: phy: realtek: fix rtl8211e rx/tx delay config"). Fixes: 10662a33dcd9 ("ARM: dts: sun7i: Add dts file for Bananapro board") Signed-off-by: Hermann Lauer <Hermann.Lauer@uni-heidelberg.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20210128111842.GA11919@lemon.iwr.uni-heidelberg.de
2021-02-03KVM: x86: cleanup CR3 reserved bits checksPaolo Bonzini
If not in long mode, the low bits of CR3 are reserved but not enforced to be zero, so remove those checks. If in long mode, however, the MBZ bits extend down to the highest physical address bit of the guest, excluding the encryption bit. Make the checks consistent with the above, and match them between nested_vmcb_checks and KVM_SET_SREGS. Cc: stable@vger.kernel.org Fixes: 761e41693465 ("KVM: nSVM: Check that MBZ bits in CR3 and CR4 are not set on vmrun of nested guests") Fixes: a780a3ea6282 ("KVM: X86: Fix reserved bits check for MOV to CR3") Reviewed-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-02-03KVM: SVM: Treat SVM as unsupported when running as an SEV guestSean Christopherson
Don't let KVM load when running as an SEV guest, regardless of what CPUID says. Memory is encrypted with a key that is not accessible to the host (L0), thus it's impossible for L0 to emulate SVM, e.g. it'll see garbage when reading the VMCB. Technically, KVM could decrypt all memory that needs to be accessible to the L0 and use shadow paging so that L0 does not need to shadow NPT, but exposing such information to L0 largely defeats the purpose of running as an SEV guest. This can always be revisited if someone comes up with a use case for running VMs inside SEV guests. Note, VMLOAD, VMRUN, etc... will also #GP on GPAs with C-bit set, i.e. KVM is doomed even if the SEV guest is debuggable and the hypervisor is willing to decrypt the VMCB. This may or may not be fixed on CPUs that have the SVME_ADDR_CHK fix. Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson <seanjc@google.com> Message-Id: <20210202212017.2486595-1-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-02-02RISC-V: Define MAXPHYSMEM_1GB only for RV32Atish Patra
MAXPHYSMEM_1GB option was added for RV32 because RV32 only supports 1GB of maximum physical memory. This lead to few compilation errors reported by kernel test robot which created the following configuration combination which are not useful but can be configured. 1. MAXPHYSMEM_1GB & RV64 2, MAXPHYSMEM_2GB & RV32 Fix this by restricting MAXPHYSMEM_1GB for RV32 and MAXPHYSMEM_2GB only for RV64. Fixes: e557793799c5 ("RISC-V: Fix maximum allowed phsyical memory for RV32") Cc: stable@vger.kernel.org Reported-by: Randy Dunlap <rdunlap@infradead.org> Acked-by: Randy Dunlap <rdunlap@infradead.org> Tested-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Atish Patra <atish.patra@wdc.com> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
2021-02-02riscv: Align on L1_CACHE_BYTES when STRICT_KERNEL_RWXSebastien Van Cauwenberghe
Allows the sections to be aligned on smaller boundaries and therefore results in a smaller kernel image size. Signed-off-by: Sebastien Van Cauwenberghe <svancau@gmail.com> Reviewed-by: Atish Patra <atish.patra@wdc.com> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
2021-02-02RISC-V: Fix .init section permission updateAtish Patra
.init section permission should only updated to non-execute if STRICT_KERNEL_RWX is enabled. Otherwise, this will lead to a kernel hang. Fixes: 19a00869028f ("RISC-V: Protect all kernel sections including init early") Cc: stable@vger.kernel.org Suggested-by: Geert Uytterhoeven <geert@linux-m68k.org> Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Atish Patra <atish.patra@wdc.com> Reviewed-by: Atish Patra <atish.patra@wdc.com> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
2021-02-02riscv: virt_addr_valid must check the address belongs to linear mappingAlexandre Ghiti
virt_addr_valid macro checks that a virtual address is valid, ie that the address belongs to the linear mapping and that the corresponding physical page exists. Add the missing check that ensures the virtual address belongs to the linear mapping, otherwise __virt_to_phys, when compiled with CONFIG_DEBUG_VIRTUAL enabled, raises a WARN that is interpreted as a kernel bug by syzbot. Signed-off-by: Alexandre Ghiti <alex@ghiti.fr> Reviewed-by: Atish Patra <atish.patra@wdc.com> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
2021-02-02Merge tag 'imx-fixes-5.11-3' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into arm/fixes i.MX fixes for 5.11, round 3: - Fix DCFG address range on LS1046A SoC. * tag 'imx-fixes-5.11-3' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux: arm64: dts: ls1046a: fix dcfg address range Link: https://lore.kernel.org/r/20210202071441.GP907@dragon Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2021-02-02arm64: Use simpler arithmetics for the linear map macrosCatalin Marinas
Because of the tagged addresses, the __is_lm_address() and __lm_to_phys() macros grew to some harder to understand bitwise operations using PAGE_OFFSET. Since these macros only accept untagged addresses, use a simple subtract operation. Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Acked-by: Ard Biesheuvel <ardb@kernel.org> Cc: Will Deacon <will@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Link: https://lore.kernel.org/r/20210201190634.22942-3-catalin.marinas@arm.com
2021-02-02arm64: Do not pass tagged addresses to __is_lm_address()Catalin Marinas
Commit 519ea6f1c82f ("arm64: Fix kernel address detection of __is_lm_address()") fixed the incorrect validation of addresses below PAGE_OFFSET. However, it no longer allowed tagged addresses to be passed to virt_addr_valid(). Fix this by explicitly resetting the pointer tag prior to invoking __is_lm_address(). This is consistent with the __lm_to_phys() macro. Fixes: 519ea6f1c82f ("arm64: Fix kernel address detection of __is_lm_address()") Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Acked-by: Ard Biesheuvel <ardb@kernel.org> Cc: <stable@vger.kernel.org> # 5.4.x Cc: Will Deacon <will@kernel.org> Cc: Vincenzo Frascino <vincenzo.frascino@arm.com> Cc: Mark Rutland <mark.rutland@arm.com> Link: https://lore.kernel.org/r/20210201190634.22942-2-catalin.marinas@arm.com