This is a note to let you know that I've just added the patch titled
powerpc: Don't Oops when accessing /proc/powerpc/lparcfg without hypervisor
to the 3.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
powerpc-don-t-oops-when-accessing-proc-powerpc-lparcfg-without-hypervisor.patch
and it can be found in the queue-3.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <[email protected]> know about it.
>From c349bf07d6c05e89c967327af0f334604826d0e4 Mon Sep 17 00:00:00 2001
From: Benjamin Herrenschmidt <[email protected]>
Date: Tue, 27 Aug 2013 16:38:33 +1000
Subject: powerpc: Don't Oops when accessing /proc/powerpc/lparcfg without
hypervisor
From: Benjamin Herrenschmidt <[email protected]>
commit f5f6cbb61610b7bf9d9d96db9c3979d62a424bab upstream.
/proc/powerpc/lparcfg is an ancient facility (though still actively used)
which allows access to some informations relative to the partition when
running underneath a PAPR compliant hypervisor.
It makes no sense on non-pseries machines. However, currently, not only
can it be created on these if the kernel has pseries support, but accessing
it on such a machine will crash due to trying to do hypervisor calls.
In fact, it should also not do HV calls on older pseries that didn't have
an hypervisor either.
Finally, it has the plumbing to be a module but is a "bool" Kconfig option.
This fixes the whole lot by turning it into a machine_device_initcall
that is only created on pseries, and adding the necessary hypervisor
check before calling the H_GET_EM_PARMS hypercall
Signed-off-by: Benjamin Herrenschmidt <[email protected]>
[bwh: Backported to 3.2: lparcfg_cleanup() was a bit different]
Signed-off-by: Ben Hutchings <[email protected]>
Cc: Yijing Wang <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/powerpc/kernel/lparcfg.c | 23 +++++++++--------------
1 file changed, 9 insertions(+), 14 deletions(-)
--- a/arch/powerpc/kernel/lparcfg.c
+++ b/arch/powerpc/kernel/lparcfg.c
@@ -35,7 +35,13 @@
#include <asm/vdso_datapage.h>
#include <asm/vio.h>
#include <asm/mmu.h>
+#include <asm/machdep.h>
+
+/*
+ * This isn't a module but we expose that to userspace
+ * via /proc so leave the definitions here
+ */
#define MODULE_VERS "1.9"
#define MODULE_NAME "lparcfg"
@@ -419,7 +425,8 @@ static void parse_em_data(struct seq_fil
{
unsigned long retbuf[PLPAR_HCALL_BUFSIZE];
- if (plpar_hcall(H_GET_EM_PARMS, retbuf) == H_SUCCESS)
+ if (firmware_has_feature(FW_FEATURE_LPAR) &&
+ plpar_hcall(H_GET_EM_PARMS, retbuf) == H_SUCCESS)
seq_printf(m, "power_mode_data=%016lx\n", retbuf[0]);
}
@@ -678,7 +685,6 @@ static int lparcfg_open(struct inode *in
}
static const struct file_operations lparcfg_fops = {
- .owner = THIS_MODULE,
.read = seq_read,
.write = lparcfg_write,
.open = lparcfg_open,
@@ -704,15 +710,4 @@ static int __init lparcfg_init(void)
proc_ppc64_lparcfg = ent;
return 0;
}
-
-static void __exit lparcfg_cleanup(void)
-{
- if (proc_ppc64_lparcfg)
- remove_proc_entry("lparcfg", proc_ppc64_lparcfg->parent);
-}
-
-module_init(lparcfg_init);
-module_exit(lparcfg_cleanup);
-MODULE_DESCRIPTION("Interface for LPAR configuration data");
-MODULE_AUTHOR("Dave Engebretsen");
-MODULE_LICENSE("GPL");
+machine_device_initcall(pseries, lparcfg_init);
Patches currently in stable-queue which might be from [email protected]
are
queue-3.4/powerpc-don-t-oops-when-accessing-proc-powerpc-lparcfg-without-hypervisor.patch
queue-3.4/powerpc-pseries-duplicate-dtl-entries-sometimes-sent-to-userspace.patch
queue-3.4/powerpc-restore-registers-on-error-exit-from-csum_partial_copy_generic.patch
queue-3.4/powerpc-pseries-lparcfg-fix-possible-overflow-are-more-than-1026.patch
queue-3.4/powerpc-fix-emulation-of-illegal-instructions-on-powernv-platform.patch
queue-3.4/powerpc-smp-section-mismatch-from-smp_release_cpus-to-__initdata-spinning_secondaries.patch
queue-3.4/powerpc-sysfs-disable-writing-to-purr-in-guest-mode.patch
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
