--- /dev/null
+From 28b89b9e6f7b6c8fef7b3af39828722bca20cfee Mon Sep 17 00:00:00 2001
+From: Joonwoo Park <joonwoop@codeaurora.org>
+Date: Sun, 11 Sep 2016 21:14:58 -0700
+Subject: cpuset: handle race between CPU hotplug and cpuset_hotplug_work
+
+From: Joonwoo Park <joonwoop@codeaurora.org>
+
+commit 28b89b9e6f7b6c8fef7b3af39828722bca20cfee upstream.
+
+A discrepancy between cpu_online_mask and cpuset's effective_cpus
+mask is inevitable during hotplug since cpuset defers updating of
+effective_cpus mask using a workqueue, during which time nothing
+prevents the system from more hotplug operations. For that reason
+guarantee_online_cpus() walks up the cpuset hierarchy until it finds
+an intersection under the assumption that top cpuset's effective_cpus
+mask intersects with cpu_online_mask even with such a race occurring.
+
+However a sequence of CPU hotplugs can open a time window, during which
+none of the effective CPUs in the top cpuset intersect with
+cpu_online_mask.
+
+For example when there are 4 possible CPUs 0-3 and only CPU0 is online:
+
+ ======================== ===========================
+ cpu_online_mask top_cpuset.effective_cpus
+ ======================== ===========================
+ echo 1 > cpu2/online.
+ CPU hotplug notifier woke up hotplug work but not yet scheduled.
+ [0,2] [0]
+
+ echo 0 > cpu0/online.
+ The workqueue is still runnable.
+ [2] [0]
+ ======================== ===========================
+
+ Now there is no intersection between cpu_online_mask and
+ top_cpuset.effective_cpus. Thus invoking sys_sched_setaffinity() at
+ this moment can cause following:
+
+ Unable to handle kernel NULL pointer dereference at virtual address 000000d0
+ ------------[ cut here ]------------
+ Kernel BUG at ffffffc0001389b0 [verbose debug info unavailable]
+ Internal error: Oops - BUG: 96000005 [#1] PREEMPT SMP
+ Modules linked in:
+ CPU: 2 PID: 1420 Comm: taskset Tainted: G W 4.4.8+ #98
+ task: ffffffc06a5c4880 ti: ffffffc06e124000 task.ti: ffffffc06e124000
+ PC is at guarantee_online_cpus+0x2c/0x58
+ LR is at cpuset_cpus_allowed+0x4c/0x6c
+ <snip>
+ Process taskset (pid: 1420, stack limit = 0xffffffc06e124020)
+ Call trace:
+ [<ffffffc0001389b0>] guarantee_online_cpus+0x2c/0x58
+ [<ffffffc00013b208>] cpuset_cpus_allowed+0x4c/0x6c
+ [<ffffffc0000d61f0>] sched_setaffinity+0xc0/0x1ac
+ [<ffffffc0000d6374>] SyS_sched_setaffinity+0x98/0xac
+ [<ffffffc000085cb0>] el0_svc_naked+0x24/0x28
+
+The top cpuset's effective_cpus are guaranteed to be identical to
+cpu_online_mask eventually. Hence fall back to cpu_online_mask when
+there is no intersection between top cpuset's effective_cpus and
+cpu_online_mask.
+
+Signed-off-by: Joonwoo Park <joonwoop@codeaurora.org>
+Acked-by: Li Zefan <lizefan@huawei.com>
+Cc: Tejun Heo <tj@kernel.org>
+Cc: cgroups@vger.kernel.org
+Cc: linux-kernel@vger.kernel.org
+Signed-off-by: Tejun Heo <tj@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ kernel/cpuset.c | 17 ++++++++++++++---
+ 1 file changed, 14 insertions(+), 3 deletions(-)
+
+--- a/kernel/cpuset.c
++++ b/kernel/cpuset.c
+@@ -324,8 +324,7 @@ static struct file_system_type cpuset_fs
+ /*
+ * Return in pmask the portion of a cpusets's cpus_allowed that
+ * are online. If none are online, walk up the cpuset hierarchy
+- * until we find one that does have some online cpus. The top
+- * cpuset always has some cpus online.
++ * until we find one that does have some online cpus.
+ *
+ * One way or another, we guarantee to return some non-empty subset
+ * of cpu_online_mask.
+@@ -334,8 +333,20 @@ static struct file_system_type cpuset_fs
+ */
+ static void guarantee_online_cpus(struct cpuset *cs, struct cpumask *pmask)
+ {
+- while (!cpumask_intersects(cs->effective_cpus, cpu_online_mask))
++ while (!cpumask_intersects(cs->effective_cpus, cpu_online_mask)) {
+ cs = parent_cs(cs);
++ if (unlikely(!cs)) {
++ /*
++ * The top cpuset doesn't have any online cpu as a
++ * consequence of a race between cpuset_hotplug_work
++ * and cpu hotplug notifier. But we know the top
++ * cpuset's effective_cpus is on its way to to be
++ * identical to cpu_online_mask.
++ */
++ cpumask_copy(pmask, cpu_online_mask);
++ return;
++ }
++ }
+ cpumask_and(pmask, cs->effective_cpus, cpu_online_mask);
+ }
+
--- /dev/null
+From 5b398e416e880159fe55eefd93c6588fa072cd66 Mon Sep 17 00:00:00 2001
+From: zhong jiang <zhongjiang@huawei.com>
+Date: Wed, 28 Sep 2016 15:22:30 -0700
+Subject: mm,ksm: fix endless looping in allocating memory when ksm enable
+
+From: zhong jiang <zhongjiang@huawei.com>
+
+commit 5b398e416e880159fe55eefd93c6588fa072cd66 upstream.
+
+I hit the following hung task when runing a OOM LTP test case with 4.1
+kernel.
+
+Call trace:
+[<ffffffc000086a88>] __switch_to+0x74/0x8c
+[<ffffffc000a1bae0>] __schedule+0x23c/0x7bc
+[<ffffffc000a1c09c>] schedule+0x3c/0x94
+[<ffffffc000a1eb84>] rwsem_down_write_failed+0x214/0x350
+[<ffffffc000a1e32c>] down_write+0x64/0x80
+[<ffffffc00021f794>] __ksm_exit+0x90/0x19c
+[<ffffffc0000be650>] mmput+0x118/0x11c
+[<ffffffc0000c3ec4>] do_exit+0x2dc/0xa74
+[<ffffffc0000c46f8>] do_group_exit+0x4c/0xe4
+[<ffffffc0000d0f34>] get_signal+0x444/0x5e0
+[<ffffffc000089fcc>] do_signal+0x1d8/0x450
+[<ffffffc00008a35c>] do_notify_resume+0x70/0x78
+
+The oom victim cannot terminate because it needs to take mmap_sem for
+write while the lock is held by ksmd for read which loops in the page
+allocator
+
+ksm_do_scan
+ scan_get_next_rmap_item
+ down_read
+ get_next_rmap_item
+ alloc_rmap_item #ksmd will loop permanently.
+
+There is no way forward because the oom victim cannot release any memory
+in 4.1 based kernel. Since 4.6 we have the oom reaper which would solve
+this problem because it would release the memory asynchronously.
+Nevertheless we can relax alloc_rmap_item requirements and use
+__GFP_NORETRY because the allocation failure is acceptable as ksm_do_scan
+would just retry later after the lock got dropped.
+
+Such a patch would be also easy to backport to older stable kernels which
+do not have oom_reaper.
+
+While we are at it add GFP_NOWARN so the admin doesn't have to be alarmed
+by the allocation failure.
+
+Link: http://lkml.kernel.org/r/1474165570-44398-1-git-send-email-zhongjiang@huawei.com
+Signed-off-by: zhong jiang <zhongjiang@huawei.com>
+Suggested-by: Hugh Dickins <hughd@google.com>
+Suggested-by: Michal Hocko <mhocko@suse.cz>
+Acked-by: Michal Hocko <mhocko@suse.com>
+Acked-by: Hugh Dickins <hughd@google.com>
+Signed-off-by: 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/ksm.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/mm/ksm.c
++++ b/mm/ksm.c
+@@ -283,7 +283,8 @@ static inline struct rmap_item *alloc_rm
+ {
+ struct rmap_item *rmap_item;
+
+- rmap_item = kmem_cache_zalloc(rmap_item_cache, GFP_KERNEL);
++ rmap_item = kmem_cache_zalloc(rmap_item_cache, GFP_KERNEL |
++ __GFP_NORETRY | __GFP_NOWARN);
+ if (rmap_item)
+ ksm_rmap_items++;
+ return rmap_item;
--- /dev/null
+From f6d7c1b5598b6407c3f1da795dd54acf99c1990c Mon Sep 17 00:00:00 2001
+From: Karl Beldan <kbeldan@baylibre.com>
+Date: Mon, 29 Aug 2016 07:45:49 +0000
+Subject: mtd: nand: davinci: Reinitialize the HW ECC engine in 4bit hwctl
+
+From: Karl Beldan <kbeldan@baylibre.com>
+
+commit f6d7c1b5598b6407c3f1da795dd54acf99c1990c upstream.
+
+This fixes subpage writes when using 4-bit HW ECC.
+
+There has been numerous reports about ECC errors with devices using this
+driver for a while. Also the 4-bit ECC has been reported as broken with
+subpages in [1] and with 16 bits NANDs in the driver and in mach* board
+files both in mainline and in the vendor BSPs.
+
+What I saw with 4-bit ECC on a 16bits NAND (on an LCDK) which got me to
+try reinitializing the ECC engine:
+- R/W on whole pages properly generates/checks RS code
+- try writing the 1st subpage only of a blank page, the subpage is well
+ written and the RS code properly generated, re-reading the same page
+ the HW detects some ECC error, reading the same page again no ECC
+ error is detected
+
+Note that the ECC engine is already reinitialized in the 1-bit case.
+
+Tested on my LCDK with UBI+UBIFS using subpages.
+This could potentially get rid of the issue workarounded in [1].
+
+[1] 28c015a9daab ("mtd: davinci-nand: disable subpage write for keystone-nand")
+
+Fixes: 6a4123e581b3 ("mtd: nand: davinci_nand, 4-bit ECC for smallpage")
+Signed-off-by: Karl Beldan <kbeldan@baylibre.com>
+Acked-by: Boris Brezillon <boris.brezillon@free-electrons.com>
+Signed-off-by: Brian Norris <computersforpeace@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/mtd/nand/davinci_nand.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/mtd/nand/davinci_nand.c
++++ b/drivers/mtd/nand/davinci_nand.c
+@@ -241,6 +241,9 @@ static void nand_davinci_hwctl_4bit(stru
+ unsigned long flags;
+ u32 val;
+
++ /* Reset ECC hardware */
++ davinci_nand_readl(info, NAND_4BIT_ECC1_OFFSET);
++
+ spin_lock_irqsave(&davinci_nand_lock, flags);
+
+ /* Start 4-bit ECC calculation for read/write */
--- /dev/null
+cpuset-handle-race-between-cpu-hotplug-and-cpuset_hotplug_work.patch
+mtd-nand-davinci-reinitialize-the-hw-ecc-engine-in-4bit-hwctl.patch
+mm-ksm-fix-endless-looping-in-allocating-memory-when-ksm-enable.patch
--- /dev/null
+cpuset-handle-race-between-cpu-hotplug-and-cpuset_hotplug_work.patch
+cgroup-fix-invalid-controller-enable-rejections-with-cgroup-namespace.patch
+scripts-recordmcount.c-account-for-.softirqentry.text.patch
+mtd-nand-davinci-reinitialize-the-hw-ecc-engine-in-4bit-hwctl.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
