* Re: [PATCH] powerpc/mm: Fix thread_pkey_regs_init()
From: Balbir Singh @ 2018-03-27 3:53 UTC (permalink / raw)
To: Ram Pai
Cc: Michael Ellerman, open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
Benjamin Herrenschmidt, Paul Mackerras, Aneesh Kumar KV,
Haren Myneni/Beaverton/IBM, Michal Hocko, Thiago Jung Bauermann,
fweimer, msuchanek
In-Reply-To: <1522118214-7040-1-git-send-email-linuxram@us.ibm.com>
On Tue, Mar 27, 2018 at 1:36 PM, Ram Pai <linuxram@us.ibm.com> wrote:
> thread_pkey_regs_init() initializes the pkey related registers
> instead of initializing the fields in the task structures. Fortunately
> those key related registers are re-set to zero when the task
> gets scheduled on the cpu. However its good to fix this glaringly
> visible error.
>
> cc: Michael Ellermen <mpe@ellerman.id.au>
> Signed-off-by: Ram Pai <linuxram@us.ibm.com>
> Signed-off-by: Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com>
> ---
Acked-by: Balbir Singh <bsingharora@gmail.com>
Balbir Singh
^ permalink raw reply
* Re: [PATCH v4] mm, pkey: treat pkey-0 special
From: Balbir Singh @ 2018-03-27 4:15 UTC (permalink / raw)
To: Michael Ellerman
Cc: Ram Pai, Ingo Molnar, akpm@linux-foundation.org,
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT), linux-mm,
maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT), linux-arch,
linux-kernel@vger.kernel.org, Dave Hansen, Benjamin Herrenschmidt,
Paul Mackerras, Anshuman Khandual, Aneesh Kumar KV,
Haren Myneni/Beaverton/IBM, Michal Hocko, Thiago Jung Bauermann,
Eric W. Biederman, Jonathan Corbet, Arnd Bergmann, fweimer,
msuchanek, Thomas Gleixner, Ulrich.Weigand, Ram Pai
In-Reply-To: <87o9jaji0q.fsf@concordia.ellerman.id.au>
On Tue, Mar 27, 2018 at 2:48 PM, Michael Ellerman <mpe@ellerman.id.au> wrote:
> Ram Pai <linuxram@us.ibm.com> writes:
>
>> On Fri, Mar 16, 2018 at 10:02:22PM +1100, Balbir Singh wrote:
>>> On Fri, Mar 16, 2018 at 9:33 PM, Ram Pai <linuxram@us.ibm.com> wrote:
>>> > Applications need the ability to associate an address-range with some
>>> > key and latter revert to its initial default key. Pkey-0 comes close to
>>> > providing this function but falls short, because the current
>>> > implementation disallows applications to explicitly associate pkey-0 to
>>> > the address range.
>>> >
>>> > Clarify the semantics of pkey-0 and provide the corresponding
>>> > implementation.
>>> >
>>> > Pkey-0 is special with the following semantics.
>>> > (a) it is implicitly allocated and can never be freed. It always exists.
>>> > (b) it is the default key assigned to any address-range.
>>> > (c) it can be explicitly associated with any address-range.
>>> >
>>> > Tested on powerpc only. Could not test on x86.
>>>
>>> Ram,
>>>
>>> I was wondering if we should check the AMOR values on the ppc side to make sure
>>> that pkey0 is indeed available for use as default. I am still of the
>>> opinion that we
>>
>> AMOR cannot be read/written by the OS in priviledge-non-hypervisor-mode.
>> We could try testing if key-0 is available to the OS by temproarily
>> changing the bits key-0 bits of AMR or IAMR register. But will be
>> dangeorous to do, for you might disable read,execute of all the pages,
>> since all pages are asscoiated with key-0 bydefault.
>
> No we should do what firmware tells us. If it says key 0 is available we
> use it, otherwise we don't.
>
> Now if you notice the way the firmware API (device tree property) is
> defined, it tells us how many keys are available, counting from 0.
>
I could not find counting from 0 anywhere, are we expected to look
at the AMOR and figure out what we have access to? Why do we
assume they'll be contiguous, it makes our life easy, but I really
could not find any documentation on it
> So for pkey 0 to be reserved there must be 0 keys available.
>
> End of story.
>
> cheers
Cheers,
Balbir Singh.
^ permalink raw reply
* [PATCH] powerpc: Only support DYNAMIC_FTRACE not static
From: Michael Ellerman @ 2018-03-27 4:29 UTC (permalink / raw)
To: linuxppc-dev; +Cc: rostedt, naveen.n.rao
We've had dynamic ftrace support for over 9 years since Steve first
wrote it, all the distros use dynamic, and static is basically
untested these days, so drop support for static ftrace.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/Kconfig | 1 +
arch/powerpc/include/asm/ftrace.h | 4 +---
arch/powerpc/kernel/trace/ftrace.c | 2 --
arch/powerpc/kernel/trace/ftrace_32.S | 20 ------------------
arch/powerpc/kernel/trace/ftrace_64.S | 29 --------------------------
arch/powerpc/kernel/trace/ftrace_64_mprofile.S | 3 ---
arch/powerpc/kernel/trace/ftrace_64_pg.S | 2 --
7 files changed, 2 insertions(+), 59 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 73ce5dd07642..080651bbc5a6 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -162,6 +162,7 @@ config PPC
select BUILDTIME_EXTABLE_SORT
select CLONE_BACKWARDS
select DCACHE_WORD_ACCESS if PPC64 && CPU_LITTLE_ENDIAN
+ select DYNAMIC_FTRACE if FUNCTION_TRACER
select EDAC_ATOMIC_SCRUB
select EDAC_SUPPORT
select GENERIC_ATOMIC64 if PPC32
diff --git a/arch/powerpc/include/asm/ftrace.h b/arch/powerpc/include/asm/ftrace.h
index f7a23c2dce74..3542ba03a9aa 100644
--- a/arch/powerpc/include/asm/ftrace.h
+++ b/arch/powerpc/include/asm/ftrace.h
@@ -48,7 +48,6 @@
#else /* !__ASSEMBLY__ */
extern void _mcount(void);
-#ifdef CONFIG_DYNAMIC_FTRACE
static inline unsigned long ftrace_call_adjust(unsigned long addr)
{
/* reloction of mcount call site is the same as the address */
@@ -58,13 +57,12 @@ static inline unsigned long ftrace_call_adjust(unsigned long addr)
struct dyn_arch_ftrace {
struct module *mod;
};
-#endif /* CONFIG_DYNAMIC_FTRACE */
#endif /* __ASSEMBLY__ */
#ifdef CONFIG_DYNAMIC_FTRACE_WITH_REGS
#define ARCH_SUPPORTS_FTRACE_OPS 1
#endif
-#endif
+#endif /* CONFIG_FUNCTION_TRACER */
#if defined(CONFIG_FTRACE_SYSCALLS) && !defined(__ASSEMBLY__)
#ifdef PPC64_ELF_ABI_v1
diff --git a/arch/powerpc/kernel/trace/ftrace.c b/arch/powerpc/kernel/trace/ftrace.c
index 79d2924e75d5..c076a32093fd 100644
--- a/arch/powerpc/kernel/trace/ftrace.c
+++ b/arch/powerpc/kernel/trace/ftrace.c
@@ -662,7 +662,6 @@ int __init ftrace_dyn_arch_init(void)
#ifdef CONFIG_FUNCTION_GRAPH_TRACER
-#ifdef CONFIG_DYNAMIC_FTRACE
extern void ftrace_graph_call(void);
extern void ftrace_graph_stub(void);
@@ -691,7 +690,6 @@ int ftrace_disable_ftrace_graph_caller(void)
return ftrace_modify_code(ip, old, new);
}
-#endif /* CONFIG_DYNAMIC_FTRACE */
/*
* Hook the return address and push it in the stack of return addrs
diff --git a/arch/powerpc/kernel/trace/ftrace_32.S b/arch/powerpc/kernel/trace/ftrace_32.S
index afef2c076282..2c29098f630f 100644
--- a/arch/powerpc/kernel/trace/ftrace_32.S
+++ b/arch/powerpc/kernel/trace/ftrace_32.S
@@ -14,7 +14,6 @@
#include <asm/ftrace.h>
#include <asm/export.h>
-#ifdef CONFIG_DYNAMIC_FTRACE
_GLOBAL(mcount)
_GLOBAL(_mcount)
/*
@@ -47,26 +46,7 @@ _GLOBAL(ftrace_graph_stub)
MCOUNT_RESTORE_FRAME
/* old link register ends up in ctr reg */
bctr
-#else
-_GLOBAL(mcount)
-_GLOBAL(_mcount)
-
- MCOUNT_SAVE_FRAME
- subi r3, r3, MCOUNT_INSN_SIZE
- LOAD_REG_ADDR(r5, ftrace_trace_function)
- lwz r5,0(r5)
-
- mtctr r5
- bctrl
- nop
-
-#ifdef CONFIG_FUNCTION_GRAPH_TRACER
- b ftrace_graph_caller
-#endif
- MCOUNT_RESTORE_FRAME
- bctr
-#endif
EXPORT_SYMBOL(_mcount)
_GLOBAL(ftrace_stub)
diff --git a/arch/powerpc/kernel/trace/ftrace_64.S b/arch/powerpc/kernel/trace/ftrace_64.S
index e5ccea19821e..e25f77c10a72 100644
--- a/arch/powerpc/kernel/trace/ftrace_64.S
+++ b/arch/powerpc/kernel/trace/ftrace_64.S
@@ -14,7 +14,6 @@
#include <asm/ppc-opcode.h>
#include <asm/export.h>
-#ifdef CONFIG_DYNAMIC_FTRACE
_GLOBAL(mcount)
_GLOBAL(_mcount)
EXPORT_SYMBOL(_mcount)
@@ -23,34 +22,6 @@ EXPORT_SYMBOL(_mcount)
mtlr r0
bctr
-#else /* CONFIG_DYNAMIC_FTRACE */
-_GLOBAL_TOC(_mcount)
-EXPORT_SYMBOL(_mcount)
- /* Taken from output of objdump from lib64/glibc */
- mflr r3
- ld r11, 0(r1)
- stdu r1, -112(r1)
- std r3, 128(r1)
- ld r4, 16(r11)
-
- subi r3, r3, MCOUNT_INSN_SIZE
- LOAD_REG_ADDR(r5,ftrace_trace_function)
- ld r5,0(r5)
- ld r5,0(r5)
- mtctr r5
- bctrl
- nop
-
-#ifdef CONFIG_FUNCTION_GRAPH_TRACER
- b ftrace_graph_caller
-#endif
- ld r0, 128(r1)
- mtlr r0
- addi r1, r1, 112
-_GLOBAL(ftrace_stub)
- blr
-#endif /* CONFIG_DYNAMIC_FTRACE */
-
#ifdef CONFIG_FUNCTION_GRAPH_TRACER
_GLOBAL(return_to_handler)
/* need to save return values */
diff --git a/arch/powerpc/kernel/trace/ftrace_64_mprofile.S b/arch/powerpc/kernel/trace/ftrace_64_mprofile.S
index f57822aa2fe8..1d5e68113125 100644
--- a/arch/powerpc/kernel/trace/ftrace_64_mprofile.S
+++ b/arch/powerpc/kernel/trace/ftrace_64_mprofile.S
@@ -17,7 +17,6 @@
#include <asm/bug.h>
#include <asm/ptrace.h>
-#ifdef CONFIG_DYNAMIC_FTRACE
/*
*
* ftrace_caller()/ftrace_regs_caller() is the function that replaces _mcount()
@@ -311,8 +310,6 @@ livepatch_handler:
blr
#endif /* CONFIG_LIVEPATCH */
-#endif /* CONFIG_DYNAMIC_FTRACE */
-
#ifdef CONFIG_FUNCTION_GRAPH_TRACER
_GLOBAL(ftrace_graph_caller)
stdu r1, -112(r1)
diff --git a/arch/powerpc/kernel/trace/ftrace_64_pg.S b/arch/powerpc/kernel/trace/ftrace_64_pg.S
index 3d8186832a34..cd7ec8072bc3 100644
--- a/arch/powerpc/kernel/trace/ftrace_64_pg.S
+++ b/arch/powerpc/kernel/trace/ftrace_64_pg.S
@@ -14,7 +14,6 @@
#include <asm/ppc-opcode.h>
#include <asm/export.h>
-#ifdef CONFIG_DYNAMIC_FTRACE
_GLOBAL_TOC(ftrace_caller)
lbz r3, PACA_FTRACE_DISABLED(r13)
cmpdi r3, 0
@@ -43,7 +42,6 @@ _GLOBAL(ftrace_graph_stub)
_GLOBAL(ftrace_stub)
blr
-#endif /* CONFIG_DYNAMIC_FTRACE */
#ifdef CONFIG_FUNCTION_GRAPH_TRACER
_GLOBAL(ftrace_graph_caller)
--
2.14.1
^ permalink raw reply related
* [PATCH v3 4/8] KVM: PPC: Book3S HV: Return error from h_set_mode(SET_DAWR) on POWER9
From: Michael Neuling @ 2018-03-27 4:37 UTC (permalink / raw)
To: mpe
Cc: linuxppc-dev, paulus, david, npiggin, pedromfc, kvm-ppc,
Ananth N Mavinakayanahalli
In-Reply-To: <20180327043724.13862-1-mikey@neuling.org>
Return H_P2 on a h_set_mode(SET_DAWR) on POWER9 where the DAWR is
disabled.
Current Linux guests ignore this error, so they will silently not get
the DAWR (sigh). The same error code is being used by POWERVM in this
case.
Signed-off-by: Michael Neuling <mikey@neuling.org>
---
arch/powerpc/kvm/book3s_hv.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
index 89707354c2..0c17c9f30b 100644
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -741,6 +741,8 @@ static int kvmppc_h_set_mode(struct kvm_vcpu *vcpu, unsigned long mflags,
case H_SET_MODE_RESOURCE_SET_DAWR:
if (!kvmppc_power8_compatible(vcpu))
return H_P2;
+ if (!ppc_breakpoint_available())
+ return H_P2;
if (mflags)
return H_UNSUPPORTED_FLAG_START;
if (value2 & DABRX_HYP)
--
2.14.1
^ permalink raw reply related
* [PATCH v3 0/8] powerpc: Disable DAWR on POWER9
From: Michael Neuling @ 2018-03-27 4:37 UTC (permalink / raw)
To: mpe
Cc: linuxppc-dev, paulus, david, npiggin, pedromfc, kvm-ppc,
Ananth N Mavinakayanahalli
Using the DAWR on POWER9 can cause xstops, hence we need to disable
it.
The current CPU_FTR for DAWR is a bit messy. Despite having
CPU_FTR_DAWR, currently we assume DAWR exists in the KVM code based on
CPU_FTR_ARCH_207. In other places we assume DAWR exists if
CPU_FTR_DAWR is set.
This attempts to clear up the situation by always using CPU_FTR_DAWR
before setting the DAWR (to a non-zero value).
DAWR has 5 different ways of being set from userspace. ptrace,
h_set_mode, h_set_mode(DAWR), h_set_dabr(), kvmppc_set_one_reg() and
xmon.
For ptrace, we now advertise zero breakpoints on POWER9 via the
PPC_PTRACE_GETHWDBGINFO call. This results in GDB falling back to
software emulation of the watchpoint (which is slow).
h_set_mode() and h_set_dabr() will now return an error to the guest
when on a POWER9 host. Current Linux guests ignore this error, so they
will silently not get the DAWR (sigh). The same error codes are being
used by POWERVM in this case.
kvmppc_set_one_reg() will store the value in the vcpu but won't
actually set it on POWER9 hardware. This is done so we don't break
migration from P8 to P9, at the cost of silently losing the DAWR on
the migration. This is not ideal but hopefully the best overall
solution. This approach has been acked by paulus.
For xmon, the 'bd' command will return an error on P9.
Thanks to Pedro Franco de Carvalho for the initial version of this.
v3:
Split patches
Fix usage of H_UNSUPPORTED
v2:
Move to CPU feature quirk from Nick's
dbginfo.num_data_bps = 0 if !breakpoint_available() from Pedro
^ permalink raw reply
* [PATCH v3 2/8] powerpc: Update ptrace to use ppc_breakpoint_available()
From: Michael Neuling @ 2018-03-27 4:37 UTC (permalink / raw)
To: mpe
Cc: linuxppc-dev, paulus, david, npiggin, pedromfc, kvm-ppc,
Ananth N Mavinakayanahalli
In-Reply-To: <20180327043724.13862-1-mikey@neuling.org>
This updates the ptrace code to use ppc_breakpoint_available().
We now advertise via PPC_PTRACE_GETHWDBGINFO zero breakpoints when the
DAWR is missing (ie. POWER9). This results in GDB falling back to
software emulation of the breakpoint (which is slow).
For the features advertised by PPC_PTRACE_GETHWDBGINFO, we keep
advertising DAWR as if we don't GDB assumes 1 breakpoint irrespective
of the number of breakpoints advertised. GDB then fails later when
trying to set this one breakpoint.
Signed-off-by: Michael Neuling <mikey@neuling.org>
---
arch/powerpc/kernel/hw_breakpoint.c | 3 +++
arch/powerpc/kernel/ptrace.c | 16 ++++++++++++++--
2 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/hw_breakpoint.c b/arch/powerpc/kernel/hw_breakpoint.c
index 53b9c1dfd7..4c1012b80d 100644
--- a/arch/powerpc/kernel/hw_breakpoint.c
+++ b/arch/powerpc/kernel/hw_breakpoint.c
@@ -33,6 +33,7 @@
#include <asm/hw_breakpoint.h>
#include <asm/processor.h>
#include <asm/sstep.h>
+#include <asm/debug.h>
#include <linux/uaccess.h>
/*
@@ -171,6 +172,8 @@ int arch_validate_hwbkpt_settings(struct perf_event *bp)
* HW_BREAKPOINT_ALIGN by rounding off to the lower address, the
* 'symbolsize' should satisfy the check below.
*/
+ if (!ppc_breakpoint_available())
+ return -ENODEV;
length_max = 8; /* DABR */
if (cpu_has_feature(CPU_FTR_DAWR)) {
length_max = 512 ; /* 64 doublewords */
diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
index ca72d7391d..d23cf632ed 100644
--- a/arch/powerpc/kernel/ptrace.c
+++ b/arch/powerpc/kernel/ptrace.c
@@ -41,6 +41,7 @@
#include <asm/switch_to.h>
#include <asm/tm.h>
#include <asm/asm-prototypes.h>
+#include <asm/debug.h>
#define CREATE_TRACE_POINTS
#include <trace/events/syscalls.h>
@@ -2378,6 +2379,7 @@ static int ptrace_set_debugreg(struct task_struct *task, unsigned long addr,
struct perf_event_attr attr;
#endif /* CONFIG_HAVE_HW_BREAKPOINT */
#ifndef CONFIG_PPC_ADV_DEBUG_REGS
+ bool set_bp = true;
struct arch_hw_breakpoint hw_brk;
#endif
@@ -2411,9 +2413,10 @@ static int ptrace_set_debugreg(struct task_struct *task, unsigned long addr,
hw_brk.address = data & (~HW_BRK_TYPE_DABR);
hw_brk.type = (data & HW_BRK_TYPE_DABR) | HW_BRK_TYPE_PRIV_ALL;
hw_brk.len = 8;
+ set_bp = (data) && (hw_brk.type & HW_BRK_TYPE_RDWR);
#ifdef CONFIG_HAVE_HW_BREAKPOINT
bp = thread->ptrace_bps[0];
- if ((!data) || !(hw_brk.type & HW_BRK_TYPE_RDWR)) {
+ if (!set_bp) {
if (bp) {
unregister_hw_breakpoint(bp);
thread->ptrace_bps[0] = NULL;
@@ -2450,6 +2453,9 @@ static int ptrace_set_debugreg(struct task_struct *task, unsigned long addr,
return PTR_ERR(bp);
}
+#else /* !CONFIG_HAVE_HW_BREAKPOINT */
+ if (set_bp && (!ppc_breakpoint_available()))
+ return -ENODEV;
#endif /* CONFIG_HAVE_HW_BREAKPOINT */
task->thread.hw_brk = hw_brk;
#else /* CONFIG_PPC_ADV_DEBUG_REGS */
@@ -2904,6 +2910,9 @@ static long ppc_set_hwdebug(struct task_struct *child,
if (child->thread.hw_brk.address)
return -ENOSPC;
+ if (!ppc_breakpoint_available())
+ return -ENODEV;
+
child->thread.hw_brk = brk;
return 1;
@@ -3052,7 +3061,10 @@ long arch_ptrace(struct task_struct *child, long request,
#endif
#else /* !CONFIG_PPC_ADV_DEBUG_REGS */
dbginfo.num_instruction_bps = 0;
- dbginfo.num_data_bps = 1;
+ if (ppc_breakpoint_available())
+ dbginfo.num_data_bps = 1;
+ else
+ dbginfo.num_data_bps = 0;
dbginfo.num_condition_regs = 0;
#ifdef CONFIG_PPC64
dbginfo.data_bp_alignment = 8;
--
2.14.1
^ permalink raw reply related
* [PATCH v3 3/8] powerpc: Update xmon to use ppc_breakpoint_available()
From: Michael Neuling @ 2018-03-27 4:37 UTC (permalink / raw)
To: mpe
Cc: linuxppc-dev, paulus, david, npiggin, pedromfc, kvm-ppc,
Ananth N Mavinakayanahalli
In-Reply-To: <20180327043724.13862-1-mikey@neuling.org>
The 'bd' command will now print an error and not set the breakpoint on
P9.
Signed-off-by: Michael Neuling <mikey@neuling.org>
---
arch/powerpc/xmon/xmon.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
index a06cf6e389..047a682c6d 100644
--- a/arch/powerpc/xmon/xmon.c
+++ b/arch/powerpc/xmon/xmon.c
@@ -1302,6 +1302,11 @@ bpt_cmds(void)
static const char badaddr[] = "Only kernel addresses are permitted for breakpoints\n";
int mode;
case 'd': /* bd - hardware data breakpoint */
+ if (!ppc_breakpoint_available()) {
+ printf("Hardware data breakpoint "
+ "not supported on this cpu\n");
+ break;
+ }
mode = 7;
cmd = inchar();
if (cmd == 'r')
--
2.14.1
^ permalink raw reply related
* [PATCH v3 1/8] powerpc: Add ppc_breakpoint_available()
From: Michael Neuling @ 2018-03-27 4:37 UTC (permalink / raw)
To: mpe
Cc: linuxppc-dev, paulus, david, npiggin, pedromfc, kvm-ppc,
Ananth N Mavinakayanahalli
In-Reply-To: <20180327043724.13862-1-mikey@neuling.org>
Add ppc_breakpoint_available() to determine if a breakpoint is
available currently via the DAWR or DABR.
Signed-off-by: Michael Neuling <mikey@neuling.org>
---
arch/powerpc/include/asm/debug.h | 1 +
arch/powerpc/kernel/process.c | 12 ++++++++++++
2 files changed, 13 insertions(+)
diff --git a/arch/powerpc/include/asm/debug.h b/arch/powerpc/include/asm/debug.h
index fc97404de0..ce5da214ff 100644
--- a/arch/powerpc/include/asm/debug.h
+++ b/arch/powerpc/include/asm/debug.h
@@ -47,6 +47,7 @@ static inline int debugger_fault_handler(struct pt_regs *regs) { return 0; }
void set_breakpoint(struct arch_hw_breakpoint *brk);
void __set_breakpoint(struct arch_hw_breakpoint *brk);
+bool ppc_breakpoint_available(void);
#ifdef CONFIG_PPC_ADV_DEBUG_REGS
extern void do_send_trap(struct pt_regs *regs, unsigned long address,
unsigned long error_code, int brkpt);
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index ec4f363ebb..24a591b4db 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -827,6 +827,18 @@ void set_breakpoint(struct arch_hw_breakpoint *brk)
preempt_enable();
}
+/* Check if we have DAWR or DABR hardware */
+bool ppc_breakpoint_available(void)
+{
+ if (cpu_has_feature(CPU_FTR_DAWR))
+ return true; /* POWER8 DAWR */
+ if (cpu_has_feature(CPU_FTR_ARCH_207S))
+ return false; /* POWER9 with DAWR disabled */
+ /* DABR: Everything but POWER8 and POWER9 */
+ return true;
+}
+EXPORT_SYMBOL_GPL(ppc_breakpoint_available);
+
#ifdef CONFIG_PPC64
DEFINE_PER_CPU(struct cpu_usage, cpu_usage_array);
#endif
--
2.14.1
^ permalink raw reply related
* [PATCH v3 5/8] KVM: PPC: Book3S HV: Return error from h_set_dabr() on POWER9
From: Michael Neuling @ 2018-03-27 4:37 UTC (permalink / raw)
To: mpe
Cc: linuxppc-dev, paulus, david, npiggin, pedromfc, kvm-ppc,
Ananth N Mavinakayanahalli
In-Reply-To: <20180327043724.13862-1-mikey@neuling.org>
POWER7 compat mode guests can use h_set_dabr on POWER9. POWER9 should
use the DAWR but since it's disabled there we can't.
This returns H_UNSUPPORTED on a h_set_dabr() on POWER9 where the DAWR
is disabled.
Current Linux guests ignore this error, so they will silently not get
the DAWR (sigh). The same error code is being used by POWERVM in this
case.
Signed-off-by: Michael Neuling <mikey@neuling.org>
---
arch/powerpc/include/asm/hvcall.h | 1 +
arch/powerpc/kvm/book3s_hv_rmhandlers.S | 8 +++++++-
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/hvcall.h b/arch/powerpc/include/asm/hvcall.h
index eca3f9c689..e87d465af4 100644
--- a/arch/powerpc/include/asm/hvcall.h
+++ b/arch/powerpc/include/asm/hvcall.h
@@ -88,6 +88,7 @@
#define H_P8 -61
#define H_P9 -62
#define H_TOO_BIG -64
+#define H_UNSUPPORTED -67
#define H_OVERLAP -68
#define H_INTERRUPT -69
#define H_BAD_DATA -70
diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
index f31f357b8c..13e23a5275 100644
--- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
+++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
@@ -2506,8 +2506,14 @@ END_FTR_SECTION_IFSET(CPU_FTR_ARCH_207S)
li r3,0
blr
+2:
+BEGIN_FTR_SECTION
+ /* POWER9 with disabled DAWR */
+ li r3, H_UNSUPPORTED
+ blr
+END_FTR_SECTION_IFCLR(CPU_FTR_DAWR)
/* Emulate H_SET_DABR/X on P8 for the sake of compat mode guests */
-2: rlwimi r5, r4, 5, DAWRX_DR | DAWRX_DW
+ rlwimi r5, r4, 5, DAWRX_DR | DAWRX_DW
rlwimi r5, r4, 2, DAWRX_WT
clrrdi r4, r4, 3
std r4, VCPU_DAWR(r3)
--
2.14.1
^ permalink raw reply related
* [PATCH v3 6/8] KVM: PPC: Book3S HV: Handle migration with POWER9 disabled DAWR
From: Michael Neuling @ 2018-03-27 4:37 UTC (permalink / raw)
To: mpe
Cc: linuxppc-dev, paulus, david, npiggin, pedromfc, kvm-ppc,
Ananth N Mavinakayanahalli
In-Reply-To: <20180327043724.13862-1-mikey@neuling.org>
POWER9 with the DAWR disabled causes problems for partition
migration. Either we have to fail the migration (since we lose the
DAWR) or we silently drop the DAWR and allow the migration to pass.
This patch does the latter and allows the migration to pass (at the
cost of silently losing the DAWR). This is not ideal but hopefully the
best overall solution. This approach has been acked by Paulus.
With this patch kvmppc_set_one_reg() will store the DAWR in the vcpu
but won't actually set it on POWER9 hardware.
Signed-off-by: Michael Neuling <mikey@neuling.org>
---
arch/powerpc/kvm/book3s_hv_rmhandlers.S | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
index 13e23a5275..8ba20b11ba 100644
--- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
+++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
@@ -886,8 +886,14 @@ END_FTR_SECTION_IFCLR(CPU_FTR_ARCH_207S)
ld r6, VCPU_DAWRX(r4)
ld r7, VCPU_CIABR(r4)
ld r8, VCPU_TAR(r4)
+ /*
+ * Handle broken DAWR case by not writing it. This means we
+ * can still store the DAWR register for migration.
+ */
+BEGIN_FTR_SECTION
mtspr SPRN_DAWR, r5
mtspr SPRN_DAWRX, r6
+END_FTR_SECTION_IFSET(CPU_FTR_DAWR)
mtspr SPRN_CIABR, r7
mtspr SPRN_TAR, r8
ld r5, VCPU_IC(r4)
@@ -1834,6 +1840,10 @@ BEGIN_FTR_SECTION
ld r6, STACK_SLOT_DAWR(r1)
ld r7, STACK_SLOT_DAWRX(r1)
mtspr SPRN_CIABR, r5
+ /*
+ * If the DAWR doesn't work, it's ok to write these here as
+ * this value should always be zero
+ */
mtspr SPRN_DAWR, r6
mtspr SPRN_DAWRX, r7
END_FTR_SECTION_IFSET(CPU_FTR_ARCH_207S)
--
2.14.1
^ permalink raw reply related
* [PATCH v3 7/8] powerpc: Disable DAWR on POWER9 via CPU feature quirk
From: Michael Neuling @ 2018-03-27 4:37 UTC (permalink / raw)
To: mpe
Cc: linuxppc-dev, paulus, david, npiggin, pedromfc, kvm-ppc,
Ananth N Mavinakayanahalli
In-Reply-To: <20180327043724.13862-1-mikey@neuling.org>
This disables the DAWR on all POWER9 CPUs via cpu feature quirk.
Using the DAWR on POWER9 can cause xstops, hence we need to disable
it.
Signed-off-by: Michael Neuling <mikey@neuling.org>
---
arch/powerpc/kernel/dt_cpu_ftrs.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/powerpc/kernel/dt_cpu_ftrs.c b/arch/powerpc/kernel/dt_cpu_ftrs.c
index 945e2c29ad..941a5fbd8d 100644
--- a/arch/powerpc/kernel/dt_cpu_ftrs.c
+++ b/arch/powerpc/kernel/dt_cpu_ftrs.c
@@ -709,6 +709,9 @@ static __init void cpufeatures_cpu_quirks(void)
cur_cpu_spec->cpu_features |= CPU_FTR_POWER9_DD1;
else if ((version & 0xffffefff) == 0x004e0201)
cur_cpu_spec->cpu_features |= CPU_FTR_POWER9_DD2_1;
+
+ if ((version & 0xffff0000) == 0x004e0000)
+ cur_cpu_spec->cpu_features &= ~(CPU_FTR_DAWR);
}
static void __init cpufeatures_setup_finished(void)
--
2.14.1
^ permalink raw reply related
* [PATCH v3 8/8] powerpc: Disable DAWR in the base POWER9 CPU features
From: Michael Neuling @ 2018-03-27 4:37 UTC (permalink / raw)
To: mpe
Cc: linuxppc-dev, paulus, david, npiggin, pedromfc, kvm-ppc,
Ananth N Mavinakayanahalli
In-Reply-To: <20180327043724.13862-1-mikey@neuling.org>
Using the DAWR on POWER9 can cause xstops, hence we need to disable
it.
Signed-off-by: Michael Neuling <mikey@neuling.org>
---
arch/powerpc/include/asm/cputable.h | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/cputable.h b/arch/powerpc/include/asm/cputable.h
index a2c5c95882..79a206bcd4 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -463,9 +463,8 @@ static inline void cpu_feature_keys_init(void) { }
CPU_FTR_DSCR | CPU_FTR_SAO | \
CPU_FTR_STCX_CHECKS_ADDRESS | CPU_FTR_POPCNTB | CPU_FTR_POPCNTD | \
CPU_FTR_CFAR | CPU_FTR_HVMODE | CPU_FTR_VMX_COPY | \
- CPU_FTR_DBELL | CPU_FTR_HAS_PPR | CPU_FTR_DAWR | \
- CPU_FTR_ARCH_207S | CPU_FTR_TM_COMP | CPU_FTR_ARCH_300 | \
- CPU_FTR_PKEY)
+ CPU_FTR_DBELL | CPU_FTR_HAS_PPR | CPU_FTR_ARCH_207S | \
+ CPU_FTR_TM_COMP | CPU_FTR_ARCH_300 | CPU_FTR_PKEY)
#define CPU_FTRS_POWER9_DD1 ((CPU_FTRS_POWER9 | CPU_FTR_POWER9_DD1) & \
(~CPU_FTR_SAO))
#define CPU_FTRS_POWER9_DD2_0 CPU_FTRS_POWER9
--
2.14.1
^ permalink raw reply related
* Re: linux-next: manual merge of the powerpc tree with the powerpc-fixes tree
From: Michael Ellerman @ 2018-03-27 4:52 UTC (permalink / raw)
To: Stephen Rothwell, Benjamin Herrenschmidt, PowerPC
Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
Aneesh Kumar K.V, Paul Mackerras
In-Reply-To: <20180327101125.145e4dc5@canb.auug.org.au>
Stephen Rothwell <sfr@canb.auug.org.au> writes:
> Hi all,
>
> Today's linux-next merge of the powerpc tree got a conflict in:
>
> arch/powerpc/include/asm/cputable.h
> arch/powerpc/kernel/dt_cpu_ftrs.c
>
> between commit:
>
> a5d4b5891c2f ("powerpc/mm: Fixup tlbie vs store ordering issue on POWER9")
>
> from the powerpc-fixes tree and commits:
>
> 9bbf0b576d32 ("powerpc: Free up CPU feature bits on 64-bit machines")
> b5af4f279323 ("powerpc: Add CPU feature bits for TM bug workarounds on POWER9 v2.2")
>
> from the powerpc tree.
Thanks, yeah that was a bit of disaster.
I'll merge fixes into next before sending to Linus.
cheers
^ permalink raw reply
* Re: [RFC] new SYSCALL_DEFINE/COMPAT_SYSCALL_DEFINE wrappers
From: John Paul Adrian Glaubitz @ 2018-03-27 4:58 UTC (permalink / raw)
To: Linus Torvalds
Cc: Al Viro, Ingo Molnar, Dominik Brodowski,
Linux Kernel Mailing List, Arnd Bergmann, linux-arch,
Ralf Baechle, James Hogan, linux-mips, Benjamin Herrenschmidt,
Paul Mackerras, Michael Ellerman, ppc-dev, Martin Schwidefsky,
Heiko Carstens, linux-s390, David S . Miller, sparclinux,
Ingo Molnar, Jiri Slaby, the arch/x86 maintainers
In-Reply-To: <CA+55aFzHL1L_SEt_xqmJBfRRngTm4qbQGwxFvqSXw-MD2BiAOQ@mail.gmail.com>
On 03/27/2018 12:40 PM, Linus Torvalds wrote:
> On Mon, Mar 26, 2018 at 4:37 PM, John Paul Adrian Glaubitz
> <glaubitz@physik.fu-berlin.de> wrote:
>>
>> What about a tarball with a minimal Debian x32 chroot? Then you can
>> install interesting packages you would like to test yourself.
>
> That probably works fine.
I just created a fresh Debian x32 unstable chroot using this command:
$ debootstrap --no-check-gpg --variant=minbase --arch=x32 unstable debian-x32-unstable http://ftp.ports.debian.org/debian-ports
It can be downloaded from my Debian webspace along checksum files for
verification:
> https://people.debian.org/~glaubitz/chroots/
Let me know if you run into any issues.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
^ permalink raw reply
* Re: [PATCH script] hwmon: Use octal not symbolic permissions
From: Guenter Roeck @ 2018-03-27 6:33 UTC (permalink / raw)
To: Joe Perches, Jean Delvare
Cc: linux-hwmon, linux-kernel, linuxppc-dev, linux-arm-kernel,
patches
In-Reply-To: <1522096136.12357.21.camel@perches.com>
On 03/26/2018 01:28 PM, Joe Perches wrote:
> drivers/hwmon is the most frequent user of symbolic permissions
> like S_IRUGO in the kernel tree.
>
> $ git grep -w -P "S_[A-Z]{5,5}" | \
> cut -f1 -d: | cut -f1-2 -d"/" | sed -r 's/[A-Za-z0-9_-]+\.[ch]$//' | \
> sort | uniq -c | sort -rn | head
> 3862 drivers/hwmon
> 814 drivers/scsi
> 763 drivers/net
> 242 drivers/infiniband
> 184 drivers/staging
> 181 drivers/usb
> 158 fs/proc
> 150 fs/xfs
> 148 fs/
> 142 drivers/misc
>
> But using octal and not symbolic permissions is preferred by many
> as it can be more readable.
>
> https://lkml.org/lkml/2016/8/2/1945
>
> Rather than converting these piecemeal, perhaps just do them all
> at once via a trivial script like the below:
>
> $ git grep -w -P --name-only "S_[A-Z]{5,5}" drivers/hwmon | \
> xargs ./scripts/checkpatch.pl -f --types=symbolic_perms --fix-inplace
> $ git grep -w -P --name-only "S_[A-Z]{5,5}" drivers/hwmon | \
> xargs ./scripts/checkpatch.pl -f --types=symbolic_perms --fix-inplace
>
> It's run twice because checkpatch only does 1 conversion per line
> and there are some multiple instance lines.
>
> This currently results in a 669 KB patch which is too large
> to post but can be easily generated when appropriate.
I have something similar using coccinelle, which has the added benefit
of also adjusting multi-line alignments. But then I am hesitant to pull
it in because I don't really see the point. A more intelligent approach
would be to convert hwmon drivers to the latest API, and/or to introduce
more intelligent macros such as SENSOR_DEVICE_ATTR_{RO,RW,WO}. But that
would require active work as well as reviewers, and especially the latter
is extremely difficult if not impossible to find for the hwmon subsystem.
Since the hwmon subsystem has been labeled as both "obsolete" and "obscure",
that is maybe not entirely surprising, and I think we are good as we are.
I am happy to accept patches updating permissions as other changes are made
to a file, but I don't see a pressing need to change all files just to make
statistics happy (and backports more difficult).
Guenter
^ permalink raw reply
* Re: [PATCH script] hwmon: Use octal not symbolic permissions
From: Joe Perches @ 2018-03-27 6:52 UTC (permalink / raw)
To: Guenter Roeck, Jean Delvare
Cc: linux-hwmon, linux-kernel, linuxppc-dev, linux-arm-kernel,
patches
In-Reply-To: <9b112651-d0cf-5f3b-b643-3328028a95cd@roeck-us.net>
On Mon, 2018-03-26 at 23:33 -0700, Guenter Roeck wrote:
> On 03/26/2018 01:28 PM, Joe Perches wrote:
> > drivers/hwmon is the most frequent user of symbolic permissions
> > like S_IRUGO in the kernel tree.
[]
> I have something similar using coccinelle,
Please post the script.
I expect it doesn't work quite the same as checkpatch.
> which has the added benefit
> of also adjusting multi-line alignments.
That's a benefit, but it's makes it difficult to review.
I also have the same patch rewrap alignment post this
automated patch, done with emacs formatting.
This patch is somewhat simpler to review which is why
it's not sent along with this script.
> But then I am hesitant to pull
> it in because I don't really see the point. A more intelligent approach
> would be to convert hwmon drivers to the latest API, and/or to introduce
> more intelligent macros such as SENSOR_DEVICE_ATTR_{RO,RW,WO}.
Another approach would be to separate the const bits
from the non-const bits to reduce data.
> But that
> would require active work as well as reviewers, and especially the latter
> is extremely difficult if not impossible to find for the hwmon subsystem.
[]
> Since the hwmon subsystem has been labeled as both "obsolete" and "obscure",
> that is maybe not entirely surprising, and I think we are good as we are.
Maybe true.
> I am happy to accept patches updating permissions as other changes are made
> to a file, but I don't see a pressing need to change all files just to make
> statistics happy (and backports more difficult).
Not sure backports are a real issue.
If it were a real issue, the updated permissions are noise
and shouldn't be accepted for the other changes.
^ permalink raw reply
* Re: [PATCH v3 3/6] powerpc/kexec: Disable ftrace before switching to the new kernel
From: Naveen N. Rao @ 2018-03-27 6:53 UTC (permalink / raw)
To: Michael Ellerman, Paul Mackerras, Steven Rostedt
Cc: Anton Blanchard, linuxppc-dev, Nicholas Piggin, sathnaga
In-Reply-To: <874ll2lb7i.fsf@concordia.ellerman.id.au>
Michael Ellerman wrote:
> Michael Ellerman <mpe@ellerman.id.au> writes:
>=20
>> "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com> writes:
>>> If function_graph tracer is enabled during kexec, we see the below
>>> exception in the simulator:
>>> root@(none):/# kexec -e
>>> kvm: exiting hardware virtualization
>>> kexec_core: Starting new kernel
>>> [ 19.262020070,5] OPAL: Switch to big-endian OS
>>> kexec: Starting switchover sequence.
>>> Interrupt to 0xC000000000004380 from 0xC000000000004380
>>> ** Execution stopped: Continuous Interrupt, Instruction caused excepti=
on, **
>>>
>>> Now that we have a more effective way to disable ftrace, let's use that
>>> before switching to a new kernel during kexec.
>>>
>>> Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
>>> ---
>>> arch/powerpc/kernel/machine_kexec.c | 6 ++----
>>> 1 file changed, 2 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/arch/powerpc/kernel/machine_kexec.c b/arch/powerpc/kernel/=
machine_kexec.c
>>> index 2694d078741d..4a1b24a9dd61 100644
>>> --- a/arch/powerpc/kernel/machine_kexec.c
>>> +++ b/arch/powerpc/kernel/machine_kexec.c
>>> @@ -95,16 +95,14 @@ void arch_crash_save_vmcoreinfo(void)
>>> */
>>> void machine_kexec(struct kimage *image)
>>> {
>>> - int save_ftrace_enabled;
>>> -
>>> - save_ftrace_enabled =3D __ftrace_enabled_save();
>>> + get_paca()->ftrace_disabled =3D 1;
>>
>> This doesn't compile on 32-bit:
>>
>> Failed: powerpc-next/corenet32_smp_defconfig/powerpc-5.3 (http://kiss=
kb.ozlabs.ibm.com/kisskb/buildresult/13314085/log/)
>> /kisskb/src/arch/powerpc/kernel/machine_kexec.c:105:12: error: inval=
id type argument of '->' (have 'int')
>> /kisskb/src/arch/powerpc/kernel/machine_kexec.c:98:12: error: invali=
d type argument of '->' (have 'int')
>> /kisskb/src/arch/powerpc/kernel/machine_kexec.c:98:2: error: implici=
t declaration of function 'get_paca' [-Werror=3Dimplicit-function-declarati=
on]
Hmm... pmac32_defconfig built fine for me, so I thought we are ok there.
>>
>>
>> A wrapper is probably best that does nothing on 32-bit.
>=20
> Actually it should probably do __ftrace_enabled_save() etc. on 32-bit,
> like the existing code does.
Agree. In hindsight, I'm not updating ftrace_32.S, so I think I will=20
gate this with CONFIG_PPC64.
Thanks,
Naveen
=
^ permalink raw reply
* Re: [RFC PATCH] powerpc/xmon: Use OPAL_DEBUG to debug srest in OPAL
From: Vasant Hegde @ 2018-03-27 7:12 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev
Cc: Stewart Smith, Ananth N Mavinakayanahalli,
Mahesh Jagannath Salgaonkar
In-Reply-To: <20180326150946.23555-1-npiggin@gmail.com>
On 03/26/2018 08:39 PM, Nicholas Piggin wrote:
> xmon can be entered via sreset NMI (from a management sreset, or an
> NMI IPI), which can interrupt OPAL. Add checks to xmon to see if pc
> or sp are within OPAL memory, and if so, then use OPAL_DEBUG to
> print the opal stack and return the Linux stack, which can then be
> dumped by xmon
Nick,
OPAL uses FSP/cronus interface for many of debug interface (like OPAL assert,
getting opal console, triggering FSP R/R etc). May be in future we may add new
debug capability.
Once secureboot is enabled none of these interface work and we have limited debug
capability.
Here you are using very generic API name (OPAL_DEBUG). May be we should have generic
interface (exported via debugfs?) here rather than SRESET specific one.
-Vasant
>
> The OPAL side of this, with sample xmon output is here:
>
> https://lists.ozlabs.org/pipermail/skiboot/2018-March/010856.html
>
> This could be plumed into the oops printing code as well.
>
> Thanks,
> Nick
> ---
> arch/powerpc/include/asm/opal.h | 4 ++++
> arch/powerpc/platforms/powernv/opal-wrappers.S | 1 +
> arch/powerpc/platforms/powernv/opal.c | 5 +++++
> arch/powerpc/xmon/xmon.c | 27 ++++++++++++++++++++++++++
> 4 files changed, 37 insertions(+)
>
> diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
> index 12e70fb58700..afcc0c5ed5b0 100644
> --- a/arch/powerpc/include/asm/opal.h
> +++ b/arch/powerpc/include/asm/opal.h
> @@ -27,6 +27,8 @@ extern struct kobject *opal_kobj;
> /* /ibm,opal */
> extern struct device_node *opal_node;
>
> +bool in_opal_text_heap_stack(u64 address);
> +
> /* API functions */
> int64_t opal_invalid_call(void);
> int64_t opal_npu_destroy_context(uint64_t phb_id, uint64_t pid, uint64_t bdf);
> @@ -289,6 +291,8 @@ int opal_sensor_group_clear(u32 group_hndl, int token);
>
> s64 opal_signal_system_reset(s32 cpu);
>
> +s64 opal_debug(u32 debug_type, u64 r1);
> +
> /* Internal functions */
> extern int early_init_dt_scan_opal(unsigned long node, const char *uname,
> int depth, void *data);
> diff --git a/arch/powerpc/platforms/powernv/opal-wrappers.S b/arch/powerpc/platforms/powernv/opal-wrappers.S
> index 1b2936ba6040..78b9ae003553 100644
> --- a/arch/powerpc/platforms/powernv/opal-wrappers.S
> +++ b/arch/powerpc/platforms/powernv/opal-wrappers.S
> @@ -323,3 +323,4 @@ OPAL_CALL(opal_sensor_group_clear, OPAL_SENSOR_GROUP_CLEAR);
> OPAL_CALL(opal_npu_spa_setup, OPAL_NPU_SPA_SETUP);
> OPAL_CALL(opal_npu_spa_clear_cache, OPAL_NPU_SPA_CLEAR_CACHE);
> OPAL_CALL(opal_npu_tl_set, OPAL_NPU_TL_SET);
> +OPAL_CALL(opal_debug, 167);
> diff --git a/arch/powerpc/platforms/powernv/opal.c b/arch/powerpc/platforms/powernv/opal.c
> index c15182765ff5..0b7ff5fb18f8 100644
> --- a/arch/powerpc/platforms/powernv/opal.c
> +++ b/arch/powerpc/platforms/powernv/opal.c
> @@ -64,6 +64,11 @@ static struct atomic_notifier_head opal_msg_notifier_head[OPAL_MSG_TYPE_MAX];
> static uint32_t opal_heartbeat;
> static struct task_struct *kopald_tsk;
>
> +bool in_opal_text_heap_stack(u64 address)
> +{
> + return (address >= opal.base && address < opal.base + opal.size);
> +}
> +
> void opal_configure_cores(void)
> {
> u64 reinit_flags = 0;
> diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
> index 82e1a3ee6e0f..ade1adcc1ab8 100644
> --- a/arch/powerpc/xmon/xmon.c
> +++ b/arch/powerpc/xmon/xmon.c
> @@ -452,6 +452,15 @@ static inline int unrecoverable_excp(struct pt_regs *regs)
> #endif
> }
>
> +static bool in_opal(unsigned long addr)
> +{
> + if (firmware_has_feature(FW_FEATURE_OPAL))
> + if (in_opal_text_heap_stack(addr))
> + return true;
> +
> + return false;
> +}
> +
> static int xmon_core(struct pt_regs *regs, int fromipi)
> {
> int cmd = 0;
> @@ -510,6 +519,9 @@ static int xmon_core(struct pt_regs *regs, int fromipi)
>
> xmon_fault_jmp[cpu] = recurse_jmp;
>
> + if (in_opal(regs->nip))
> + printf("xmon: cpu 0x%x stopped in OPAL!\n", cpu);
> +
> bp = NULL;
> if ((regs->msr & (MSR_IR|MSR_PR|MSR_64BIT)) == (MSR_IR|MSR_64BIT))
> bp = at_breakpoint(regs->nip);
> @@ -1484,8 +1496,23 @@ static void xmon_show_stack(unsigned long sp, unsigned long lr,
> unsigned long marker;
> struct pt_regs regs;
>
> + if (in_opal(sp)) {
> + struct debug_struct {
> + unsigned long nip;
> + unsigned long r1;
> + unsigned long r1_caller;
> + } db;
> + printf("SP is in OPAL, calling OPAL to dump stack\n");
> + db.nip = cpu_to_be64(pc);
> + db.r1 = cpu_to_be64(sp);
> + opal_debug(1, (unsigned long)&db);
> + sp = be64_to_cpu(db.r1_caller);
> + }
> +
> while (max_to_print--) {
> if (!is_kernel_addr(sp)) {
> + if (in_opal(pc) && in_opal(sp))
> + printf("SP (%lx) is in OPAL\n", sp);
> if (sp != 0)
> printf("SP (%lx) is in userspace\n", sp);
> break;
>
^ permalink raw reply
* Re: [PATCH] powerpc/powernv/nvram: opal_nvram_write handle unknown OPAL errors
From: Vasant Hegde @ 2018-03-27 7:17 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev
In-Reply-To: <20180326150233.23089-1-npiggin@gmail.com>
On 03/26/2018 08:32 PM, Nicholas Piggin wrote:
> opal_nvram_write currently just assumes success if it encounters an
> error other than OPAL_BUSY or OPAL_BUSY_EVENT. Have it return -EIO
> on other errors instead.
>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
> ---
> arch/powerpc/platforms/powernv/opal-nvram.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/powerpc/platforms/powernv/opal-nvram.c b/arch/powerpc/platforms/powernv/opal-nvram.c
> index 9db4398ded5d..13bf625dc3e8 100644
> --- a/arch/powerpc/platforms/powernv/opal-nvram.c
> +++ b/arch/powerpc/platforms/powernv/opal-nvram.c
> @@ -59,6 +59,8 @@ static ssize_t opal_nvram_write(char *buf, size_t count, loff_t *index)
> if (rc == OPAL_BUSY_EVENT)
> opal_poll_events(NULL);
Current code does continuous poller here. May be we have small breathing time
here. What you say?
> }
> + if (rc)
> + return -EIO;
Good catch. Thanks!
Reviewed-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
-Vasant
^ permalink raw reply
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
From: Michal Hocko @ 2018-03-27 7:24 UTC (permalink / raw)
To: Ilya Smith
Cc: Matthew Wilcox, rth, ink, mattst88, vgupta, linux, tony.luck,
fenghua.yu, ralf, jejb, Helge Deller, benh, paulus, mpe,
schwidefsky, heiko.carstens, ysato, dalias, davem, tglx, mingo,
hpa, x86, nyc, viro, arnd, gregkh, deepa.kernel, Hugh Dickins,
kstewart, pombredanne, Andrew Morton, steve.capper, punit.agrawal,
aneesh.kumar, npiggin, Kees Cook, bhsharma, riel, nitin.m.gupta,
Kirill A. Shutemov, Dan Williams, Jan Kara, ross.zwisler,
Jerome Glisse, Andrea Arcangeli, Oleg Nesterov, linux-alpha, LKML,
linux-snps-arc, linux-ia64, linux-metag, linux-mips, linux-parisc,
linuxppc-dev, linux-s390, linux-sh, sparclinux, Linux-MM
In-Reply-To: <01A133F4-27DF-4AE2-80D6-B0368BF758CD@gmail.com>
On Mon 26-03-18 22:45:31, Ilya Smith wrote:
>
> > On 26 Mar 2018, at 11:46, Michal Hocko <mhocko@kernel.org> wrote:
> >
> > On Fri 23-03-18 20:55:49, Ilya Smith wrote:
> >>
> >>> On 23 Mar 2018, at 15:48, Matthew Wilcox <willy@infradead.org> wrote:
> >>>
> >>> On Thu, Mar 22, 2018 at 07:36:36PM +0300, Ilya Smith wrote:
> >>>> Current implementation doesn't randomize address returned by mmap.
> >>>> All the entropy ends with choosing mmap_base_addr at the process
> >>>> creation. After that mmap build very predictable layout of address
> >>>> space. It allows to bypass ASLR in many cases. This patch make
> >>>> randomization of address on any mmap call.
> >>>
> >>> Why should this be done in the kernel rather than libc? libc is perfectly
> >>> capable of specifying random numbers in the first argument of mmap.
> >> Well, there is following reasons:
> >> 1. It should be done in any libc implementation, what is not possible IMO;
> >
> > Is this really so helpful?
>
> Yes, ASLR is one of very important mitigation techniques which are really used
> to protect applications. If there is no ASLR, it is very easy to exploit
> vulnerable application and compromise the system. We can’t just fix all the
> vulnerabilities right now, thats why we have mitigations - techniques which are
> makes exploitation more hard or impossible in some cases.
>
> Thats why it is helpful.
I am not questioning ASLR in general. I am asking whether we really need
per mmap ASLR in general. I can imagine that some environments want to
pay the additional price and other side effects, but considering this
can be achieved by libc, why to add more code to the kernel?
> >
> >> 2. User mode is not that layer which should be responsible for choosing
> >> random address or handling entropy;
> >
> > Why?
>
> Because of the following reasons:
> 1. To get random address you should have entropy. These entropy shouldn’t be
> exposed to attacker anyhow, the best case is to get it from kernel. So this is
> a syscall.
/dev/[u]random is not sufficient?
> 2. You should have memory map of your process to prevent remapping or big
> fragmentation. Kernel already has this map.
/proc/self/maps?
> You will got another one in libc.
> And any non-libc user of mmap (via syscall, etc) will make hole in your map.
> This one also decrease performance cause you any way call syscall_mmap
> which will try to find some address for you in worst case, but after you already
> did some computing on it.
I do not understand. a) you should be prepared to pay an additional
price for an additional security measures and b) how would anybody punch
a hole into your mapping?
> 3. The more memory you use in userland for these proposal, the easier for
> attacker to leak it or use in exploitation techniques.
This is true in general, isn't it? I fail to see how kernel chosen and
user chosen ranges would make any difference.
> 4. It is so easy to fix Kernel function and so hard to support memory
> management from userspace.
Well, on the other hand the new layout mode will add a maintenance
burden on the kernel and will have to be maintained for ever because it
is a user visible ABI.
> >> 3. Memory fragmentation is unpredictable in this case
> >>
> >> Off course user mode could use random ‘hint’ address, but kernel may
> >> discard this address if it is occupied for example and allocate just before
> >> closest vma. So this solution doesn’t give that much security like
> >> randomization address inside kernel.
> >
> > The userspace can use the new MAP_FIXED_NOREPLACE to probe for the
> > address range atomically and chose a different range on failure.
> >
>
> This algorithm should track current memory. If he doesn’t he may cause
> infinite loop while trying to choose memory. And each iteration increase time
> needed on allocation new memory, what is not preferred by any libc library
> developer.
Well, I am pretty sure userspace can implement proper free ranges
tracking...
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* Re: [RFC PATCH] powerpc/xmon: Use OPAL_DEBUG to debug srest in OPAL
From: Nicholas Piggin @ 2018-03-27 7:28 UTC (permalink / raw)
To: Vasant Hegde
Cc: linuxppc-dev, Stewart Smith, Mahesh Jagannath Salgaonkar,
Ananth N Mavinakayanahalli
In-Reply-To: <25588979-81cd-2a63-59f8-728686855117@linux.vnet.ibm.com>
On Tue, 27 Mar 2018 12:42:32 +0530
Vasant Hegde <hegdevasant@linux.vnet.ibm.com> wrote:
> On 03/26/2018 08:39 PM, Nicholas Piggin wrote:
> > xmon can be entered via sreset NMI (from a management sreset, or an
> > NMI IPI), which can interrupt OPAL. Add checks to xmon to see if pc
> > or sp are within OPAL memory, and if so, then use OPAL_DEBUG to
> > print the opal stack and return the Linux stack, which can then be
> > dumped by xmon
>
> Nick,
>
>
> OPAL uses FSP/cronus interface for many of debug interface (like OPAL assert,
> getting opal console, triggering FSP R/R etc). May be in future we may add new
> debug capability.
It would be good to ensure an API could accommodate them, or at least
not get in the way.
> Once secureboot is enabled none of these interface work and we have limited debug
> capability.
>
> Here you are using very generic API name (OPAL_DEBUG). May be we should have generic
> interface (exported via debugfs?) here rather than SRESET specific one.
OPAL_DEBUG here actually uses the sub-function OPAL_DEBUG_DUMP_STACK (1),
but I didn't bring that constant across from skiboot which I should have.
But I don't think this is SRESET specific. If Linux has any way to get
an r1 for a CPU in OPAL, then it can use this function. If it does not,
then it simply can't use it.
I haven't really followed what's happening with secure boot, but presumably
we can still get NMIs (at least machine check, even if all system reset
sources are suppressed).
> >
> > The OPAL side of this, with sample xmon output is here:
> >
> > https://lists.ozlabs.org/pipermail/skiboot/2018-March/010856.html
> >
> > This could be plumed into the oops printing code as well.
Thanks,
Nick
^ permalink raw reply
* Re: [PATCH script] hwmon: Use octal not symbolic permissions
From: Joe Perches @ 2018-03-27 7:35 UTC (permalink / raw)
To: Guenter Roeck, Jean Delvare
Cc: linux-hwmon, linux-kernel, linuxppc-dev, linux-arm-kernel,
patches
In-Reply-To: <9b112651-d0cf-5f3b-b643-3328028a95cd@roeck-us.net>
On Mon, 2018-03-26 at 23:33 -0700, Guenter Roeck wrote:
> Since the hwmon subsystem has been labeled as both "obsolete" and "obscure",
fyi: It's marked Maintained in MAINTAINERS
HARDWARE MONITORING
M: Jean Delvare <jdelvare@suse.com>
M: Guenter Roeck <linux@roeck-us.net>
L: linux-hwmon@vger.kernel.org
W: http://hwmon.wiki.kernel.org/
T: git git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git
S: Maintained
F: Documentation/hwmon/
F: drivers/hwmon/
F: include/linux/hwmon*.h
^ permalink raw reply
* Re: [PATCH] powerpc/powernv/nvram: opal_nvram_write handle unknown OPAL errors
From: Nicholas Piggin @ 2018-03-27 7:38 UTC (permalink / raw)
To: Vasant Hegde; +Cc: linuxppc-dev, skiboot
In-Reply-To: <ad352964-1b12-8556-a876-a10e84336a5e@linux.vnet.ibm.com>
On Tue, 27 Mar 2018 12:47:31 +0530
Vasant Hegde <hegdevasant@linux.vnet.ibm.com> wrote:
> On 03/26/2018 08:32 PM, Nicholas Piggin wrote:
> > opal_nvram_write currently just assumes success if it encounters an
> > error other than OPAL_BUSY or OPAL_BUSY_EVENT. Have it return -EIO
> > on other errors instead.
> >
> > Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
> > ---
> > arch/powerpc/platforms/powernv/opal-nvram.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/arch/powerpc/platforms/powernv/opal-nvram.c b/arch/powerpc/platforms/powernv/opal-nvram.c
> > index 9db4398ded5d..13bf625dc3e8 100644
> > --- a/arch/powerpc/platforms/powernv/opal-nvram.c
> > +++ b/arch/powerpc/platforms/powernv/opal-nvram.c
> > @@ -59,6 +59,8 @@ static ssize_t opal_nvram_write(char *buf, size_t count, loff_t *index)
> > if (rc == OPAL_BUSY_EVENT)
> > opal_poll_events(NULL);
>
> Current code does continuous poller here. May be we have small breathing time
> here. What you say?
Yeah that's probably not a bad idea. I cc'ed skiboot list -- what's a
reasonable delay between retries? Linux has a bunch of similar kind of
loops if you grep for opal_poll_events and OPAL_BUSY. It would be good
to convert them all to a standard form with a standard delay as
recommended by OPAL, and where specific calls have different delay
for a good reason, that would be documented in the OPAL API docs.
Thanks,
Nick
^ permalink raw reply
* Re: RFC on writel and writel_relaxed
From: Arnd Bergmann @ 2018-03-27 7:56 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Benjamin Herrenschmidt, Sinan Kaya, David Laight, Oliver,
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
linux-rdma@vger.kernel.org, Alexander Duyck, Will Deacon,
Paul E. McKenney
In-Reply-To: <20180326222756.GJ15554@ziepe.ca>
On Tue, Mar 27, 2018 at 12:27 AM, Jason Gunthorpe <jgg@ziepe.ca> wrote:
> On Tue, Mar 27, 2018 at 09:01:57AM +1100, Benjamin Herrenschmidt wrote:
>> On Mon, 2018-03-26 at 17:46 -0400, Sinan Kaya wrote:
>
> I even see patches adding wmb() based on actual observed memory
> corruption during testing on Intel:
>
> https://patchwork.kernel.org/patch/10177207/
>
> So you think all of this is unnecessary and writel is totally strongly
> ordered, even on multi-socket Intel?
This example adds a wmb() between two writes to a coherent DMA
area, it is definitely required there. I'm pretty sure I've never seen
any bug reports pointing to a missing wmb() between memory
and MMIO write accesses, but if you remember seeing them in the
list, maybe you can look again for some evidence of something going
wrong on x86 without it?
Arnd
^ permalink raw reply
* [bug report] powerpc/4xx: Adding PCIe MSI support
From: Dan Carpenter @ 2018-03-27 8:37 UTC (permalink / raw)
To: rsarmah; +Cc: linuxppc-dev
[ This is really really ancient code. - dan ]
Hello Rupjyoti Sarmah,
The patch 3fb7933850fa: "powerpc/4xx: Adding PCIe MSI support" from
Mar 29, 2011, leads to the following static checker warning:
arch/powerpc/platforms/4xx/msi.c:100 ppc4xx_setup_msi_irqs()
warn: 'int_no >= 0' 'false' implies 'int_no < 0' is 'true'
arch/powerpc/platforms/4xx/msi.c
79 static int ppc4xx_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
80 {
81 int int_no = -ENOMEM;
82 unsigned int virq;
83 struct msi_msg msg;
84 struct msi_desc *entry;
85 struct ppc4xx_msi *msi_data = &ppc4xx_msi;
86
87 dev_dbg(&dev->dev, "PCIE-MSI:%s called. vec %x type %d\n",
88 __func__, nvec, type);
89 if (type == PCI_CAP_ID_MSIX)
90 pr_debug("ppc4xx msi: MSI-X untested, trying anyway.\n");
91
92 msi_data->msi_virqs = kmalloc((msi_irqs) * sizeof(int), GFP_KERNEL);
93 if (!msi_data->msi_virqs)
94 return -ENOMEM;
95
96 for_each_pci_msi_entry(entry, dev) {
97 int_no = msi_bitmap_alloc_hwirqs(&msi_data->bitmap, 1);
98 if (int_no >= 0)
^^^^^^^^^^^
99 break;
100 if (int_no < 0) {
^^^^^^^^^^
Smatch is saying that this check could be removed, which is true.
101 pr_debug("%s: fail allocating msi interrupt\n",
102 __func__);
103 }
104 virq = irq_of_parse_and_map(msi_data->msi_dev, int_no);
^^^^^^
It doesn't seem right to pass negative indexes to irq_of_parse_and_map().
It could result in a read before the start of the array in
of_irq_parse_oldworld(), I think.
105 if (!virq) {
106 dev_err(&dev->dev, "%s: fail mapping irq\n", __func__);
107 msi_bitmap_free_hwirqs(&msi_data->bitmap, int_no, 1);
108 return -ENOSPC;
109 }
110 dev_dbg(&dev->dev, "%s: virq = %d\n", __func__, virq);
111
112 /* Setup msi address space */
113 msg.address_hi = msi_data->msi_addr_hi;
114 msg.address_lo = msi_data->msi_addr_lo;
115
116 irq_set_msi_desc(virq, entry);
117 msg.data = int_no;
118 pci_write_msi_msg(virq, &msg);
119 }
120 return 0;
121 }
regards,
dan carpenter
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox