From c7253b52a05ba1a10cdb27f7e46a8ef2df58d43f Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Thu, 20 Mar 2014 01:45:05 +0000 Subject: [PATCH] 3.4-stable patches added patches: arm-7991-1-sa1100-fix-compile-problem-on-collie.patch cpuset-fix-a-race-condition-in-__cpuset_node_allowed_softwall.patch genirq-remove-racy-waitqueue_active-check.patch regulator-core-replace-direct-ops-enable-usage.patch x86-amd-numa-fix-northbridge-quirk-to-assign-correct-numa-node.patch --- ...sa1100-fix-compile-problem-on-collie.patch | 44 ++++++++++++ ...on-in-__cpuset_node_allowed_softwall.patch | 33 +++++++++ ...q-remove-racy-waitqueue_active-check.patch | 61 +++++++++++++++++ ...core-replace-direct-ops-enable-usage.patch | 67 +++++++++++++++++++ queue-3.4/series | 5 ++ ...ge-quirk-to-assign-correct-numa-node.patch | 41 ++++++++++++ 6 files changed, 251 insertions(+) create mode 100644 queue-3.4/arm-7991-1-sa1100-fix-compile-problem-on-collie.patch create mode 100644 queue-3.4/cpuset-fix-a-race-condition-in-__cpuset_node_allowed_softwall.patch create mode 100644 queue-3.4/genirq-remove-racy-waitqueue_active-check.patch create mode 100644 queue-3.4/regulator-core-replace-direct-ops-enable-usage.patch create mode 100644 queue-3.4/x86-amd-numa-fix-northbridge-quirk-to-assign-correct-numa-node.patch diff --git a/queue-3.4/arm-7991-1-sa1100-fix-compile-problem-on-collie.patch b/queue-3.4/arm-7991-1-sa1100-fix-compile-problem-on-collie.patch new file mode 100644 index 00000000000..82f0ad6bf4f --- /dev/null +++ b/queue-3.4/arm-7991-1-sa1100-fix-compile-problem-on-collie.patch @@ -0,0 +1,44 @@ +From 052450fdc55894a39fbae93d9bbe43947956f663 Mon Sep 17 00:00:00 2001 +From: Linus Walleij +Date: Tue, 25 Feb 2014 22:41:41 +0100 +Subject: ARM: 7991/1: sa1100: fix compile problem on Collie + +From: Linus Walleij + +commit 052450fdc55894a39fbae93d9bbe43947956f663 upstream. + +Due to a problem in the MFD Kconfig it was not possible to +compile the UCB battery driver for the Collie SA1100 system, +in turn making it impossible to compile in the battery driver. +(See patch "mfd: include all drivers in subsystem menu".) + +After fixing the MFD Kconfig (separate patch) a compile error +appears in the Collie battery driver due to the +implicitly requiring through +via prior to commit +40ca061b "ARM: 7841/1: sa1100: remove complex GPIO interface". + +Fix this up by including the required header into +. + +Cc: Andrea Adami +Cc: Dmitry Eremin-Solenikov +Signed-off-by: Linus Walleij +Signed-off-by: Russell King +Signed-off-by: Greg Kroah-Hartman + +--- + arch/arm/mach-sa1100/include/mach/collie.h | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/arch/arm/mach-sa1100/include/mach/collie.h ++++ b/arch/arm/mach-sa1100/include/mach/collie.h +@@ -13,6 +13,8 @@ + #ifndef __ASM_ARCH_COLLIE_H + #define __ASM_ARCH_COLLIE_H + ++#include "hardware.h" /* Gives GPIO_MAX */ ++ + extern void locomolcd_power(int on); + + #define COLLIE_SCOOP_GPIO_BASE (GPIO_MAX + 1) diff --git a/queue-3.4/cpuset-fix-a-race-condition-in-__cpuset_node_allowed_softwall.patch b/queue-3.4/cpuset-fix-a-race-condition-in-__cpuset_node_allowed_softwall.patch new file mode 100644 index 00000000000..f76eabf4045 --- /dev/null +++ b/queue-3.4/cpuset-fix-a-race-condition-in-__cpuset_node_allowed_softwall.patch @@ -0,0 +1,33 @@ +From 99afb0fd5f05aac467ffa85c36778fec4396209b Mon Sep 17 00:00:00 2001 +From: Li Zefan +Date: Thu, 27 Feb 2014 18:19:36 +0800 +Subject: cpuset: fix a race condition in __cpuset_node_allowed_softwall() + +From: Li Zefan + +commit 99afb0fd5f05aac467ffa85c36778fec4396209b upstream. + +It's not safe to access task's cpuset after releasing task_lock(). +Holding callback_mutex won't help. + +Signed-off-by: Li Zefan +Signed-off-by: Tejun Heo +Signed-off-by: Greg Kroah-Hartman + +--- + kernel/cpuset.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/kernel/cpuset.c ++++ b/kernel/cpuset.c +@@ -2338,9 +2338,9 @@ int __cpuset_node_allowed_softwall(int n + + task_lock(current); + cs = nearest_hardwall_ancestor(task_cs(current)); ++ allowed = node_isset(node, cs->mems_allowed); + task_unlock(current); + +- allowed = node_isset(node, cs->mems_allowed); + mutex_unlock(&callback_mutex); + return allowed; + } diff --git a/queue-3.4/genirq-remove-racy-waitqueue_active-check.patch b/queue-3.4/genirq-remove-racy-waitqueue_active-check.patch new file mode 100644 index 00000000000..dda6781a01e --- /dev/null +++ b/queue-3.4/genirq-remove-racy-waitqueue_active-check.patch @@ -0,0 +1,61 @@ +From c685689fd24d310343ac33942e9a54a974ae9c43 Mon Sep 17 00:00:00 2001 +From: Chuansheng Liu +Date: Mon, 24 Feb 2014 11:29:50 +0800 +Subject: genirq: Remove racy waitqueue_active check + +From: Chuansheng Liu + +commit c685689fd24d310343ac33942e9a54a974ae9c43 upstream. + +We hit one rare case below: + +T1 calling disable_irq(), but hanging at synchronize_irq() +always; +The corresponding irq thread is in sleeping state; +And all CPUs are in idle state; + +After analysis, we found there is one possible scenerio which +causes T1 is waiting there forever: +CPU0 CPU1 + synchronize_irq() + wait_event() + spin_lock() + atomic_dec_and_test(&threads_active) + insert the __wait into queue + spin_unlock() + if(waitqueue_active) + atomic_read(&threads_active) + wake_up() + +Here after inserted the __wait into queue on CPU0, and before +test if queue is empty on CPU1, there is no barrier, it maybe +cause it is not visible for CPU1 immediately, although CPU0 has +updated the queue list. +It is similar for CPU0 atomic_read() threads_active also. + +So we'd need one smp_mb() before waitqueue_active.that, but removing +the waitqueue_active() check solves it as wel l and it makes +things simple and clear. + +Signed-off-by: Chuansheng Liu +Cc: Xiaoming Wang +Link: http://lkml.kernel.org/r/1393212590-32543-1-git-send-email-chuansheng.liu@intel.com +Signed-off-by: Thomas Gleixner +Signed-off-by: Greg Kroah-Hartman + +--- + kernel/irq/manage.c | 3 +-- + 1 file changed, 1 insertion(+), 2 deletions(-) + +--- a/kernel/irq/manage.c ++++ b/kernel/irq/manage.c +@@ -777,8 +777,7 @@ static irqreturn_t irq_thread_fn(struct + + static void wake_threads_waitq(struct irq_desc *desc) + { +- if (atomic_dec_and_test(&desc->threads_active) && +- waitqueue_active(&desc->wait_for_threads)) ++ if (atomic_dec_and_test(&desc->threads_active)) + wake_up(&desc->wait_for_threads); + } + diff --git a/queue-3.4/regulator-core-replace-direct-ops-enable-usage.patch b/queue-3.4/regulator-core-replace-direct-ops-enable-usage.patch new file mode 100644 index 00000000000..59ff78a5c44 --- /dev/null +++ b/queue-3.4/regulator-core-replace-direct-ops-enable-usage.patch @@ -0,0 +1,67 @@ +From 30c219710358c5cca2f8bd2e9e547c6aadf7cf8b Mon Sep 17 00:00:00 2001 +From: Markus Pargmann +Date: Thu, 20 Feb 2014 17:36:03 +0100 +Subject: regulator: core: Replace direct ops->enable usage + +From: Markus Pargmann + +commit 30c219710358c5cca2f8bd2e9e547c6aadf7cf8b upstream. + +There are some direct ops->enable in the regulator core driver. This is +a potential issue as the function _regulator_do_enable() handles gpio +regulators and the normal ops->enable calls. These gpio regulators are +simply ignored when ops->enable is called directly. + +One possible bug is that boot-on and always-on gpio regulators are not +enabled on registration. + +This patch replaces all ops->enable calls by _regulator_do_enable. + +[Handle missing enable operations -- broonie] + +Signed-off-by: Markus Pargmann +Signed-off-by: Mark Brown +Signed-off-by: Greg Kroah-Hartman + + +--- + drivers/regulator/core.c | 14 +++++++------- + 1 file changed, 7 insertions(+), 7 deletions(-) + +--- a/drivers/regulator/core.c ++++ b/drivers/regulator/core.c +@@ -894,6 +894,8 @@ static int machine_constraints_voltage(s + return 0; + } + ++static int _regulator_do_enable(struct regulator_dev *rdev); ++ + /** + * set_machine_constraints - sets regulator constraints + * @rdev: regulator source +@@ -950,10 +952,9 @@ static int set_machine_constraints(struc + /* If the constraints say the regulator should be on at this point + * and we have control then make sure it is enabled. + */ +- if ((rdev->constraints->always_on || rdev->constraints->boot_on) && +- ops->enable) { +- ret = ops->enable(rdev); +- if (ret < 0) { ++ if (rdev->constraints->always_on || rdev->constraints->boot_on) { ++ ret = _regulator_do_enable(rdev); ++ if (ret < 0 && ret != -EINVAL) { + rdev_err(rdev, "failed to enable\n"); + goto out; + } +@@ -3061,9 +3062,8 @@ int regulator_suspend_finish(void) + struct regulator_ops *ops = rdev->desc->ops; + + mutex_lock(&rdev->mutex); +- if ((rdev->use_count > 0 || rdev->constraints->always_on) && +- ops->enable) { +- error = ops->enable(rdev); ++ if (rdev->use_count > 0 || rdev->constraints->always_on) { ++ error = _regulator_do_enable(rdev); + if (error) + ret = error; + } else { diff --git a/queue-3.4/series b/queue-3.4/series index bb9d1835239..68320926052 100644 --- a/queue-3.4/series +++ b/queue-3.4/series @@ -12,3 +12,8 @@ drm-ttm-don-t-oops-if-no-invalidate_caches.patch alsa-oxygen-xonar-dg-x-capture-from-i2s-channel-1-not-2.patch alsa-usb-audio-add-quirk-for-logitech-webcam-c500.patch powerpc-align-p_dyn-p_rela-and-p_st-symbols.patch +arm-7991-1-sa1100-fix-compile-problem-on-collie.patch +regulator-core-replace-direct-ops-enable-usage.patch +x86-amd-numa-fix-northbridge-quirk-to-assign-correct-numa-node.patch +genirq-remove-racy-waitqueue_active-check.patch +cpuset-fix-a-race-condition-in-__cpuset_node_allowed_softwall.patch diff --git a/queue-3.4/x86-amd-numa-fix-northbridge-quirk-to-assign-correct-numa-node.patch b/queue-3.4/x86-amd-numa-fix-northbridge-quirk-to-assign-correct-numa-node.patch new file mode 100644 index 00000000000..599bfe1fdc8 --- /dev/null +++ b/queue-3.4/x86-amd-numa-fix-northbridge-quirk-to-assign-correct-numa-node.patch @@ -0,0 +1,41 @@ +From 847d7970defb45540735b3fb4e88471c27cacd85 Mon Sep 17 00:00:00 2001 +From: Daniel J Blueman +Date: Thu, 13 Mar 2014 19:43:01 +0800 +Subject: x86/amd/numa: Fix northbridge quirk to assign correct NUMA node + +From: Daniel J Blueman + +commit 847d7970defb45540735b3fb4e88471c27cacd85 upstream. + +For systems with multiple servers and routed fabric, all +northbridges get assigned to the first server. Fix this by also +using the node reported from the PCI bus. For single-fabric +systems, the northbriges are on PCI bus 0 by definition, which +are on NUMA node 0 by definition, so this is invarient on most +systems. + +Tested on fam10h and fam15h single and multi-fabric systems and +candidate for stable. + +Signed-off-by: Daniel J Blueman +Acked-by: Steffen Persvold +Acked-by: Borislav Petkov +Link: http://lkml.kernel.org/r/1394710981-3596-1-git-send-email-daniel@numascale.com +Signed-off-by: Ingo Molnar +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kernel/quirks.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/x86/kernel/quirks.c ++++ b/arch/x86/kernel/quirks.c +@@ -525,7 +525,7 @@ static void __init quirk_amd_nb_node(str + return; + + pci_read_config_dword(nb_ht, 0x60, &val); +- node = val & 7; ++ node = pcibus_to_node(dev->bus) | (val & 7); + /* + * Some hardware may return an invalid node ID, + * so check it first: -- 2.47.3