+++ /dev/null
-From c10e7f56c98af101b7af458f19bb8a212cca0f2d Mon Sep 17 00:00:00 2001
-From: Yu Zhao <yuzhao@google.com>
-Date: Tue, 12 Feb 2019 15:35:58 -0800
-Subject: mm/gup: fix gup_pmd_range() for dax
-
-[ Upstream commit 414fd080d125408cb15d04ff4907e1dd8145c8c7 ]
-
-For dax pmd, pmd_trans_huge() returns false but pmd_huge() returns true
-on x86. So the function works as long as hugetlb is configured.
-However, dax doesn't depend on hugetlb.
-
-Link: http://lkml.kernel.org/r/20190111034033.601-1-yuzhao@google.com
-Signed-off-by: Yu Zhao <yuzhao@google.com>
-Reviewed-by: Jan Kara <jack@suse.cz>
-Cc: Dan Williams <dan.j.williams@intel.com>
-Cc: Huang Ying <ying.huang@intel.com>
-Cc: Matthew Wilcox <willy@infradead.org>
-Cc: Keith Busch <keith.busch@intel.com>
-Cc: "Michael S . Tsirkin" <mst@redhat.com>
-Cc: John Hubbard <jhubbard@nvidia.com>
-Cc: Wei Yang <richard.weiyang@gmail.com>
-Cc: Mike Rapoport <rppt@linux.ibm.com>
-Cc: Andrea Arcangeli <aarcange@redhat.com>
-Cc: "Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>
-Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
-Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-Signed-off-by: Sasha Levin <sashal@kernel.org>
----
- mm/gup.c | 3 ++-
- 1 file changed, 2 insertions(+), 1 deletion(-)
-
-diff --git a/mm/gup.c b/mm/gup.c
-index ce1630bf0b95..29a36fae8624 100644
---- a/mm/gup.c
-+++ b/mm/gup.c
-@@ -885,7 +885,8 @@ static int gup_pmd_range(pud_t pud, unsigned long addr, unsigned long end,
- if (pmd_none(pmd) || pmd_trans_splitting(pmd))
- return 0;
-
-- if (unlikely(pmd_trans_huge(pmd) || pmd_huge(pmd))) {
-+ if (unlikely(pmd_trans_huge(pmd) || pmd_huge(pmd) ||
-+ pmd_devmap(pmd))) {
- /*
- * NUMA hinting faults need to be handled in the GUP
- * slowpath for accounting purposes and so that they
---
-2.19.1
-
+++ /dev/null
-From b5382511a65617df9f933b467a2fb4a17445a3b5 Mon Sep 17 00:00:00 2001
-From: Russell King <rmk+kernel@armlinux.org.uk>
-Date: Fri, 15 Feb 2019 13:55:47 +0000
-Subject: net: marvell: mvneta: fix DMA debug warning
-
-[ Upstream commit a8fef9ba58c9966ddb1fec916d8d8137c9d8bc89 ]
-
-Booting 4.20 on SolidRun Clearfog issues this warning with DMA API
-debug enabled:
-
-WARNING: CPU: 0 PID: 555 at kernel/dma/debug.c:1230 check_sync+0x514/0x5bc
-mvneta f1070000.ethernet: DMA-API: device driver tries to sync DMA memory it has not allocated [device address=0x000000002dd7dc00] [size=240 bytes]
-Modules linked in: ahci mv88e6xxx dsa_core xhci_plat_hcd xhci_hcd devlink armada_thermal marvell_cesa des_generic ehci_orion phy_armada38x_comphy mcp3021 spi_orion evbug sfp mdio_i2c ip_tables x_tables
-CPU: 0 PID: 555 Comm: bridge-network- Not tainted 4.20.0+ #291
-Hardware name: Marvell Armada 380/385 (Device Tree)
-[<c0019638>] (unwind_backtrace) from [<c0014888>] (show_stack+0x10/0x14)
-[<c0014888>] (show_stack) from [<c07f54e0>] (dump_stack+0x9c/0xd4)
-[<c07f54e0>] (dump_stack) from [<c00312bc>] (__warn+0xf8/0x124)
-[<c00312bc>] (__warn) from [<c00313b0>] (warn_slowpath_fmt+0x38/0x48)
-[<c00313b0>] (warn_slowpath_fmt) from [<c00b0370>] (check_sync+0x514/0x5bc)
-[<c00b0370>] (check_sync) from [<c00b04f8>] (debug_dma_sync_single_range_for_cpu+0x6c/0x74)
-[<c00b04f8>] (debug_dma_sync_single_range_for_cpu) from [<c051bd14>] (mvneta_poll+0x298/0xf58)
-[<c051bd14>] (mvneta_poll) from [<c0656194>] (net_rx_action+0x128/0x424)
-[<c0656194>] (net_rx_action) from [<c000a230>] (__do_softirq+0xf0/0x540)
-[<c000a230>] (__do_softirq) from [<c00386e0>] (irq_exit+0x124/0x144)
-[<c00386e0>] (irq_exit) from [<c009b5e0>] (__handle_domain_irq+0x58/0xb0)
-[<c009b5e0>] (__handle_domain_irq) from [<c03a63c4>] (gic_handle_irq+0x48/0x98)
-[<c03a63c4>] (gic_handle_irq) from [<c0009a10>] (__irq_svc+0x70/0x98)
-...
-
-This appears to be caused by mvneta_rx_hwbm() calling
-dma_sync_single_range_for_cpu() with the wrong struct device pointer,
-as the buffer manager device pointer is used to map and unmap the
-buffer. Fix this.
-
-Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
-Signed-off-by: David S. Miller <davem@davemloft.net>
-Signed-off-by: Sasha Levin <sashal@kernel.org>
----
- drivers/net/ethernet/marvell/mvneta.c | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
-index 6212177781d5..922c4afc767b 100644
---- a/drivers/net/ethernet/marvell/mvneta.c
-+++ b/drivers/net/ethernet/marvell/mvneta.c
-@@ -1482,7 +1482,7 @@ static int mvneta_rx(struct mvneta_port *pp, int rx_todo,
- if (unlikely(!skb))
- goto err_drop_frame;
-
-- dma_sync_single_range_for_cpu(dev->dev.parent,
-+ dma_sync_single_range_for_cpu(&pp->bm_priv->pdev->dev,
- rx_desc->buf_phys_addr,
- MVNETA_MH_SIZE + NET_SKB_PAD,
- rx_bytes,
---
-2.19.1
-
--- /dev/null
+From 1d1f898df6586c5ea9aeaf349f13089c6fa37903 Mon Sep 17 00:00:00 2001
+From: "Zhang, Jun" <jun.zhang@intel.com>
+Date: Tue, 18 Dec 2018 06:55:01 -0800
+Subject: rcu: Do RCU GP kthread self-wakeup from softirq and interrupt
+
+From: Zhang, Jun <jun.zhang@intel.com>
+
+commit 1d1f898df6586c5ea9aeaf349f13089c6fa37903 upstream.
+
+The rcu_gp_kthread_wake() function is invoked when it might be necessary
+to wake the RCU grace-period kthread. Because self-wakeups are normally
+a useless waste of CPU cycles, if rcu_gp_kthread_wake() is invoked from
+this kthread, it naturally refuses to do the wakeup.
+
+Unfortunately, natural though it might be, this heuristic fails when
+rcu_gp_kthread_wake() is invoked from an interrupt or softirq handler
+that interrupted the grace-period kthread just after the final check of
+the wait-event condition but just before the schedule() call. In this
+case, a wakeup is required, even though the call to rcu_gp_kthread_wake()
+is within the RCU grace-period kthread's context. Failing to provide
+this wakeup can result in grace periods failing to start, which in turn
+results in out-of-memory conditions.
+
+This race window is quite narrow, but it actually did happen during real
+testing. It would of course need to be fixed even if it was strictly
+theoretical in nature.
+
+This patch does not Cc stable because it does not apply cleanly to
+earlier kernel versions.
+
+Fixes: 48a7639ce80c ("rcu: Make callers awaken grace-period kthread")
+Reported-by: "He, Bo" <bo.he@intel.com>
+Co-developed-by: "Zhang, Jun" <jun.zhang@intel.com>
+Co-developed-by: "He, Bo" <bo.he@intel.com>
+Co-developed-by: "xiao, jin" <jin.xiao@intel.com>
+Co-developed-by: Bai, Jie A <jie.a.bai@intel.com>
+Signed-off: "Zhang, Jun" <jun.zhang@intel.com>
+Signed-off: "He, Bo" <bo.he@intel.com>
+Signed-off: "xiao, jin" <jin.xiao@intel.com>
+Signed-off: Bai, Jie A <jie.a.bai@intel.com>
+Signed-off-by: "Zhang, Jun" <jun.zhang@intel.com>
+[ paulmck: Switch from !in_softirq() to "!in_interrupt() &&
+ !in_serving_softirq() to avoid redundant wakeups and to also handle the
+ interrupt-handler scenario as well as the softirq-handler scenario that
+ actually occurred in testing. ]
+Signed-off-by: Paul E. McKenney <paulmck@linux.ibm.com>
+Link: https://lkml.kernel.org/r/CD6925E8781EFD4D8E11882D20FC406D52A11F61@SHSMSX104.ccr.corp.intel.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ kernel/rcu/tree.c | 20 ++++++++++++++------
+ 1 file changed, 14 insertions(+), 6 deletions(-)
+
+--- a/kernel/rcu/tree.c
++++ b/kernel/rcu/tree.c
+@@ -1399,15 +1399,23 @@ static int rcu_future_gp_cleanup(struct
+ }
+
+ /*
+- * Awaken the grace-period kthread for the specified flavor of RCU.
+- * Don't do a self-awaken, and don't bother awakening when there is
+- * nothing for the grace-period kthread to do (as in several CPUs
+- * raced to awaken, and we lost), and finally don't try to awaken
+- * a kthread that has not yet been created.
++ * Awaken the grace-period kthread. Don't do a self-awaken (unless in
++ * an interrupt or softirq handler), and don't bother awakening when there
++ * is nothing for the grace-period kthread to do (as in several CPUs raced
++ * to awaken, and we lost), and finally don't try to awaken a kthread that
++ * has not yet been created. If all those checks are passed, track some
++ * debug information and awaken.
++ *
++ * So why do the self-wakeup when in an interrupt or softirq handler
++ * in the grace-period kthread's context? Because the kthread might have
++ * been interrupted just as it was going to sleep, and just after the final
++ * pre-sleep check of the awaken condition. In this case, a wakeup really
++ * is required, and is therefore supplied.
+ */
+ static void rcu_gp_kthread_wake(struct rcu_state *rsp)
+ {
+- if (current == rsp->gp_kthread ||
++ if ((current == rsp->gp_kthread &&
++ !in_interrupt() && !in_serving_softirq()) ||
+ !ACCESS_ONCE(rsp->gp_flags) ||
+ !rsp->gp_kthread)
+ return;
crypto-ahash-fix-another-early-termination-in-hash-walk.patch
s390-dasd-fix-using-offset-into-zero-size-array-erro.patch
input-matrix_keypad-use-flush_delayed_work.patch
-mm-gup-fix-gup_pmd_range-for-dax.patch
i2c-cadence-fix-the-hold-bit-setting.patch
input-st-keyscan-fix-potential-zalloc-null-dereferen.patch
assoc_array-fix-shortcut-creation.patch
net-systemport-fix-reception-of-bpdus.patch
net-mv643xx_eth-disable-clk-on-error-path-in-mv643xx.patch
arm64-relax-gic-version-check-during-early-boot.patch
-net-marvell-mvneta-fix-dma-debug-warning.patch
tmpfs-fix-link-accounting-when-a-tmpfile-is-linked-i.patch
net-set-static-variable-an-initial-value-in-atl2_pro.patch
cifs-fix-read-after-write-for-files-with-read-caching.patch
nfsd-fix-memory-corruption-caused-by-readdir.patch
nfsd-fix-wrong-check-in-write_v4_end_grace.patch
md-fix-failed-allocation-of-md_register_thread.patch
+rcu-do-rcu-gp-kthread-self-wakeup-from-softirq-and-interrupt.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
