* Re: [PATCH v7 8/9] powerpc/mce: Add sysctl control for recovery action on MCE.
From: Aneesh Kumar K.V @ 2018-08-08 15:37 UTC (permalink / raw)
To: Michael Ellerman, Mahesh J Salgaonkar, linuxppc-dev
Cc: Aneesh Kumar K.V, Michal Suchanek, Ananth Narayan,
Nicholas Piggin, Laurent Dufour
In-Reply-To: <87o9ecaovz.fsf@concordia.ellerman.id.au>
On 08/08/2018 08:26 PM, Michael Ellerman wrote:
> Mahesh J Salgaonkar <mahesh@linux.vnet.ibm.com> writes:
>> From: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
>>
>> Introduce recovery action for recovered memory errors (MCEs). There are
>> soft memory errors like SLB Multihit, which can be a result of a bad
>> hardware OR software BUG. Kernel can easily recover from these soft errors
>> by flushing SLB contents. After the recovery kernel can still continue to
>> function without any issue. But in some scenario's we may keep getting
>> these soft errors until the root cause is fixed. To be able to analyze and
>> find the root cause, best way is to gather enough data and system state at
>> the time of MCE. Hence this patch introduces a sysctl knob where user can
>> decide either to continue after recovery or panic the kernel to capture the
>> dump.
>
> I'm not convinced we want this.
>
> As we've discovered it's often not possible to reconstruct what happened
> based on a dump anyway.
>
> The key thing you need is the content of the SLB and that's not included
> in a dump.
>
> So I think we should dump the SLB content when we get the MCE (which
> this series does) and any other useful info, and then if we can recover
> we should.
>
The reasoning there is what if we got multi-hit due to some corruption
in slb_cache_ptr. ie. some part of kernel is wrongly updating the paca
data structure due to wrong pointer. Now that is far fetched, but then
possible right?. Hence the idea that, if we don't have much insight into
why a slb multi-hit occur from the dmesg which include slb content,
slb_cache contents etc, there should be an easy way to force a dump that
might assist in further debug.
-aneesh
^ permalink raw reply
* [PATCH] powerpc/mm: remove huge_pte_offset_and_shift() prototype
From: Christophe Leroy @ 2018-08-08 15:36 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: linux-kernel, linuxppc-dev
huge_pte_offset_and_shift() has never existed
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
---
arch/powerpc/include/asm/hugetlb.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/powerpc/include/asm/hugetlb.h b/arch/powerpc/include/asm/hugetlb.h
index 3225eb6402cc..2d00cc530083 100644
--- a/arch/powerpc/include/asm/hugetlb.h
+++ b/arch/powerpc/include/asm/hugetlb.h
@@ -84,9 +84,6 @@ static inline pte_t *hugepte_offset(hugepd_t hpd, unsigned long addr,
return dir + idx;
}
-pte_t *huge_pte_offset_and_shift(struct mm_struct *mm,
- unsigned long addr, unsigned *shift);
-
void flush_dcache_icache_hugepage(struct page *page);
int slice_is_hugepage_only_range(struct mm_struct *mm, unsigned long addr,
--
2.13.3
^ permalink raw reply related
* [PATCH v3 1/2] powerpc/pseries: Avoid blocking rtas polling handling multiple PRRN events
From: John Allen @ 2018-08-08 15:29 UTC (permalink / raw)
To: linuxppc-dev, mpe; +Cc: nfont, desnesn, John Allen
In-Reply-To: <20180808152926.28842-1-jallen@linux.ibm.com>
When a PRRN event is being handled and another PRRN event comes in, the
second event will block rtas polling waiting on the first to complete,
preventing any further rtas events from being handled. This can be
especially problematic in case that PRRN events are continuously being
queued in which case rtas polling gets indefinitely blocked completely.
This patch removes the blocking call to flush_work and allows the
default workqueue behavior to handle duplicate events.
Signed-off-by: John Allen <jallen@linux.ibm.com>
---
v3:
-Scrap the mutex as it only replicates existing workqueue behavior.
v2:
-Unlock prrn_lock when PRRN operations are complete, not after handler is
scheduled.
-Remove call to flush_work, the previous broken method of serializing
PRRN events.
---
arch/powerpc/kernel/rtasd.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/powerpc/kernel/rtasd.c b/arch/powerpc/kernel/rtasd.c
index 44d66c33d59d..2017934e5985 100644
--- a/arch/powerpc/kernel/rtasd.c
+++ b/arch/powerpc/kernel/rtasd.c
@@ -290,7 +290,6 @@ static DECLARE_WORK(prrn_work, prrn_work_fn);
static void prrn_schedule_update(u32 scope)
{
- flush_work(&prrn_work);
prrn_update_scope = scope;
schedule_work(&prrn_work);
}
--
2.17.1
^ permalink raw reply related
* [PATCH v3 2/2] powerpc/pseries: Wait for completion of hotplug events during PRRN handling
From: John Allen @ 2018-08-08 15:29 UTC (permalink / raw)
To: linuxppc-dev, mpe; +Cc: nfont, desnesn, John Allen
In-Reply-To: <20180808152926.28842-1-jallen@linux.ibm.com>
While handling PRRN events, the time to handle the actual hotplug events
dwarfs the time it takes to perform the device tree updates and queue the
hotplug events. In the case that PRRN events are being queued continuously,
hotplug events have been observed to be queued faster than the kernel can
actually handle them. This patch avoids the problem by waiting for a
hotplug request to complete before queueing more hotplug events.
Signed-off-by: John Allen <jallen@linux.ibm.com>
---
arch/powerpc/platforms/pseries/mobility.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/pseries/mobility.c b/arch/powerpc/platforms/pseries/mobility.c
index 8a8033a249c7..49930848fa78 100644
--- a/arch/powerpc/platforms/pseries/mobility.c
+++ b/arch/powerpc/platforms/pseries/mobility.c
@@ -242,6 +242,7 @@ static int add_dt_node(__be32 parent_phandle, __be32 drc_index)
static void prrn_update_node(__be32 phandle)
{
struct pseries_hp_errorlog *hp_elog;
+ struct completion hotplug_done;
struct device_node *dn;
/*
@@ -263,7 +264,9 @@ static void prrn_update_node(__be32 phandle)
hp_elog->id_type = PSERIES_HP_ELOG_ID_DRC_INDEX;
hp_elog->_drc_u.drc_index = phandle;
- queue_hotplug_event(hp_elog, NULL, NULL);
+ init_completion(&hotplug_done);
+ queue_hotplug_event(hp_elog, &hotplug_done, NULL);
+ wait_for_completion(&hotplug_done);
kfree(hp_elog);
}
--
2.17.1
^ permalink raw reply related
* [PATCH v3 0/2] powerpc/pseries: Improve serialization of PRRN events
From: John Allen @ 2018-08-08 15:29 UTC (permalink / raw)
To: linuxppc-dev, mpe; +Cc: nfont, desnesn
Stress testing has uncovered issues with handling continuously queued PRRN
events. Running PRRN events in this way can seriously load the system given
the sheer volume of dlpar being handled. This patchset ensures that PRRN
events are handled more synchronously, only allowing the PRRN handler to
queue a single dlpar event at any given time. Additionally, it ensures
that rtas polling continues normally when multiple PRRN events are queued
simultaneously.
v3:
-Scrap the PRRN mutex as it only replicates existing workqueue behavior.
v2:
-Unlock prrn_lock when PRRN operations are complete, not after handler is
scheduled.
-Remove call to flush_work, the previous broken method of serializing
PRRN events.
John Allen (2):
powerpc/pseries: Avoid blocking rtas polling handling multiple PRRN
events
powerpc/pseries: Wait for completion of hotplug events during PRRN
handling
arch/powerpc/kernel/rtasd.c | 10 +++++++---
arch/powerpc/platforms/pseries/mobility.c | 5 ++++-
2 files changed, 11 insertions(+), 4 deletions(-)
--
2.17.1
^ permalink raw reply
* Re: [PATCH v7 8/9] powerpc/mce: Add sysctl control for recovery action on MCE.
From: Michael Ellerman @ 2018-08-08 14:56 UTC (permalink / raw)
To: Mahesh J Salgaonkar, linuxppc-dev
Cc: Aneesh Kumar K.V, Michal Suchanek, Ananth Narayan,
Nicholas Piggin, Laurent Dufour
In-Reply-To: <153365146712.14256.11869543914717297278.stgit@jupiter.in.ibm.com>
Mahesh J Salgaonkar <mahesh@linux.vnet.ibm.com> writes:
> From: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
>
> Introduce recovery action for recovered memory errors (MCEs). There are
> soft memory errors like SLB Multihit, which can be a result of a bad
> hardware OR software BUG. Kernel can easily recover from these soft errors
> by flushing SLB contents. After the recovery kernel can still continue to
> function without any issue. But in some scenario's we may keep getting
> these soft errors until the root cause is fixed. To be able to analyze and
> find the root cause, best way is to gather enough data and system state at
> the time of MCE. Hence this patch introduces a sysctl knob where user can
> decide either to continue after recovery or panic the kernel to capture the
> dump.
I'm not convinced we want this.
As we've discovered it's often not possible to reconstruct what happened
based on a dump anyway.
The key thing you need is the content of the SLB and that's not included
in a dump.
So I think we should dump the SLB content when we get the MCE (which
this series does) and any other useful info, and then if we can recover
we should.
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/64s: Make unrecoverable SLB miss less confusing
From: Naveen N. Rao @ 2018-08-08 14:42 UTC (permalink / raw)
To: Michael Ellerman, Nicholas Piggin; +Cc: anton, linuxppc-dev, paulus
In-Reply-To: <87tvo59c1d.fsf@concordia.ellerman.id.au>
Michael Ellerman wrote:
> Nicholas Piggin <npiggin@gmail.com> writes:
>> On Thu, 26 Jul 2018 23:01:51 +1000
>> Michael Ellerman <mpe@ellerman.id.au> wrote:
>>
>>> If we take an SLB miss while MSR[RI]=3D0 we can't recover and have to
>>> oops. Currently this is reported by faking up a 0x4100 exception, eg:
>>>=20
>>> Unrecoverable exception 4100 at 0
>>> Oops: Unrecoverable exception, sig: 6 [#1]
>>> ...
>>> CPU: 0 PID: 1262 Comm: sh Not tainted 4.18.0-rc3-gcc-7.3.1-00098-g7fc=
2229fb2ab-dirty #9
>>> NIP: 0000000000000000 LR: c00000000000b9e4 CTR: 00007fff8bb971b0
>>> REGS: c0000000ee02bbb0 TRAP: 4100
>>> ...
>>> LR [c00000000000b9e4] system_call+0x5c/0x70
>>>=20
>>> The 0x4100 value was chosen back in 2004 as part of the fix for the
>>> "mega bug" - "ppc64: Fix SLB reload bug". Back then it was obvious
>>> that 0x4100 was not a real trap value, as the highest actual trap was
>>> less than 0x2000.
>>>=20
>>> Since then however the architecture has changed and now we have
>>> "virtual mode" or "relon" exceptions, in which exceptions can be
>>> delivered with the MMU on starting at 0x4000.
>>>=20
>>> At a glance 0x4100 looks like a virtual mode 0x100 exception, aka
>>> system reset exception. A close reading of the architecture will show
>>> that system reset exceptions can't be delivered in virtual mode, and
>>> so 0x4100 is not a valid trap number. But that's not immediately
>>> obvious. There's also nothing about 0x4100 that suggests SLB miss.
>>>=20
>>> So to make things a bit less confusing switch to a fake but unique and
>>> hopefully more helpful numbering. For data SLB misses we report a
>>> 0x390 trap and for instruction we report 0x490. Compared to 0x380 and
>>> 0x480 for the actual data & instruction SLB exceptions.
>>>=20
>>> Also add a C handler that prints a more explicit message. The end
>>> result is something like:
>>>=20
>>> Oops: Unrecoverable SLB miss (MSR[RI]=3D0), sig: 6 [#3]
>>
>> This is all good, but allow me to nitpick. Our unrecoverable
>> exception messages (and other messages, but those) are becoming a bit
>> ad-hoc and messy.
>>
>> It would be nice to go the other way eventually and consolidate them
>> into one. Would be nice to have a common function that takes regs and
>> returns the string of the corresponding exception name that makes
>> these more readable.
>=20
> Yeah that's true, though some of them aren't simply a mapping from the
> trap number, eg. the kernel bad stack one.
>=20
> But in general our whole oops output, regs, stack trace etc. could use a
> revamp.
>=20
> I've been thinking of making the trap number more prominent and
> providing a text description, because apparently not everyone knows the
> trap numbers by heart :)
Yes please, guilty as charged :)
https://patchwork.ozlabs.org/patch/899980/
Thanks,
Naveen
=
^ permalink raw reply
* Re: [PATCH v7 4/9] powerpc/pseries: Define MCE error event section.
From: Michael Ellerman @ 2018-08-08 14:42 UTC (permalink / raw)
To: Mahesh J Salgaonkar, linuxppc-dev
Cc: Aneesh Kumar K.V, Michal Suchanek, Ananth Narayan,
Nicholas Piggin, Laurent Dufour
In-Reply-To: <153365141396.14256.7147876868875454254.stgit@jupiter.in.ibm.com>
Hi Mahesh,
A few nitpicks.
Mahesh J Salgaonkar <mahesh@linux.vnet.ibm.com> writes:
> From: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
>
> On pseries, the machine check error details are part of RTAS extended
> event log passed under Machine check exception section. This patch adds
> the definition of rtas MCE event section and related helper
> functions.
>
> Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
> ---
> arch/powerpc/include/asm/rtas.h | 111 +++++++++++++++++++++++++++++++++++++++
> 1 file changed, 111 insertions(+)
AFIACS none of this ever gets used outside of ras.c, should it should
just go in there.
> diff --git a/arch/powerpc/include/asm/rtas.h b/arch/powerpc/include/asm/rtas.h
> index 71e393c46a49..adc677c5e3a4 100644
> --- a/arch/powerpc/include/asm/rtas.h
> +++ b/arch/powerpc/include/asm/rtas.h
> @@ -326,6 +334,109 @@ struct pseries_hp_errorlog {
> #define PSERIES_HP_ELOG_ID_DRC_COUNT 3
> #define PSERIES_HP_ELOG_ID_DRC_IC 4
>
> +/* RTAS pseries MCE errorlog section */
> +#pragma pack(push, 1)
> +struct pseries_mc_errorlog {
> + __be32 fru_id;
> + __be32 proc_id;
> + uint8_t error_type;
Please use kernel types, so u8.
> + union {
> + struct {
> + uint8_t ue_err_type;
> + /* XXXXXXXX
> + * X 1: Permanent or Transient UE.
> + * X 1: Effective address provided.
> + * X 1: Logical address provided.
> + * XX 2: Reserved.
> + * XXX 3: Type of UE error.
> + */
But which bit is bit 0? And is that the LSB or MSB?
> + uint8_t reserved_1[6];
> + __be64 effective_address;
> + __be64 logical_address;
> + } ue_error;
> + struct {
> + uint8_t soft_err_type;
> + /* XXXXXXXX
> + * X 1: Effective address provided.
> + * XXXXX 5: Reserved.
> + * XX 2: Type of SLB/ERAT/TLB error.
> + */
> + uint8_t reserved_1[6];
> + __be64 effective_address;
> + uint8_t reserved_2[8];
> + } soft_error;
> + } u;
> +};
> +#pragma pack(pop)
Why not __packed ?
> +/* RTAS pseries MCE error types */
> +#define PSERIES_MC_ERROR_TYPE_UE 0x00
> +#define PSERIES_MC_ERROR_TYPE_SLB 0x01
> +#define PSERIES_MC_ERROR_TYPE_ERAT 0x02
> +#define PSERIES_MC_ERROR_TYPE_TLB 0x04
> +#define PSERIES_MC_ERROR_TYPE_D_CACHE 0x05
> +#define PSERIES_MC_ERROR_TYPE_I_CACHE 0x07
Once these are in ras.c they can have less unwieldy names, ie. the
PSERIES at least can be dropped.
> +/* RTAS pseries MCE error sub types */
> +#define PSERIES_MC_ERROR_UE_INDETERMINATE 0
> +#define PSERIES_MC_ERROR_UE_IFETCH 1
> +#define PSERIES_MC_ERROR_UE_PAGE_TABLE_WALK_IFETCH 2
> +#define PSERIES_MC_ERROR_UE_LOAD_STORE 3
> +#define PSERIES_MC_ERROR_UE_PAGE_TABLE_WALK_LOAD_STORE 4
> +
> +#define PSERIES_MC_ERROR_SLB_PARITY 0
> +#define PSERIES_MC_ERROR_SLB_MULTIHIT 1
> +#define PSERIES_MC_ERROR_SLB_INDETERMINATE 2
> +
> +#define PSERIES_MC_ERROR_ERAT_PARITY 1
> +#define PSERIES_MC_ERROR_ERAT_MULTIHIT 2
> +#define PSERIES_MC_ERROR_ERAT_INDETERMINATE 3
> +
> +#define PSERIES_MC_ERROR_TLB_PARITY 1
> +#define PSERIES_MC_ERROR_TLB_MULTIHIT 2
> +#define PSERIES_MC_ERROR_TLB_INDETERMINATE 3
> +
> +static inline uint8_t rtas_mc_error_type(const struct pseries_mc_errorlog *mlog)
> +{
> + return mlog->error_type;
> +}
Why not just access it directly?
> +static inline uint8_t rtas_mc_error_sub_type(
> + const struct pseries_mc_errorlog *mlog)
> +{
> + switch (mlog->error_type) {
> + case PSERIES_MC_ERROR_TYPE_UE:
> + return (mlog->u.ue_error.ue_err_type & 0x07);
> + case PSERIES_MC_ERROR_TYPE_SLB:
> + case PSERIES_MC_ERROR_TYPE_ERAT:
> + case PSERIES_MC_ERROR_TYPE_TLB:
> + return (mlog->u.soft_error.soft_err_type & 0x03);
> + default:
> + return 0;
> + }
> +}
> +
> +static inline uint64_t rtas_mc_get_effective_addr(
> + const struct pseries_mc_errorlog *mlog)
> +{
> + uint64_t addr = 0;
That should be __be64.
> +
> + switch (mlog->error_type) {
> + case PSERIES_MC_ERROR_TYPE_UE:
> + if (mlog->u.ue_error.ue_err_type & 0x40)
> + addr = mlog->u.ue_error.effective_address;
> + break;
> + case PSERIES_MC_ERROR_TYPE_SLB:
> + case PSERIES_MC_ERROR_TYPE_ERAT:
> + case PSERIES_MC_ERROR_TYPE_TLB:
> + if (mlog->u.soft_error.soft_err_type & 0x80)
> + addr = mlog->u.soft_error.effective_address;
> + default:
> + break;
> + }
> + return be64_to_cpu(addr);
> +}
> +
> struct pseries_errorlog *get_pseries_errorlog(struct rtas_error_log *log,
> uint16_t section_id);
>
cheers
^ permalink raw reply
* Re: powerpc/64: Disable irq restore warning for now
From: Michael Ellerman @ 2018-08-08 14:28 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev; +Cc: npiggin
In-Reply-To: <20180807114846.6198-1-mpe@ellerman.id.au>
On Tue, 2018-08-07 at 11:48:46 UTC, Michael Ellerman wrote:
> We recently added a warning in arch_local_irq_restore() to check that
> the soft masking state matches reality.
>
> Unfortunately it trips in a few places, which are not entirely trivial
> to fix. The key problem is if we're doing function_graph tracing of
> restore_math(), the warning pops and then seems to recurse. It's not
> entirely clear because the system continuously oopses on all CPUs,
> with the output interleaved and unreadable.
>
> It's also been observed on a G5 coming out of idle.
>
> Until we can fix those cases disable the warning for now.
>
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Applied to powerpc next.
https://git.kernel.org/powerpc/c/4da1f79227ad42550e3e70e7b4812e
cheers
^ permalink raw reply
* Re: powerpc/Makefiles: Convert ifeq to ifdef where possible
From: Michael Ellerman @ 2018-08-08 14:26 UTC (permalink / raw)
To: Rodrigo R. Galvao
Cc: kstewart, rosattig, mgreer, paulus, sfr, daniel, dale, nfont,
naveen.n.rao, agust, linux, arnd, npiggin, ast, hare, tglx,
maurosr, gregkh, linux-kernel, pombredanne, linuxppc-dev
In-Reply-To: <1533573723-29692-1-git-send-email-rosattig@linux.vnet.ibm.com>
On Mon, 2018-08-06 at 16:42:03 UTC, "Rodrigo R. Galvao" wrote:
> In Makefiles if we're testing a CONFIG_FOO symbol for equality with 'y'
> we can instead just use ifdef. The latter reads easily, so convert to
> it where possible.
>
> Signed-off-by: Rodrigo R. Galvao <rosattig@linux.vnet.ibm.com>
> Reviewed-by: Mauro S. M. Rodrigues <maurosr@linux.vnet.ibm.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/badf436f6fa5dc864d579d73fe7538
cheers
^ permalink raw reply
* Re: misc: cxl: changed asterisk position
From: Michael Ellerman @ 2018-08-08 14:26 UTC (permalink / raw)
To: Parth Y Shah, fbarrat, andrew.donnellan, arnd, gregkh
Cc: linuxppc-dev, linux-kernel, Parth Y Shah
In-Reply-To: <1533291638-22224-1-git-send-email-sparth1292@gmail.com>
On Fri, 2018-08-03 at 10:20:38 UTC, Parth Y Shah wrote:
> Resolved <"foo* bar" should be "foo *bar"> error
>
> Signed-off-by: Parth Y Shah <sparth1292@gmail.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/a0ac3687fb404d59296ecba4642071
cheers
^ permalink raw reply
* Re: powpc:feature: of_node_put is not needed after iterator.
From: Michael Ellerman @ 2018-08-08 14:26 UTC (permalink / raw)
To: zhong jiang, benh; +Cc: paulus, linuxppc-dev, linux-kernel
In-Reply-To: <1533392700-24621-1-git-send-email-zhongjiang@huawei.com>
On Sat, 2018-08-04 at 14:25:00 UTC, zhong jiang wrote:
> for_each_node_by_name iterators only exit normally when the loop
> cursor is NULL, So there is no point to call of_node_put.
>
> Signed-off-by: zhong jiang <zhongjiang@huawei.com>
> Reviewed-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/81d7b08b3cec79a43411e7175401b3
cheers
^ permalink raw reply
* Re: [v4, 1/6] powerpc/traps: Print unhandled signals in a separate function
From: Michael Ellerman @ 2018-08-08 14:26 UTC (permalink / raw)
To: Murilo Opsfelder Araujo, linux-kernel
Cc: Michael Neuling, Murilo Opsfelder Araujo, Simon Guo,
Nicholas Piggin, Paul Mackerras, Eric W . Biederman,
Andrew Donnellan, Alastair D'Silva, Joe Perches,
Sukadev Bhattiprolu, linuxppc-dev, Cyril Bur, Tobin C . Harding
In-Reply-To: <20180801213320.11203-2-muriloo@linux.ibm.com>
On Wed, 2018-08-01 at 21:33:15 UTC, Murilo Opsfelder Araujo wrote:
> Isolate the logic of printing unhandled signals out of _exception_pkey().
> No functional change, only code rearrangement.
>
> Signed-off-by: Murilo Opsfelder Araujo <muriloo@linux.ibm.com>
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/658b0f92bc7003bc734471f61bf7cd
cheers
^ permalink raw reply
* Re: [v3, 1/4] powerpc/64: Make exception table clearer in __copy_tofrom_user_base
From: Michael Ellerman @ 2018-08-08 14:26 UTC (permalink / raw)
To: Paul Mackerras, linuxppc-dev
In-Reply-To: <1533291186-5374-2-git-send-email-paulus@ozlabs.org>
On Fri, 2018-08-03 at 10:13:03 UTC, Paul Mackerras wrote:
> This aims to make the generation of exception table entries for the
> loads and stores in __copy_tofrom_user_base clearer and easier to
> verify. Instead of having a series of local labels on the loads and
> stores, with a series of corresponding labels later for the exception
> handlers, we now use macros to generate exception table entries at the
> point of each load and store that could potentially trap. We do this
> with the macros lex (load exception) and stex (store exception).
> These macros are used right before the load or store to which they
> apply.
>
> Some complexity is introduced by the fact that we have some more work
> to do after hitting an exception, because we need to calculate and
> return the number of bytes not copied. The code uses r3 as the
> current pointer into the destination buffer, that is, the address of
> the first byte of the destination that has not been modified.
> However, at various points in the copy loops, r3 can be 4, 8, 16 or 24
> bytes behind that point.
>
> To express this offset in an understandable way, we define a symbol
> r3_offset which is updated at various points so that it equal to the
> difference between the address of the first unmodified byte of the
> destination and the value in r3. (In fact it only needs to be
> accurate at the point of each lex or stex macro invocation.)
>
> The rules for updating r3_offset are as follows:
>
> * It starts out at 0
> * An addi r3,r3,N instruction decreases r3_offset by N
> * A store instruction (stb, sth, stw, std) to N(r3)
> increases r3_offset by the width of the store (1, 2, 4, 8)
> * A store with update instruction (stbu, sthu, stwu, stdu) to N(r3)
> sets r3_offset to the width of the store.
>
> There is some trickiness to the way that the lex and stex macros and
> the associated exception handlers work. I would have liked to use
> the current value of r3_offset in the name of the symbol used as
> the exception handler, as in ".Lld_exc_$(r3_offset)" and then
> have symbols .Lld_exc_0, .Lld_exc_8, .Lld_exc_16 etc. corresponding
> to the offsets that needed to be added to r3. However, I couldn't
> see a way to do that with gas.
>
> Instead, the exception handler address is .Lld_exc - r3_offset or
> .Lst_exc - r3_offset, that is, the distance ahead of .Lld_exc/.Lst_exc
> that we start executing is equal to the amount that we need to add to
> r3. This works because r3_offset is always a small multiple of 4,
> and our instructions are 4 bytes long. This means that before
> .Lld_exc and .Lst_exc, we have a sequence of instructions that
> increments r3 by 4, 8, 16 or 24 depending on where we start. The
> sequence increments r3 by 4 per instruction (on average).
>
> We also replace the exception table for the 4k copy loop by a
> macro per load or store. These loads and stores all use exactly
> the same exception handler, which simply resets the argument registers
> r3, r4 and r5 to there original values and re-does the whole copy
> using the slower loop.
>
> Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/a7c81ce398e2ad304f61d6167155f3
cheers
^ permalink raw reply
* Re: [v5,8/8] Documentation: Add nospectre_v1 parameter
From: Michael Ellerman @ 2018-08-08 14:26 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev, diana.craciun
Cc: oss, bharat.bhushan, leoyang.li
In-Reply-To: <20180727230639.25413-9-mpe@ellerman.id.au>
On Fri, 2018-07-27 at 23:06:39 UTC, Michael Ellerman wrote:
> From: Diana Craciun <diana.craciun@nxp.com>
>
> Currently only supported on powerpc.
>
> Signed-off-by: Diana Craciun <diana.craciun@nxp.com>
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Applied to powerpc next.
https://git.kernel.org/powerpc/c/26cb1f36c43ee6e89d2a9f48a5a750
cheers
^ permalink raw reply
* Re: [v8,1/4] selftests/powerpc: add test for 32 bits memcmp
From: Michael Ellerman @ 2018-08-08 14:26 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras,
wei.guo.simon, segher
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <b3d7b6cdb89a48be06a2630bf0d762d9d17d931f.1531511429.git.christophe.leroy@c-s.fr>
On Wed, 2018-08-01 at 09:01:10 UTC, Christophe Leroy wrote:
> This patch renames memcmp test to memcmp_64 and adds
> a memcmp_32 test for testing the 32 bits version of memcmp()
>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/1bb07b593adc1934a526eb04acfe8b
cheers
^ permalink raw reply
* Re: [v2, 1/2] selftests/powerpc: Skip earlier in alignment_handler test
From: Michael Ellerman @ 2018-08-08 14:26 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev; +Cc: mikey, andrew.donnellan
In-Reply-To: <20180731120842.32715-1-mpe@ellerman.id.au>
On Tue, 2018-07-31 at 12:08:41 UTC, Michael Ellerman wrote:
> Currently the alignment_handler test prints "Can't open /dev/fb0"
> about 80 times per run, which is a little annoying.
>
> Refactor it to check earlier if it can open /dev/fb0 and skip if not,
> this results in each test printing something like:
>
> test: test_alignment_handler_vsx_206
> tags: git_version:v4.18-rc3-134-gfb21a48904aa
> [SKIP] Test skipped on line 291
> skip: test_alignment_handler_vsx_206
>
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
> Acked-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Series applied to powerpc next.
https://git.kernel.org/powerpc/c/edba42cd14dbb0cc8b48cf786b006a
cheers
^ permalink raw reply
* Re: [v5, 1/8] powerpc/64: Disable the speculation barrier from the command line
From: Michael Ellerman @ 2018-08-08 14:26 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev, diana.craciun
Cc: oss, bharat.bhushan, leoyang.li
In-Reply-To: <20180727230639.25413-2-mpe@ellerman.id.au>
On Fri, 2018-07-27 at 23:06:32 UTC, Michael Ellerman wrote:
> From: Diana Craciun <diana.craciun@nxp.com>
>
> The speculation barrier can be disabled from the command line
> with the parameter: "nospectre_v1".
>
> Signed-off-by: Diana Craciun <diana.craciun@nxp.com>
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Series applied to powerpc next.
https://git.kernel.org/powerpc/c/cf175dc315f90185128fb061dc05b6
cheers
^ permalink raw reply
* Re: [resend] powerpc/64s: fix page table fragment refcount race vs speculative references
From: Michael Ellerman @ 2018-08-08 14:26 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev
Cc: Aneesh Kumar K . V, Andrew Morton, Linus Torvalds,
Nicholas Piggin, linux-mm
In-Reply-To: <20180727114817.27190-1-npiggin@gmail.com>
On Fri, 2018-07-27 at 11:48:17 UTC, Nicholas Piggin wrote:
> The page table fragment allocator uses the main page refcount racily
> with respect to speculative references. A customer observed a BUG due
> to page table page refcount underflow in the fragment allocator. This
> can be caused by the fragment allocator set_page_count stomping on a
> speculative reference, and then the speculative failure handler
> decrements the new reference, and the underflow eventually pops when
> the page tables are freed.
>
> Fix this by using a dedicated field in the struct page for the page
> table fragment allocator.
>
> Fixes: 5c1f6ee9a31c ("powerpc: Reduce PTE table memory wastage")
> Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/4231aba000f5a4583dd9f67057aadb
cheers
^ permalink raw reply
* Re: [01/16] powerpc/64s: Move SET_SCRATCH0() into EXCEPTION_PROLOG_PSERIES()
From: Michael Ellerman @ 2018-08-08 14:26 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev; +Cc: paulus, anton, npiggin
In-Reply-To: <20180726130717.18761-2-mpe@ellerman.id.au>
On Thu, 2018-07-26 at 13:07:02 UTC, Michael Ellerman wrote:
> EXCEPTION_PROLOG_PSERIES() only has two users, STD_EXCEPTION_PSERIES()
> and STD_EXCEPTION_HV() both of which "call" SET_SCRATCH0(), so just
> move SET_SCRATCH0() into EXCEPTION_PROLOG_PSERIES().
>
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Series applied to powerpc next.
https://git.kernel.org/powerpc/c/4a7a0a8444ba4cebb3a6744e9c14fc
cheers
^ permalink raw reply
* Re: [1/3] selftests/powerpc: Add a helper for checking if we're on ppc64le
From: Michael Ellerman @ 2018-08-08 14:26 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev
In-Reply-To: <20180726122459.9293-1-mpe@ellerman.id.au>
On Thu, 2018-07-26 at 12:24:57 UTC, Michael Ellerman wrote:
> Some of our selftests have only been tested on ppc64le and crash or
> behave weirdly on ppc64/ppc32. So add a helper for checking the UTS
> machine.
>
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Series applied to powerpc next.
https://git.kernel.org/powerpc/c/95f9b3af401f5b4daeb908a2c658e8
cheers
^ permalink raw reply
* Re: powerpc/64s: Make rfi_flush_fallback a little more robust
From: Michael Ellerman @ 2018-08-08 14:26 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev; +Cc: anton, npiggin
In-Reply-To: <20180726124244.13993-1-mpe@ellerman.id.au>
On Thu, 2018-07-26 at 12:42:44 UTC, Michael Ellerman wrote:
> Because rfi_flush_fallback runs immediately before the return to
> userspace it currently runs with the user r1 (stack pointer). This
> means if we oops in there we will report a bad kernel stack pointer in
> the exception entry path, eg:
>
> Bad kernel stack pointer 7ffff7150e40 at c0000000000023b4
> Oops: Bad kernel stack pointer, sig: 6 [#1]
> LE SMP NR_CPUS=32 NUMA PowerNV
> Modules linked in:
> CPU: 0 PID: 1246 Comm: klogd Not tainted 4.18.0-rc2-gcc-7.3.1-00175-g0443f8a69ba3 #7
> NIP: c0000000000023b4 LR: 0000000010053e00 CTR: 0000000000000040
> REGS: c0000000fffe7d40 TRAP: 4100 Not tainted (4.18.0-rc2-gcc-7.3.1-00175-g0443f8a69ba3)
> MSR: 9000000002803031 <SF,HV,VEC,VSX,FP,ME,IR,DR,LE> CR: 44000442 XER: 20000000
> CFAR: c00000000000bac8 IRQMASK: c0000000f1e66a80
> GPR00: 0000000002000000 00007ffff7150e40 00007fff93a99900 0000000000000020
> ...
> NIP [c0000000000023b4] rfi_flush_fallback+0x34/0x80
> LR [0000000010053e00] 0x10053e00
>
> Although the NIP tells us where we were, and the TRAP number tells us
> what happened, it would still be nicer if we could report the actual
> exception rather than barfing about the stack pointer.
>
> We an do that fairly simply by loading the kernel stack pointer on
> entry and restoring the user value before returning. That way we see a
> regular oops such as:
>
> Unrecoverable exception 4100 at c00000000000239c
> Oops: Unrecoverable exception, sig: 6 [#1]
> LE SMP NR_CPUS=32 NUMA PowerNV
> Modules linked in:
> CPU: 0 PID: 1251 Comm: klogd Not tainted 4.18.0-rc3-gcc-7.3.1-00097-g4ebfcac65acd-dirty #40
> NIP: c00000000000239c LR: 0000000010053e00 CTR: 0000000000000040
> REGS: c0000000f1e17bb0 TRAP: 4100 Not tainted (4.18.0-rc3-gcc-7.3.1-00097-g4ebfcac65acd-dirty)
> MSR: 9000000002803031 <SF,HV,VEC,VSX,FP,ME,IR,DR,LE> CR: 44000442 XER: 20000000
> CFAR: c00000000000bac8 IRQMASK: 0
> ...
> NIP [c00000000000239c] rfi_flush_fallback+0x3c/0x80
> LR [0000000010053e00] 0x10053e00
> Call Trace:
> [c0000000f1e17e30] [c00000000000b9e4] system_call+0x5c/0x70 (unreliable)
>
> Note this shouldn't make the kernel stack pointer vulnerable to a
> meltdown attack, because it should be flushed from the cache before we
> return to userspace. The user r1 value will be in the cache, because
> we load it in the return path, but that is harmless.
>
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
> Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
Applied to powerpc next.
https://git.kernel.org/powerpc/c/78ee9946371f5848ddfc88ab1a4386
cheers
^ permalink raw reply
* Re: powerpc/pasemi: Use pr_err/pr_warn... for kernel messages
From: Michael Ellerman @ 2018-08-08 14:25 UTC (permalink / raw)
To: Darren Stevens, linuxppc-dev; +Cc: Olof Johansson, Christian Zigotzky
In-Reply-To: <4c4cb05c4d.141a83d@auth.smtp.1and1.co.uk>
On Wed, 2018-07-25 at 20:45:01 UTC, Darren Stevens wrote:
> Pasemi code still uses printk(KERN_ERR/KERN_WARN ... change these to
> pr_err(, pr_warn(... to match other powerpc arch code.
>
> No functional changes.
>
> Signed-off-by: Darren Stevens <darren@stevens-zone.net>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/e13606d7321c0c08d4ac2d74a11026
cheers
^ permalink raw reply
* Re: powerpc/pasemi: Seach for PCI root bus by compatible property
From: Michael Ellerman @ 2018-08-08 14:25 UTC (permalink / raw)
To: Darren Stevens, linuxppc-dev; +Cc: Olof Johansson, Christian Zigotzky
In-Reply-To: <4c4cb2b4391.4d23d508@auth.smtp.1and1.co.uk>
On Wed, 2018-07-25 at 20:55:18 UTC, Darren Stevens wrote:
> Pasemi arch code finds the root of the PCI-e bus by searching the
> device-tree for a node called 'pxp'. But the root bus has a
> compatible property of 'pasemi,rootbus' so search for that instead.
>
> Signed-off-by: Darren Stevens <darren@stevens-zone.net>
> Acked-by: Olof Johansson <olof@lixom.net>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/250a93501d6265bbb9ddf06af25ac9
cheers
^ permalink raw reply
* Re: powerpc/64s: free page table caches at exit_mmap time
From: Michael Ellerman @ 2018-08-08 14:25 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev; +Cc: Aneesh Kumar K . V, Nicholas Piggin
In-Reply-To: <20180725095428.22561-1-npiggin@gmail.com>
On Wed, 2018-07-25 at 09:54:28 UTC, Nicholas Piggin wrote:
> The kernel page table caches are tied to init_mm, so there is no
> more need for them after userspace is finished.
>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
> Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/34c604d27590fdc9a2c944be8c50ae
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