[patch 05/10] cpu topology: convert siblings_show macro to accept non-lvalues.

[Martin Schwidefsky]

From: Heiko Carstens <heiko.carstens@xxxxxxxxxx>

The sibling cpu masks on s390 can change because of dynamic cpu
reconfiguration. Therefore accesses to these masks are protected with
a lock so there aren't concurrent read and write accesses at the same
time. cpumask_scnprint in define_siblings_show_func expects an lvalue
for the cpu mask which would make the locking down in the s390 arch
code pointless. To solve this change the topology code to save a
snapshot of the sibling cpu mask and use that for output purposes.

Signed-off-by: Heiko Carstens <heiko.carstens@xxxxxxxxxx>
Signed-off-by: Martin Schwidefsky <schwidefsky@xxxxxxxxxx>
---

 drivers/base/topology.c |   17 ++++++++++-------
 1 file changed, 10 insertions(+), 7 deletions(-)

Index: quilt-2.6/drivers/base/topology.c
===================================================================
--- quilt-2.6.orig/drivers/base/topology.c
+++ quilt-2.6/drivers/base/topology.c
@@ -40,13 +40,16 @@ static ssize_t show_##name(struct sys_de
 	return sprintf(buf, "%d\n", topology_##name(cpu));	\
 }
 
-#define define_siblings_show_func(name)					\
-static ssize_t show_##name(struct sys_device *dev, char *buf)		\
-{									\
-	ssize_t len = -1;						\
-	unsigned int cpu = dev->id;					\
-	len = cpumask_scnprintf(buf, NR_CPUS+1, topology_##name(cpu));	\
-	return (len + sprintf(buf + len, "\n"));			\
+#define define_siblings_show_func(name)				\
+static ssize_t show_##name(struct sys_device *dev, char *buf)	\
+{								\
+	ssize_t len = -1;					\
+	unsigned int cpu = dev->id;				\
+	cpumask_t mask; 					\
+								\
+	mask = topology_##name(cpu);				\
+	len = cpumask_scnprintf(buf, NR_CPUS + 1, mask);	\
+	return len + sprintf(buf + len, "\n");			\
 }
 
 #ifdef	topology_physical_package_id

-- 
blue skies,
   Martin.

"Reality continues to ruin my life." - Calvin.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/