- 20 Aug, 2016 33 commits
-
-
Sebastian Ott authored
commit 0f5d050c upstream. Prior to commit 1bc6664b a call to enable_cmf for a device for which channel measurement was already enabled resulted in a reset of the measurement data. What looked like bugs at the time (a 2nd allocation was triggered but failed, reset was called regardless of previous failures, and errors have not been reported to userspace) was actually something at least one userspace tool depended on. Restore that behavior in a sane way. Fixes: 1bc6664b ("s390/cio: use device_lock during cmb activation") Signed-off-by:
Sebastian Ott <sebott@linux.vnet.ibm.com> Reviewed-by:
Cornelia Huck <cornelia.huck@de.ibm.com> Reviewed-by:
Peter Oberparleiter <oberpar@linux.vnet.ibm.com> Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Paolo Bonzini authored
commit c43203ca upstream. If the processor exits to KVM while delivering an interrupt, the hypervisor then requeues the interrupt for the next vmentry. Trying to enter SMM in this same window causes to enter non-root mode in emulated SMM (i.e. with IF=0) and with a request to inject an IRQ (i.e. with a valid VM-entry interrupt info field). This is invalid guest state (SDM 26.3.1.4 "Check on Guest RIP and RFLAGS") and the processor fails vmentry. The fix is to defer the injection from KVM_REQ_SMI to KVM_REQ_EVENT, like we already do for e.g. NMIs. This patch doesn't change the name of the process_smi function so that it can be applied to stable releases. The next patch will modify the names so that process_nmi and process_smi handle respectively KVM_REQ_NMI and KVM_REQ_SMI. This is especially common with Windows, probably due to the self-IPI trick that it uses to deliver deferred procedure calls (DPCs). Reported-by:
Laszlo Ersek <lersek@redhat.com> Reported-by:
Michał Zegan <webczat_200@poczta.onet.pl> Fixes: 64d60670Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
Radim Krčmář <rkrcmar@redhat.com> Signed-off-by:
-
Jim Mattson authored
commit 2f1fe811 upstream. When freeing the nested resources of a vcpu, there is an assumption that the vcpu's vmcs01 is the current VMCS on the CPU that executes nested_release_vmcs12(). If this assumption is violated, the vcpu's vmcs01 may be made active on multiple CPUs at the same time, in violation of Intel's specification. Moreover, since the vcpu's vmcs01 is not VMCLEARed on every CPU on which it is active, it can linger in a CPU's VMCS cache after it has been freed and potentially repurposed. Subsequent eviction from the CPU's VMCS cache on a capacity miss can result in memory corruption. It is not sufficient for vmx_free_vcpu() to call vmx_load_vmcs01(). If the vcpu in question was last loaded on a different CPU, it must be migrated to the current CPU before calling vmx_load_vmcs01(). Signed-off-by:
Jim Mattson <jmattson@google.com> Signed-off-by:
-
Cao, Lei authored
commit b244c9fc upstream. With PML enabled, guest will shut down if a PML full VMEXIT occurs during event delivery. According to Intel SDM 27.2.3, PML full VMEXIT can occur when event is being delivered through IDT, so KVM should not exit to user space with error. Instead, it should let EXIT_REASON_PML_FULL go through and the event will be re-injected on the next VMENTRY. Signed-off-by:
Lei Cao <lei.cao@stratus.com> Fixes: 843e4330 ("KVM: VMX: Add PML support in VMX") [Shortened the summary and Cc'd stable.] Signed-off-by:
-
Alexis Dambricourt authored
commit 30b072ce upstream. The following #PF may occurs: [ 1403.317041] BUG: unable to handle kernel paging request at 0000000200000068 [ 1403.317045] IP: [<ffffffffc04c20b0>] __mtrr_lookup_var_next+0x10/0xa0 [kvm] [ 1403.317123] Call Trace: [ 1403.317134] [<ffffffffc04c2a65>] ? kvm_mtrr_check_gfn_range_consistency+0xc5/0x120 [kvm] [ 1403.317143] [<ffffffffc04ac11f>] ? tdp_page_fault+0x9f/0x2c0 [kvm] [ 1403.317152] [<ffffffffc0498128>] ? kvm_set_msr_common+0x858/0xc00 [kvm] [ 1403.317161] [<ffffffffc04b8883>] ? x86_emulate_insn+0x273/0xd30 [kvm] [ 1403.317171] [<ffffffffc04c04e4>] ? kvm_cpuid+0x34/0x190 [kvm] [ 1403.317180] [<ffffffffc04a5bb9>] ? kvm_mmu_page_fault+0x59/0xe0 [kvm] [ 1403.317183] [<ffffffffc0d729e1>] ? vmx_handle_exit+0x1d1/0x14a0 [kvm_intel] [ 1403.317185] [<ffffffffc0d75f3f>] ? atomic_switch_perf_msrs+0x6f/0xa0 [kvm_intel] [ 1403.317187] [<ffffffffc0d7621d>] ? vmx_vcpu_run+0x2ad/0x420 [kvm_intel] [ 1403.317196] [<ffffffffc04a0962>] ? kvm_arch_vcpu_ioctl_run+0x622/0x1550 [kvm] [ 1403.317204] [<ffffffffc049abb9>] ? kvm_arch_vcpu_load+0x59/0x210 [kvm] [ 1403.317206] [<ffffffff81036245>] ? __kernel_fpu_end+0x35/0x100 [ 1403.317213] [<ffffffffc0487eb6>] ? kvm_vcpu_ioctl+0x316/0x5d0 [kvm] [ 1403.317215] [<ffffffff81088225>] ? do_sigtimedwait+0xd5/0x220 [ 1403.317217] [<ffffffff811f84dd>] ? do_vfs_ioctl+0x9d/0x5c0 [ 1403.317224] [<ffffffffc04928ae>] ? kvm_on_user_return+0x3e/0x70 [kvm] [ 1403.317225] [<ffffffff811f8a74>] ? SyS_ioctl+0x74/0x80 [ 1403.317227] [<ffffffff815bf0b6>] ? entry_SYSCALL_64_fastpath+0x1e/0xa8 [ 1403.317242] RIP [<ffffffffc04c20b0>] __mtrr_lookup_var_next+0x10/0xa0 [kvm] At mtrr_lookup_fixed_next(), when the condition 'if (iter->index >= ARRAY_SIZE(iter->mtrr_state->fixed_ranges))' becomes true, mtrr_lookup_var_start() is called with iter->range with gargabe values from the fixed MTRR union field. Then, list_prepare_entry() do not call list_entry() initialization, keeping a garbage pointer in iter->range which is accessed in the following __mtrr_lookup_var_next() call. Fixes: f571c097Signed-off-by:
Alexis Dambricourt <alexis@blade-group.com> Signed-off-by:
-
Paul Mackerras authored
commit 93d17397 upstream. It turns out that if the guest does a H_CEDE while the CPU is in a transactional state, and the H_CEDE does a nap, and the nap loses the architected state of the CPU (which is is allowed to do), then we lose the checkpointed state of the virtual CPU. In addition, the transactional-memory state recorded in the MSR gets reset back to non-transactional, and when we try to return to the guest, we take a TM bad thing type of program interrupt because we are trying to transition from non-transactional to transactional with a hrfid instruction, which is not permitted. The result of the program interrupt occurring at that point is that the host CPU will hang in an infinite loop with interrupts disabled. Thus this is a denial of service vulnerability in the host which can be triggered by any guest (and depending on the guest kernel, it can potentially triggered by unprivileged userspace in the guest). This vulnerability has been assigned the ID CVE-2016-5412. To fix this, we save the TM state before napping and restore it on exit from the nap, when handling a H_CEDE in real mode. The case where H_CEDE exits to host virtual mode is already OK (as are other hcalls which exit to host virtual mode) because the exit path saves the TM state. Signed-off-by:
Paul Mackerras <paulus@ozlabs.org> Signed-off-by:
-
Paul Mackerras authored
commit f024ee09 upstream. This moves the transactional memory state save and restore sequences out of the guest entry/exit paths into separate procedures. This is so that these sequences can be used in going into and out of nap in a subsequent patch. The only code changes here are (a) saving and restore LR on the stack, since these new procedures get called with a bl instruction, (b) explicitly saving r1 into the PACA instead of assuming that HSTATE_HOST_R1(r13) is already set, and (c) removing an unnecessary and redundant setting of MSR[TM] that should have been removed by commit 9d4d0bdd9e0a ("KVM: PPC: Book3S HV: Add transactional memory support", 2013-09-24) but wasn't. Signed-off-by:
-
Mark Rutland authored
commit dfbca61a upstream. In create_safe_exec_page(), we create a copy of the hibernate exit text, along with some page tables to map this via TTBR0. We then install the new tables in TTBR0. In swsusp_arch_resume() we call create_safe_exec_page() before trying a number of operations which may fail (e.g. copying the linear map page tables). If these fail, we bail out of swsusp_arch_resume() and return an error code, but leave TTBR0 as-is. Subsequently, the core hibernate code will call free_basic_memory_bitmaps(), which will free all of the memory allocations we made, including the page tables installed in TTBR0. Thus, we may have TTBR0 pointing at dangling freed memory for some period of time. If the hibernate attempt was triggered by a user requesting a hibernate test via the reboot syscall, we may return to userspace with the clobbered TTBR0 value. Avoid these issues by reorganising swsusp_arch_resume() such that we have no failure paths after create_safe_exec_page(). We also add a check that the zero page allocation succeeded, matching what we have for other allocations. Fixes: 82869ac5 ("arm64: kernel: Add support for hibernate/suspend-to-disk") Signed-off-by:
Mark Rutland <mark.rutland@arm.com> Acked-by:
James Morse <james.morse@arm.com> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Will Deacon <will.deacon@arm.com> Signed-off-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
-
Mark Rutland authored
commit 0194e760 upstream. In create_safe_exec_page we install a set of global mappings in TTBR0, then subsequently invalidate TLBs. While TTBR0 points at the zero page, and the TLBs should be free of stale global entries, we may have stale ASID-tagged entries (e.g. from the EFI runtime services mappings) for the same VAs. Per the ARM ARM these ASID-tagged entries may conflict with newly-allocated global entries, and we must follow a Break-Before-Make approach to avoid issues resulting from this. This patch reworks create_safe_exec_page to invalidate TLBs while the zero page is still in place, ensuring that there are no potential conflicts when the new TTBR0 value is installed. As a single CPU is online while this code executes, we do not need to perform broadcast TLB maintenance, and can call local_flush_tlb_all(), which also subsumes some barriers. The remaining assembly is converted to use write_sysreg() and isb(). Other than this, we safely manipulate TTBRs in the hibernate dance. The code we install as part of the new TTBR0 mapping (the hibernated kernel's swsusp_arch_suspend_exit) installs a zero page into TTBR1, invalidates TLBs, then installs its preferred value. Upon being restored to the middle of swsusp_arch_suspend, the new image will call __cpu_suspend_exit, which will call cpu_uninstall_idmap, installing the zero page in TTBR0 and invalidating all TLB entries. Fixes: 82869ac5 ("arm64: kernel: Add support for hibernate/suspend-to-disk") Signed-off-by:
-
Andrew Jones authored
commit 89581f06 upstream. We need to set cpsr before determining the spsr bank, as the bank depends on the target exception level of the injection, not the current mode of the vcpu. Normally this is one in the same (EL1), but not when we manage to trap an EL0 fault. It still doesn't really matter for the 64-bit EL0 case though, as vcpu_spsr() unconditionally uses the EL1 bank for that. However the 32-bit EL0 case gets fun, as that path will lead to the BUG() in vcpu_spsr32(). This patch fixes the assignment order and also modifies some white space in order to better group pairs of lines that have strict order. Signed-off-by:
Andrew Jones <drjones@redhat.com> Signed-off-by:
Marc Zyngier <marc.zyngier@arm.com> Signed-off-by:
-
Ard Biesheuvel authored
commit d6732fc4 upstream. Due to the untyped KIMAGE_VADDR constant, the linker may not notice that the __rela_offset and __dynsym_offset expressions are absolute values (i.e., are not subject to relocation). This does not matter for KASLR, but it does confuse kallsyms in relative mode, since it uses the lowest non-absolute symbol address as the anchor point, and expects all other symbol addresses to be within 4 GB of it. Fix this by qualifying these expressions as ABSOLUTE() explicitly. Fixes: 0cd3defe ("arm64: kernel: perform relocation processing from ID map") Signed-off-by:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
-
Ard Biesheuvel authored
commit 04a84810 upstream. As reported by Zijun, the fdt_check_header() call in __fixmap_remap_fdt() is not safe since it is not guaranteed that the FDT header is mapped completely. Due to the minimum alignment of 8 bytes, the only fields we can assume to be mapped are 'magic' and 'totalsize'. Since the OF layer is in charge of validating the FDT image, and we are only interested in making reasonably sure that the size field contains a meaningful value, replace the fdt_check_header() call with an explicit comparison of the magic field's value against the expected value. Reported-by:
Zijun Hu <zijun_hu@htc.com> Acked-by:
-
Caesar Wang authored
commit ad1cfdf5 upstream. The 2nd additional region is the GIC virtual cpu interface register base and size. As the gic400 of rk3368 says, the cpu interface register map as below : -0x0000 GICC_CTRL . . . -0x00fc GICC_IIDR -0x1000 GICC_IDR Obviously, the region size should be greater than 0x1000. So we should make sure to include the GICC_IDR since the kernel will access it in some cases. Fixes: b790c2ca ("arm64: dts: add Rockchip rk3368 core dtsi and board dts for the r88 board") Signed-off-by:
Caesar Wang <wxt@rock-chips.com> Reviewed-by:
Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by:
Heiko Stuebner <heiko@sntech.de>
-
Dan O'Donovan authored
commit 0bd50d71 upstream. Due to a silicon issue on the Atom X5-Z8000 "Cherry Trail" processor series, a common lock must be used to prevent concurrent accesses across the 4 GPIO controllers managed by this driver. See Intel Atom Z8000 Processor Series Specification Update (Rev. 005), errata #CHT34, for further information. Signed-off-by:
Dan O'Donovan <dan@emutex.com> Acked-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Andy Shevchenko authored
commit dd3b204a upstream. The error handling is not correct since the commit 3f7dbfd8 ("gpio: intel-mid: switch to using gpiolib irqchip helpers"). Switch to devres API to fix the potential resource leak. Fixes: commit 3f7dbfd8 ("gpio: intel-mid: switch to using gpiolib irqchip helpers") Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
-
Andy Shevchenko authored
commit 3dbd3212 upstream. The commit d56d6b3d ("gpio: langwell: add Intel Merrifield support") doesn't look at all as a proper support for Intel Merrifield and I dare to say that it distorts the behaviour of the hardware. The register map is different on Intel Merrifield, i.e. only 6 out of 8 register have the same purpose but none of them has same location in the address space. The current case potentially harmful to existing hardware since it's poking registers on wrong offsets and may set some pin to be GPIO output when connected hardware doesn't expect such. Besides the above GPIO and pinctrl on Intel Merrifield have been located in different IP blocks. The functionality has been extended as well, i.e. added support of level interrupts, special registers for wake capable sources and thus, in my opinion, requires a completele separate driver. If someone wondering the existing gpio-intel-mid.c would be converted to actual pinctrl (which by the fact it is now), though I wouldn't be a volunteer to do that. Fixes: d56d6b3d ("gpio: langwell: add Intel Merrifield support") Signed-off-by:
-
Vignesh R authored
commit a246b819 upstream. NBANK() macro assumes that ngpios is a multiple of 8(BANK_SZ) and hence results in 0 banks for PCA9536 which has just 4 gpios. This is wrong as PCA9356 has 1 bank with 4 gpios. This results in uninitialized PCA953X_INVERT register. Fix this by using DIV_ROUND_UP macro in NBANK(). Signed-off-by:
Vignesh R <vigneshr@ti.com> Signed-off-by:
-
Alexandre Belloni authored
commit 0058f087 upstream. When using DMA, half duplex doesn't work properly because rx is not stopped before starting tx. Ensure we call atmel_stop_rx() in the DMA case. Signed-off-by:
Alexandre Belloni <alexandre.belloni@free-electrons.com> Acked-by:
Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by:
-
Krzysztof Kozlowski authored
commit e51e4d8a upstream. When the clk_get() of "uart" clock returns EPROBE_DEFER, the next re-probe finishes with success but uses invalid (ERR_PTR) values. This leads to dereferencing of ERR_PTR stored under ourport->clk: 12c30000.serial: Controller clock not found (...) 12c30000.serial: ttySAC3 at MMIO 0x12c30000 (irq = 61, base_baud = 0) is a S3C6400/10 Unable to handle kernel paging request at virtual address fffffdfb (clk_prepare) from [<c039f7d0>] (s3c24xx_serial_pm+0x20/0x128) (s3c24xx_serial_pm) from [<c0395414>] (uart_change_pm+0x38/0x40) (uart_change_pm) from [<c039689c>] (uart_add_one_port+0x31c/0x44c) (uart_add_one_port) from [<c03a035c>] (s3c24xx_serial_probe+0x2a8/0x418) (s3c24xx_serial_probe) from [<c03ee110>] (platform_drv_probe+0x50/0xb0) (platform_drv_probe) from [<c03ecb44>] (driver_probe_device+0x1f4/0x2b0) (driver_probe_device) from [<c03eb0c0>] (bus_for_each_drv+0x44/0x8c) (bus_for_each_drv) from [<c03ec8c8>] (__device_attach+0x9c/0x100) (__device_attach) from [<c03ebf54>] (bus_probe_device+0x84/0x8c) (bus_probe_device) from [<c03ec388>] (deferred_probe_work_func+0x60/0x8c) (deferred_probe_work_func) from [<c012fee4>] (process_one_work+0x120/0x328) (process_one_work) from [<c0130150>] (worker_thread+0x2c/0x4ac) (worker_thread) from [<c0135320>] (kthread+0xd8/0xf4) (kthread) from [<c0107978>] (ret_from_fork+0x14/0x3c) The first unsuccessful clk_get() causes s3c24xx_serial_init_port() to exit with failure but the s3c24xx_uart_port is left half-configured (e.g. port->mapbase is set, clk contains ERR_PTR). On next re-probe, the function s3c24xx_serial_init_port() will exit early with success because of configured port->mapbase and driver will use old values, including the ERR_PTR as clock. Fix this by cleaning the port->mapbase on error path so each re-probe will initialize all of the port settings. Fixes: 60e93575 ("serial: samsung: enable clock before clearing pending interrupts during init") Signed-off-by:
Krzysztof Kozlowski <k.kozlowski@samsung.com> Reviewed-by:
Javier Martinez Canillas <javier@osg.samsung.com> Tested-by:
Kevin Hilman <khilman@baylibre.com> Signed-off-by:
-
Bjorn Andersson authored
commit 30acf549 upstream. For dm uarts in pio mode tx data is transferred to the fifo register 4 bytes at a time, but care is not taken when these 4 bytes spans the end of the xmit buffer so the loop might read up to 3 bytes past the buffer and then skip the actual data at the beginning of the buffer. Fix this by, analogous to the DMA case, make sure the chunk doesn't wrap the xmit buffer. Fixes: 3a878c43 ("tty: serial: msm: Add TX DMA support") Cc: Ivan Ivanov <iivanov.xz@gmail.com> Reported-by:
Frank Rowand <frowand.list@gmail.com> Reported-by:
Nicolas Dechesne <nicolas.dechesne@linaro.org> Signed-off-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Acked-by:
Andy Gross <andy.gross@linaro.org> Tested-by:
Frank Rowand <frank.rowand@am.sony.com> Reviewed-by:
Stephen Boyd <sboyd@codeaurora.org> Signed-off-by:
-
Suzuki K Poulose authored
commit e75118a7 upstream. Passing "nosmp" should boot the kernel with a single processor, without provision to enable secondary CPUs even if they are present. "nosmp" is implemented by setting maxcpus=0. At the moment we still mark the secondary CPUs present even with nosmp, which allows the userspace to bring them up. This patch corrects the smp_prepare_cpus() to honor the maxcpus == 0. Commit 44dbcc93 ("arm64: Fix behavior of maxcpus=N") fixed the behavior for maxcpus >= 1, but broke maxcpus = 0. Fixes: 44dbcc93 ("arm64: Fix behavior of maxcpus=N") Cc: Will Deacon <will.deacon@arm.com> Cc: James Morse <james.morse@arm.com> Signed-off-by:
Suzuki K Poulose <suzuki.poulose@arm.com> Acked-by:
-
Catalin Marinas authored
commit b9c220b5 upstream. Selecting CONFIG_RANDOMIZE_BASE=y and CONFIG_MODULES=n fails to build the module PLTs support: CC arch/arm64/kernel/module-plts.o /work/Linux/linux-2.6-aarch64/arch/arm64/kernel/module-plts.c: In function ‘module_emit_plt_entry’: /work/Linux/linux-2.6-aarch64/arch/arm64/kernel/module-plts.c:32:49: error: dereferencing pointer to incomplete type ‘struct module’ This patch selects ARM64_MODULE_PLTS conditionally only if MODULES is enabled. Fixes: f80fb3a3 ("arm64: add support for kernel ASLR") Reported-by:
Jeff Vander Stoep <jeffv@google.com> Acked-by:
-
Suzuki K Poulose authored
commit 9113c2aa upstream. In smp_prepare_boot_cpu(), we invoke cpuinfo_store_boot_cpu to store the cpuinfo in a per-cpu ptr, before initialising the per-cpu offset for the boot CPU. This patch reorders the sequence to make sure we initialise the per-cpu offset before accessing the per-cpu area. Commit 4b998ff1 ("arm64: Delay cpuinfo_store_boot_cpu") fixed the issue where we modified the per-cpu area even before the kernel initialises the per-cpu areas, but failed to wait until the boot cpu updated it's offset. Fixes: 4b998ff1 ("arm64: Delay cpuinfo_store_boot_cpu") Cc: Will Deacon <will.deacon@arm.com> Signed-off-by:
-
Will Deacon authored
commit 2ce39ad1 upstream. Clearing PSTATE.D is one of the requirements for generating a debug exception. The arm64 booting protocol requires that PSTATE.D is set, since many of the debug registers (for example, the hw_breakpoint registers) are UNKNOWN out of reset and could potentially generate spurious, fatal debug exceptions in early boot code if PSTATE.D was clear. Once the debug registers have been safely initialised, PSTATE.D is cleared, however this is currently broken for two reasons: (1) The boot CPU clears PSTATE.D in a postcore_initcall and secondary CPUs clear PSTATE.D in secondary_start_kernel. Since the initcall runs after SMP (and the scheduler) have been initialised, there is no guarantee that it is actually running on the boot CPU. In this case, the boot CPU is left with PSTATE.D set and is not capable of generating debug exceptions. (2) In a preemptible kernel, we may explicitly schedule on the IRQ return path to EL1. If an IRQ occurs with PSTATE.D set in the idle thread, then we may schedule the kthread_init thread, run the postcore_initcall to clear PSTATE.D and then context switch back to the idle thread before returning from the IRQ. The exception return path will then restore PSTATE.D from the stack, and set it again. This patch fixes the problem by moving the clearing of PSTATE.D earlier to proc.S. This has the desirable effect of clearing it in one place for all CPUs, long before we have to worry about the scheduler or any exception handling. We ensure that the previous reset of MDSCR_EL1 has completed before unmasking the exception, so that any spurious exceptions resulting from UNKNOWN debug registers are not generated. Without this patch applied, the kprobes selftests have been seen to fail under KVM, where we end up attempting to step the OOL instruction buffer with PSTATE.D set and therefore fail to complete the step. Acked-by:
-
Marc Zyngier authored
commit 4c47eb1c upstream. The kprobe enablement work has uncovered that changes made by a guest to MDSCR_EL1 were propagated to the host when VHE was enabled, leading to unexpected exception being delivered. Moving this register to the list of registers that are always context-switched fixes the issue. Fixes: 9c6c3568 ("arm64: KVM: VHE: Split save/restore of registers shared between guest and host") Reported-by:
Tirumalesh Chalamarla <Tirumalesh.Chalamarla@cavium.com> Tested-by:
-
Yoshihiro Shimoda authored
commit 4fdef698 upstream. This patch fixes an issue that the xfer_work() is possible to cause NULL pointer dereference if the usb cable is disconnected while data transfer is running. In such case, a gadget driver may call usb_ep_disable()) before xfer_work() is actually called. In this case, the usbhs_pkt_pop() will call usbhsf_fifo_unselect(), and then usbhs_pipe_to_fifo() in xfer_work() will return NULL. Fixes: e73a9891 ("usb: renesas_usbhs: add DMAEngine support") Signed-off-by:
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by:
Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by:
-
Daniele Palmas authored
commit 3c0415fa upstream. This patch adds support for 0x1206 PID of Telit LE910. Since the interfaces positions are the same than the ones for 0x1043 PID of Telit LE922, telit_le922_blacklist_usbcfg3 is used. Signed-off-by:
Daniele Palmas <dnlplm@gmail.com> Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
-
Konrad Leszczynski authored
commit 9cad39fe upstream. commit f3af3651 ("usb: dwc3: gadget: always enable IOC on bulk/interrupt transfers") ended up regressing Isochronous endpoints by clearing DWC3_EP_BUSY flag too early, which resulted in choppy audio playback over USB. Fix that by partially reverting original commit and making sure that we check for isochronous endpoints. Fixes: f3af3651 ("usb: dwc3: gadget: always enable IOC on bulk/interrupt transfers") Signed-off-by:
Konrad Leszczynski <konrad.leszczynski@intel.com> Signed-off-by:
Rafal Redzimski <rafal.f.redzimski@intel.com> Signed-off-by:
-
Joseph Salisbury authored
commit 25b1f9ac upstream. BugLink: http://bugs.launchpad.net/bugs/1498667 As reported in BugLink, this device has an issue with Linux Power Management so adding a quirk. This quirk was reccomended by Alan Stern: http://lkml.iu.edu/hypermail/linux/kernel/1606.2/05590.htmlSigned-off-by:
Joseph Salisbury <joseph.salisbury@canonical.com> Signed-off-by:
-
Yoshihiro Shimoda authored
commit 15e4292a upstream. This patch fixes an issue that the CFIFOSEL register value is possible to be changed by usbhsg_ep_enable() wrongly. And then, a data transfer using CFIFO may not work correctly. For example: # modprobe g_multi file=usb-storage.bin # ifconfig usb0 192.168.1.1 up (During the USB host is sending file to the mass storage) # ifconfig usb0 down In this case, since the u_ether.c may call usb_ep_enable() in eth_stop(), if the renesas_usbhs driver is also using CFIFO for mass storage, the mass storage may not work correctly. So, this patch adds usbhs_lock() and usbhs_unlock() calling in usbhsg_ep_enable() to protect CFIFOSEL register. This is because: - CFIFOSEL.CURPIPE = 0 is also needed for the pipe configuration - The CFIFOSEL (fifo->sel) is already protected by usbhs_lock() Fixes: 97664a20 ("usb: renesas_usbhs: shrink spin lock area") Signed-off-by:
-
Iago Abal authored
commit 1d23d16a upstream. The above commit reordered spin_lock/unlock and now `&dev->lock' is acquired (rather than released) before calling `dev->driver->disconnect', `dev->driver->setup', `dev->driver->suspend', `usb_gadget_giveback_request', and `usb_gadget_udc_reset'. But this *may* not be the right way to fix the problem pointed by d3cb25a1. Note that the other usb/gadget/udc drivers do release the lock before calling these functions. There are also inconsistencies within pch_udc.c, where `dev->driver->disconnect' is called while holding `&dev->lock' in lines 613 and 1184, but not in line 2739. Finally, commit d3cb25a1 may have introduced several potential deadlocks. For instance, EBA (https://github.com/models-team/eba) reports: Double lock in drivers/usb/gadget/udc/pch_udc.c first at 2791: spin_lock(& dev->lock); [pch_udc_isr] second at 2694: spin_lock(& dev->lock); [pch_udc_svc_cfg_interrupt] after calling from 2793: pch_udc_dev_isr(dev, dev_intr); after calling from 2724: pch_udc_svc_cfg_interrupt(dev); Similarly, other potential deadlocks are 2791 -> 2793 -> 2721 -> 2657; and 2791 -> 2793 -> 2711 -> 2573 -> 1499 -> 1480. Fixes: d3cb25a1 ("usb: gadget: udc: fix spin_lock in pch_udc") Signed-off-by:
Iago Abal <mail@iagoabal.eu> Signed-off-by:
-
Alexandre Belloni authored
commit 882bd9fc upstream. The "atmel,at91sam9g45-udc" compatible UDC is also used on at91sam9x5 so it is also necessary to try to get the syscon for at91sam9x5-pmc. Fixes: 4747639f ("usb: gadget: atmel: access the PMC using regmap") Reported-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
-
Felipe Balbi authored
commit ab2a92e7 upstream. As a micro-power optimization, let's only resume the USB2 PHY if we're working on <=HIGHSPEED. If we're gonna work on SUPERSPEED or SUPERSPEED+, there's no point in resuming the USB2 PHY. Fixes: 2b0f11df ("usb: dwc3: gadget: clear SUSPHY bit before ep cmds") Signed-off-by:
-
- 16 Aug, 2016 7 commits
-
-
Greg Kroah-Hartman authored
-
Vegard Nossum authored
commit 554a5ccc upstream. If we hit this error when mounted with errors=continue or errors=remount-ro: EXT4-fs error (device loop0): ext4_mb_mark_diskspace_used:2940: comm ext4.exe: Allocating blocks 5090-6081 which overlap fs metadata then ext4_mb_new_blocks() will call ext4_mb_release_context() and try to continue. However, ext4_mb_release_context() is the wrong thing to call here since we are still actually using the allocation context. Instead, just error out. We could retry the allocation, but there is a possibility of getting stuck in an infinite loop instead, so this seems safer. [ Fixed up so we don't return EAGAIN to userspace. --tytso ] Fixes: 8556e8f3 ("ext4: Don't allow new groups to be added during block allocation") Signed-off-by:
Vegard Nossum <vegard.nossum@oracle.com> Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Cc: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> Signed-off-by:
-
Vegard Nossum authored
commit c65d5c6c upstream. If we encounter a filesystem error during orphan cleanup, we should stop. Otherwise, we may end up in an infinite loop where the same inode is processed again and again. EXT4-fs (loop0): warning: checktime reached, running e2fsck is recommended EXT4-fs error (device loop0): ext4_mb_generate_buddy:758: group 2, block bitmap and bg descriptor inconsistent: 6117 vs 0 free clusters Aborting journal on device loop0-8. EXT4-fs (loop0): Remounting filesystem read-only EXT4-fs error (device loop0) in ext4_free_blocks:4895: Journal has aborted EXT4-fs error (device loop0) in ext4_do_update_inode:4893: Journal has aborted EXT4-fs error (device loop0) in ext4_do_update_inode:4893: Journal has aborted EXT4-fs error (device loop0) in ext4_ext_remove_space:3068: IO failure EXT4-fs error (device loop0) in ext4_ext_truncate:4667: Journal has aborted EXT4-fs error (device loop0) in ext4_orphan_del:2927: Journal has aborted EXT4-fs error (device loop0) in ext4_do_update_inode:4893: Journal has aborted EXT4-fs (loop0): Inode 16 (00000000618192a0): orphan list check failed! [...] EXT4-fs (loop0): Inode 16 (0000000061819748): orphan list check failed! [...] EXT4-fs (loop0): Inode 16 (0000000061819bf0): orphan list check failed! [...] See-also: c9eb13a9 ("ext4: fix hang when processing corrupted orphaned inode list") Cc: Jan Kara <jack@suse.cz> Signed-off-by:
-
Theodore Ts'o authored
commit 5b9554dc upstream. If s_reserved_gdt_blocks is extremely large, it's possible for ext4_init_block_bitmap(), which is called when ext4 sets up an uninitialized block bitmap, to corrupt random kernel memory. Add the same checks which e2fsck has --- it must never be larger than blocksize / sizeof(__u32) --- and then add a backup check in ext4_init_block_bitmap() in case the superblock gets modified after the file system is mounted. Reported-by:
-
Vegard Nossum authored
commit 6a7fd522 upstream. If ext4_fill_super() fails early, it's possible for ext4_evict_inode() to call ext4_should_journal_data() before superblock options and flags are fully set up. In that case, the iput() on the journal inode can end up causing a BUG(). Work around this problem by reordering the tests so we only call ext4_should_journal_data() after we know it's not the journal inode. Fixes: 2d859db3 ("ext4: fix data corruption in inodes with journalled data") Fixes: 2b405bfa ("ext4: fix data=journal fast mount/umount hang") Cc: Jan Kara <jack@suse.cz> Signed-off-by:
Jan Kara <jack@suse.cz> Signed-off-by:
-
Jan Kara authored
commit 646caa9c upstream. Commit 06bd3c36 (ext4: fix data exposure after a crash) uncovered a deadlock in ext4_writepages() which was previously much harder to hit. After this commit xfstest generic/130 reproduces the deadlock on small filesystems. The problem happens when ext4_do_update_inode() sets LARGE_FILE feature and marks current inode handle as synchronous. That subsequently results in ext4_journal_stop() called from ext4_writepages() to block waiting for transaction commit while still holding page locks, reference to io_end, and some prepared bio in mpd structure each of which can possibly block transaction commit from completing and thus results in deadlock. Fix the problem by releasing page locks, io_end reference, and submitting prepared bio before calling ext4_journal_stop(). [ Changed to defer the call to ext4_journal_stop() only if the handle is synchronous. --tytso ] Reported-and-tested-by:
Eryu Guan <eguan@redhat.com> Signed-off-by:
-
Vegard Nossum authored
commit f70749ca upstream. An extent with lblock = 4294967295 and len = 1 will pass the ext4_valid_extent() test: ext4_lblk_t last = lblock + len - 1; if (len == 0 || lblock > last) return 0; since last = 4294967295 + 1 - 1 = 4294967295. This would later trigger the BUG_ON(es->es_lblk + es->es_len < es->es_lblk) in ext4_es_end(). We can simplify it by removing the - 1 altogether and changing the test to use lblock + len <= lblock, since now if len = 0, then lblock + 0 == lblock and it fails, and if len > 0 then lblock + len > lblock in order to pass (i.e. it doesn't overflow). Fixes: 5946d089 ("ext4: check for overlapping extents in ext4_valid_extent_entries()") Fixes: 2f974865 ("ext4: check for zero length extent explicitly") Cc: Eryu Guan <guaneryu@gmail.com> Signed-off-by:
Phil Turnbull <phil.turnbull@oracle.com> Signed-off-by:
-
