+++ /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;
--- /dev/null
+From 29b00e609960ae0fcff382f4c7079dd0874a5311 Mon Sep 17 00:00:00 2001
+From: "Darrick J. Wong" <darrick.wong@oracle.com>
+Date: Fri, 22 Feb 2019 22:35:32 -0800
+Subject: tmpfs: fix uninitialized return value in shmem_link
+
+From: Darrick J. Wong <darrick.wong@oracle.com>
+
+commit 29b00e609960ae0fcff382f4c7079dd0874a5311 upstream.
+
+When we made the shmem_reserve_inode call in shmem_link conditional, we
+forgot to update the declaration for ret so that it always has a known
+value. Dan Carpenter pointed out this deficiency in the original patch.
+
+Fixes: 1062af920c07 ("tmpfs: fix link accounting when a tmpfile is linked in")
+Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
+Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
+Signed-off-by: Hugh Dickins <hughd@google.com>
+Cc: Matej Kupljen <matej.kupljen@gmail.com>
+Cc: Al Viro <viro@zeniv.linux.org.uk>
+Cc: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ mm/shmem.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/mm/shmem.c
++++ b/mm/shmem.c
+@@ -2280,7 +2280,7 @@ static int shmem_create(struct inode *di
+ static int shmem_link(struct dentry *old_dentry, struct inode *dir, struct dentry *dentry)
+ {
+ struct inode *inode = old_dentry->d_inode;
+- int ret;
++ int ret = 0;
+
+ /*
+ * No ordinary (disk based) filesystem counts links as inodes;
projects / thirdparty / kernel / stable-queue.git / commitdiff
