- 26 Jan, 2017 40 commits
-
-
Bryant G. Ly authored
commit 387b978c upstream. Current code incorrectly calculates the max transfer length, since it is assuming a 4k page table, but ppc64 all run on 64k page tables. Reported-by:
Steven Royer <seroyer@linux.vnet.ibm.com> Tested-by:
Bryant G. Ly <bryantly@linux.vnet.ibm.com> Signed-off-by:
Bart Van Assche <bart.vanassche@sandisk.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Bryant G. Ly authored
commit a5b0e406 upstream. Currently, dma_alloc_coherent is being called with a GFP_KERNEL flag which allows it to sleep in an interrupt context, need to change to GFP_ATOMIC. Tested-by:
Michael Cyr <mikecyr@linux.vnet.ibm.com> Signed-off-by:
-
Mark Rutland authored
commit ddc37832 upstream. On APQ8060, the kernel crashes in arch_hw_breakpoint_init, taking an undefined instruction trap within write_wb_reg. This is because Scorpion CPUs erroneously appear to set DBGPRSR.SPD when WFI is issued, even if the core is not powered down. When DBGPRSR.SPD is set, breakpoint and watchpoint registers are treated as undefined. It's possible to trigger similar crashes later on from userspace, by requesting the kernel to install a breakpoint or watchpoint, as we can go idle at any point between the reset of the debug registers and their later use. This has always been the case. Given that this has always been broken, no-one has complained until now, and there is no clear workaround, disable hardware breakpoints and watchpoints on Scorpion to avoid these issues. Signed-off-by:
Mark Rutland <mark.rutland@arm.com> Reported-by:
Linus Walleij <linus.walleij@linaro.org> Reviewed-by:
Stephen Boyd <sboyd@codeaurora.org> Acked-by:
Will Deacon <will.deacon@arm.com> Cc: Russell King <linux@armlinux.org.uk> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
-
Sriharsha Basavapatna authored
commit ce1ca7d2 upstream. In rdma_read_chunk_frmr() when ib_post_send() fails, the error code path invokes ib_dma_unmap_sg() to unmap the sg list. It then invokes svc_rdma_put_frmr() which in turn tries to unmap the same sg list through ib_dma_unmap_sg() again. This second unmap is invalid and could lead to problems when the iova being unmapped is subsequently reused. Remove the call to unmap in rdma_read_chunk_frmr() and let svc_rdma_put_frmr() handle it. Fixes: 412a15c0 ("svcrdma: Port to new memory registration API") Signed-off-by:
Sriharsha Basavapatna <sriharsha.basavapatna@broadcom.com> Reviewed-by:
Chuck Lever <chuck.lever@oracle.com> Reviewed-by:
Yuval Shaia <yuval.shaia@oracle.com> Signed-off-by:
J. Bruce Fields <bfields@redhat.com> Signed-off-by:
-
Joonyoung Shim authored
commit bc7c36ee upstream. When a CPU goes offline a potentially pending timer interrupt is not cleared. When the CPU comes online again then the pending interrupt is delivered before the per cpu clockevent device is initialized. As a consequence the tick interrupt handler dereferences a NULL pointer. [ 51.251378] Unable to handle kernel NULL pointer dereference at virtual address 00000040 [ 51.289348] task: ee942d00 task.stack: ee960000 [ 51.293861] PC is at tick_periodic+0x38/0xb0 [ 51.298102] LR is at tick_handle_periodic+0x1c/0x90 Clear the pending interrupt in the cpu dying path. Fixes: 56a94f13 ("clocksource: exynos_mct: Avoid blocking calls in the cpu hotplug notifier") Reported-by:
Seung-Woo Kim <sw0312.kim@samsung.com> Signed-off-by:
Joonyoung Shim <jy0922.shim@samsung.com> Cc: linux-samsung-soc@vger.kernel.org Cc: cw00.choi@samsung.com Cc: daniel.lezcano@linaro.org Cc: javier@osg.samsung.com Cc: kgene@kernel.org Cc: krzk@kernel.org Cc: linux-arm-kernel@lists.infradead.org Link: http://lkml.kernel.org/r/1484628876-22065-1-git-send-email-jy0922.shim@samsung.comSigned-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Richard Weinberger authored
commit 1cb51a15 upstream. When replaying the journal it can happen that a journal entry points to a garbage collected node. This is the case when a power-cut occurred between a garbage collect run and a commit. In such a case nodes have to be read using the failable read functions to detect whether the found node matches what we expect. One corner case was forgotten, when the journal contains an entry to remove an inode all xattrs have to be removed too. UBIFS models xattr like directory entries, so the TNC code iterates over all xattrs of the inode and removes them too. This code re-uses the functions for walking directories and calls ubifs_tnc_next_ent(). ubifs_tnc_next_ent() expects to be used only after the journal and aborts when a node does not match the expected result. This behavior can render an UBIFS volume unmountable after a power-cut when xattrs are used. Fix this issue by using failable read functions in ubifs_tnc_next_ent() too when replaying the journal. Fixes: 1e51764a ("UBIFS: add new flash file system") Reported-by:
Rock Lee <rockdotlee@gmail.com> Reviewed-by:
David Gstir <david@sigma-star.at> Signed-off-by:
Richard Weinberger <richard@nod.at> Signed-off-by:
-
Johannes Berg authored
commit eeb0d56f upstream. In AP (or VLAN) mode, when unicast 802.11 packets are received, they might actually be multicast after conversion. In this case the fast-RX path didn't handle them properly to send them back to the wireless medium. Implement that by copying the SKB and sending it back out. The possible alternative would be to just punt the packet back to the regular (slow) RX path, but since we have almost all of the required code here already it's not so complicated to add here. Punting it back would also mean acquiring the spinlock, which would be bad for the stated purpose of the fast-RX path, to enable well-performing parallel RX. Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Quinn Tran authored
commit fc1ffd6c upstream. During code inspection, while investigating following stack trace seen on one of the test setup, we found out there was possibility of memory leak becuase driver was not unwinding the stack properly. This issue has not been reproduced in a test environment or on a customer setup. Here's stack trace that was seen. [1469877.797315] Call Trace: [1469877.799940] [<ffffffffa03ab6e9>] qla2x00_mem_alloc+0xb09/0x10c0 [qla2xxx] [1469877.806980] [<ffffffffa03ac50a>] qla2x00_probe_one+0x86a/0x1b50 [qla2xxx] [1469877.814013] [<ffffffff813b6d01>] ? __pm_runtime_resume+0x51/0xa0 [1469877.820265] [<ffffffff8157c1f5>] ? _raw_spin_lock_irqsave+0x25/0x90 [1469877.826776] [<ffffffff8157cd2d>] ? _raw_spin_unlock_irqrestore+0x6d/0x80 [1469877.833720] [<ffffffff810741d1>] ? preempt_count_sub+0xb1/0x100 [1469877.839885] [<ffffffff8157cd0c>] ? _raw_spin_unlock_irqrestore+0x4c/0x80 [1469877.846830] [<ffffffff81319b9c>] local_pci_probe+0x4c/0xb0 [1469877.852562] [<ffffffff810741d1>] ? preempt_count_sub+0xb1/0x100 [1469877.858727] [<ffffffff81319c89>] pci_call_probe+0x89/0xb0 Signed-off-by:
Quinn Tran <quinn.tran@cavium.com> Signed-off-by:
Himanshu Madhani <himanshu.madhani@cavium.com> Reviewed-by:
Christoph Hellwig <hch@lst.de> [ bvanassche: Fixed spelling in patch description ] Signed-off-by:
-
Ruslan Ruslichenko authored
commit 020eb3da upstream. commit d32932d0 removed the irq_retrigger callback from the IO-APIC chip and did not add it to the new IO-APIC-IR irq chip. Unfortunately the software resend fallback is not enabled on X86, so edge interrupts which are received during the lazy disabled state of the interrupt line are not retriggered and therefor lost. Restore the callbacks. [ tglx: Massaged changelog ] Fixes: d32932d0 ("x86/irq: Convert IOAPIC to use hierarchical irqdomain interfaces") Signed-off-by:
Ruslan Ruslichenko <rruslich@cisco.com> Cc: xe-linux-external@cisco.com Link: http://lkml.kernel.org/r/1484662432-13580-1-git-send-email-rruslich@cisco.comSigned-off-by:
-
Anton Blanchard authored
commit 178f3582 upstream. IBM bit 31 (for the rest of us - bit 0) is a reserved field in the instruction definition of mtspr and mfspr. Hardware is encouraged to (and does) ignore it. As a result, if userspace executes an mtspr DSCR with the reserved bit set, we get a DSCR facility unavailable exception. The kernel fails to match against the expected value/mask, and we silently return to userspace to try and re-execute the same mtspr DSCR instruction. We loop forever until the process is killed. We should do something here, and it seems mirroring what hardware does is the better option vs killing the process. While here, relax the matching of mfspr PVR too. Signed-off-by:
Anton Blanchard <anton@samba.org> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
-
Dave Martin authored
commit b34ca601 upstream. Ensure that if userspace supplies insufficient data to PTRACE_SETREGSET to fill all the check pointed registers, the thread's old check pointed registers are preserved. Fixes: 9d3918f7 ("powerpc/ptrace: Enable support for NT_PPC_CVSX") Fixes: 19cbcbf7 ("powerpc/ptrace: Enable support for NT_PPC_CFPR") Signed-off-by:
Dave Martin <Dave.Martin@arm.com> Signed-off-by:
-
Dave Martin authored
commit 99dfe80a upstream. Ensure that if userspace supplies insufficient data to PTRACE_SETREGSET to fill all the registers, the thread's old registers are preserved. Fixes: c6e6771b ("powerpc: Introduce VSX thread_struct and CONFIG_VSX") Signed-off-by:
-
Madhavan Srinivasan authored
commit d89f473f upstream. Use 0x10012 event code for PM_BRU_CMPL event in power9 event list instead of current 0x40060. Fixes: 34922527 ('powerpc/perf: Add power9 event list macros for generic and cache events') Signed-off-by:
Madhavan Srinivasan <maddy@linux.vnet.ibm.com> Signed-off-by:
-
Benjamin Herrenschmidt authored
commit 9728a7c8 upstream. The icp-opal call is missing the code from icp-native to recover interrupts snatched by KVM. Without that, when running KVM, we can get into a situation where an interrupt is lost and the CPU stuck with an elevated CPPR. Also harden replay by always checking the return from opal_int_eoi(). Fixes: d7436188 ("powerpc/xics: Add ICP OPAL backend") Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
Marc Zyngier authored
commit 1193e6ae upstream. Dmitry Vyukov reported that the syzkaller fuzzer triggered a deadlock in the vgic setup code when an error was detected, as the cleanup code tries to take a lock that is already held by the setup code. The fix is to avoid retaking the lock when cleaning up, by telling the cleanup function that we already hold it. Reported-by:
Dmitry Vyukov <dvyukov@google.com> Reviewed-by:
Christoffer Dall <christoffer.dall@linaro.org> Reviewed-by:
Eric Auger <eric.auger@redhat.com> Signed-off-by:
Marc Zyngier <marc.zyngier@arm.com> Signed-off-by:
-
Christian Borntraeger authored
commit 04478197 upstream. kvm_s390_get_machine() populates the facility bitmap by copying bytes from the host results that are stored in a 256 byte array in the prefix page. The KVM code does use the size of the target buffer (2k), thus copying and exposing unrelated kernel memory (mostly machine check related logout data). Let's use the size of the source buffer instead. This is ok, as the target buffer will always be greater or equal than the source buffer as the KVM internal buffers (and thus S390_ARCH_FAC_LIST_SIZE_BYTE) cover the maximum possible size that is allowed by STFLE, which is 256 doublewords. All structures are zero allocated so we can leave bytes 256-2047 unchanged. Add a similar fix for kvm_arch_init_vm(). Reported-by:
Heiko Carstens <heiko.carstens@de.ibm.com> [found with smatch] Signed-off-by:
Christian Borntraeger <borntraeger@de.ibm.com> Acked-by:
Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by:
-
Hauke Mehrtens authored
commit a2724663 upstream. Remove the usage of modules functions to make this driver compile again. Otherwise an include of linux/modules.h would be needed. Fixes: 02436675 ("mtd: nand: xway: convert to normal platform driver") Signed-off-by:
Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by:
Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by:
-
Hauke Mehrtens authored
commit 73529c87 upstream. The xway_nand driver accesses the ltq_ebu_membase symbol which is not exported. This also should not get exported and we should handle the EBU interface in a better way later. This quick fix just deactivated support for building as module. Fixes: 99f2b107 ("mtd: lantiq: Add NAND support on Lantiq XWAY SoC.") Signed-off-by:
-
Vladimir Zapolskiy authored
commit cf9e1672 upstream. Semantics of NR_IRQS is different on machines with SPARSE_IRQ option disabled or enabled, in the latter case IRQs are allocated starting at least from the value specified by NR_IRQS and going upwards, so the check of (irq >= NR_IRQ) to decide about an error code returned by platform_get_irq() is completely invalid, don't attempt to overrule irq subsystem in the driver. The change fixes LPC32xx NAND MLC driver initialization on boot. Fixes: 8cb17b5e ("irqchip: Add LPC32xx interrupt controller driver") Signed-off-by:
Vladimir Zapolskiy <vz@mleia.com> Acked-by:
Sylvain Lemieux <slemieux.tyco@gmail.com> Signed-off-by:
-
Stefan Schmidt authored
commit 05a974ef upstream. From 4.9 we should really avoid using the stack here as this will not be DMA able on various platforms. This changes the buffers already being present in time of 4.9 being released. This should go into stable as well. Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Stefan Schmidt <stefan@osg.samsung.com> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
-
Stefan Wahren authored
commit 01167c7b upstream. According to the code the intention is to append 8 SCK cycles instead of 4 at end of a MMC_STOP_TRANSMISSION command. But this will never happened because it's an AC command not an ADTC command. So fix this by moving the statement into the right function. Signed-off-by:
Stefan Wahren <stefan.wahren@i2se.com> Fixes: e4243f13 (mmc: mxs-mmc: add mmc host driver for i.MX23/28) Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
-
Hans de Goede authored
commit e1d070c3 upstream. Commit e5bbf307 ("mmc: sdhci-acpi: Ensure connected devices are powered when probing") introduced code to powerup any acpi child nodes listed in the dstd. But some dstd-s list all possible devices used on some board variants, while reporting if the device is actually present and enabled in the status field of the device. So we end up calling the acpi _PS0 (power-on) method for devices which are not actually present. This does not always end well, e.g. on my cube iwork8 air tablet, this results in freezing the entire tablet as soon as the r8723bs module is loaded. This commit fixes this by checking the child device's status.present and status.enabled bits and only call acpi_device_fix_up_power() if both are set. Fixes: e5bbf307 ("mmc: sdhci-acpi: Ensure connected devices are powered when probing") BugLink: https://github.com/hadess/rtl8723bs/issues/80Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Acked-by:
Adrian Hunter <adrian.hunter@intel.com> Signed-off-by:
-
Johan Hovold authored
commit 7a546af5 upstream. Make sure to check for short control transfers in order to avoid parsing uninitialised buffer data and leaking it to user space. Note that the backlight and macro-mode buffer constraints are kept as loose as possible in order to avoid any regressions should the current buffer sizes be larger than necessary. Fixes: 6f78193e ("HID: corsair: Add Corsair Vengeance K90 driver") Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
Johan Hovold authored
commit 6d104af3 upstream. Not all platforms support DMA to the stack, and specifically since v4.9 this is no longer supported on x86 with VMAP_STACK either. Note that the macro-mode buffer was larger than necessary. Fixes: 6f78193e ("HID: corsair: Add Corsair Vengeance K90 driver") Signed-off-by:
-
Bjorn Helgaas authored
commit 51ebfc92 upstream. A PCI-to-PCIe bridge (a "reverse bridge") has a PCI or PCI-X primary interface and a PCI Express secondary interface. The PCIe interface is a Downstream Port that originates a Link. See the "PCI Express to PCI/PCI-X Bridge Specification", rev 1.0, sections 1.2 and A.6. The bug report below involves a PCI-to-PCIe bridge and a PCIe switch below the bridge: 00:1e.0 Intel 82801 PCI Bridge to [bus 01-0a] 01:00.0 Pericom PI7C9X111SL PCIe-to-PCI Reversible Bridge to [bus 02-0a] 02:00.0 Pericom Device 8608 [PCIe Upstream Port] to [bus 03-0a] 03:01.0 Pericom Device 8608 [PCIe Downstream Port] to [bus 0a] 01:00.0 is configured as a PCI-to-PCIe bridge (despite the name printed by lspci). As we traverse a PCIe hierarchy, device connections alternate between PCIe Links and internal Switch logic. Previously we did not recognize that 01:00.0 had a secondary link, so we thought the 02:00.0 Upstream Port *did* have a secondary link. In fact, it's the other way around: 01:00.0 has a secondary link, and 02:00.0 has internal Switch logic on its secondary side. When we thought 02:00.0 had a secondary link, the pci_scan_slot() -> only_one_child() path assumed 02:00.0 could have only one child, so 03:00.0 was the only possible downstream device. But 03:00.0 doesn't exist, so we didn't look for any other devices on bus 03. Booting with "pci=pcie_scan_all" is a workaround, but we don't want users to have to do that. Recognize that PCI-to-PCIe bridges originate links on their secondary interfaces. Link: https://bugzilla.kernel.org/show_bug.cgi?id=189361 Fixes: d0751b98 ("PCI: Add dev->has_secondary_link to track downstream PCIe links") Tested-by:
Blake Moore <blake.moore@men.de> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Signed-off-by:
-
Murali Karicheri authored
commit a782b5f9 upstream. Previously we checked for iATU unroll support by reading PCIE_ATU_VIEWPORT even on platforms, e.g., Keystone, that do not have ATU ports. This can cause bad behavior such as asynchronous external aborts: OF: PCI: MEM 0x60000000..0x6fffffff -> 0x60000000 Unhandled fault: asynchronous external abort (0x1211) at 0x00000000 pgd = c0003000 [00000000] *pgd=80000800004003, *pmd=00000000 Internal error: : 1211 [#1] PREEMPT SMP ARM Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.9.0-00009-g6ff59d2-dirty #7 Hardware name: Keystone task: eb878000 task.stack: eb866000 PC is at dw_pcie_setup_rc+0x24/0x380 LR is at ks_pcie_host_init+0x10/0x170 Move the dw_pcie_iatu_unroll_enabled() check so we only call it on platforms that do not use the ATU. These platforms supply their own ->rd_other_conf() and ->wr_other_conf() methods. [bhelgaas: changelog] Fixes: a0601a47 ("PCI: designware: Add iATU Unroll feature") Fixes: 416379f9 ("PCI: designware: Check for iATU unroll support after initializing host") Tested-by:
Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by:
Murali Karicheri <m-karicheri2@ti.com> Signed-off-by:
Joao Pinto <jpinto@synopsys.com> Signed-off-by:
-
David Sheets authored
commit 21067527 upstream. Commit bcb6f6d2 ("fuse: use timespec64") introduced clamped nsec values in time_to_jiffies but used the max of nsec and NSEC_PER_SEC - 1 instead of the min. Because of this, dentries would stay in the cache longer than requested and go stale in scenarios that relied on their timely eviction. Fixes: bcb6f6d2 ("fuse: use timespec64") Signed-off-by:
David Sheets <dsheets@docker.com> Signed-off-by:
Miklos Szeredi <mszeredi@redhat.com> Signed-off-by:
-
Tahsin Erdogan authored
commit a8a86d78 upstream. fuse_abort_conn() moves requests from pending list to a temporary list before canceling them. This operation races with request_wait_answer() which also tries to remove the request after it gets a fatal signal. It checks FR_PENDING flag to determine whether the request is still in the pending list. Make fuse_abort_conn() clear FR_PENDING flag so that request_wait_answer() does not remove the request from temporary list. This bug causes an Oops when trying to delete an already deleted list entry in end_requests(). Fixes: ee314a87 ("fuse: abort: no fc->lock needed for request ending") Signed-off-by:
Tahsin Erdogan <tahsin@google.com> Signed-off-by:
-
Vineet Gupta authored
commit eb1357d9 upstream. commit d65283f7 added mod->arch.secstr under CONFIG_ARC_DW2_UNWIND, but used it unconditionally which broke builds when the option was disabled. Fix that by adjusting the #ifdef guard. And while at it add a missing guard (for unwinder) in module.c as well Reported-by:
Waldemar Brodkorb <wbx@openadk.org> Fixes: d65283f7 ("ARC: module: elide loop to save reference to .eh_frame") Tested-by:
Anton Kolesov <akolesov@synopsys.com> Reviewed-by:
Alexey Brodkin <abrodkin@synopsys.com> [abrodkin: provided fixlet to Kconfig per failure in allnoconfig build] Signed-off-by:
Vineet Gupta <vgupta@synopsys.com> Signed-off-by:
-
Dan Williams authored
commit 1f19b983 upstream. Commit 98a29c39 ("libnvdimm, namespace: allow creation of multiple pmem-namespaces per region") added support for establishing additional pmem namespace beyond the seed device, similar to blk namespaces. However, it neglected to delete the namespace when the size is set to zero. Fixes: 98a29c39 ("libnvdimm, namespace: allow creation of multiple pmem-namespaces per region") Signed-off-by:
Dan Williams <dan.j.williams@intel.com> Signed-off-by:
-
J. Bruce Fields authored
commit 78794d18 upstream. Context expiry times are in units of seconds since boot, not unix time. The use of get_seconds() here therefore sets the expiry time decades in the future. This prevents timely freeing of contexts destroyed by client RPC_GSS_PROC_DESTROY requests. We'd still free them eventually (when the module is unloaded or the container shut down), but a lot of contexts could pile up before then. Fixes: c5b29f88 "sunrpc: use seconds since boot in expiry cache" Reported-by:
Andy Adamson <andros@netapp.com> Signed-off-by:
-
Scott Mayhew authored
commit 546125d1 upstream. The inet6addr_chain is an atomic notifier chain, so we can't call anything that might sleep (like lock_sock)... instead of closing the socket from svc_age_temp_xprts_now (which is called by the notifier function), just have the rpc service threads do it instead. Fixes: c3d4879e "sunrpc: Add a function to close..." Signed-off-by:
Scott Mayhew <smayhew@redhat.com> Signed-off-by:
-
Paul E. McKenney authored
commit 52d7e48b upstream. The current preemptible RCU implementation goes through three phases during bootup. In the first phase, there is only one CPU that is running with preemption disabled, so that a no-op is a synchronous grace period. In the second mid-boot phase, the scheduler is running, but RCU has not yet gotten its kthreads spawned (and, for expedited grace periods, workqueues are not yet running. During this time, any attempt to do a synchronous grace period will hang the system (or complain bitterly, depending). In the third and final phase, RCU is fully operational and everything works normally. This has been OK for some time, but there has recently been some synchronous grace periods showing up during the second mid-boot phase. This code worked "by accident" for awhile, but started failing as soon as expedited RCU grace periods switched over to workqueues in commit 8b355e3b ("rcu: Drive expedited grace periods from workqueue"). Note that the code was buggy even before this commit, as it was subject to failure on real-time systems that forced all expedited grace periods to run as normal grace periods (for example, using the rcu_normal ksysfs parameter). The callchain from the failure case is as follows: early_amd_iommu_init() |-> acpi_put_table(ivrs_base); |-> acpi_tb_put_table(table_desc); |-> acpi_tb_invalidate_table(table_desc); |-> acpi_tb_release_table(...) |-> acpi_os_unmap_memory |-> acpi_os_unmap_iomem |-> acpi_os_map_cleanup |-> synchronize_rcu_expedited The kernel showing this callchain was built with CONFIG_PREEMPT_RCU=y, which caused the code to try using workqueues before they were initialized, which did not go well. This commit therefore reworks RCU to permit synchronous grace periods to proceed during this mid-boot phase. This commit is therefore a fix to a regression introduced in v4.9, and is therefore being put forward post-merge-window in v4.10. This commit sets a flag from the existing rcu_scheduler_starting() function which causes all synchronous grace periods to take the expedited path. The expedited path now checks this flag, using the requesting task to drive the expedited grace period forward during the mid-boot phase. Finally, this flag is updated by a core_initcall() function named rcu_exp_runtime_mode(), which causes the runtime codepaths to be used. Note that this arrangement assumes that tasks are not sent POSIX signals (or anything similar) from the time that the first task is spawned through core_initcall() time. Fixes: 8b355e3b ("rcu: Drive expedited grace periods from workqueue") Reported-by:
"Zheng, Lv" <lv.zheng@intel.com> Reported-by:
Borislav Petkov <bp@alien8.de> Signed-off-by:
Paul E. McKenney <paulmck@linux.vnet.ibm.com> Tested-by:
Stan Kain <stan.kain@gmail.com> Tested-by:
Ivan <waffolz@hotmail.com> Tested-by:
Emanuel Castelo <emanuel.castelo@gmail.com> Tested-by:
Bruno Pesavento <bpesavento@infinito.it> Tested-by:
Borislav Petkov <bp@suse.de> Tested-by:
Frederic Bezies <fredbezies@gmail.com> Signed-off-by:
-
Paul E. McKenney authored
commit f466ae66 upstream. It is now legal to invoke synchronize_sched() at early boot, which causes Tiny RCU's synchronize_sched() to emit spurious splats. This commit therefore removes the cond_resched() from Tiny RCU's synchronize_sched(). Fixes: 8b355e3b ("rcu: Drive expedited grace periods from workqueue") Signed-off-by:
-
Bjorn Helgaas authored
commit 89e9f7bc upstream. Martin reported that the Supermicro X8DTH-i/6/iF/6F advertises incorrect host bridge windows via _CRS: pci_root PNP0A08:00: host bridge window [io 0xf000-0xffff] pci_root PNP0A08:01: host bridge window [io 0xf000-0xffff] Both bridges advertise the 0xf000-0xffff window, which cannot be correct. Work around this by ignoring _CRS on this system. The downside is that we may not assign resources correctly to hot-added PCI devices (if they are possible on this system). Link: https://bugzilla.kernel.org/show_bug.cgi?id=42606Reported-by:
Martin Burnicki <martin.burnicki@meinberg.de> Signed-off-by:
-
Gu Zheng authored
commit 497de07d upstream. This change was missed the tmpfs modification in In CVE-2016-7097 commit 07393101 ("posix_acl: Clear SGID bit when setting file permissions") It can test by xfstest generic/375, which failed to clear setgid bit in the following test case on tmpfs: touch $testfile chown 100:100 $testfile chmod 2755 $testfile _runas -u 100 -g 101 -- setfacl -m u::rwx,g::rwx,o::rwx $testfile Signed-off-by:
Gu Zheng <guzheng1@huawei.com> Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Cc: Brad Spengler <spender@grsecurity.net> Signed-off-by:
-
Adam Ford authored
commit 7245f67f upstream. Fixes: ("ab8dd3ae ARM: DTS: Add minimal Support for Logic PD DM3730 SOM-LV") This adds the dts file into the Makefile. This should have been included in the original patch. V2: Update patch description - same source code V1: Original patch Reviewed-by:
Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by:
Adam Ford <aford173@gmail.com> Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
Vladimir Zapolskiy authored
commit af92305e upstream. On i.MX31 AVIC interrupt controller base address is at 0x68000000. The problem was shadowed by the AVIC driver, which takes the correct base address from a SoC specific header file. Fixes: d2a37b3d ("ARM i.MX31: Add devicetree support") Signed-off-by:
Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com> Reviewed-by:
Fabio Estevam <fabio.estevam@nxp.com> Signed-off-by:
Shawn Guo <shawnguo@kernel.org> Signed-off-by:
-
Vladimir Zapolskiy authored
commit 1f87aee6 upstream. i.MX31 Clock Control Module controller is found on AIPS2 bus, move it there from SPBA bus to avoid a conflict of device IO space mismatch. Fixes: ef0e4a60 ("ARM: mx31: Replace clk_register_clkdev with clock DT lookup") Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
-
Vladimir Zapolskiy authored
commit 2e575cbc upstream. The type of AVIC interrupt controller found on i.MX31 is one-cell, namely 31 for CCM DVFS and 53 for CCM, however for clock control module its interrupts are specified as 3-cells, fix it. Fixes: ef0e4a60 ("ARM: mx31: Replace clk_register_clkdev with clock DT lookup") Acked-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
