26 Jan, 2017
40 commits
-
commit 6df8c9d80a27cb587f61b4f06b57e248d8bc3f86 upstream.
sparse says:
fs/ceph/mds_client.c:291:23: warning: restricted __le32 degrades to integer
fs/ceph/mds_client.c:293:28: warning: restricted __le32 degrades to integer
fs/ceph/mds_client.c:294:28: warning: restricted __le32 degrades to integer
fs/ceph/mds_client.c:296:28: warning: restricted __le32 degrades to integerThe op value is __le32, so we need to convert it before comparing it.
Signed-off-by: Jeff Layton
Reviewed-by: Sage Weil
Signed-off-by: Ilya Dryomov
Signed-off-by: Greg Kroah-Hartman -
commit 387b978cb0d12cf3720ecb17e652e0a9991a08e2 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
Tested-by: Steven Royer
Signed-off-by: Bryant G. Ly
Signed-off-by: Bart Van Assche
Signed-off-by: Greg Kroah-Hartman -
commit a5b0e4062fb225155189e593699bbfcd0597f8b5 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: Steven Royer
Reviewed-by: Michael Cyr
Signed-off-by: Bryant G. Ly
Signed-off-by: Bart Van Assche
Signed-off-by: Greg Kroah-Hartman -
commit ddc37832a1349f474c4532de381498020ed71d31 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
Reported-by: Linus Walleij
Reviewed-by: Stephen Boyd
Acked-by: Will Deacon
Cc: Russell King
Signed-off-by: Russell King
Signed-off-by: Greg Kroah-Hartman -
commit ce1ca7d2d140a1f4aaffd297ac487f246963dd2f 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: 412a15c0fe53 ("svcrdma: Port to new memory registration API")
Signed-off-by: Sriharsha Basavapatna
Reviewed-by: Chuck Lever
Reviewed-by: Yuval Shaia
Signed-off-by: J. Bruce Fields
Signed-off-by: Greg Kroah-Hartman -
commit bc7c36eedb0c7004aa06c2afc3c5385adada8fa3 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/0x90Clear the pending interrupt in the cpu dying path.
Fixes: 56a94f13919c ("clocksource: exynos_mct: Avoid blocking calls in the cpu hotplug notifier")
Reported-by: Seung-Woo Kim
Signed-off-by: Joonyoung Shim
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.com
Signed-off-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman -
commit 1cb51a15b576ee325d527726afff40947218fd5e 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: 1e51764a3c2ac05a ("UBIFS: add new flash file system")
Reported-by: Rock Lee
Reviewed-by: David Gstir
Signed-off-by: Richard Weinberger
Signed-off-by: Greg Kroah-Hartman -
commit eeb0d56fab4cd7848cf2be6704fa48900dbc1381 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
Signed-off-by: Greg Kroah-Hartman -
commit fc1ffd6cb38a1c1af625b9833c41928039e733f5 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] [] qla2x00_mem_alloc+0xb09/0x10c0 [qla2xxx]
[1469877.806980] [] qla2x00_probe_one+0x86a/0x1b50 [qla2xxx]
[1469877.814013] [] ? __pm_runtime_resume+0x51/0xa0
[1469877.820265] [] ? _raw_spin_lock_irqsave+0x25/0x90
[1469877.826776] [] ? _raw_spin_unlock_irqrestore+0x6d/0x80
[1469877.833720] [] ? preempt_count_sub+0xb1/0x100
[1469877.839885] [] ? _raw_spin_unlock_irqrestore+0x4c/0x80
[1469877.846830] [] local_pci_probe+0x4c/0xb0
[1469877.852562] [] ? preempt_count_sub+0xb1/0x100
[1469877.858727] [] pci_call_probe+0x89/0xb0Signed-off-by: Quinn Tran
Signed-off-by: Himanshu Madhani
Reviewed-by: Christoph Hellwig
[ bvanassche: Fixed spelling in patch description ]
Signed-off-by: Bart Van Assche
Signed-off-by: Greg Kroah-Hartman -
commit 020eb3daaba2857b32c4cf4c82f503d6a00a67de upstream.
commit d32932d02e18 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: d32932d02e18 ("x86/irq: Convert IOAPIC to use hierarchical irqdomain interfaces")
Signed-off-by: Ruslan Ruslichenko
Cc: xe-linux-external@cisco.com
Link: http://lkml.kernel.org/r/1484662432-13580-1-git-send-email-rruslich@cisco.com
Signed-off-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman -
commit 178f358208ceb8b38e5cff3f815e0db4a6a70a07 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
Signed-off-by: Michael Ellerman
Signed-off-by: Greg Kroah-Hartman -
commit b34ca60148c53971d373643195cc5c4d5d20be78 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: 9d3918f7c0e5 ("powerpc/ptrace: Enable support for NT_PPC_CVSX")
Fixes: 19cbcbf75a0c ("powerpc/ptrace: Enable support for NT_PPC_CFPR")
Signed-off-by: Dave Martin
Signed-off-by: Michael Ellerman
Signed-off-by: Greg Kroah-Hartman -
commit 99dfe80a2a246c600440a815741fd2e74a8b4977 upstream.
Ensure that if userspace supplies insufficient data to PTRACE_SETREGSET
to fill all the registers, the thread's old registers are preserved.Fixes: c6e6771b87d4 ("powerpc: Introduce VSX thread_struct and CONFIG_VSX")
Signed-off-by: Dave Martin
Signed-off-by: Michael Ellerman
Signed-off-by: Greg Kroah-Hartman -
commit d89f473ff6f84872e761419f7233d6e00f99c340 upstream.
Use 0x10012 event code for PM_BRU_CMPL event in power9 event list
instead of current 0x40060.Fixes: 34922527a2bcb ('powerpc/perf: Add power9 event list macros for generic and cache events')
Signed-off-by: Madhavan Srinivasan
Signed-off-by: Michael Ellerman
Signed-off-by: Greg Kroah-Hartman -
commit 9728a7c8ab2f7a1c8d5c95278d2e4f4ac1285385 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: d74361881f0d ("powerpc/xics: Add ICP OPAL backend")
Signed-off-by: Benjamin Herrenschmidt
Signed-off-by: Michael Ellerman
Signed-off-by: Greg Kroah-Hartman -
commit 1193e6aeecb36c74c48c7cd0f641acbbed9ddeef 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
Reviewed-by: Christoffer Dall
Reviewed-by: Eric Auger
Signed-off-by: Marc Zyngier
Signed-off-by: Greg Kroah-Hartman -
commit 04478197416e3a302e9ebc917ba1aa884ef9bfab 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
[found with smatch]
Signed-off-by: Christian Borntraeger
Acked-by: Cornelia Huck
Signed-off-by: Greg Kroah-Hartman -
commit a2724663494f7313f53da10d8c0a729c5e3c4dea upstream.
Remove the usage of modules functions to make this driver compile
again. Otherwise an include of linux/modules.h would be needed.Fixes: 024366750c2e ("mtd: nand: xway: convert to normal platform driver")
Signed-off-by: Hauke Mehrtens
Signed-off-by: Boris Brezillon
Signed-off-by: Greg Kroah-Hartman -
commit 73529c872a189c747bdb528ce9b85b67b0e28dec 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: 99f2b107924c ("mtd: lantiq: Add NAND support on Lantiq XWAY SoC.")
Signed-off-by: Hauke Mehrtens
Signed-off-by: Boris Brezillon
Signed-off-by: Greg Kroah-Hartman -
commit cf9e1672a66c49ed8903c01b4c380a2f2dc91b40 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: 8cb17b5ed017 ("irqchip: Add LPC32xx interrupt controller driver")
Signed-off-by: Vladimir Zapolskiy
Acked-by: Sylvain Lemieux
Signed-off-by: Boris Brezillon
Signed-off-by: Greg Kroah-Hartman -
commit 05a974efa4bdf6e2a150e3f27dc6fcf0a9ad5655 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
Signed-off-by: Stefan Schmidt
Signed-off-by: Marcel Holtmann
Signed-off-by: Greg Kroah-Hartman -
commit 01167c7b9cbf099c69fe411a228e4e9c7104e123 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
Fixes: e4243f13d10e (mmc: mxs-mmc: add mmc host driver for i.MX23/28)
Signed-off-by: Ulf Hansson
Signed-off-by: Greg Kroah-Hartman -
commit e1d070c3793a2766122865a7c2142853b48808c5 upstream.
Commit e5bbf30733f9 ("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: e5bbf30733f9 ("mmc: sdhci-acpi: Ensure connected devices are powered when probing")
BugLink: https://github.com/hadess/rtl8723bs/issues/80
Signed-off-by: Hans de Goede
Acked-by: Adrian Hunter
Signed-off-by: Ulf Hansson
Signed-off-by: Greg Kroah-Hartman -
commit 7a546af50eb78ab99840903083231eb635c8a566 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: 6f78193ee9ea ("HID: corsair: Add Corsair Vengeance K90 driver")
Signed-off-by: Johan Hovold
Signed-off-by: Jiri Kosina
Signed-off-by: Greg Kroah-Hartman -
commit 6d104af38b570d37aa32a5803b04c354f8ed513d 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: 6f78193ee9ea ("HID: corsair: Add Corsair Vengeance K90 driver")
Signed-off-by: Johan Hovold
Signed-off-by: Jiri Kosina
Signed-off-by: Greg Kroah-Hartman -
commit 51ebfc92b72b4f7dac1ab45683bf56741e454b8c 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: d0751b98dfa3 ("PCI: Add dev->has_secondary_link to track downstream PCIe links")
Tested-by: Blake Moore
Signed-off-by: Bjorn Helgaas
Signed-off-by: Greg Kroah-Hartman -
commit a782b5f986c3fa1cfa7f2b57941200c6a5809242 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/0x170Move 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: a0601a470537 ("PCI: designware: Add iATU Unroll feature")
Fixes: 416379f9ebde ("PCI: designware: Check for iATU unroll support after initializing host")
Tested-by: Kishon Vijay Abraham I
Signed-off-by: Murali Karicheri
Signed-off-by: Bjorn Helgaas
Acked-By: Joao Pinto
Signed-off-by: Greg Kroah-Hartman -
commit 210675270caa33253e4c33f3c5e657e7d6060812 upstream.
Commit bcb6f6d2b9c2 ("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: bcb6f6d2b9c2 ("fuse: use timespec64")
Signed-off-by: David Sheets
Signed-off-by: Miklos Szeredi
Signed-off-by: Greg Kroah-Hartman -
commit a8a86d78d673b1c99fe9b0064739fde9e9774184 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: ee314a870e40 ("fuse: abort: no fc->lock needed for request ending")
Signed-off-by: Tahsin Erdogan
Signed-off-by: Miklos Szeredi
Signed-off-by: Greg Kroah-Hartman -
commit eb1357d942e5d96de6b4c20a8ffa55acf96233a2 upstream.
commit d65283f7b695b5 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
Fixes: d65283f7b695b5 ("ARC: module: elide loop to save reference to .eh_frame")
Tested-by: Anton Kolesov
Reviewed-by: Alexey Brodkin
[abrodkin: provided fixlet to Kconfig per failure in allnoconfig build]
Signed-off-by: Vineet Gupta
Signed-off-by: Greg Kroah-Hartman -
commit 1f19b983a8877f81763fab3e693c6befe212736d upstream.
Commit 98a29c39dc68 ("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: 98a29c39dc68 ("libnvdimm, namespace: allow creation of multiple pmem-namespaces per region")
Signed-off-by: Dan Williams
Signed-off-by: Greg Kroah-Hartman -
commit 78794d1890708cf94e3961261e52dcec2cc34722 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: c5b29f885afe "sunrpc: use seconds since boot in expiry cache"
Reported-by: Andy Adamson
Signed-off-by: J. Bruce Fields
Signed-off-by: Greg Kroah-Hartman -
commit 546125d1614264d26080817d0c8cddb9b25081fa 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: c3d4879e01be "sunrpc: Add a function to close..."
Signed-off-by: Scott Mayhew
Signed-off-by: J. Bruce Fields
Signed-off-by: Greg Kroah-Hartman -
commit 52d7e48b86fc108e45a656d8e53e4237993c481d 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
8b355e3bc140 ("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_expeditedThe 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: 8b355e3bc140 ("rcu: Drive expedited grace periods from workqueue")
Reported-by: "Zheng, Lv"
Reported-by: Borislav Petkov
Signed-off-by: Paul E. McKenney
Tested-by: Stan Kain
Tested-by: Ivan
Tested-by: Emanuel Castelo
Tested-by: Bruno Pesavento
Tested-by: Borislav Petkov
Tested-by: Frederic Bezies
Signed-off-by: Greg Kroah-Hartman -
commit f466ae66fa6a599f9a53b5f9bafea4b8cfffa7fb 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: 8b355e3bc140 ("rcu: Drive expedited grace periods from workqueue")
Signed-off-by: Paul E. McKenney
Signed-off-by: Greg Kroah-Hartman -
commit 89e9f7bcd8744ea25fcf0ac671b8d72c10d7d790 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=42606
Reported-by: Martin Burnicki
Signed-off-by: Bjorn Helgaas
Signed-off-by: Greg Kroah-Hartman -
commit 497de07d89c1410d76a15bec2bb41f24a2a89f31 upstream.
This change was missed the tmpfs modification in In CVE-2016-7097
commit 073931017b49 ("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 $testfileSigned-off-by: Gu Zheng
Signed-off-by: Al Viro
Cc: Brad Spengler
Signed-off-by: Greg Kroah-Hartman -
commit 7245f67f86e847769f41dacad26bb8f5b5d74bf4 upstream.
Fixes: ("ab8dd3aed011 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 patchReviewed-by: Javier Martinez Canillas
Signed-off-by: Adam Ford
Signed-off-by: Tony Lindgren
Signed-off-by: Greg Kroah-Hartman -
commit af92305e567b7f4c9cf48b9e46c1f48ec9ffb1fb 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: d2a37b3d91f4 ("ARM i.MX31: Add devicetree support")
Signed-off-by: Vladimir Zapolskiy
Reviewed-by: Fabio Estevam
Signed-off-by: Shawn Guo
Signed-off-by: Greg Kroah-Hartman -
commit 1f87aee6a2e55eda466a43ba6248a8b75eede153 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: ef0e4a606fb6 ("ARM: mx31: Replace clk_register_clkdev with clock DT lookup")
Signed-off-by: Vladimir Zapolskiy
Acked-by: Uwe Kleine-König
Signed-off-by: Shawn Guo
Signed-off-by: Greg Kroah-Hartman
