* [PATCH v3 RESEND 1/3] powerpc/pseries: Parse control memory access error
From: Ganesh Goudar @ 2022-01-07 14:14 UTC (permalink / raw)
To: linuxppc-dev, mpe; +Cc: Ganesh Goudar, mahesh, npiggin, dja
Add support to parse and log control memory access
error for pseries. These changes are made according to
PAPR v2.11 10.3.2.2.12.
Signed-off-by: Ganesh Goudar <ganeshgr@linux.ibm.com>
---
arch/powerpc/platforms/pseries/ras.c | 36 ++++++++++++++++++++++++----
1 file changed, 32 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/ras.c b/arch/powerpc/platforms/pseries/ras.c
index 56092dccfdb8..e62a0ca2611a 100644
--- a/arch/powerpc/platforms/pseries/ras.c
+++ b/arch/powerpc/platforms/pseries/ras.c
@@ -60,11 +60,17 @@ struct pseries_mc_errorlog {
* XX 2: Reserved.
* XXX 3: Type of UE error.
*
- * For error_type != MC_ERROR_TYPE_UE
+ * For error_type == MC_ERROR_TYPE_SLB/ERAT/TLB
* XXXXXXXX
* X 1: Effective address provided.
* XXXXX 5: Reserved.
* XX 2: Type of SLB/ERAT/TLB error.
+ *
+ * For error_type == MC_ERROR_TYPE_CTRL_MEM_ACCESS
+ * XXXXXXXX
+ * X 1: Error causing address provided.
+ * XXX 3: Type of error.
+ * XXXX 4: Reserved.
*/
u8 sub_err_type;
u8 reserved_1[6];
@@ -80,6 +86,7 @@ struct pseries_mc_errorlog {
#define MC_ERROR_TYPE_TLB 0x04
#define MC_ERROR_TYPE_D_CACHE 0x05
#define MC_ERROR_TYPE_I_CACHE 0x07
+#define MC_ERROR_TYPE_CTRL_MEM_ACCESS 0x08
/* RTAS pseries MCE error sub types */
#define MC_ERROR_UE_INDETERMINATE 0
@@ -90,6 +97,7 @@ struct pseries_mc_errorlog {
#define UE_EFFECTIVE_ADDR_PROVIDED 0x40
#define UE_LOGICAL_ADDR_PROVIDED 0x20
+#define MC_EFFECTIVE_ADDR_PROVIDED 0x80
#define MC_ERROR_SLB_PARITY 0
#define MC_ERROR_SLB_MULTIHIT 1
@@ -103,6 +111,9 @@ struct pseries_mc_errorlog {
#define MC_ERROR_TLB_MULTIHIT 2
#define MC_ERROR_TLB_INDETERMINATE 3
+#define MC_ERROR_CTRL_MEM_ACCESS_PTABLE_WALK 0
+#define MC_ERROR_CTRL_MEM_ACCESS_OP_ACCESS 1
+
static inline u8 rtas_mc_error_sub_type(const struct pseries_mc_errorlog *mlog)
{
switch (mlog->error_type) {
@@ -112,6 +123,8 @@ static inline u8 rtas_mc_error_sub_type(const struct pseries_mc_errorlog *mlog)
case MC_ERROR_TYPE_ERAT:
case MC_ERROR_TYPE_TLB:
return (mlog->sub_err_type & 0x03);
+ case MC_ERROR_TYPE_CTRL_MEM_ACCESS:
+ return (mlog->sub_err_type & 0x70) >> 4;
default:
return 0;
}
@@ -656,7 +669,7 @@ static int mce_handle_err_virtmode(struct pt_regs *regs,
mce_err.u.slb_error_type = MCE_SLB_ERROR_INDETERMINATE;
break;
}
- if (mce_log->sub_err_type & 0x80)
+ if (mce_log->sub_err_type & MC_EFFECTIVE_ADDR_PROVIDED)
eaddr = be64_to_cpu(mce_log->effective_address);
break;
case MC_ERROR_TYPE_ERAT:
@@ -673,7 +686,7 @@ static int mce_handle_err_virtmode(struct pt_regs *regs,
mce_err.u.erat_error_type = MCE_ERAT_ERROR_INDETERMINATE;
break;
}
- if (mce_log->sub_err_type & 0x80)
+ if (mce_log->sub_err_type & MC_EFFECTIVE_ADDR_PROVIDED)
eaddr = be64_to_cpu(mce_log->effective_address);
break;
case MC_ERROR_TYPE_TLB:
@@ -690,7 +703,7 @@ static int mce_handle_err_virtmode(struct pt_regs *regs,
mce_err.u.tlb_error_type = MCE_TLB_ERROR_INDETERMINATE;
break;
}
- if (mce_log->sub_err_type & 0x80)
+ if (mce_log->sub_err_type & MC_EFFECTIVE_ADDR_PROVIDED)
eaddr = be64_to_cpu(mce_log->effective_address);
break;
case MC_ERROR_TYPE_D_CACHE:
@@ -699,6 +712,21 @@ static int mce_handle_err_virtmode(struct pt_regs *regs,
case MC_ERROR_TYPE_I_CACHE:
mce_err.error_type = MCE_ERROR_TYPE_ICACHE;
break;
+ case MC_ERROR_TYPE_CTRL_MEM_ACCESS:
+ mce_err.error_type = MCE_ERROR_TYPE_RA;
+ switch (err_sub_type) {
+ case MC_ERROR_CTRL_MEM_ACCESS_PTABLE_WALK:
+ mce_err.u.ra_error_type =
+ MCE_RA_ERROR_PAGE_TABLE_WALK_LOAD_STORE_FOREIGN;
+ break;
+ case MC_ERROR_CTRL_MEM_ACCESS_OP_ACCESS:
+ mce_err.u.ra_error_type =
+ MCE_RA_ERROR_LOAD_STORE_FOREIGN;
+ break;
+ }
+ if (mce_log->sub_err_type & MC_EFFECTIVE_ADDR_PROVIDED)
+ eaddr = be64_to_cpu(mce_log->effective_address);
+ break;
case MC_ERROR_TYPE_UNKNOWN:
default:
mce_err.error_type = MCE_ERROR_TYPE_UNKNOWN;
--
2.31.1
^ permalink raw reply related
* [PATCH v3 RESEND 3/3] powerpc/mce: Modify the real address error logging messages
From: Ganesh Goudar @ 2022-01-07 14:14 UTC (permalink / raw)
To: linuxppc-dev, mpe; +Cc: Ganesh Goudar, mahesh, npiggin, dja
In-Reply-To: <20220107141428.67862-1-ganeshgr@linux.ibm.com>
To avoid ambiguity, modify the strings in real address error
logging messages to "foreign/control memory" from "foreign",
Since the error discriptions in P9 user manual and P10 user
manual are different for same type of errors.
P9 User Manual for MCE:
DSISR:59 Host real address to foreign space during translation.
DSISR:60 Host real address to foreign space on a load or store
access.
P10 User Manual for MCE:
DSISR:59 D-side tablewalk used a host real address in the
control memory address range.
DSISR:60 D-side operand access to control memory address space.
Signed-off-by: Ganesh Goudar <ganeshgr@linux.ibm.com>
---
arch/powerpc/kernel/mce.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/kernel/mce.c b/arch/powerpc/kernel/mce.c
index fd829f7f25a4..55ccc651d1b0 100644
--- a/arch/powerpc/kernel/mce.c
+++ b/arch/powerpc/kernel/mce.c
@@ -401,14 +401,14 @@ void machine_check_print_event_info(struct machine_check_event *evt,
static const char *mc_ra_types[] = {
"Indeterminate",
"Instruction fetch (bad)",
- "Instruction fetch (foreign)",
+ "Instruction fetch (foreign/control memory)",
"Page table walk ifetch (bad)",
- "Page table walk ifetch (foreign)",
+ "Page table walk ifetch (foreign/control memory)",
"Load (bad)",
"Store (bad)",
"Page table walk Load/Store (bad)",
- "Page table walk Load/Store (foreign)",
- "Load/Store (foreign)",
+ "Page table walk Load/Store (foreign/control memory)",
+ "Load/Store (foreign/control memory)",
};
static const char *mc_link_types[] = {
"Indeterminate",
--
2.31.1
^ permalink raw reply related
* Re: [PATCH 1/3] powerpc64/bpf: Store temp registers' bpf to ppc mapping
From: Naveen N. Rao @ 2022-01-07 17:13 UTC (permalink / raw)
To: Jordan Niethe, linuxppc-dev
In-Reply-To: <20210727065539.299598-1-jniethe5@gmail.com>
Jordan Niethe wrote:
> In bpf_jit_build_body(), the mapping of TMP_REG_1 and TMP_REG_2's bpf
> register to ppc register is evalulated at every use despite not
> changing. Instead, determine the ppc register once and store the result.
> This will be more useful when a later patch introduces a more complex
> mapping from bpf registers to ppc registers.
>
> Signed-off-by: Jordan Niethe <jniethe5@gmail.com>
> ---
> arch/powerpc/net/bpf_jit_comp64.c | 163 +++++++++++++-----------------
> 1 file changed, 69 insertions(+), 94 deletions(-)
I know this is eons ago and this patch will need updating, but if you
intend to revive this:
Acked-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Thanks,
Naveen
^ permalink raw reply
* Re: [PATCH 2/3] powerpc/bpf: Use helper for mapping bpf to ppc registers on PPC64
From: Naveen N. Rao @ 2022-01-07 17:25 UTC (permalink / raw)
To: Jordan Niethe, linuxppc-dev
In-Reply-To: <20210727065539.299598-2-jniethe5@gmail.com>
Jordan Niethe wrote:
> Prepare for doing commit 40272035e1d0 ("powerpc/bpf: Reallocate BPF
> registers to volatile registers when possible on PPC32") on PPC64 in a
> later patch. Instead of directly accessing the const b2p[] array for
> mapping bpf to ppc registers use bpf_to_ppc() which allows per struct
> codegen_context mappings.
>
> Signed-off-by: Jordan Niethe <jniethe5@gmail.com>
> ---
> arch/powerpc/net/bpf_jit.h | 5 ++
> arch/powerpc/net/bpf_jit64.h | 30 +++++-----
> arch/powerpc/net/bpf_jit_comp32.c | 5 --
> arch/powerpc/net/bpf_jit_comp64.c | 96 ++++++++++++++++---------------
> 4 files changed, 71 insertions(+), 65 deletions(-)
>
> diff --git a/arch/powerpc/net/bpf_jit.h b/arch/powerpc/net/bpf_jit.h
> index 99fad093f43e..db86fa37f1dd 100644
> --- a/arch/powerpc/net/bpf_jit.h
> +++ b/arch/powerpc/net/bpf_jit.h
> @@ -172,6 +172,11 @@ void bpf_jit_build_prologue(u32 *image, struct codegen_context *ctx);
> void bpf_jit_build_epilogue(u32 *image, struct codegen_context *ctx);
> void bpf_jit_realloc_regs(struct codegen_context *ctx);
>
> +static inline int bpf_to_ppc(struct codegen_context *ctx, int reg)
> +{
> + return ctx->b2p[reg];
> +}
> +
> #endif
You are following what has been done on ppc32 here, but since ctx is
almost always available where b2p[] is used, I'm thinking it might be
simpler to convert it into a macro:
#define b2p(i) ctx->cb2p[i]
We will just need to rename the global b2p array, as well as the one in
codegen_context. Everywhere else, it will be a simple b2p[] -> b2p()
change.
- Naveen
^ permalink raw reply
* Re: [PATCH 3/3] powerpc/bpf: Reallocate BPF registers to volatile registers when possible on PPC64
From: Naveen N. Rao @ 2022-01-07 17:58 UTC (permalink / raw)
To: Christophe Leroy, Jordan Niethe, linuxppc-dev
In-Reply-To: <0c70202c-54f7-78e7-0091-0dfa8e6ab207@csgroup.eu>
Christophe Leroy wrote:
>
>
> Le 27/07/2021 à 08:55, Jordan Niethe a écrit :
>> Implement commit 40272035e1d0 ("powerpc/bpf: Reallocate BPF registers to
>> volatile registers when possible on PPC32") for PPC64.
>>
>> When the BPF routine doesn't call any function, the non volatile
>> registers can be reallocated to volatile registers in order to avoid
>> having to save them/restore on the stack. To keep track of which
>> registers can be reallocated to make sure registers are set seen when
>> used.
>
> Maybe you could try and do as on PPC32, try to use r0 as much as possible instead of TMP regs.
> r0 needs to be used carefully because for some instructions (ex: addi, lwz, etc) r0 means 0 instead
> of register 0, but it would help freeing one more register in several cases.
Yes, but I think the utility of register re-mapping is debatable on
ppc64 since we are using NVRs only for BPF NVRs. Unlike the savings seen
with the test case shown in the commit description (and with other test
programs in test_bpf), most real world BPF programs will be generated by
llvm which will only use the NVRs if necessary. I also suspect that most
BPF programs will end up making at least one helper call.
On ppc32 though, there is value in re-mapping registers, especially
BPF_REG_AX and TMP_REG, and to a lesser extent, BPF_REG_5, since those
are volatile BPF registers and can be remapped regardless of a helper
call.
- Naveen
^ permalink raw reply
* [PATCH v3 0/6] KVM: PPC: MMIO fixes
From: Fabiano Rosas @ 2022-01-07 21:00 UTC (permalink / raw)
To: kvm-ppc; +Cc: linuxppc-dev, npiggin, aik
This v3 addresses review comments:
Merge patches 3 and 7, now patch 6, which returns EMULATE_FAIL and now
also alters the error message.
Remove the now unnecessary 'advance' variable from emulate_loadstore
in patch 4.
v2:
https://lore.kernel.org/r/20220106200304.4070825-1-farosas@linux.ibm.com
v1:
https://lore.kernel.org/r/20211223211528.3560711-1-farosas@linux.ibm.com
Fabiano Rosas (6):
KVM: PPC: Book3S HV: Stop returning internal values to userspace
KVM: PPC: Fix vmx/vsx mixup in mmio emulation
KVM: PPC: Don't use pr_emerg when mmio emulation fails
KVM: PPC: mmio: Queue interrupt at kvmppc_emulate_mmio
KVM: PPC: mmio: Return to guest after emulation failure
KVM: PPC: mmio: Reject instructions that access more than mmio.data
size
arch/powerpc/kvm/emulate_loadstore.c | 8 +-------
arch/powerpc/kvm/powerpc.c | 24 +++++++++++++++++-------
2 files changed, 18 insertions(+), 14 deletions(-)
--
2.33.1
^ permalink raw reply
* [PATCH v3 2/6] KVM: PPC: Fix vmx/vsx mixup in mmio emulation
From: Fabiano Rosas @ 2022-01-07 21:00 UTC (permalink / raw)
To: kvm-ppc; +Cc: linuxppc-dev, npiggin, aik
In-Reply-To: <20220107210012.4091153-1-farosas@linux.ibm.com>
The MMIO emulation code for vector instructions is duplicated between
VSX and VMX. When emulating VMX we should check the VMX copy size
instead of the VSX one.
Fixes: acc9eb9305fe ("KVM: PPC: Reimplement LOAD_VMX/STORE_VMX instruction ...")
Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com>
Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
---
arch/powerpc/kvm/powerpc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index 1e130bb087c4..92e552ab5a77 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -1507,7 +1507,7 @@ int kvmppc_handle_vmx_load(struct kvm_vcpu *vcpu,
{
enum emulation_result emulated = EMULATE_DONE;
- if (vcpu->arch.mmio_vsx_copy_nums > 2)
+ if (vcpu->arch.mmio_vmx_copy_nums > 2)
return EMULATE_FAIL;
while (vcpu->arch.mmio_vmx_copy_nums) {
@@ -1604,7 +1604,7 @@ int kvmppc_handle_vmx_store(struct kvm_vcpu *vcpu,
unsigned int index = rs & KVM_MMIO_REG_MASK;
enum emulation_result emulated = EMULATE_DONE;
- if (vcpu->arch.mmio_vsx_copy_nums > 2)
+ if (vcpu->arch.mmio_vmx_copy_nums > 2)
return EMULATE_FAIL;
vcpu->arch.io_gpr = rs;
--
2.33.1
^ permalink raw reply related
* [PATCH v3 1/6] KVM: PPC: Book3S HV: Stop returning internal values to userspace
From: Fabiano Rosas @ 2022-01-07 21:00 UTC (permalink / raw)
To: kvm-ppc; +Cc: linuxppc-dev, npiggin, aik
In-Reply-To: <20220107210012.4091153-1-farosas@linux.ibm.com>
Our kvm_arch_vcpu_ioctl_run currently returns the RESUME_HOST values
to userspace, against the API of the KVM_RUN ioctl which returns 0 on
success.
Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com>
Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
---
This was noticed while enabling the kvm selftests for powerpc. There's
an assert at the _vcpu_run function when we return a value different
from the expected.
---
arch/powerpc/kvm/powerpc.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index a72920f4f221..1e130bb087c4 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -1849,6 +1849,14 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu)
#ifdef CONFIG_ALTIVEC
out:
#endif
+
+ /*
+ * We're already returning to userspace, don't pass the
+ * RESUME_HOST flags along.
+ */
+ if (r > 0)
+ r = 0;
+
vcpu_put(vcpu);
return r;
}
--
2.33.1
^ permalink raw reply related
* [PATCH v3 5/6] KVM: PPC: mmio: Return to guest after emulation failure
From: Fabiano Rosas @ 2022-01-07 21:00 UTC (permalink / raw)
To: kvm-ppc; +Cc: linuxppc-dev, npiggin, aik
In-Reply-To: <20220107210012.4091153-1-farosas@linux.ibm.com>
If MMIO emulation fails we don't want to crash the whole guest by
returning to userspace.
The original commit bbf45ba57eae ("KVM: ppc: PowerPC 440 KVM
implementation") added a todo:
/* XXX Deliver Program interrupt to guest. */
and later the commit d69614a295ae ("KVM: PPC: Separate loadstore
emulation from priv emulation") added the Program interrupt injection
but in another file, so I'm assuming it was missed that this block
needed to be altered.
Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com>
Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
---
arch/powerpc/kvm/powerpc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index 6daeea4a7de1..56b0faab7a5f 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -309,7 +309,7 @@ int kvmppc_emulate_mmio(struct kvm_vcpu *vcpu)
kvmppc_get_last_inst(vcpu, INST_GENERIC, &last_inst);
kvmppc_core_queue_program(vcpu, 0);
pr_info("%s: emulation failed (%08x)\n", __func__, last_inst);
- r = RESUME_HOST;
+ r = RESUME_GUEST;
break;
}
default:
--
2.33.1
^ permalink raw reply related
* [PATCH v3 6/6] KVM: PPC: mmio: Reject instructions that access more than mmio.data size
From: Fabiano Rosas @ 2022-01-07 21:00 UTC (permalink / raw)
To: kvm-ppc; +Cc: linuxppc-dev, npiggin, aik
In-Reply-To: <20220107210012.4091153-1-farosas@linux.ibm.com>
The MMIO interface between the kernel and userspace uses a structure
that supports a maximum of 8-bytes of data. Instructions that access
more than that need to be emulated in parts.
We currently don't have generic support for splitting the emulation in
parts and each set of instructions needs to be explicitly included.
There's already an error message being printed when a load or store
exceeds the mmio.data buffer but we don't fail the emulation until
later at kvmppc_complete_mmio_load and even then we allow userspace to
make a partial copy of the data, which ends up overwriting some fields
of the mmio structure.
This patch makes the emulation fail earlier at kvmppc_handle_load|store,
which will send a Program interrupt to the guest. This is better than
allowing the guest to proceed with partial data.
Note that this was caught in a somewhat artificial scenario using
quadword instructions (lq/stq), there's no account of an actual guest
in the wild running instructions that are not properly emulated.
(While here, fix the error message to check against 'bytes' and not
'run->mmio.len' which at this point has an old value.)
Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com>
Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
---
arch/powerpc/kvm/powerpc.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index 56b0faab7a5f..a1643ca988e0 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -1246,7 +1246,8 @@ static int __kvmppc_handle_load(struct kvm_vcpu *vcpu,
if (bytes > sizeof(run->mmio.data)) {
printk(KERN_ERR "%s: bad MMIO length: %d\n", __func__,
- run->mmio.len);
+ bytes);
+ return EMULATE_FAIL;
}
run->mmio.phys_addr = vcpu->arch.paddr_accessed;
@@ -1335,7 +1336,8 @@ int kvmppc_handle_store(struct kvm_vcpu *vcpu,
if (bytes > sizeof(run->mmio.data)) {
printk(KERN_ERR "%s: bad MMIO length: %d\n", __func__,
- run->mmio.len);
+ bytes);
+ return EMULATE_FAIL;
}
run->mmio.phys_addr = vcpu->arch.paddr_accessed;
--
2.33.1
^ permalink raw reply related
* [PATCH v3 4/6] KVM: PPC: mmio: Queue interrupt at kvmppc_emulate_mmio
From: Fabiano Rosas @ 2022-01-07 21:00 UTC (permalink / raw)
To: kvm-ppc; +Cc: linuxppc-dev, npiggin, aik
In-Reply-To: <20220107210012.4091153-1-farosas@linux.ibm.com>
If MMIO emulation fails, we queue a Program interrupt to the
guest. Move that line up into kvmppc_emulate_mmio, which is where we
set RESUME_GUEST/HOST. This allows the removal of the 'advance'
variable.
No functional change, just separation of responsibilities.
Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com>
---
arch/powerpc/kvm/emulate_loadstore.c | 8 +-------
arch/powerpc/kvm/powerpc.c | 2 +-
2 files changed, 2 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/kvm/emulate_loadstore.c b/arch/powerpc/kvm/emulate_loadstore.c
index 48272a9b9c30..4dec920fe4c9 100644
--- a/arch/powerpc/kvm/emulate_loadstore.c
+++ b/arch/powerpc/kvm/emulate_loadstore.c
@@ -73,7 +73,6 @@ int kvmppc_emulate_loadstore(struct kvm_vcpu *vcpu)
{
u32 inst;
enum emulation_result emulated = EMULATE_FAIL;
- int advance = 1;
struct instruction_op op;
/* this default type might be overwritten by subcategories */
@@ -355,15 +354,10 @@ int kvmppc_emulate_loadstore(struct kvm_vcpu *vcpu)
}
}
- if (emulated == EMULATE_FAIL) {
- advance = 0;
- kvmppc_core_queue_program(vcpu, 0);
- }
-
trace_kvm_ppc_instr(inst, kvmppc_get_pc(vcpu), emulated);
/* Advance past emulated instruction. */
- if (advance)
+ if (emulated != EMULATE_FAIL)
kvmppc_set_pc(vcpu, kvmppc_get_pc(vcpu) + 4);
return emulated;
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index 4d7d0d080232..6daeea4a7de1 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -307,7 +307,7 @@ int kvmppc_emulate_mmio(struct kvm_vcpu *vcpu)
u32 last_inst;
kvmppc_get_last_inst(vcpu, INST_GENERIC, &last_inst);
- /* XXX Deliver Program interrupt to guest. */
+ kvmppc_core_queue_program(vcpu, 0);
pr_info("%s: emulation failed (%08x)\n", __func__, last_inst);
r = RESUME_HOST;
break;
--
2.33.1
^ permalink raw reply related
* [PATCH v3 3/6] KVM: PPC: Don't use pr_emerg when mmio emulation fails
From: Fabiano Rosas @ 2022-01-07 21:00 UTC (permalink / raw)
To: kvm-ppc; +Cc: linuxppc-dev, npiggin, aik
In-Reply-To: <20220107210012.4091153-1-farosas@linux.ibm.com>
If MMIO emulation fails we deliver a Program interrupt to the
guest. This is a normal event for the host, so use pr_info.
Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com>
---
arch/powerpc/kvm/powerpc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index 92e552ab5a77..4d7d0d080232 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -308,7 +308,7 @@ int kvmppc_emulate_mmio(struct kvm_vcpu *vcpu)
kvmppc_get_last_inst(vcpu, INST_GENERIC, &last_inst);
/* XXX Deliver Program interrupt to guest. */
- pr_emerg("%s: emulation failed (%08x)\n", __func__, last_inst);
+ pr_info("%s: emulation failed (%08x)\n", __func__, last_inst);
r = RESUME_HOST;
break;
}
--
2.33.1
^ permalink raw reply related
* [Bug 215389] pagealloc: memory corruption at building glibc-2.33 and running its' testsuite
From: bugzilla-daemon @ 2022-01-08 1:07 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <bug-215389-206035@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=215389
--- Comment #4 from Erhard F. (erhard_f@mailbox.org) ---
I was able to easily reproduce this on 5.15.13, however not on 5.16-rc8.
But on 5.16-rc8 I got this the 3rd time I ran the glibc testsuite:
[...]
watchdog: BUG: soft lockup - CPU#1 stuck for 26s! [kworker/u4:7:32566]
Modules linked in: auth_rpcgss nfsv4 dns_resolver nfs lockd grace sunrpc
ghash_generic gf128mul gcm ccm algif_aead des_generic libdes ctr cbc ecb
algif_skcipher aes_generic libaes cmac sha512_generic sha1_generic sha1_powerpc
md5 md5_ppc md4 b43legacy mac80211 libarc4 snd_aoa_codec_tas
snd_aoa_fabric_layout snd_aoa cfg80211 rfkill evdev mac_hid therm_windtunnel
firewire_ohci firewire_core crc_itu_t sr_mod cdrom snd_aoa_i2sbus
snd_aoa_soundbus snd_pcm snd_timer snd ohci_pci soundcore radeon ohci_hcd
ehci_pci ehci_hcd hwmon i2c_algo_bit drm_ttm_helper ttm ssb drm_kms_helper
pcmcia pcmcia_core usbcore 8250_pci syscopyarea sysfillrect sysimgblt
usb_common 8250 8250_base serial_mctrl_gpio fb_sys_fops pkcs8_key_parser fuse
drm drm_panel_orientation_quirks configfs
CPU: 1 PID: 32566 Comm: kworker/u4:7 Not tainted 5.16.0-rc8-PowerMacG4 #1
Workqueue: zswap1 compact_page_work
NIP: c0078730 LR: c0078724 CTR: 00000000
REGS: f698dd40 TRAP: 0900 Not tainted (5.16.0-rc8-PowerMacG4)
MSR: 00009032 <EE,ME,IR,DR,RI> CR: 44008242 XER: 20000000
GPR00: c01856c8 f698de00 ca20b540 00000001 d4c73ffc 00000000 de0bd0bc aaaaaaaa
GPR08: aaaaaaaa 00000000 ffffffff 00000004 84002242 00000000 c00553fc 00000001
GPR16: 00000002 d4c73fc0 c0980000 002ec02c 00000040 d4c7300c d4c7302e c19c4bc0
GPR24: c19c4bc0 c0185d74 ef0d0040 d4c73008 d4c74a4c 0000007f de0bd000 d4c74a54
NIP [c0078730] arch_write_lock+0x28/0x3c
LR [c0078724] arch_write_lock+0x1c/0x3c
Call Trace:
[f698de00] [c0185d74] release_z3fold_page_locked+0x0/0x44 (unreliable)
[f698de20] [c01856c8] do_compact_page+0x334/0x508
[f698de80] [c004f354] process_one_work+0x1d4/0x288
[f698dec0] [c004f814] worker_thread+0x1b8/0x260
[f698df00] [c0055514] kthread+0x118/0x11c
[f698df30] [c0016268] ret_from_kernel_thread+0x5c/0x64
Instruction dump:
39610020 4bfa7668 9421ffe0 7c0802a6 90010024 93e1001c 7c7f1b78 7fe3fb78
4bffff0d 2c030000 41a20014 813f0000 <2c090000> 4182ffe8 4bfffff4 39610020
Kernel panic - not syncing: softlockup: hung tasks
CPU: 1 PID: 32566 Comm: kworker/u4:7 Tainted: G L
5.16.0-rc8-PowerMacG4 #1
Workqueue: zswap1 compact_page_work
Call Trace:
[f698dbb0] [c03e7f04] dump_stack_lvl+0x60/0x80 (unreliable)
[f698dbd0] [c0037734] panic+0x128/0x30c
[f698dc30] [c00c6334] watchdog_nmi_enable+0x0/0x10
[f698dc70] [c0097fc8] __hrtimer_run_queues+0xf0/0x154
[f698dcb0] [c0098b7c] hrtimer_interrupt+0xf8/0x25c
[f698dcf0] [c000d70c] timer_interrupt+0x20c/0x294
[f698dd30] [c0004a50] Decrementer_virt+0x100/0x104
--- interrupt: 900 at arch_write_lock+0x28/0x3c
NIP: c0078730 LR: c0078724 CTR: 00000000
REGS: f698dd40 TRAP: 0900 Tainted: G L
(5.16.0-rc8-PowerMacG4)
MSR: 00009032 <EE,ME,IR,DR,RI> CR: 44008242 XER: 20000000
GPR00: c01856c8 f698de00 ca20b540 00000001 d4c73ffc 00000000 de0bd0bc aaaaaaaa
GPR08: aaaaaaaa 00000000 ffffffff 00000004 84002242 00000000 c00553fc 00000001
GPR16: 00000002 d4c73fc0 c0980000 002ec02c 00000040 d4c7300c d4c7302e c19c4bc0
GPR24: c19c4bc0 c0185d74 ef0d0040 d4c73008 d4c74a4c 0000007f de0bd000 d4c74a54
NIP [c0078730] arch_write_lock+0x28/0x3c
LR [c0078724] arch_write_lock+0x1c/0x3c
--- interrupt: 900
[f698de00] [c0185d74] release_z3fold_page_locked+0x0/0x44 (unreliable)
[f698de20] [c01856c8] do_compact_page+0x334/0x508
[f698de80] [c004f354] process_one_work+0x1d4/0x288
[f698dec0] [c004f814] worker_thread+0x1b8/0x260
[f698df00] [c0055514] kthread+0x118/0x11c
[f698df30] [c0016268] ret_from_kernel_thread+0x5c/0x64
Rebooting in 40 seconds..
Which is interesting because on bug #213837 my not yet finished bisect is also
giving hints z3fold may be the problem...
I'll check out next whether the issue is reproduceable on 5.15.x when I use
zbud or zmalloc for zswap instead of z3fold.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* Re: [PATCH v2 1/2] powerpc: Fix virt_addr_valid() check
From: Kefeng Wang @ 2022-01-08 11:58 UTC (permalink / raw)
To: Kees Cook, Laura Abbott, Mark Rutland, linux-mm, Andrew Morton,
linux-kernel, Michael Ellerman, Benjamin Herrenschmidt,
Paul Mackerras, linuxppc-dev
Cc: Nicholas Piggin
In-Reply-To: <20211225120621.13908-2-wangkefeng.wang@huawei.com>
Hi PPC maintainers， ping..
On 2021/12/25 20:06, Kefeng Wang wrote:
> When run ethtool eth0, the BUG occurred,
>
> usercopy: Kernel memory exposure attempt detected from SLUB object not in SLUB page?! (offset 0, size 1048)!
> kernel BUG at mm/usercopy.c:99
> ...
> usercopy_abort+0x64/0xa0 (unreliable)
> __check_heap_object+0x168/0x190
> __check_object_size+0x1a0/0x200
> dev_ethtool+0x2494/0x2b20
> dev_ioctl+0x5d0/0x770
> sock_do_ioctl+0xf0/0x1d0
> sock_ioctl+0x3ec/0x5a0
> __se_sys_ioctl+0xf0/0x160
> system_call_exception+0xfc/0x1f0
> system_call_common+0xf8/0x200
>
> The code shows below,
>
> data = vzalloc(array_size(gstrings.len, ETH_GSTRING_LEN));
> copy_to_user(useraddr, data, gstrings.len * ETH_GSTRING_LEN))
>
> The data is alloced by vmalloc(), virt_addr_valid(ptr) will return true
> on PowerPC64, which leads to the panic.
>
> As commit 4dd7554a6456 ("powerpc/64: Add VIRTUAL_BUG_ON checks for __va
> and __pa addresses") does, make sure the virt addr above PAGE_OFFSET in
> the virt_addr_valid().
>
> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
> ---
> arch/powerpc/include/asm/page.h | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/include/asm/page.h b/arch/powerpc/include/asm/page.h
> index 254687258f42..300d4c105a3a 100644
> --- a/arch/powerpc/include/asm/page.h
> +++ b/arch/powerpc/include/asm/page.h
> @@ -132,7 +132,10 @@ static inline bool pfn_valid(unsigned long pfn)
> #define virt_to_page(kaddr) pfn_to_page(virt_to_pfn(kaddr))
> #define pfn_to_kaddr(pfn) __va((pfn) << PAGE_SHIFT)
>
> -#define virt_addr_valid(kaddr) pfn_valid(virt_to_pfn(kaddr))
> +#define virt_addr_valid(vaddr) ({ \
> + unsigned long _addr = (unsigned long)vaddr; \
> + (unsigned long)(_addr) >= PAGE_OFFSET && pfn_valid(virt_to_pfn(_addr)); \
> +})
>
> /*
> * On Book-E parts we need __va to parse the device tree and we can't
^ permalink raw reply
* Re: [PATCH 03/13] powerpc/bpf: Update ldimm64 instructions during extra pass
From: Jiri Olsa @ 2022-01-08 14:45 UTC (permalink / raw)
To: Naveen N. Rao
Cc: Daniel Borkmann, ykaliuta, johan.almbladh, song, bpf,
linuxppc-dev, Alexei Starovoitov, Hari Bathini
In-Reply-To: <7cc162af77ba918eb3ecd26ec9e7824bc44b1fae.1641468127.git.naveen.n.rao@linux.vnet.ibm.com>
On Thu, Jan 06, 2022 at 05:15:07PM +0530, Naveen N. Rao wrote:
> These instructions are updated after the initial JIT, so redo codegen
> during the extra pass. Rename bpf_jit_fixup_subprog_calls() to clarify
> that this is more than just subprog calls.
>
> Fixes: 69c087ba6225b5 ("bpf: Add bpf_for_each_map_elem() helper")
> Cc: stable@vger.kernel.org # v5.15
> Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Tested-by: Jiri Olsa <jolsa@redhat.com>
thanks,
jirka
> ---
> arch/powerpc/net/bpf_jit_comp.c | 29 +++++++++++++++++++++++------
> arch/powerpc/net/bpf_jit_comp32.c | 6 ++++++
> arch/powerpc/net/bpf_jit_comp64.c | 7 ++++++-
> 3 files changed, 35 insertions(+), 7 deletions(-)
>
> diff --git a/arch/powerpc/net/bpf_jit_comp.c b/arch/powerpc/net/bpf_jit_comp.c
> index d6ffdd0f2309d0..56dd1f4e3e4447 100644
> --- a/arch/powerpc/net/bpf_jit_comp.c
> +++ b/arch/powerpc/net/bpf_jit_comp.c
> @@ -23,15 +23,15 @@ static void bpf_jit_fill_ill_insns(void *area, unsigned int size)
> memset32(area, BREAKPOINT_INSTRUCTION, size / 4);
> }
>
> -/* Fix the branch target addresses for subprog calls */
> -static int bpf_jit_fixup_subprog_calls(struct bpf_prog *fp, u32 *image,
> - struct codegen_context *ctx, u32 *addrs)
> +/* Fix updated addresses (for subprog calls, ldimm64, et al) during extra pass */
> +static int bpf_jit_fixup_addresses(struct bpf_prog *fp, u32 *image,
> + struct codegen_context *ctx, u32 *addrs)
> {
> const struct bpf_insn *insn = fp->insnsi;
> bool func_addr_fixed;
> u64 func_addr;
> u32 tmp_idx;
> - int i, ret;
> + int i, j, ret;
>
> for (i = 0; i < fp->len; i++) {
> /*
> @@ -66,6 +66,23 @@ static int bpf_jit_fixup_subprog_calls(struct bpf_prog *fp, u32 *image,
> * of the JITed sequence remains unchanged.
> */
> ctx->idx = tmp_idx;
> + } else if (insn[i].code == (BPF_LD | BPF_IMM | BPF_DW)) {
> + tmp_idx = ctx->idx;
> + ctx->idx = addrs[i] / 4;
> +#ifdef CONFIG_PPC32
> + PPC_LI32(ctx->b2p[insn[i].dst_reg] - 1, (u32)insn[i + 1].imm);
> + PPC_LI32(ctx->b2p[insn[i].dst_reg], (u32)insn[i].imm);
> + for (j = ctx->idx - addrs[i] / 4; j < 4; j++)
> + EMIT(PPC_RAW_NOP());
> +#else
> + func_addr = ((u64)(u32)insn[i].imm) | (((u64)(u32)insn[i + 1].imm) << 32);
> + PPC_LI64(b2p[insn[i].dst_reg], func_addr);
> + /* overwrite rest with nops */
> + for (j = ctx->idx - addrs[i] / 4; j < 5; j++)
> + EMIT(PPC_RAW_NOP());
> +#endif
> + ctx->idx = tmp_idx;
> + i++;
> }
> }
>
> @@ -200,13 +217,13 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *fp)
> /*
> * Do not touch the prologue and epilogue as they will remain
> * unchanged. Only fix the branch target address for subprog
> - * calls in the body.
> + * calls in the body, and ldimm64 instructions.
> *
> * This does not change the offsets and lengths of the subprog
> * call instruction sequences and hence, the size of the JITed
> * image as well.
> */
> - bpf_jit_fixup_subprog_calls(fp, code_base, &cgctx, addrs);
> + bpf_jit_fixup_addresses(fp, code_base, &cgctx, addrs);
>
> /* There is no need to perform the usual passes. */
> goto skip_codegen_passes;
> diff --git a/arch/powerpc/net/bpf_jit_comp32.c b/arch/powerpc/net/bpf_jit_comp32.c
> index 997a47fa615b30..2258d3886d02ec 100644
> --- a/arch/powerpc/net/bpf_jit_comp32.c
> +++ b/arch/powerpc/net/bpf_jit_comp32.c
> @@ -293,6 +293,8 @@ int bpf_jit_build_body(struct bpf_prog *fp, u32 *image, struct codegen_context *
> bool func_addr_fixed;
> u64 func_addr;
> u32 true_cond;
> + u32 tmp_idx;
> + int j;
>
> /*
> * addrs[] maps a BPF bytecode address into a real offset from
> @@ -908,8 +910,12 @@ int bpf_jit_build_body(struct bpf_prog *fp, u32 *image, struct codegen_context *
> * 16 byte instruction that uses two 'struct bpf_insn'
> */
> case BPF_LD | BPF_IMM | BPF_DW: /* dst = (u64) imm */
> + tmp_idx = ctx->idx;
> PPC_LI32(dst_reg_h, (u32)insn[i + 1].imm);
> PPC_LI32(dst_reg, (u32)insn[i].imm);
> + /* padding to allow full 4 instructions for later patching */
> + for (j = ctx->idx - tmp_idx; j < 4; j++)
> + EMIT(PPC_RAW_NOP());
> /* Adjust for two bpf instructions */
> addrs[++i] = ctx->idx * 4;
> break;
> diff --git a/arch/powerpc/net/bpf_jit_comp64.c b/arch/powerpc/net/bpf_jit_comp64.c
> index 472d4a551945dd..3d018ecc475b2b 100644
> --- a/arch/powerpc/net/bpf_jit_comp64.c
> +++ b/arch/powerpc/net/bpf_jit_comp64.c
> @@ -319,6 +319,7 @@ int bpf_jit_build_body(struct bpf_prog *fp, u32 *image, struct codegen_context *
> u64 imm64;
> u32 true_cond;
> u32 tmp_idx;
> + int j;
>
> /*
> * addrs[] maps a BPF bytecode address into a real offset from
> @@ -848,9 +849,13 @@ int bpf_jit_build_body(struct bpf_prog *fp, u32 *image, struct codegen_context *
> case BPF_LD | BPF_IMM | BPF_DW: /* dst = (u64) imm */
> imm64 = ((u64)(u32) insn[i].imm) |
> (((u64)(u32) insn[i+1].imm) << 32);
> + tmp_idx = ctx->idx;
> + PPC_LI64(dst_reg, imm64);
> + /* padding to allow full 5 instructions for later patching */
> + for (j = ctx->idx - tmp_idx; j < 5; j++)
> + EMIT(PPC_RAW_NOP());
> /* Adjust for two bpf instructions */
> addrs[++i] = ctx->idx * 4;
> - PPC_LI64(dst_reg, imm64);
> break;
>
> /*
> --
> 2.34.1
>
^ permalink raw reply
* [PATCH 06/23] powerpc/membarrier: Remove special barrier on mm switch
From: Andy Lutomirski @ 2022-01-08 16:43 UTC (permalink / raw)
To: Andrew Morton, Linux-MM
Cc: linux-arch, x86, Rik van Riel, Peter Zijlstra, Randy Dunlap,
linuxppc-dev, Nicholas Piggin, Dave Hansen, Mathieu Desnoyers,
Andy Lutomirski, Paul Mackerras, Nadav Amit
In-Reply-To: <cover.1641659630.git.luto@kernel.org>
powerpc did the following on some, but not all, paths through
switch_mm_irqs_off():
/*
* Only need the full barrier when switching between processes.
* Barrier when switching from kernel to userspace is not
* required here, given that it is implied by mmdrop(). Barrier
* when switching from userspace to kernel is not needed after
* store to rq->curr.
*/
if (likely(!(atomic_read(&next->membarrier_state) &
(MEMBARRIER_STATE_PRIVATE_EXPEDITED |
MEMBARRIER_STATE_GLOBAL_EXPEDITED)) || !prev))
return;
This is puzzling: if !prev, then one might expect that we are switching
from kernel to user, not user to kernel, which is inconsistent with the
comment. But this is all nonsense, because the one and only caller would
never have prev == NULL and would, in fact, OOPS if prev == NULL.
In any event, this code is unnecessary, since the new generic
membarrier_finish_switch_mm() provides the same barrier without arch help.
arch/powerpc/include/asm/membarrier.h remains as an empty header,
because a later patch in this series will add code to it.
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Nicholas Piggin <npiggin@gmail.com>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Andy Lutomirski <luto@kernel.org>
---
arch/powerpc/include/asm/membarrier.h | 24 ------------------------
arch/powerpc/mm/mmu_context.c | 1 -
2 files changed, 25 deletions(-)
diff --git a/arch/powerpc/include/asm/membarrier.h b/arch/powerpc/include/asm/membarrier.h
index de7f79157918..b90766e95bd1 100644
--- a/arch/powerpc/include/asm/membarrier.h
+++ b/arch/powerpc/include/asm/membarrier.h
@@ -1,28 +1,4 @@
#ifndef _ASM_POWERPC_MEMBARRIER_H
#define _ASM_POWERPC_MEMBARRIER_H
-static inline void membarrier_arch_switch_mm(struct mm_struct *prev,
- struct mm_struct *next,
- struct task_struct *tsk)
-{
- /*
- * Only need the full barrier when switching between processes.
- * Barrier when switching from kernel to userspace is not
- * required here, given that it is implied by mmdrop(). Barrier
- * when switching from userspace to kernel is not needed after
- * store to rq->curr.
- */
- if (IS_ENABLED(CONFIG_SMP) &&
- likely(!(atomic_read(&next->membarrier_state) &
- (MEMBARRIER_STATE_PRIVATE_EXPEDITED |
- MEMBARRIER_STATE_GLOBAL_EXPEDITED)) || !prev))
- return;
-
- /*
- * The membarrier system call requires a full memory barrier
- * after storing to rq->curr, before going back to user-space.
- */
- smp_mb();
-}
-
#endif /* _ASM_POWERPC_MEMBARRIER_H */
diff --git a/arch/powerpc/mm/mmu_context.c b/arch/powerpc/mm/mmu_context.c
index 74246536b832..5f2daa6b0497 100644
--- a/arch/powerpc/mm/mmu_context.c
+++ b/arch/powerpc/mm/mmu_context.c
@@ -84,7 +84,6 @@ void switch_mm_irqs_off(struct mm_struct *prev, struct mm_struct *next,
asm volatile ("dssall");
if (!new_on_cpu)
- membarrier_arch_switch_mm(prev, next, tsk);
/*
* The actual HW switching method differs between the various
--
2.33.1
^ permalink raw reply related
* [PATCH 07/23] membarrier: Rewrite sync_core_before_usermode() and improve documentation
From: Andy Lutomirski @ 2022-01-08 16:43 UTC (permalink / raw)
To: Andrew Morton, Linux-MM
Cc: linux-arch, x86, Catalin Marinas, Will Deacon, Rik van Riel,
Peter Zijlstra, Randy Dunlap, linuxppc-dev, Nicholas Piggin,
Dave Hansen, Mathieu Desnoyers, stable, Andy Lutomirski,
Paul Mackerras, Nadav Amit, linux-arm-kernel
In-Reply-To: <cover.1641659630.git.luto@kernel.org>
The old sync_core_before_usermode() comments suggested that a
non-icache-syncing return-to-usermode instruction is x86-specific and that
all other architectures automatically notice cross-modified code on return
to userspace.
This is misleading. The incantation needed to modify code from one
CPU and execute it on another CPU is highly architecture dependent.
On x86, according to the SDM, one must modify the code, issue SFENCE
if the modification was WC or nontemporal, and then issue a "serializing
instruction" on the CPU that will execute the code. membarrier() can do
the latter.
On arm, arm64 and powerpc, one must flush the icache and then flush the
pipeline on the target CPU, although the CPU manuals don't necessarily use
this language.
So let's drop any pretense that we can have a generic way to define or
implement membarrier's SYNC_CORE operation and instead require all
architectures to define the helper and supply their own documentation as to
how to use it. This means x86, arm64, and powerpc for now. Let's also
rename the function from sync_core_before_usermode() to
membarrier_sync_core_before_usermode() because the precise flushing details
may very well be specific to membarrier, and even the concept of
"sync_core" in the kernel is mostly an x86-ism.
(It may well be the case that, on real x86 processors, synchronizing the
icache (which requires no action at all) and "flushing the pipeline" is
sufficient, but trying to use this language would be confusing at best.
LFENCE does something awfully like "flushing the pipeline", but the SDM
does not permit LFENCE as an alternative to a "serializing instruction"
for this purpose.)
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Nicholas Piggin <npiggin@gmail.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Nicholas Piggin <npiggin@gmail.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: x86@kernel.org
Cc: stable@vger.kernel.org
Acked-by: Will Deacon <will@kernel.org> # for arm64
Fixes: 70216e18e519 ("membarrier: Provide core serializing command, *_SYNC_CORE")
Signed-off-by: Andy Lutomirski <luto@kernel.org>
---
.../membarrier-sync-core/arch-support.txt | 69 ++++++-------------
arch/arm/include/asm/membarrier.h | 21 ++++++
arch/arm64/include/asm/membarrier.h | 19 +++++
arch/powerpc/include/asm/membarrier.h | 10 +++
arch/x86/Kconfig | 1 -
arch/x86/include/asm/membarrier.h | 25 +++++++
arch/x86/include/asm/sync_core.h | 20 ------
arch/x86/kernel/alternative.c | 2 +-
arch/x86/kernel/cpu/mce/core.c | 2 +-
arch/x86/mm/tlb.c | 3 +-
drivers/misc/sgi-gru/grufault.c | 2 +-
drivers/misc/sgi-gru/gruhandles.c | 2 +-
drivers/misc/sgi-gru/grukservices.c | 2 +-
include/linux/sched/mm.h | 1 -
include/linux/sync_core.h | 21 ------
init/Kconfig | 3 -
kernel/sched/membarrier.c | 14 +++-
17 files changed, 115 insertions(+), 102 deletions(-)
create mode 100644 arch/arm/include/asm/membarrier.h
create mode 100644 arch/arm64/include/asm/membarrier.h
create mode 100644 arch/x86/include/asm/membarrier.h
delete mode 100644 include/linux/sync_core.h
diff --git a/Documentation/features/sched/membarrier-sync-core/arch-support.txt b/Documentation/features/sched/membarrier-sync-core/arch-support.txt
index 883d33b265d6..4009b26bf5c3 100644
--- a/Documentation/features/sched/membarrier-sync-core/arch-support.txt
+++ b/Documentation/features/sched/membarrier-sync-core/arch-support.txt
@@ -5,51 +5,26 @@
#
# Architecture requirements
#
-# * arm/arm64/powerpc
#
-# Rely on implicit context synchronization as a result of exception return
-# when returning from IPI handler, and when returning to user-space.
-#
-# * x86
-#
-# x86-32 uses IRET as return from interrupt, which takes care of the IPI.
-# However, it uses both IRET and SYSEXIT to go back to user-space. The IRET
-# instruction is core serializing, but not SYSEXIT.
-#
-# x86-64 uses IRET as return from interrupt, which takes care of the IPI.
-# However, it can return to user-space through either SYSRETL (compat code),
-# SYSRETQ, or IRET.
-#
-# Given that neither SYSRET{L,Q}, nor SYSEXIT, are core serializing, we rely
-# instead on write_cr3() performed by switch_mm() to provide core serialization
-# after changing the current mm, and deal with the special case of kthread ->
-# uthread (temporarily keeping current mm into active_mm) by issuing a
-# sync_core_before_usermode() in that specific case.
-#
- -----------------------
- | arch |status|
- -----------------------
- | alpha: | TODO |
- | arc: | TODO |
- | arm: | ok |
- | arm64: | ok |
- | csky: | TODO |
- | h8300: | TODO |
- | hexagon: | TODO |
- | ia64: | TODO |
- | m68k: | TODO |
- | microblaze: | TODO |
- | mips: | TODO |
- | nds32: | TODO |
- | nios2: | TODO |
- | openrisc: | TODO |
- | parisc: | TODO |
- | powerpc: | ok |
- | riscv: | TODO |
- | s390: | TODO |
- | sh: | TODO |
- | sparc: | TODO |
- | um: | TODO |
- | x86: | ok |
- | xtensa: | TODO |
- -----------------------
+# An architecture that wants to support
+# MEMBARRIER_CMD_PRIVATE_EXPEDITED_SYNC_CORE needs to define precisely what it
+# is supposed to do and implement membarrier_sync_core_before_usermode() to
+# make it do that. Then it can select ARCH_HAS_MEMBARRIER_SYNC_CORE via
+# Kconfig and document what SYNC_CORE does on that architecture in this
+# list.
+#
+# On x86, a program can safely modify code, issue
+# MEMBARRIER_CMD_PRIVATE_EXPEDITED_SYNC_CORE, and then execute that code, via
+# the modified address or an alias, from any thread in the calling process.
+#
+# On arm and arm64, a program can modify code, flush the icache as needed,
+# and issue MEMBARRIER_CMD_PRIVATE_EXPEDITED_SYNC_CORE to force a "context
+# synchronizing event", aka pipeline flush on all CPUs that might run the
+# calling process. Then the program can execute the modified code as long
+# as it is executed from an address consistent with the icache flush and
+# the CPU's cache type. On arm, cacheflush(2) can be used for the icache
+# flushing operation.
+#
+# On powerpc, a program can use MEMBARRIER_CMD_PRIVATE_EXPEDITED_SYNC_CORE
+# similarly to arm64. It would be nice if the powerpc maintainers could
+# add a more clear explanantion.
diff --git a/arch/arm/include/asm/membarrier.h b/arch/arm/include/asm/membarrier.h
new file mode 100644
index 000000000000..c162a0758657
--- /dev/null
+++ b/arch/arm/include/asm/membarrier.h
@@ -0,0 +1,21 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _ASM_ARM_MEMBARRIER_H
+#define _ASM_ARM_MEMBARRIER_H
+
+#include <asm/barrier.h>
+
+/*
+ * On arm, anyone trying to use membarrier() to handle JIT code is required
+ * to first flush the icache (most likely by using cacheflush(2) and then
+ * do SYNC_CORE. All that's needed after the icache flush is to execute a
+ * "context synchronization event".
+ *
+ * Returning to user mode is a context synchronization event, so no
+ * specific action by the kernel is needed other than ensuring that the
+ * kernel is entered.
+ */
+static inline void membarrier_sync_core_before_usermode(void)
+{
+}
+
+#endif /* _ASM_ARM_MEMBARRIER_H */
diff --git a/arch/arm64/include/asm/membarrier.h b/arch/arm64/include/asm/membarrier.h
new file mode 100644
index 000000000000..db8e0ea57253
--- /dev/null
+++ b/arch/arm64/include/asm/membarrier.h
@@ -0,0 +1,19 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _ASM_ARM64_MEMBARRIER_H
+#define _ASM_ARM64_MEMBARRIER_H
+
+#include <asm/barrier.h>
+
+/*
+ * On arm64, anyone trying to use membarrier() to handle JIT code is
+ * required to first flush the icache and then do SYNC_CORE. All that's
+ * needed after the icache flush is to execute a "context synchronization
+ * event". Right now, ERET does this, and we are guaranteed to ERET before
+ * any user code runs. If Linux ever programs the CPU to make ERET stop
+ * being a context synchronizing event, then this will need to be adjusted.
+ */
+static inline void membarrier_sync_core_before_usermode(void)
+{
+}
+
+#endif /* _ASM_ARM64_MEMBARRIER_H */
diff --git a/arch/powerpc/include/asm/membarrier.h b/arch/powerpc/include/asm/membarrier.h
index b90766e95bd1..466abe6fdcea 100644
--- a/arch/powerpc/include/asm/membarrier.h
+++ b/arch/powerpc/include/asm/membarrier.h
@@ -1,4 +1,14 @@
#ifndef _ASM_POWERPC_MEMBARRIER_H
#define _ASM_POWERPC_MEMBARRIER_H
+#include <asm/barrier.h>
+
+/*
+ * The RFI family of instructions are context synchronising, and
+ * that is how we return to userspace, so nothing is required here.
+ */
+static inline void membarrier_sync_core_before_usermode(void)
+{
+}
+
#endif /* _ASM_POWERPC_MEMBARRIER_H */
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index d9830e7e1060..5060c38bf560 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -90,7 +90,6 @@ config X86
select ARCH_HAS_SET_DIRECT_MAP
select ARCH_HAS_STRICT_KERNEL_RWX
select ARCH_HAS_STRICT_MODULE_RWX
- select ARCH_HAS_SYNC_CORE_BEFORE_USERMODE
select ARCH_HAS_SYSCALL_WRAPPER
select ARCH_HAS_UBSAN_SANITIZE_ALL
select ARCH_HAS_DEBUG_WX
diff --git a/arch/x86/include/asm/membarrier.h b/arch/x86/include/asm/membarrier.h
new file mode 100644
index 000000000000..9b72a1b49359
--- /dev/null
+++ b/arch/x86/include/asm/membarrier.h
@@ -0,0 +1,25 @@
+#ifndef _ASM_X86_MEMBARRIER_H
+#define _ASM_X86_MEMBARRIER_H
+
+#include <asm/sync_core.h>
+
+/*
+ * Ensure that the CPU notices any instruction changes before the next time
+ * it returns to usermode.
+ */
+static inline void membarrier_sync_core_before_usermode(void)
+{
+ /* With PTI, we unconditionally serialize before running user code. */
+ if (static_cpu_has(X86_FEATURE_PTI))
+ return;
+
+ /*
+ * Even if we're in an interrupt, we might reschedule before returning,
+ * in which case we could switch to a different thread in the same mm
+ * and return using SYSRET or SYSEXIT. Instead of trying to keep
+ * track of our need to sync the core, just sync right away.
+ */
+ sync_core();
+}
+
+#endif /* _ASM_X86_MEMBARRIER_H */
diff --git a/arch/x86/include/asm/sync_core.h b/arch/x86/include/asm/sync_core.h
index ab7382f92aff..bfe4ac4e6be2 100644
--- a/arch/x86/include/asm/sync_core.h
+++ b/arch/x86/include/asm/sync_core.h
@@ -88,24 +88,4 @@ static inline void sync_core(void)
iret_to_self();
}
-/*
- * Ensure that a core serializing instruction is issued before returning
- * to user-mode. x86 implements return to user-space through sysexit,
- * sysrel, and sysretq, which are not core serializing.
- */
-static inline void sync_core_before_usermode(void)
-{
- /* With PTI, we unconditionally serialize before running user code. */
- if (static_cpu_has(X86_FEATURE_PTI))
- return;
-
- /*
- * Even if we're in an interrupt, we might reschedule before returning,
- * in which case we could switch to a different thread in the same mm
- * and return using SYSRET or SYSEXIT. Instead of trying to keep
- * track of our need to sync the core, just sync right away.
- */
- sync_core();
-}
-
#endif /* _ASM_X86_SYNC_CORE_H */
diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
index e9da3dc71254..b47cd22b2eb1 100644
--- a/arch/x86/kernel/alternative.c
+++ b/arch/x86/kernel/alternative.c
@@ -17,7 +17,7 @@
#include <linux/kprobes.h>
#include <linux/mmu_context.h>
#include <linux/bsearch.h>
-#include <linux/sync_core.h>
+#include <asm/sync_core.h>
#include <asm/text-patching.h>
#include <asm/alternative.h>
#include <asm/sections.h>
diff --git a/arch/x86/kernel/cpu/mce/core.c b/arch/x86/kernel/cpu/mce/core.c
index 193204aee880..a2529e09f620 100644
--- a/arch/x86/kernel/cpu/mce/core.c
+++ b/arch/x86/kernel/cpu/mce/core.c
@@ -41,12 +41,12 @@
#include <linux/irq_work.h>
#include <linux/export.h>
#include <linux/set_memory.h>
-#include <linux/sync_core.h>
#include <linux/task_work.h>
#include <linux/hardirq.h>
#include <asm/intel-family.h>
#include <asm/processor.h>
+#include <asm/sync_core.h>
#include <asm/traps.h>
#include <asm/tlbflush.h>
#include <asm/mce.h>
diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c
index 1ae15172885e..74b7a615bc15 100644
--- a/arch/x86/mm/tlb.c
+++ b/arch/x86/mm/tlb.c
@@ -12,6 +12,7 @@
#include <linux/sched/mm.h>
#include <asm/tlbflush.h>
+#include <asm/membarrier.h>
#include <asm/mmu_context.h>
#include <asm/nospec-branch.h>
#include <asm/cache.h>
@@ -491,7 +492,7 @@ static void sync_core_if_membarrier_enabled(struct mm_struct *next)
#ifdef CONFIG_MEMBARRIER
if (unlikely(atomic_read(&next->membarrier_state) &
MEMBARRIER_STATE_PRIVATE_EXPEDITED_SYNC_CORE))
- sync_core_before_usermode();
+ membarrier_sync_core_before_usermode();
#endif
}
diff --git a/drivers/misc/sgi-gru/grufault.c b/drivers/misc/sgi-gru/grufault.c
index d7ef61e602ed..462c667bd6c4 100644
--- a/drivers/misc/sgi-gru/grufault.c
+++ b/drivers/misc/sgi-gru/grufault.c
@@ -20,8 +20,8 @@
#include <linux/io.h>
#include <linux/uaccess.h>
#include <linux/security.h>
-#include <linux/sync_core.h>
#include <linux/prefetch.h>
+#include <asm/sync_core.h>
#include "gru.h"
#include "grutables.h"
#include "grulib.h"
diff --git a/drivers/misc/sgi-gru/gruhandles.c b/drivers/misc/sgi-gru/gruhandles.c
index 1d75d5e540bc..c8cba1c1b00f 100644
--- a/drivers/misc/sgi-gru/gruhandles.c
+++ b/drivers/misc/sgi-gru/gruhandles.c
@@ -16,7 +16,7 @@
#define GRU_OPERATION_TIMEOUT (((cycles_t) local_cpu_data->itc_freq)*10)
#define CLKS2NSEC(c) ((c) *1000000000 / local_cpu_data->itc_freq)
#else
-#include <linux/sync_core.h>
+#include <asm/sync_core.h>
#include <asm/tsc.h>
#define GRU_OPERATION_TIMEOUT ((cycles_t) tsc_khz*10*1000)
#define CLKS2NSEC(c) ((c) * 1000000 / tsc_khz)
diff --git a/drivers/misc/sgi-gru/grukservices.c b/drivers/misc/sgi-gru/grukservices.c
index 0ea923fe6371..ce03ff3f7c3a 100644
--- a/drivers/misc/sgi-gru/grukservices.c
+++ b/drivers/misc/sgi-gru/grukservices.c
@@ -16,10 +16,10 @@
#include <linux/miscdevice.h>
#include <linux/proc_fs.h>
#include <linux/interrupt.h>
-#include <linux/sync_core.h>
#include <linux/uaccess.h>
#include <linux/delay.h>
#include <linux/export.h>
+#include <asm/sync_core.h>
#include <asm/io_apic.h>
#include "gru.h"
#include "grulib.h"
diff --git a/include/linux/sched/mm.h b/include/linux/sched/mm.h
index e8919995d8dd..e107f292fc42 100644
--- a/include/linux/sched/mm.h
+++ b/include/linux/sched/mm.h
@@ -7,7 +7,6 @@
#include <linux/sched.h>
#include <linux/mm_types.h>
#include <linux/gfp.h>
-#include <linux/sync_core.h>
/*
* Routines for handling mm_structs
diff --git a/include/linux/sync_core.h b/include/linux/sync_core.h
deleted file mode 100644
index 013da4b8b327..000000000000
--- a/include/linux/sync_core.h
+++ /dev/null
@@ -1,21 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-#ifndef _LINUX_SYNC_CORE_H
-#define _LINUX_SYNC_CORE_H
-
-#ifdef CONFIG_ARCH_HAS_SYNC_CORE_BEFORE_USERMODE
-#include <asm/sync_core.h>
-#else
-/*
- * This is a dummy sync_core_before_usermode() implementation that can be used
- * on all architectures which return to user-space through core serializing
- * instructions.
- * If your architecture returns to user-space through non-core-serializing
- * instructions, you need to write your own functions.
- */
-static inline void sync_core_before_usermode(void)
-{
-}
-#endif
-
-#endif /* _LINUX_SYNC_CORE_H */
-
diff --git a/init/Kconfig b/init/Kconfig
index 11f8a845f259..bbaf93f9438b 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -2364,9 +2364,6 @@ source "kernel/Kconfig.locks"
config ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE
bool
-config ARCH_HAS_SYNC_CORE_BEFORE_USERMODE
- bool
-
# It may be useful for an architecture to override the definitions of the
# SYSCALL_DEFINE() and __SYSCALL_DEFINEx() macros in <linux/syscalls.h>
# and the COMPAT_ variants in <linux/compat.h>, in particular to use a
diff --git a/kernel/sched/membarrier.c b/kernel/sched/membarrier.c
index 327830f89c37..eb73eeaedc7d 100644
--- a/kernel/sched/membarrier.c
+++ b/kernel/sched/membarrier.c
@@ -5,6 +5,14 @@
* membarrier system call
*/
#include "sched.h"
+#ifdef CONFIG_ARCH_HAS_MEMBARRIER_SYNC_CORE
+#include <asm/membarrier.h>
+#else
+static inline void membarrier_sync_core_before_usermode(void)
+{
+ compiletime_assert(0, "architecture does not implement membarrier_sync_core_before_usermode");
+}
+#endif
/*
* The basic principle behind the regular memory barrier mode of
@@ -231,12 +239,12 @@ static void ipi_sync_core(void *info)
* the big comment at the top of this file.
*
* A sync_core() would provide this guarantee, but
- * sync_core_before_usermode() might end up being deferred until
- * after membarrier()'s smp_mb().
+ * membarrier_sync_core_before_usermode() might end up being deferred
+ * until after membarrier()'s smp_mb().
*/
smp_mb(); /* IPIs should be serializing but paranoid. */
- sync_core_before_usermode();
+ membarrier_sync_core_before_usermode();
}
static void ipi_rseq(void *info)
--
2.33.1
^ permalink raw reply related
* [Bug 215389] pagealloc: memory corruption at building glibc-2.33 and running its' testsuite
From: bugzilla-daemon @ 2022-01-08 18:14 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <bug-215389-206035@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=215389
--- Comment #5 from Erhard F. (erhard_f@mailbox.org) ---
Ok, with zswap lzo/zbud I also get this memory corruption on 5.15.13. So most
probably it's not lzo/z3pool but something else. I'll start a bisect then...
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* Re: [PATCH v5 04/21] kernel: Add combined power-off+restart handler call chain API
From: Michał Mirosław @ 2022-01-08 23:35 UTC (permalink / raw)
To: Dmitry Osipenko
Cc: Ulf Hansson, Rich Felker, linux-ia64, Santosh Shilimkar,
Rafael J. Wysocki, Boris Ostrovsky, Linus Walleij, Dave Hansen,
Liam Girdwood, James E.J. Bottomley, Thierry Reding,
Paul Mackerras, Pavel Machek, H. Peter Anvin, linux-riscv,
Vincent Chen, Will Deacon, Greg Ungerer, Stefano Stabellini,
alankao, Yoshinori Sato, Krzysztof Kozlowski, linux-sh,
Helge Deller, x86, Russell King, linux-csky, Jonathan Hunter,
linux-acpi, Ingo Molnar, Geert Uytterhoeven, Catalin Marinas,
xen-devel, linux-mips, Guenter Roeck, Len Brown, Albert Ou,
Lee Jones, linux-m68k, Mark Brown, Borislav Petkov, Greentime Hu,
Paul Walmsley, linux-tegra, Thomas Gleixner, Andy Shevchenko,
Juergen Gross, Thomas Bogendoerfer, Daniel Lezcano, linux-parisc,
linux-pm, Sebastian Reichel, linux-kernel, K . C . Kuen-Chern Lin,
Palmer Dabbelt, Philipp Zabel, Guo Ren, Andrew Morton,
linuxppc-dev, Joshua Thompson
In-Reply-To: <20211212210309.9851-5-digetx@gmail.com>
On Mon, Dec 13, 2021 at 12:02:52AM +0300, Dmitry Osipenko wrote:
[...]
> +/**
> + * struct power_off_data - Power-off callback argument
> + *
> + * @cb_data: Callback data.
> + */
> +struct power_off_data {
> + void *cb_data;
> +};
> +
> +/**
> + * struct power_off_prep_data - Power-off preparation callback argument
> + *
> + * @cb_data: Callback data.
> + */
> +struct power_off_prep_data {
> + void *cb_data;
> +};
Why two exactly same structures? Why only a single pointer instead? If
it just to enable type-checking callbacks, then thouse could be opaque
or zero-sized structs that would be embedded or casted away in
respective callbacks.
> +
> +/**
> + * struct restart_data - Restart callback argument
> + *
> + * @cb_data: Callback data.
> + * @cmd: Restart command string.
> + * @stop_chain: Further lower priority callbacks won't be executed if set to
> + * true. Can be changed within callback. Default is false.
> + * @mode: Reboot mode ID.
> + */
> +struct restart_data {
> + void *cb_data;
> + const char *cmd;
> + bool stop_chain;
> + enum reboot_mode mode;
> +};
> +
> +/**
> + * struct reboot_prep_data - Reboot and shutdown preparation callback argument
> + *
> + * @cb_data: Callback data.
> + * @cmd: Restart command string.
> + * @stop_chain: Further lower priority callbacks won't be executed if set to
> + * true. Can be changed within callback. Default is false.
Why would we want to stop power-off or erboot chain? If the callback
succeded, then further calls won't be made. If it doesn't succeed, but
possibly breaks the system somehow, it shouldn't return. Then the only
case left would be to just try the next method of shutting down.
> + * @mode: Preparation mode ID.
> + */
> +struct reboot_prep_data {
> + void *cb_data;
> + const char *cmd;
> + bool stop_chain;
> + enum reboot_prepare_mode mode;
> +};
> +
> +struct sys_off_handler_private_data {
> + struct notifier_block power_off_nb;
> + struct notifier_block restart_nb;
> + struct notifier_block reboot_nb;
What's the difference between restart and reboot?
> + void (*platform_power_off_cb)(void);
> + void (*simple_power_off_cb)(void *data);
> + void *simple_power_off_cb_data;
> + bool registered;
> +};
BTW, I couldn't find a right description of my idea of unifying the
chains before, so let me sketch it now.
The idea is to have a single system-off chain in which the callback
gets a mode ({QUERY_*, PREP_*, DO_*} for each of {*_REBOOT, *_POWEROFF, ...?).
The QUERY_* calls would be made in can_kernel_reboot/poweroff(): all
would be called, and if at least one returned true, then the shutdown
mode would continue. All of PREP_* would be called then. After that
all DO_* would be tried until one doesn't return (succeeded or broke
the system hard). Classic for(;;); could be a final fallback for the
case where arch/machine (lowest priority) call would return instead
of halting the system in machine-dependent way. The QUERY and PREP
stages could be combined, but I haven't thought about it enough to
see what conditions would need to be imposed on the callbacks in
that case (maybe it's not worth the trouble, since it isn't a fast
path anyway?). The goal here is to have less (duplicated) code in
kernel, but otherwise it seems equivalent to your API proposal.
Best Regards
Michał Mirosław
^ permalink raw reply
* [Bug 215470] New: Unable to boot NXP P2020 processor (freeze before any print to stdout)
From: bugzilla-daemon @ 2022-01-09 21:41 UTC (permalink / raw)
To: linuxppc-dev
https://bugzilla.kernel.org/show_bug.cgi?id=215470
Bug ID: 215470
Summary: Unable to boot NXP P2020 processor (freeze before any
print to stdout)
Product: Platform Specific/Hardware
Version: 2.5
Kernel Version: >=v5.15-rc1
Hardware: PPC-32
OS: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: PPC-32
Assignee: platform_ppc-32@kernel-bugs.osdl.org
Reporter: paweldembicki@gmail.com
Regression: No
Created attachment 300248
--> https://bugzilla.kernel.org/attachment.cgi?id=300248&action=edit
my .config file
Hello,
I'm unable to boot kernel on NXP P2020 powerpc processor, image built from
mainline tree after commit:
https://lore.kernel.org/all/1fc81f07cabebb875b963e295408cc3dd38c8d85.1614674882.git.christophe.leroy@csgroup.eu/
Workaround:
After revert 1fc81f07cabe, it's start work again.
My compiler: powerpc-openwrt-linux-gcc (OpenWrt GCC 11.2.0 r18180-95697901c8)
11.2.0, GNU ld (GNU Binutils) 2.37
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* Re: Linux kernel: powerpc: KVM guest can trigger host crash on Power8
From: John Paul Adrian Glaubitz @ 2022-01-09 22:17 UTC (permalink / raw)
To: Michael Ellerman; +Cc: debian-powerpc@lists.debian.org, linuxppc-dev
In-Reply-To: <872c2364-a5db-0533-c8bd-91e03c067a2f@physik.fu-berlin.de>
Hi Michael!
On 1/7/22 12:20, John Paul Adrian Glaubitz wrote:
>> Can you separately test with (on the host):
>>
>> # echo 0 > /sys/module/kvm_hv/parameters/dynamic_mt_modes
>
> I'm trying to turn off "dynamic_mt_modes" first and see if that makes any difference.
>
> I will report back.
So far the machine is running stable now and the VM built gcc-9 without
crashing the host. I will continue to monitor the machine and report back
if it crashes, but it looks like this could be it.
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] powerpc/xive: Add missing null check after calling kmalloc
From: Michael Ellerman @ 2022-01-10 1:50 UTC (permalink / raw)
To: linux-kernel, Ammar Faizi, linuxppc-dev
Cc: Yang Li, Paul Mackerras, Cédric Le Goater
In-Reply-To: <20211226135314.251221-1-ammar.faizi@intel.com>
On Sun, 26 Dec 2021 20:54:02 +0700, Ammar Faizi wrote:
> Commit 930914b7d528fc ("powerpc/xive: Add a debugfs file to dump
> internal XIVE state") forgot to add a null check.
>
> Add it.
>
>
Applied to powerpc/next.
[1/1] powerpc/xive: Add missing null check after calling kmalloc
https://git.kernel.org/powerpc/c/18dbfcdedc802f9500b2c29794f22a31d27639c0
cheers
^ permalink raw reply
* Re: [PATCH] floppy: Remove usage of the deprecated "pci-dma-compat.h" API
From: Michael Ellerman @ 2022-01-10 1:50 UTC (permalink / raw)
To: benh, paulus, mpe, Christophe JAILLET
Cc: kernel-janitors, linuxppc-dev, linux-kernel
In-Reply-To: <9e24eedeab44cbb840598bb188561a48811de845.1641119338.git.christophe.jaillet@wanadoo.fr>
On Sun, 2 Jan 2022 11:29:54 +0100, Christophe JAILLET wrote:
> In [1], Christoph Hellwig has proposed to remove the wrappers in
> include/linux/pci-dma-compat.h.
>
> Some reasons why this API should be removed have been given by Julia
> Lawall in [2].
>
> A coccinelle script has been used to perform the needed transformation
> Only relevant parts are given below.
>
> [...]
Applied to powerpc/next.
[1/1] floppy: Remove usage of the deprecated "pci-dma-compat.h" API
https://git.kernel.org/powerpc/c/e57c2fd6cdf8db581ac93b909b2664751e7cf30c
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/cacheinfo: use default_groups in kobj_type
From: Michael Ellerman @ 2022-01-10 1:50 UTC (permalink / raw)
To: linux-kernel, Greg Kroah-Hartman
Cc: Parth Shah, Gautham R. Shenoy, Paul Mackerras, linuxppc-dev
In-Reply-To: <20220104155450.1291277-1-gregkh@linuxfoundation.org>
On Tue, 4 Jan 2022 16:54:50 +0100, Greg Kroah-Hartman wrote:
> There are currently 2 ways to create a set of sysfs files for a
> kobj_type, through the default_attrs field, and the default_groups
> field. Move the powerpc cacheinfo sysfs code to use default_groups
> field which has been the preferred way since aa30f47cf666 ("kobject: Add
> support for default attribute groups to kobj_type") so that we can soon
> get rid of the obsolete default_attrs field.
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/cacheinfo: use default_groups in kobj_type
https://git.kernel.org/powerpc/c/2bdf3f9e9df0a4ce7709fc916b9997ca2dc30d25
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/opal: use default_groups in kobj_type
From: Michael Ellerman @ 2022-01-10 1:51 UTC (permalink / raw)
To: linux-kernel, Greg Kroah-Hartman
Cc: Vasant Hegde, Paul Mackerras, Joel Stanley, linuxppc-dev
In-Reply-To: <20220104161318.1306023-1-gregkh@linuxfoundation.org>
On Tue, 4 Jan 2022 17:13:18 +0100, Greg Kroah-Hartman wrote:
> There are currently 2 ways to create a set of sysfs files for a
> kobj_type, through the default_attrs field, and the default_groups
> field. Move the powerpc opal dump and elog sysfs code to use
> default_groups field which has been the preferred way since aa30f47cf666
> ("kobject: Add support for default attribute groups to kobj_type") so
> that we can soon get rid of the obsolete default_attrs field.
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/opal: use default_groups in kobj_type
https://git.kernel.org/powerpc/c/32a1bda4b12a3d324bd585e1aa20dac824ab719c
cheers
^ 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