summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)Author
2020-07-16arm64: ptrace: Consistently use pseudo-singlestep exceptionsWill Deacon
Although the arm64 single-step state machine can be fast-forwarded in cases where we wish to generate a SIGTRAP without actually executing an instruction, this has two major limitations outside of simply skipping an instruction due to emulation. 1. Stepping out of a ptrace signal stop into a signal handler where SIGTRAP is blocked. Fast-forwarding the stepping state machine in this case will result in a forced SIGTRAP, with the handler reset to SIG_DFL. 2. The hardware implicitly fast-forwards the state machine when executing an SVC instruction for issuing a system call. This can interact badly with subsequent ptrace stops signalled during the execution of the system call (e.g. SYSCALL_EXIT or seccomp traps), as they may corrupt the stepping state by updating the PSTATE for the tracee. Resolve both of these issues by injecting a pseudo-singlestep exception on entry to a signal handler and also on return to userspace following a system call. Cc: <stable@vger.kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Tested-by: Luis Machado <luis.machado@linaro.org> Reported-by: Keno Fischer <keno@juliacomputing.com> Signed-off-by: Will Deacon <will@kernel.org>
2020-07-15arm64: dts: spcfpga: Align GIC, NAND and UART nodenames with dtschemaKrzysztof Kozlowski
Fix dtschema validator warnings like: intc@fffc1000: $nodename:0: 'intc@fffc1000' does not match '^interrupt-controller(@[0-9a-f,]+)*$' Fixes: 78cd6a9d8e15 ("arm64: dts: Add base stratix 10 dtsi") Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
2020-07-15ARM: dts: socfpga: Align L2 cache-controller nodename with dtschemaKrzysztof Kozlowski
Fix dtschema validator warnings like: l2-cache@fffff000: $nodename:0: 'l2-cache@fffff000' does not match '^(cache-controller|cpu)(@[0-9a-f,]+)*$' Fixes: 475dc86d08de ("arm: dts: socfpga: Add a base DTSI for Altera's Arria10 SOC") Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
2020-07-15arm64: dts: stratix10: increase QSPI reg address in nand dts fileDinh Nguyen
Match the QSPI reg address in the socfpga_stratix10_socdk.dts file. Fixes: 80f132d73709 ("arm64: dts: increase the QSPI reg address for Stratix10 and Agilex") Cc: linux-stable <stable@vger.kernel.org> # >= v5.6 Signed-off-by: Dinh Nguyen <dinh.nguyen@intel.com>
2020-07-15arm64: dts: stratix10: add status to qspi dts nodeDinh Nguyen
Add status = "okay" to QSPI node. Fixes: 0cb140d07fc75 ("arm64: dts: stratix10: Add QSPI support for Stratix10") Cc: linux-stable <stable@vger.kernel.org> # >= v5.6 Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
2020-07-15arm64: dts: agilex: add status to qspi dts nodeDinh Nguyen
Add status = "okay" to QSPI node. Fixes: c4c8757b2d895 ("arm64: dts: agilex: add QSPI support for Intel Agilex") Cc: linux-stable <stable@vger.kernel.org> # >= v5.5 Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
2020-07-15powerpc/vas: Report proper error code for address translation failureHaren Myneni
P9 DD2 NX workbook (Table 4-36) says DMA controller uses CC=5 internally for translation fault handling. NX reserves CC=250 for OS to notify user space when NX encounters address translation failure on the request buffer. Not an issue in earlier releases as NX does not get faults on kernel addresses. This patch defines CSB_CC_FAULT_ADDRESS(250) and updates CSB.CC with this proper error code for user space. Fixes: c96c4436aba4 ("powerpc/vas: Update CSB and notify process for fault CRBs") Signed-off-by: Haren Myneni <haren@linux.ibm.com> [mpe: Added Fixes tag and fix typo in comment] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/019fd53e7538c6f8f332d175df74b1815ef5aa8c.camel@linux.ibm.com
2020-07-14riscv: use 16KB kernel stack on 64-bitAndreas Schwab
With the current 8KB stack size there are frequent overflows in a 64-bit configuration. We may split IRQ stacks off in the future, but this fixes a number of issues right now. Signed-off-by: Andreas Schwab <schwab@suse.de> Reviewed-by: Anup Patel <anup@brainfault.org> [Palmer: mention irqstack in the commit text] Fixes: 7db91e57a0ac ("RISC-V: Task implementation") Cc: stable@vger.kernel.org Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
2020-07-14irqdomain/treewide: Keep firmware node unconditionally allocatedThomas Gleixner
Quite some non OF/ACPI users of irqdomains allocate firmware nodes of type IRQCHIP_FWNODE_NAMED or IRQCHIP_FWNODE_NAMED_ID and free them right after creating the irqdomain. The only purpose of these FW nodes is to convey name information. When this was introduced the core code did not store the pointer to the node in the irqdomain. A recent change stored the firmware node pointer in irqdomain for other reasons and missed to notice that the usage sites which do the alloc_fwnode/create_domain/free_fwnode sequence are broken by this. Storing a dangling pointer is dangerous itself, but in case that the domain is destroyed later on this leads to a double free. Remove the freeing of the firmware node after creating the irqdomain from all affected call sites to cure this. Fixes: 711419e504eb ("irqdomain: Add the missing assignment of domain->fwnode for named fwnode") Reported-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Marc Zyngier <maz@kernel.org> Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/873661qakd.fsf@nanos.tec.linutronix.de
2020-07-14ARM: dts: Fix dcan driver probe failed on am437x platformdillon min
Got following d_can probe errors with kernel 5.8-rc1 on am437x [ 10.730822] CAN device driver interface Starting Wait for Network to be Configured... [ OK ] Reached target Network. [ 10.787363] c_can_platform 481cc000.can: probe failed [ 10.792484] c_can_platform: probe of 481cc000.can failed with error -2 [ 10.799457] c_can_platform 481d0000.can: probe failed [ 10.804617] c_can_platform: probe of 481d0000.can failed with error -2 actually, Tony has fixed this issue on am335x with the patch [3] Since am437x has the same clock structure with am335x [1][2], so reuse the code from Tony Lindgren's patch [3] to fix it. [1]: https://www.ti.com/lit/pdf/spruh73 Chapter-23, Figure 23-1. DCAN Integration [2]: https://www.ti.com/lit/pdf/spruhl7 Chapter-25, Figure 25-1. DCAN Integration [3]: commit 516f1117d0fb ("ARM: dts: Configure osc clock for d_can on am335x") Fixes: 1a5cd7c23cc5 ("bus: ti-sysc: Enable all clocks directly during init to read revision") Signed-off-by: dillon min <dillon.minfei@gmail.com> [tony@atomide.com: aligned commit message a bit for readability] Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-07-14ARM: OMAP2+: Fix possible memory leak in omap_hwmod_allocate_moduleChen Tao
Fix memory leak in omap_hwmod_allocate_module not freeing in handling error path. Fixes: 8c87970543b17("ARM: OMAP2+: Add functions to allocate module data from device tree") Signed-off-by: Chen Tao <chentao107@huawei.com> Reviewed-by: Paul Walmsley <paul@pwsan.com> [tony@atomide.com: fix call iounmap for missing regs] Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-07-14powerpc/pseries/svm: Fix incorrect check for shared_lppaca_sizeSatheesh Rajendran
Early secure guest boot hits the below crash while booting with vcpus numbers aligned with page boundary for PAGE size of 64k and LPPACA size of 1k i.e 64, 128 etc. Partition configured for 64 cpus. CPU maps initialized for 1 thread per core ------------[ cut here ]------------ kernel BUG at arch/powerpc/kernel/paca.c:89! Oops: Exception in kernel mode, sig: 5 [#1] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries This is due to the BUG_ON() for shared_lppaca_total_size equal to shared_lppaca_size. Instead the code should only BUG_ON() if we have exceeded the total_size, which indicates we've overflowed the array. Fixes: bd104e6db6f0 ("powerpc/pseries/svm: Use shared memory for LPPACA structures") Cc: stable@vger.kernel.org # v5.4+ Signed-off-by: Satheesh Rajendran <sathnaga@linux.vnet.ibm.com> Reviewed-by: Laurent Dufour <ldufour@linux.ibm.com> Reviewed-by: Thiago Jung Bauermann <bauerman@linux.ibm.com> [mpe: Reword change log to clarify we're fixing not removing the check] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20200619070113.16696-1-sathnaga@linux.vnet.ibm.com
2020-07-13Merge branch 'for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input Pull input fixes from Dmitry Torokhov: "A few quirks for the Elan touchpad driver, another Thinkpad is being switched over from PS/2 to native RMI4 interface, and we gave a brand new SW_MACHINE_COVER switch definition" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input: Input: elan_i2c - add more hardware ID for Lenovo laptops Input: i8042 - add Lenovo XiaoXin Air 12 to i8042 nomux list Revert "Input: elants_i2c - report resolution information for touch major" Input: elan_i2c - only increment wakeup count on touch Input: synaptics - enable InterTouch for ThinkPad X1E 1st gen ARM: dts: n900: remove mmc1 card detect gpio Input: add `SW_MACHINE_COVER`
2020-07-13arm64: defconfig: Enable CONFIG_PCIE_RCAR_HOSTLad Prabhakar
config option PCIE_RCAR internally selects PCIE_RCAR_HOST which builds the same driver. So this patch renames CONFIG_PCIE_RCAR to CONFIG_PCIE_RCAR_HOST so that PCIE_RCAR can be safely dropped from Kconfig file. Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Link: https://lore.kernel.org/r/1589494238-2933-1-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2020-07-13powerpc/book3s64/pkeys: Fix pkey_access_permitted() for execute disable pkeyAneesh Kumar K.V
Even if the IAMR value denies execute access, the current code returns true from pkey_access_permitted() for an execute permission check, if the AMR read pkey bit is cleared. This results in repeated page fault loop with a test like below: #define _GNU_SOURCE #include <errno.h> #include <stdio.h> #include <stdlib.h> #include <signal.h> #include <inttypes.h> #include <assert.h> #include <malloc.h> #include <unistd.h> #include <pthread.h> #include <sys/mman.h> #ifdef SYS_pkey_mprotect #undef SYS_pkey_mprotect #endif #ifdef SYS_pkey_alloc #undef SYS_pkey_alloc #endif #ifdef SYS_pkey_free #undef SYS_pkey_free #endif #undef PKEY_DISABLE_EXECUTE #define PKEY_DISABLE_EXECUTE 0x4 #define SYS_pkey_mprotect 386 #define SYS_pkey_alloc 384 #define SYS_pkey_free 385 #define PPC_INST_NOP 0x60000000 #define PPC_INST_BLR 0x4e800020 #define PROT_RWX (PROT_READ | PROT_WRITE | PROT_EXEC) static int sys_pkey_mprotect(void *addr, size_t len, int prot, int pkey) { return syscall(SYS_pkey_mprotect, addr, len, prot, pkey); } static int sys_pkey_alloc(unsigned long flags, unsigned long access_rights) { return syscall(SYS_pkey_alloc, flags, access_rights); } static int sys_pkey_free(int pkey) { return syscall(SYS_pkey_free, pkey); } static void do_execute(void *region) { /* jump to region */ asm volatile( "mtctr %0;" "bctrl" : : "r"(region) : "ctr", "lr"); } static void do_protect(void *region) { size_t pgsize; int i, pkey; pgsize = getpagesize(); pkey = sys_pkey_alloc(0, PKEY_DISABLE_EXECUTE); assert (pkey > 0); /* perform mprotect */ assert(!sys_pkey_mprotect(region, pgsize, PROT_RWX, pkey)); do_execute(region); /* free pkey */ assert(!sys_pkey_free(pkey)); } int main(int argc, char **argv) { size_t pgsize, numinsns; unsigned int *region; int i; /* allocate memory region to protect */ pgsize = getpagesize(); region = memalign(pgsize, pgsize); assert(region != NULL); assert(!mprotect(region, pgsize, PROT_RWX)); /* fill page with NOPs with a BLR at the end */ numinsns = pgsize / sizeof(region[0]); for (i = 0; i < numinsns - 1; i++) region[i] = PPC_INST_NOP; region[i] = PPC_INST_BLR; do_protect(region); return EXIT_SUCCESS; } The fix is to only check the IAMR for an execute check, the AMR value is not relevant. Fixes: f2407ef3ba22 ("powerpc: helper to validate key-access permissions of a pte") Cc: stable@vger.kernel.org # v4.16+ Reported-by: Sandipan Das <sandipan@linux.ibm.com> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> [mpe: Add detail to change log, tweak wording & formatting] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20200712132047.1038594-1-aneesh.kumar@linux.ibm.com
2020-07-13ARM: imx: Remove imx_add_imx_dma() unused irq_err argumentBjorn Helgaas
No callers of imx_add_imx_dma() need an error IRQ, so they supply 0 as "irq_err", which means we register a resource of IRQ 0, which is invalid and causes a warning if used. Remove the "irq_err" argument altogether so there's no chance of trying to use the invalid IRQ 0. Fixes: a85a6c86c25be ("driver core: platform: Clarify that IRQ 0 is invalid") Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: Russell King <linux@armlinux.org.uk> Cc: Shawn Guo <shawnguo@kernel.org> Cc: Sascha Hauer <s.hauer@pengutronix.de> Cc: kernel@pengutronix.de Cc: Fabio Estevam <festevam@gmail.com> Cc: linux-imx@nxp.com Cc: linux-arm-kernel@lists.infradead.org Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2020-07-13ARM: imx: Provide correct number of resources when registering gpio devicesGuenter Roeck
Since commit a85a6c86c25be ("driver core: platform: Clarify that IRQ 0 is invalid"), the kernel is a bit touchy when it encounters interrupt 0. As a result, there are lots of warnings such as the following when booting systems such as 'kzm'. WARNING: CPU: 0 PID: 1 at drivers/base/platform.c:224 platform_get_irq_optional+0x118/0x128 0 is an invalid IRQ number Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.8.0-rc3 #1 Hardware name: Kyoto Microcomputer Co., Ltd. KZM-ARM11-01 [<c01127d4>] (unwind_backtrace) from [<c010c620>] (show_stack+0x10/0x14) [<c010c620>] (show_stack) from [<c06f5f54>] (dump_stack+0xe8/0x120) [<c06f5f54>] (dump_stack) from [<c0128878>] (__warn+0xe4/0x108) [<c0128878>] (__warn) from [<c0128910>] (warn_slowpath_fmt+0x74/0xbc) [<c0128910>] (warn_slowpath_fmt) from [<c08b8e84>] (platform_get_irq_optional+0x118/0x128) [<c08b8e84>] (platform_get_irq_optional) from [<c08b8eb4>] (platform_irq_count+0x20/0x3c) [<c08b8eb4>] (platform_irq_count) from [<c0728660>] (mxc_gpio_probe+0x8c/0x494) [<c0728660>] (mxc_gpio_probe) from [<c08b93cc>] (platform_drv_probe+0x48/0x98) [<c08b93cc>] (platform_drv_probe) from [<c08b703c>] (really_probe+0x214/0x344) [<c08b703c>] (really_probe) from [<c08b7274>] (driver_probe_device+0x58/0xb4) [<c08b7274>] (driver_probe_device) from [<c08b7478>] (device_driver_attach+0x58/0x60) [<c08b7478>] (device_driver_attach) from [<c08b7504>] (__driver_attach+0x84/0xc0) [<c08b7504>] (__driver_attach) from [<c08b50f8>] (bus_for_each_dev+0x78/0xb8) [<c08b50f8>] (bus_for_each_dev) from [<c08b62cc>] (bus_add_driver+0x154/0x1e0) [<c08b62cc>] (bus_add_driver) from [<c08b82b8>] (driver_register+0x74/0x108) [<c08b82b8>] (driver_register) from [<c0102320>] (do_one_initcall+0x80/0x3b4) [<c0102320>] (do_one_initcall) from [<c1501008>] (kernel_init_freeable+0x170/0x208) [<c1501008>] (kernel_init_freeable) from [<c0e178d4>] (kernel_init+0x8/0x11c) [<c0e178d4>] (kernel_init) from [<c0100134>] (ret_from_fork+0x14/0x20) As it turns out, mxc_register_gpio() is a bit lax when setting the number of resources: it registers a resource with interrupt 0 when in reality there is no such interrupt. Fix the problem by not declaring the second interrupt resource if there is no second interrupt. Fixes: a85a6c86c25be ("driver core: platform: Clarify that IRQ 0 is invalid") Cc: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2020-07-12Merge tag 'xtensa-20200712' of git://github.com/jcmvbkbc/linux-xtensaLinus Torvalds
Pull Xtensa fixes from Max Filippov: - fix __sync_fetch_and_{and,or}_4 declarations to avoid build warning - update *pos in cpuinfo_op.next to avoid runtime warning - use for_each_set_bit in xtensa_pmu_irq_handler instead of open-coding it * tag 'xtensa-20200712' of git://github.com/jcmvbkbc/linux-xtensa: xtensa: simplify xtensa_pmu_irq_handler xtensa: update *pos in cpuinfo_op.next xtensa: fix __sync_fetch_and_{and,or}_4 declarations
2020-07-11Merge tag 'riscv-for-linus-5.8-rc5' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux Pull RISC-V fixes from Palmer Dabbelt: "I have a few KGDB-related fixes. They're mostly fixes for build warnings, but there's also: - Support for the qSupported and qXfer packets, which are necessary to pass around GDB XML information which we need for the RISC-V GDB port to fully function. - Users can now select STRICT_KERNEL_RWX instead of forcing it on" * tag 'riscv-for-linus-5.8-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux: riscv: Avoid kgdb.h including gdb_xml.h to solve unused-const-variable warning kgdb: Move the extern declaration kgdb_has_hit_break() to generic kgdb.h riscv: Fix "no previous prototype" compile warning in kgdb.c file riscv: enable the Kconfig prompt of STRICT_KERNEL_RWX kgdb: enable arch to support XML packet.
2020-07-11Merge tag 'powerpc-5.8-6' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux Pull powerpc fix from Michael Ellerman: "One fix for a crash/soft lockup on Power8, caused by the exception rework we did in v5.7. Thanks to Paul Menzel and Nicholas Piggin" * tag 'powerpc-5.8-6' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux: powerpc/64s/exception: Fix 0x1500 interrupt handler crash
2020-07-11ARM: dts: imx6qdl-gw551x: fix audio SSITim Harvey
The audio codec on the GW551x routes to ssi1. It fixes audio capture on the device. Cc: stable@vger.kernel.org Fixes: 3117e851cef1 ("ARM: dts: imx: Add TDA19971 HDMI Receiver to GW551x") Signed-off-by: Tim Harvey <tharvey@gateworks.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2020-07-10mips: Remove compiler check in unroll macroNathan Chancellor
CONFIG_CC_IS_GCC is undefined when Clang is used, which breaks the build (see our Travis link below). Clang 8 was chosen as a minimum version for this check because there were some improvements around __builtin_constant_p in that release. In reality, MIPS was not even buildable until clang 9 so that check was not technically necessary. Just remove all compiler checks and just assume that we have a working compiler. Fixes: d4e60453266b ("Restore gcc check in mips asm/unroll.h") Link: https://travis-ci.com/github/ClangBuiltLinux/continuous-integration/jobs/359642821 Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2020-07-10Merge tag 'arm64-fixes' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux Pull arm64 fixes from Will Deacon: "An unfortunately large collection of arm64 fixes for -rc5. Some of this is absolutely trivial, but the alternatives, vDSO and CPU errata workaround fixes are significant. At least people are finding and fixing these things, I suppose. - Fix workaround for CPU erratum #1418040 to disable the compat vDSO - Fix Oops when single-stepping with KGDB - Fix memory attributes for hypervisor device mappings at EL2 - Fix memory leak in PSCI and remove useless variable assignment - Fix up some comments and asm labels in our entry code - Fix broken register table formatting in our generated html docs - Fix missing NULL sentinel in CPU errata workaround list - Fix patching of branches in alternative instruction sections" * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: arm64/alternatives: don't patch up internal branches arm64: Add missing sentinel to erratum_1463225 arm64: Documentation: Fix broken table in generated HTML arm64: kgdb: Fix single-step exception handling oops arm64: entry: Tidy up block comments and label numbers arm64: Rework ARM_ERRATUM_1414080 handling arm64: arch_timer: Disable the compat vdso for cores affected by ARM64_WORKAROUND_1418040 arm64: arch_timer: Allow an workaround descriptor to disable compat vdso arm64: Introduce a way to disable the 32bit vdso arm64: entry: Fix the typo in the comment of el1_dbg() drivers/firmware/psci: Assign @err directly in hotplug_tests() drivers/firmware/psci: Fix memory leakage in alloc_init_cpu_groups() KVM: arm64: Fix definition of PAGE_HYP_DEVICE
2020-07-10Merge tag 's390-5.8-5' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux Pull s390 fixes from Heiko Carstens: "This is mainly due to the fact that Gerald Schaefer's and also my old email addresses currently do not work any longer. Therefore we decided to switch to new email addresses and reflect that in the MAINTAINERS file. - Update email addresses in MAINTAINERS file and add .mailmap entries for Gerald Schaefer and Heiko Carstens. - Fix huge pte soft dirty copying" * tag 's390-5.8-5' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux: MAINTAINERS: update email address for Gerald Schaefer MAINTAINERS: update email address for Heiko Carstens s390/mm: fix huge pte soft dirty copying
2020-07-10Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvmLinus Torvalds
Pull vkm fixes from Paolo Bonzini: "Two simple but important bugfixes" * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: KVM: MIPS: Fix build errors for 32bit kernel KVM: nVMX: fixes for preemption timer migration
2020-07-10KVM: MIPS: Fix build errors for 32bit kernelHuacai Chen
Commit dc6d95b153e78ed70b1b2c04a ("KVM: MIPS: Add more MMIO load/store instructions emulation") introduced some 64bit load/store instructions emulation which are unavailable on 32bit platform, and it causes build errors: arch/mips/kvm/emulate.c: In function 'kvm_mips_emulate_store': arch/mips/kvm/emulate.c:1734:6: error: right shift count >= width of type [-Werror] ((vcpu->arch.gprs[rt] >> 56) & 0xff); ^ arch/mips/kvm/emulate.c:1738:6: error: right shift count >= width of type [-Werror] ((vcpu->arch.gprs[rt] >> 48) & 0xffff); ^ arch/mips/kvm/emulate.c:1742:6: error: right shift count >= width of type [-Werror] ((vcpu->arch.gprs[rt] >> 40) & 0xffffff); ^ arch/mips/kvm/emulate.c:1746:6: error: right shift count >= width of type [-Werror] ((vcpu->arch.gprs[rt] >> 32) & 0xffffffff); ^ arch/mips/kvm/emulate.c:1796:6: error: left shift count >= width of type [-Werror] (vcpu->arch.gprs[rt] << 32); ^ arch/mips/kvm/emulate.c:1800:6: error: left shift count >= width of type [-Werror] (vcpu->arch.gprs[rt] << 40); ^ arch/mips/kvm/emulate.c:1804:6: error: left shift count >= width of type [-Werror] (vcpu->arch.gprs[rt] << 48); ^ arch/mips/kvm/emulate.c:1808:6: error: left shift count >= width of type [-Werror] (vcpu->arch.gprs[rt] << 56); ^ cc1: all warnings being treated as errors make[3]: *** [arch/mips/kvm/emulate.o] Error 1 So, use #if defined(CONFIG_64BIT) && defined(CONFIG_KVM_MIPS_VZ) to guard the 64bit load/store instructions emulation. Reported-by: kernel test robot <lkp@intel.com> Fixes: dc6d95b153e78ed70b1b2c04a ("KVM: MIPS: Add more MMIO load/store instructions emulation") Signed-off-by: Huacai Chen <chenhc@lemote.com> Message-Id: <1594365797-536-1-git-send-email-chenhc@lemote.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-07-10KVM: nVMX: fixes for preemption timer migrationPaolo Bonzini
Commit 850448f35aaf ("KVM: nVMX: Fix VMX preemption timer migration", 2020-06-01) accidentally broke nVMX live migration from older version by changing the userspace ABI. Restore it and, while at it, ensure that vmx->nested.has_preemption_timer_deadline is always initialized according to the KVM_STATE_VMX_PREEMPTION_TIMER_DEADLINE flag. Cc: Makarand Sonare <makarandsonare@google.com> Fixes: 850448f35aaf ("KVM: nVMX: Fix VMX preemption timer migration") Reviewed-by: Jim Mattson <jmattson@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-07-09riscv: Avoid kgdb.h including gdb_xml.h to solve unused-const-variable warningVincent Chen
The constant arrays in gdb_xml.h are only used in arch/riscv/kernel/kgdb.c, but other c files may include the gdb_xml.h indirectly via including the kgdb.h. Hence, It will cause many unused-const-variable warnings. This patch makes the kgdb.h not to include the gdb_xml.h to solve this problem. Signed-off-by: Vincent Chen <vincent.chen@sifive.com> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
2020-07-09kgdb: Move the extern declaration kgdb_has_hit_break() to generic kgdb.hVincent Chen
Currently, only riscv kgdb.c uses the kgdb_has_hit_break() to identify the kgdb breakpoint. It causes other architectures will encounter the "no previous prototype" warnings if the compile option has W=1. Moving the declaration of extern kgdb_has_hit_break() from risc-v kgdb.h to generic kgdb.h to avoid generating these warnings. Signed-off-by: Vincent Chen <vincent.chen@sifive.com> Acked-by: Daniel Thompson <daniel.thompson@linaro.org> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
2020-07-09riscv: Fix "no previous prototype" compile warning in kgdb.c fileVincent Chen
Some functions are only used in the kgdb.c file. Add static properities to these functions to avoid "no previous prototype" compile warnings Signed-off-by: Vincent Chen <vincent.chen@sifive.com> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
2020-07-09riscv: enable the Kconfig prompt of STRICT_KERNEL_RWXVincent Chen
Due to lack of hardware breakpoint support, the kernel option CONFIG_STRICT_KERNEL_RWX should be disabled when using KGDB. However, CONFIG_STRICT_KERNEL_RWX is always enabled now. Therefore, select ARCH_OPTIONAL_KERNEL_RWX_DEFAULT to enable CONFIG_STRICT_KERNEL_RWX by default, and then select ARCH_OPTIONAL_KERNEL_RWX to enable the Kconfig prompt of CONFIG_STRICT_KERNEL_RWX so that users can turn it off. Signed-off-by: Vincent Chen <vincent.chen@sifive.com> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
2020-07-09Restore gcc check in mips asm/unroll.hCesar Eduardo Barros
While raising the gcc version requirement to 4.9, the compile-time check in the unroll macro was accidentally changed from being used on gcc and clang to being used on clang only. Restore the gcc check, changing it from "gcc >= 4.7" to "all gcc". [ We should probably remove this all entirely: if we remove the check for CLANG, then the check for GCC can go away. Older versions of clang are not really appropriate or supported for kernel builds - Linus ] Fixes: 6ec4476ac825 ("Raise gcc version requirement to 4.9") Signed-off-by: Cesar Eduardo Barros <cesarb@cesarb.eti.br> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2020-07-09arm64/alternatives: don't patch up internal branchesArd Biesheuvel
Commit f7b93d42945c ("arm64/alternatives: use subsections for replacement sequences") moved the alternatives replacement sequences into subsections, in order to keep the as close as possible to the code that they replace. Unfortunately, this broke the logic in branch_insn_requires_update, which assumed that any branch into kernel executable code was a branch that required updating, which is no longer the case now that the code sequences that are patched in are in the same section as the patch site itself. So the only way to discriminate branches that require updating and ones that don't is to check whether the branch targets the replacement sequence itself, and so we can drop the call to kernel_text_address() entirely. Fixes: f7b93d42945c ("arm64/alternatives: use subsections for replacement sequences") Reported-by: Alexandru Elisei <alexandru.elisei@arm.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Tested-by: Alexandru Elisei <alexandru.elisei@arm.com> Link: https://lore.kernel.org/r/20200709125953.30918-1-ardb@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
2020-07-09s390/mm: fix huge pte soft dirty copyingJanosch Frank
If the pmd is soft dirty we must mark the pte as soft dirty (and not dirty). This fixes some cases for guest migration with huge page backings. Cc: <stable@vger.kernel.org> # 4.8 Fixes: bc29b7ac1d9f ("s390/mm: clean up pte/pmd encoding") Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com> Reviewed-by: Gerald Schaefer <gerald.schaefer@de.ibm.com> Signed-off-by: Janosch Frank <frankja@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2020-07-09x86/entry/common: Make prepare_exit_to_usermode() staticThomas Gleixner
No users outside this file anymore. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Andy Lutomirski <luto@kernel.org> Link: https://lkml.kernel.org/r/20200708192934.301116609@linutronix.de
2020-07-09x86/entry: Mark check_user_regs() noinstrThomas Gleixner
It's called from the non-instrumentable section. Fixes: c9c26150e61d ("x86/entry: Assert that syscalls are on the right stack") Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Andy Lutomirski <luto@kernel.org> Link: https://lkml.kernel.org/r/20200708192934.191497962@linutronix.de
2020-07-09x86/traps: Disable interrupts in exc_aligment_check()Thomas Gleixner
exc_alignment_check() fails to disable interrupts before returning to the entry code. Fixes: ca4c6a9858c2 ("x86/traps: Make interrupt enable/disable symmetric in C code") Reported-by: syzbot+0889df9502bc0f112b31@syzkaller.appspotmail.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Andy Lutomirski <luto@kernel.org> Link: https://lkml.kernel.org/r/20200708192934.076519438@linutronix.de
2020-07-09arm64: Add missing sentinel to erratum_1463225Florian Fainelli
When the erratum_1463225 array was introduced a sentinel at the end was missing thus causing a KASAN: global-out-of-bounds in is_affected_midr_range_list on arm64 error. Fixes: a9e821b89daa ("arm64: Add KRYO4XX gold CPU cores to erratum list 1463225 and 1418040") Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org> Link: https://lore.kernel.org/linux-arm-kernel/CA+G9fYs3EavpU89-rTQfqQ9GgxAMgMAk7jiiVrfP0yxj5s+Q6g@mail.gmail.com/ Link: https://lore.kernel.org/r/20200709051345.14544-1-f.fainelli@gmail.com Signed-off-by: Will Deacon <will@kernel.org>
2020-07-09efi/libstub/arm64: link stub lib.a conditionallyMasahiro Yamada
Since commit 799c43415442 ("kbuild: thin archives make default for all archs"), core-y is passed to the linker with --whole-archive. Hence, the whole of stub library is linked to vmlinux. Use libs-y so that lib.a is passed after --no-whole-archive for conditional linking. The unused drivers/firmware/efi/libstub/relocate.o will be dropped for ARCH=arm64. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Link: https://lore.kernel.org/r/20200604022031.164207-1-masahiroy@kernel.org Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-07-08arm64: kgdb: Fix single-step exception handling oopsWei Li
After entering kdb due to breakpoint, when we execute 'ss' or 'go' (will delay installing breakpoints, do single-step first), it won't work correctly, and it will enter kdb due to oops. It's because the reason gotten in kdb_stub() is not as expected, and it seems that the ex_vector for single-step should be 0, like what arch powerpc/sh/parisc has implemented. Before the patch: Entering kdb (current=0xffff8000119e2dc0, pid 0) on processor 0 due to Keyboard Entry [0]kdb> bp printk Instruction(i) BP #0 at 0xffff8000101486cc (printk) is enabled addr at ffff8000101486cc, hardtype=0 installed=0 [0]kdb> g / # echo h > /proc/sysrq-trigger Entering kdb (current=0xffff0000fa878040, pid 266) on processor 3 due to Breakpoint @ 0xffff8000101486cc [3]kdb> ss Entering kdb (current=0xffff0000fa878040, pid 266) on processor 3 Oops: (null) due to oops @ 0xffff800010082ab8 CPU: 3 PID: 266 Comm: sh Not tainted 5.7.0-rc4-13839-gf0e5ad491718 #6 Hardware name: linux,dummy-virt (DT) pstate: 00000085 (nzcv daIf -PAN -UAO) pc : el1_irq+0x78/0x180 lr : __handle_sysrq+0x80/0x190 sp : ffff800015003bf0 x29: ffff800015003d20 x28: ffff0000fa878040 x27: 0000000000000000 x26: ffff80001126b1f0 x25: ffff800011b6a0d8 x24: 0000000000000000 x23: 0000000080200005 x22: ffff8000101486cc x21: ffff800015003d30 x20: 0000ffffffffffff x19: ffff8000119f2000 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 x8 : ffff800015003e50 x7 : 0000000000000002 x6 : 00000000380b9990 x5 : ffff8000106e99e8 x4 : ffff0000fadd83c0 x3 : 0000ffffffffffff x2 : ffff800011b6a0d8 x1 : ffff800011b6a000 x0 : ffff80001130c9d8 Call trace: el1_irq+0x78/0x180 printk+0x0/0x84 write_sysrq_trigger+0xb0/0x118 proc_reg_write+0xb4/0xe0 __vfs_write+0x18/0x40 vfs_write+0xb0/0x1b8 ksys_write+0x64/0xf0 __arm64_sys_write+0x14/0x20 el0_svc_common.constprop.2+0xb0/0x168 do_el0_svc+0x20/0x98 el0_sync_handler+0xec/0x1a8 el0_sync+0x140/0x180 [3]kdb> After the patch: Entering kdb (current=0xffff8000119e2dc0, pid 0) on processor 0 due to Keyboard Entry [0]kdb> bp printk Instruction(i) BP #0 at 0xffff8000101486cc (printk) is enabled addr at ffff8000101486cc, hardtype=0 installed=0 [0]kdb> g / # echo h > /proc/sysrq-trigger Entering kdb (current=0xffff0000fa852bc0, pid 268) on processor 0 due to Breakpoint @ 0xffff8000101486cc [0]kdb> g Entering kdb (current=0xffff0000fa852bc0, pid 268) on processor 0 due to Breakpoint @ 0xffff8000101486cc [0]kdb> ss Entering kdb (current=0xffff0000fa852bc0, pid 268) on processor 0 due to SS trap @ 0xffff800010082ab8 [0]kdb> Fixes: 44679a4f142b ("arm64: KGDB: Add step debugging support") Signed-off-by: Wei Li <liwei391@huawei.com> Tested-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20200509214159.19680-2-liwei391@huawei.com Signed-off-by: Will Deacon <will@kernel.org>
2020-07-08arm64: entry: Tidy up block comments and label numbersWill Deacon
Continually butchering our entry code with CPU errata workarounds has led to it looking a little scruffy. Consistently used /* */ comment style for multi-line block comments and ensure that small numeric labels use consecutive integers. No functional change, but the state of things was irritating. Signed-off-by: Will Deacon <will@kernel.org>
2020-07-08arm64: Rework ARM_ERRATUM_1414080 handlingMarc Zyngier
The current handling of erratum 1414080 has the side effect that cntkctl_el1 can get changed for both 32 and 64bit tasks. This isn't a problem so far, but if we ever need to mitigate another of these errata on the 64bit side, we'd better keep the messing with cntkctl_el1 local to 32bit tasks. For that, make sure that on entering the kernel from a 32bit tasks, userspace access to cntvct gets enabled, and disabled returning to userspace, while it never gets changed for 64bit tasks. Signed-off-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Mark Rutland <mark.rutland@arm.com> Link: https://lore.kernel.org/r/20200706163802.1836732-5-maz@kernel.org [will: removed branch instructions per Mark's review comments] Signed-off-by: Will Deacon <will@kernel.org>
2020-07-08arm64: arch_timer: Allow an workaround descriptor to disable compat vdsoMarc Zyngier
As we are about to disable the vdso for compat tasks in some circumstances, let's allow a workaround descriptor to express exactly that. Signed-off-by: Marc Zyngier <maz@kernel.org> Acked-by: Mark Rutland <mark.rutland@arm.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20200706163802.1836732-3-maz@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
2020-07-08arm64: Introduce a way to disable the 32bit vdsoMarc Zyngier
We have a class of errata (grouped under the ARM64_WORKAROUND_1418040 banner) that force the trapping of counter access from 32bit EL0. We would normally disable the whole vdso for such defect, except that it would disable it for 64bit userspace as well, which is a shame. Instead, add a new vdso_clock_mode, which signals that the vdso isn't usable for compat tasks. This gets checked in the new vdso_clocksource_ok() helper, now provided for the 32bit vdso. Signed-off-by: Marc Zyngier <maz@kernel.org> Acked-by: Mark Rutland <mark.rutland@arm.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20200706163802.1836732-2-maz@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
2020-07-08arm64: entry: Fix the typo in the comment of el1_dbg()Kevin Hao
The function name should be local_daif_mask(). Signed-off-by: Kevin Hao <haokexin@gmail.com> Acked-by: Mark Rutlamd <mark.rutland@arm.com> Link: https://lore.kernel.org/r/20200417103212.45812-2-haokexin@gmail.com Signed-off-by: Will Deacon <will@kernel.org>
2020-07-08KVM: arm64: Fix definition of PAGE_HYP_DEVICEWill Deacon
PAGE_HYP_DEVICE is intended to encode attribute bits for an EL2 stage-1 pte mapping a device. Unfortunately, it includes PROT_DEVICE_nGnRE which encodes attributes for EL1 stage-1 mappings such as UXN and nG, which are RES0 for EL2, and DBM which is meaningless as TCR_EL2.HD is not set. Fix the definition of PAGE_HYP_DEVICE so that it doesn't set RES0 bits at EL2. Acked-by: Marc Zyngier <maz@kernel.org> Cc: Marc Zyngier <maz@kernel.org> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: James Morse <james.morse@arm.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200708162546.26176-1-will@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
2020-07-08Raise gcc version requirement to 4.9Linus Torvalds
I realize that we fairly recently raised it to 4.8, but the fact is, 4.9 is a much better minimum version to target. We have a number of workarounds for actual bugs in pre-4.9 gcc versions (including things like internal compiler errors on ARM), but we also have some syntactic workarounds for lacking features. In particular, raising the minimum to 4.9 means that we can now just assume _Generic() exists, which is likely the much better replacement for a lot of very convoluted built-time magic with conditionals on sizeof and/or __builtin_choose_expr() with same_type() etc. Using _Generic also means that you will need to have a very recent version of 'sparse', but thats easy to build yourself, and much less of a hassle than some old gcc version can be. The latest (in a long string) of reasons for minimum compiler version upgrades was commit 5435f73d5c4a ("efi/x86: Fix build with gcc 4"). Ard points out that RHEL 7 uses gcc-4.8, but the people who stay back on old RHEL versions persumably also don't build their own kernels anyway. And maybe they should cross-built or just have a little side affair with a newer compiler? Acked-by: Ard Biesheuvel <ardb@kernel.org> Acked-by: Peter Zijlstra <peterz@infradead.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2020-07-08powerpc/64s/exception: Fix 0x1500 interrupt handler crashNicholas Piggin
A typo caused the interrupt handler to branch immediately to the common "unknown interrupt" handler and skip the special case test for denormal cause. This does not affect KVM softpatch handling (e.g., for POWER9 TM assist) because the KVM test was moved to common code by commit 9600f261acaa ("powerpc/64s/exception: Move KVM test to common code") just before this bug was introduced. Fixes: 3f7fbd97d07d ("powerpc/64s/exception: Clean up SRR specifiers") Reported-by: Paul Menzel <pmenzel@molgen.mpg.de> Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Tested-by: Paul Menzel <pmenzel@molgen.mpg.de> [mpe: Split selftest into a separate patch] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20200708074942.1713396-1-npiggin@gmail.com
2020-07-08xtensa: simplify xtensa_pmu_irq_handlerXu Wang
Use for_each_set_bit() instead of open-coding it to simplify the code. Signed-off-by: Xu Wang <vulab@iscas.ac.cn> Message-Id: <20200708062023.7986-1-vulab@iscas.ac.cn> Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
2020-07-07Merge tag 'arc-5.8-rc5' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc Pull ARC fixes from Vineet Gupta: - User build systems to pass -mcpu - Fix potential EFA clobber in syscall handler - Fix ARCompact 2 levels of interrupts build - Detect newer HS CPU releases - misc other fixes * tag 'arc-5.8-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc: ARCv2: support loop buffer (LPB) disabling ARC: build: remove deprecated toggle for arc700 builds ARC: build: allow users to specify -mcpu ARCv2: boot log: detect newer/upconing HS3x/HS4x releases ARC: elf: use right ELF_ARCH ARC: [arcompact] fix bitrot with 2 levels of interrupt ARC: entry: fix potential EFA clobber when TIF_SYSCALL_TRACE
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-28 20:52:02 +0000