From 12ce61eda8df93d914e1d20d4bfff92280e96455 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Wed, 7 Mar 2012 09:54:46 -0800 Subject: [PATCH] 3.2-stable patches added patches: mm-memcg-correct-unregistring-of-events-attached-to-the-same-eventfd.patch nommu-don-t-need-to-clear-vm_mm-when-deleting-a-vma.patch --- ...-touch-cpusets-during-suspend-resume.patch | 58 --------------- ...-events-attached-to-the-same-eventfd.patch | 71 +++++++++++++++++++ ...d-to-clear-vm_mm-when-deleting-a-vma.patch | 33 +++++++++ queue-3.2/series | 3 +- 4 files changed, 106 insertions(+), 59 deletions(-) delete mode 100644 queue-3.2/cpu-hotplug-cpusets-suspend-don-t-touch-cpusets-during-suspend-resume.patch create mode 100644 queue-3.2/mm-memcg-correct-unregistring-of-events-attached-to-the-same-eventfd.patch create mode 100644 queue-3.2/nommu-don-t-need-to-clear-vm_mm-when-deleting-a-vma.patch diff --git a/queue-3.2/cpu-hotplug-cpusets-suspend-don-t-touch-cpusets-during-suspend-resume.patch b/queue-3.2/cpu-hotplug-cpusets-suspend-don-t-touch-cpusets-during-suspend-resume.patch deleted file mode 100644 index 9d07d330f35..00000000000 --- a/queue-3.2/cpu-hotplug-cpusets-suspend-don-t-touch-cpusets-during-suspend-resume.patch +++ /dev/null @@ -1,58 +0,0 @@ -From 8f2f748b0656257153bcf0941df8d6060acc5ca6 Mon Sep 17 00:00:00 2001 -From: "Srivatsa S. Bhat" -Date: Thu, 23 Feb 2012 15:27:15 +0530 -Subject: CPU hotplug, cpusets, suspend: Don't touch cpusets during suspend/resume - -From: "Srivatsa S. Bhat" - -commit 8f2f748b0656257153bcf0941df8d6060acc5ca6 upstream. - -Currently, during CPU hotplug, the cpuset callbacks modify the cpusets -to reflect the state of the system, and this handling is asymmetric. -That is, upon CPU offline, that CPU is removed from all cpusets. However -when it comes back online, it is put back only to the root cpuset. - -This gives rise to a significant problem during suspend/resume. During -suspend, we offline all non-boot cpus and during resume we online them back. -Which means, after a resume, all cpusets (except the root cpuset) will be -restricted to just one single CPU (the boot cpu). But the whole point of -suspend/resume is to restore the system to a state which is as close as -possible to how it was before suspend. - -So to fix this, don't touch cpusets during suspend/resume. That is, modify -the cpuset-related CPU hotplug callback to just ignore CPU hotplug when it -is initiated as part of the suspend/resume sequence. - -Reported-by: Prashanth Nageshappa -Signed-off-by: Srivatsa S. Bhat -Cc: Linus Torvalds -Cc: Andrew Morton -Link: http://lkml.kernel.org/r/4F460D7B.1020703@linux.vnet.ibm.com -Signed-off-by: Peter Zijlstra -Signed-off-by: Ingo Molnar -Signed-off-by: Greg Kroah-Hartman - ---- - kernel/sched.c | 4 ++-- - 1 file changed, 2 insertions(+), 2 deletions(-) - ---- a/kernel/sched.c -+++ b/kernel/sched.c -@@ -8001,7 +8001,7 @@ int __init sched_create_sysfs_power_savi - static int cpuset_cpu_active(struct notifier_block *nfb, unsigned long action, - void *hcpu) - { -- switch (action & ~CPU_TASKS_FROZEN) { -+ switch (action) { - case CPU_ONLINE: - case CPU_DOWN_FAILED: - cpuset_update_active_cpus(); -@@ -8014,7 +8014,7 @@ static int cpuset_cpu_active(struct noti - static int cpuset_cpu_inactive(struct notifier_block *nfb, unsigned long action, - void *hcpu) - { -- switch (action & ~CPU_TASKS_FROZEN) { -+ switch (action) { - case CPU_DOWN_PREPARE: - cpuset_update_active_cpus(); - return NOTIFY_OK; diff --git a/queue-3.2/mm-memcg-correct-unregistring-of-events-attached-to-the-same-eventfd.patch b/queue-3.2/mm-memcg-correct-unregistring-of-events-attached-to-the-same-eventfd.patch new file mode 100644 index 00000000000..c59038e8764 --- /dev/null +++ b/queue-3.2/mm-memcg-correct-unregistring-of-events-attached-to-the-same-eventfd.patch @@ -0,0 +1,71 @@ +From 371528caec553785c37f73fa3926ea0de84f986f Mon Sep 17 00:00:00 2001 +From: Anton Vorontsov +Date: Fri, 24 Feb 2012 05:14:46 +0400 +Subject: mm: memcg: Correct unregistring of events attached to the same eventfd + +From: Anton Vorontsov + +commit 371528caec553785c37f73fa3926ea0de84f986f upstream. + +There is an issue when memcg unregisters events that were attached to +the same eventfd: + +- On the first call mem_cgroup_usage_unregister_event() removes all + events attached to a given eventfd, and if there were no events left, + thresholds->primary would become NULL; + +- Since there were several events registered, cgroups core will call + mem_cgroup_usage_unregister_event() again, but now kernel will oops, + as the function doesn't expect that threshold->primary may be NULL. + +That's a good question whether mem_cgroup_usage_unregister_event() +should actually remove all events in one go, but nowadays it can't +do any better as cftype->unregister_event callback doesn't pass +any private event-associated cookie. So, let's fix the issue by +simply checking for threshold->primary. + +FWIW, w/o the patch the following oops may be observed: + + BUG: unable to handle kernel NULL pointer dereference at 0000000000000004 + IP: [] mem_cgroup_usage_unregister_event+0x9c/0x1f0 + Pid: 574, comm: kworker/0:2 Not tainted 3.3.0-rc4+ #9 Bochs Bochs + RIP: 0010:[] [] mem_cgroup_usage_unregister_event+0x9c/0x1f0 + RSP: 0018:ffff88001d0b9d60 EFLAGS: 00010246 + Process kworker/0:2 (pid: 574, threadinfo ffff88001d0b8000, task ffff88001de91cc0) + Call Trace: + [] cgroup_event_remove+0x2b/0x60 + [] process_one_work+0x174/0x450 + [] worker_thread+0x123/0x2d0 + +Signed-off-by: Anton Vorontsov +Acked-by: KAMEZAWA Hiroyuki +Cc: Kirill A. Shutemov +Cc: Michal Hocko +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + mm/memcontrol.c | 5 ++++- + 1 file changed, 4 insertions(+), 1 deletion(-) + +--- a/mm/memcontrol.c ++++ b/mm/memcontrol.c +@@ -4502,6 +4502,9 @@ static void mem_cgroup_usage_unregister_ + */ + BUG_ON(!thresholds); + ++ if (!thresholds->primary) ++ goto unlock; ++ + usage = mem_cgroup_usage(memcg, type == _MEMSWAP); + + /* Check if a threshold crossed before removing */ +@@ -4550,7 +4553,7 @@ swap_buffers: + + /* To be sure that nobody uses thresholds */ + synchronize_rcu(); +- ++unlock: + mutex_unlock(&memcg->thresholds_lock); + } + diff --git a/queue-3.2/nommu-don-t-need-to-clear-vm_mm-when-deleting-a-vma.patch b/queue-3.2/nommu-don-t-need-to-clear-vm_mm-when-deleting-a-vma.patch new file mode 100644 index 00000000000..ba978e06543 --- /dev/null +++ b/queue-3.2/nommu-don-t-need-to-clear-vm_mm-when-deleting-a-vma.patch @@ -0,0 +1,33 @@ +From b94cfaf6685d691dc3fab023cf32f65e9b7be09c Mon Sep 17 00:00:00 2001 +From: David Howells +Date: Thu, 23 Feb 2012 13:51:00 +0000 +Subject: NOMMU: Don't need to clear vm_mm when deleting a VMA + +From: David Howells + +commit b94cfaf6685d691dc3fab023cf32f65e9b7be09c upstream. + +Don't clear vm_mm in a deleted VMA as it's unnecessary and might +conceivably break the filesystem or driver VMA close routine. + +Reported-by: Al Viro +Signed-off-by: David Howells +Acked-by: Al Viro +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + mm/nommu.c | 2 -- + 1 file changed, 2 deletions(-) + +--- a/mm/nommu.c ++++ b/mm/nommu.c +@@ -779,8 +779,6 @@ static void delete_vma_from_mm(struct vm + + if (vma->vm_next) + vma->vm_next->vm_prev = vma->vm_prev; +- +- vma->vm_mm = NULL; + } + + /* diff --git a/queue-3.2/series b/queue-3.2/series index 369e4c2a50c..f979928dce0 100644 --- a/queue-3.2/series +++ b/queue-3.2/series @@ -23,8 +23,9 @@ mfd-test-for-jack-detection-when-deciding-if-wm8994-should-suspend.patch genirq-clear-action-thread_mask-if-irq_oneshot-is-not-set.patch arm-s3c24xx-dma-resume-regression-fix.patch move-logitech-harmony-900-from-cdc_ether-to-zaurus.patch -cpu-hotplug-cpusets-suspend-don-t-touch-cpusets-during-suspend-resume.patch alpha-fix-32-64-bit-bug-in-futex-support.patch mmc-atmel-mci-don-t-use-dma-features-when-using-dma-with-no-chan-available.patch mmc-sdhci-esdhc-imx-fix-for-mmc-cards-on-i.mx5.patch aio-wake-up-waiters-when-freeing-unused-kiocbs.patch +mm-memcg-correct-unregistring-of-events-attached-to-the-same-eventfd.patch +nommu-don-t-need-to-clear-vm_mm-when-deleting-a-vma.patch -- 2.47.3