[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20120917003631.247940408@decadent.org.uk>
Date: Mon, 17 Sep 2012 01:37:01 +0100
From: Ben Hutchings <ben@...adent.org.uk>
To: linux-kernel@...r.kernel.org, stable@...r.kernel.org
Cc: torvalds@...ux-foundation.org, akpm@...ux-foundation.org,
alan@...rguk.ukuu.org.uk, Anton Blanchard <anton@...ba.org>,
Benjamin Herrenschmidt <benh@...nel.crashing.org>
Subject: [ 036/135] powerpc: Update DSCR on all CPUs when writing sysfs dscr_default
3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Anton Blanchard <anton@...ba.org>
commit 1b6ca2a6fe56e7697d57348646e07df08f43b1bb upstream.
Writing to dscr_default in sysfs doesn't actually change the DSCR -
we rely on a context switch on each CPU to do the work. There is no
guarantee we will get a context switch in a reasonable amount of time
so fire off an IPI to force an immediate change.
This issue was found with the following test case:
http://ozlabs.org/~anton/junkcode/dscr_explicit_test.c
Signed-off-by: Anton Blanchard <anton@...ba.org>
Signed-off-by: Benjamin Herrenschmidt <benh@...nel.crashing.org>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <ben@...adent.org.uk>
---
arch/powerpc/kernel/sysfs.c | 8 ++++++++
1 file changed, 8 insertions(+)
--- a/arch/powerpc/kernel/sysfs.c
+++ b/arch/powerpc/kernel/sysfs.c
@@ -192,6 +192,12 @@ static ssize_t show_dscr_default(struct
return sprintf(buf, "%lx\n", dscr_default);
}
+static void update_dscr(void *dummy)
+{
+ if (!current->thread.dscr_inherit)
+ mtspr(SPRN_DSCR, dscr_default);
+}
+
static ssize_t __used store_dscr_default(struct sysdev_class *class,
struct sysdev_class_attribute *attr, const char *buf,
size_t count)
@@ -204,6 +210,8 @@ static ssize_t __used store_dscr_default
return -EINVAL;
dscr_default = val;
+ on_each_cpu(update_dscr, NULL, 1);
+
return count;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists