* [PATCH 02/16] powerpc/64s: Move SET_SCRATCH0() into EXCEPTION_RELON_PROLOG_PSERIES()
From: Michael Ellerman @ 2018-07-26 13:07 UTC (permalink / raw)
To: linuxppc-dev; +Cc: npiggin, anton, paulus
In-Reply-To: <20180726130717.18761-1-mpe@ellerman.id.au>
EXCEPTION_RELON_PROLOG_PSERIES() only has two users,
STD_RELON_EXCEPTION_PSERIES() and STD_RELON_EXCEPTION_HV() both of
which "call" SET_SCRATCH0(), so just move SET_SCRATCH0() into
EXCEPTION_RELON_PROLOG_PSERIES().
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/include/asm/exception-64s.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/exception-64s.h b/arch/powerpc/include/asm/exception-64s.h
index d6932990be15..a3027ef75500 100644
--- a/arch/powerpc/include/asm/exception-64s.h
+++ b/arch/powerpc/include/asm/exception-64s.h
@@ -182,6 +182,7 @@
* case EXCEPTION_RELON_PROLOG_PSERIES_1 will be using lr.
*/
#define EXCEPTION_RELON_PROLOG_PSERIES(area, label, h, extra, vec) \
+ SET_SCRATCH0(r13); /* save r13 */ \
EXCEPTION_PROLOG_0(area); \
EXCEPTION_PROLOG_1(area, extra, vec); \
EXCEPTION_RELON_PROLOG_PSERIES_1(label, h)
@@ -575,7 +576,6 @@ END_FTR_SECTION_NESTED(ftr,ftr,943)
#define STD_RELON_EXCEPTION_PSERIES(loc, vec, label) \
/* No guest interrupts come through here */ \
- SET_SCRATCH0(r13); /* save r13 */ \
EXCEPTION_RELON_PROLOG_PSERIES(PACA_EXGEN, label, EXC_STD, NOTEST, vec);
#define STD_RELON_EXCEPTION_PSERIES_OOL(vec, label) \
@@ -583,7 +583,6 @@ END_FTR_SECTION_NESTED(ftr,ftr,943)
EXCEPTION_RELON_PROLOG_PSERIES_1(label, EXC_STD)
#define STD_RELON_EXCEPTION_HV(loc, vec, label) \
- SET_SCRATCH0(r13); /* save r13 */ \
EXCEPTION_RELON_PROLOG_PSERIES(PACA_EXGEN, label, \
EXC_HV, KVMTEST_HV, vec);
--
2.14.1
^ permalink raw reply related
* [PATCH 01/16] powerpc/64s: Move SET_SCRATCH0() into EXCEPTION_PROLOG_PSERIES()
From: Michael Ellerman @ 2018-07-26 13:07 UTC (permalink / raw)
To: linuxppc-dev; +Cc: npiggin, anton, paulus
In-Reply-To: <20180726130717.18761-1-mpe@ellerman.id.au>
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>
---
arch/powerpc/include/asm/exception-64s.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/exception-64s.h b/arch/powerpc/include/asm/exception-64s.h
index c40b4380951c..d6932990be15 100644
--- a/arch/powerpc/include/asm/exception-64s.h
+++ b/arch/powerpc/include/asm/exception-64s.h
@@ -343,6 +343,7 @@ END_FTR_SECTION_NESTED(ftr,ftr,943)
__EXCEPTION_PROLOG_PSERIES_1_NORI(label, h)
#define EXCEPTION_PROLOG_PSERIES(area, label, h, extra, vec) \
+ SET_SCRATCH0(r13); /* save r13 */ \
EXCEPTION_PROLOG_0(area); \
EXCEPTION_PROLOG_1(area, extra, vec); \
EXCEPTION_PROLOG_PSERIES_1(label, h);
@@ -551,7 +552,6 @@ END_FTR_SECTION_NESTED(ftr,ftr,943)
* Exception vectors.
*/
#define STD_EXCEPTION_PSERIES(vec, label) \
- SET_SCRATCH0(r13); /* save r13 */ \
EXCEPTION_PROLOG_PSERIES(PACA_EXGEN, label, \
EXC_STD, KVMTEST_PR, vec); \
@@ -566,7 +566,6 @@ END_FTR_SECTION_NESTED(ftr,ftr,943)
EXCEPTION_PROLOG_PSERIES_1(label, EXC_STD)
#define STD_EXCEPTION_HV(loc, vec, label) \
- SET_SCRATCH0(r13); /* save r13 */ \
EXCEPTION_PROLOG_PSERIES(PACA_EXGEN, label, \
EXC_HV, KVMTEST_HV, vec);
--
2.14.1
^ permalink raw reply related
* [PATCH 00/16] Finally remove PSERIES from exception naming
From: Michael Ellerman @ 2018-07-26 13:07 UTC (permalink / raw)
To: linuxppc-dev; +Cc: npiggin, anton, paulus
This finally annoyed me enough to do something about it, I foolishly started
pulling the string and now here I am.
I think the end result is sufficiently more readable to justify the churn. I
particularly like that we now have EXCEPTION_PROLOG_0/1/2.
It will cause some pain for backports, but Nick plans to rewrite the exception
vectors entirely at some point so this will be trivial in comparison.
cheers
Michael Ellerman (16):
powerpc/64s: Move SET_SCRATCH0() into EXCEPTION_PROLOG_PSERIES()
powerpc/64s: Move SET_SCRATCH0() into EXCEPTION_RELON_PROLOG_PSERIES()
powerpc/64s: Rename STD_EXCEPTION_PSERIES to STD_EXCEPTION
powerpc/64s: Rename STD_EXCEPTION_PSERIES_OOL to STD_EXCEPTION_OOL
powerpc/64s: Rename STD_RELON_EXCEPTION_PSERIES to STD_RELON_EXCEPTION
powerpc/64s: Rename STD_RELON_EXCEPTION_PSERIES_OOL to
STD_RELON_EXCEPTION_OOL
powerpc/64s: Rename EXCEPTION_PROLOG_PSERIES_1 to EXCEPTION_PROLOG_2
powerpc/64s: Remove PSERIES from the NORI macros
powerpc/64s: Rename EXCEPTION_RELON_PROLOG_PSERIES_1
powerpc/64s: Rename EXCEPTION_RELON_PROLOG_PSERIES
powerpc/64s: Rename EXCEPTION_PROLOG_PSERIES to EXCEPTION_PROLOG
powerpc/64s: Drop _MASKABLE_EXCEPTION_PSERIES()
powerpc/64s: Drop _MASKABLE_RELON_EXCEPTION_PSERIES()
powerpc/64s: Remove PSERIES naming from the MASKABLE macros
powerpc/64s: Drop unused loc parameter to MASKABLE_EXCEPTION macros
powerpc/64s: Don't use __MASKABLE_EXCEPTION unnecessarily
arch/powerpc/include/asm/exception-64s.h | 117 ++++++++++++++-----------------
arch/powerpc/include/asm/head-64.h | 16 ++---
arch/powerpc/kernel/exceptions-64s.S | 32 ++++-----
3 files changed, 72 insertions(+), 93 deletions(-)
--
2.14.1
^ permalink raw reply
* Re: [PATCH v4 00/11] hugetlb: Factorize hugetlb architecture primitives
From: Helge Deller @ 2018-07-26 12:59 UTC (permalink / raw)
To: Alex Ghiti
Cc: Michael Ellerman, Michal Hocko, linux, catalin.marinas,
will.deacon, tony.luck, fenghua.yu, ralf, paul.burton, jhogan,
jejb, deller, benh, paulus, ysato, dalias, davem, tglx, mingo,
hpa, x86, arnd, linux-arm-kernel, linux-kernel, linux-ia64,
linux-mips, linux-parisc, linuxppc-dev, linux-sh, sparclinux,
linux-arch, Naoya Horiguchi, Mike Kravetz
In-Reply-To: <67aba0f0-c0d4-b06f-5fbc-f4d113ce5033@ghiti.fr>
* Alex Ghiti <alex@ghiti.fr>:
> This is the result of the build for all arches tackled in this series
> rebased on 4.18-rc6:
> ...
> parisc:
> generic-64bit_defconfig: with huge page does not link
> generic-64bit_defconfig: without huge page does not link
> BUT not because of this series, any feedback welcome.
Strange, but I will check that later....
Anyway, I applied your v4-patch to my parisc64 tree, built the kernel,
started it and ran some hugetlb LTP testcases sucessfully.
So, please add:
Tested-by: Helge Deller <deller@gmx.de> # parisc
Helge
^ permalink raw reply
* [PATCH] powerpc/64s: Make unrecoverable SLB miss less confusing
From: Michael Ellerman @ 2018-07-26 13:01 UTC (permalink / raw)
To: linuxppc-dev; +Cc: npiggin, anton, paulus
If we take an SLB miss while MSR[RI]=0 we can't recover and have to
oops. Currently this is reported by faking up a 0x4100 exception, eg:
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-g7fc2229fb2ab-dirty #9
NIP: 0000000000000000 LR: c00000000000b9e4 CTR: 00007fff8bb971b0
REGS: c0000000ee02bbb0 TRAP: 4100
...
LR [c00000000000b9e4] system_call+0x5c/0x70
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.
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.
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.
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.
Also add a C handler that prints a more explicit message. The end
result is something like:
Oops: Unrecoverable SLB miss (MSR[RI]=0), sig: 6 [#3]
...
CPU: 0 PID: 1262 Comm: sh Not tainted 4.18.0-rc3-gcc-7.3.1-00098-g7fc2229fb2ab-dirty #9
NIP: 0000000000000000 LR: c00000000000b9e4 CTR: 0000000000000000
REGS: c0000000f19a3bb0 TRAP: 0490
...
LR [c00000000000b9e4] system_call+0x5c/0x70
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/include/asm/asm-prototypes.h | 1 +
arch/powerpc/kernel/exceptions-64s.S | 7 +++++--
arch/powerpc/kernel/traps.c | 6 ++++++
3 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/asm-prototypes.h b/arch/powerpc/include/asm/asm-prototypes.h
index 7841b8a60657..ffba4a6ee619 100644
--- a/arch/powerpc/include/asm/asm-prototypes.h
+++ b/arch/powerpc/include/asm/asm-prototypes.h
@@ -74,6 +74,7 @@ void facility_unavailable_exception(struct pt_regs *regs);
void TAUException(struct pt_regs *regs);
void altivec_assist_exception(struct pt_regs *regs);
void unrecoverable_exception(struct pt_regs *regs);
+void unrecoverable_slb_miss(struct pt_regs *regs);
void kernel_bad_stack(struct pt_regs *regs);
void system_reset_exception(struct pt_regs *regs);
void machine_check_exception(struct pt_regs *regs);
diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S
index a6fa85916273..8e1396433eb4 100644
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -743,11 +743,14 @@ END_MMU_FTR_SECTION_IFCLR(MMU_FTR_TYPE_RADIX)
b .
EXC_COMMON_BEGIN(unrecov_slb)
- EXCEPTION_PROLOG_COMMON(0x4100, PACA_EXSLB)
+ EXCEPTION_PROLOG_COMMON(0x390, PACA_EXSLB)
RECONCILE_IRQ_STATE(r10, r11)
bl save_nvgprs
+ beq cr6, 1f // cr6.eq is set for a data SLB miss ...
+ li r10, 0x490 // else fix trap number for instruction SLB miss
+ std r10, _TRAP(r1)
1: addi r3,r1,STACK_FRAME_OVERHEAD
- bl unrecoverable_exception
+ bl unrecoverable_slb_miss
b 1b
EXC_COMMON_BEGIN(large_addr_slb)
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index 0e17dcb48720..0b1724a0b001 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -2061,6 +2061,12 @@ void unrecoverable_exception(struct pt_regs *regs)
}
NOKPROBE_SYMBOL(unrecoverable_exception);
+void unrecoverable_slb_miss(struct pt_regs *regs)
+{
+ die("Unrecoverable SLB miss (MSR[RI]=0)", regs, SIGABRT);
+}
+NOKPROBE_SYMBOL(unrecoverable_slb_miss);
+
#if defined(CONFIG_BOOKE_WDT) || defined(CONFIG_40x)
/*
* Default handler for a Watchdog exception,
--
2.14.1
^ permalink raw reply related
* Re: [PATCH v7 4/4] kexec_file: Load kernel at top of system RAM if required
From: Michal Hocko @ 2018-07-26 12:59 UTC (permalink / raw)
To: Baoquan He
Cc: Andrew Morton, linux-kernel, robh+dt, dan.j.williams,
nicolas.pitre, josh, fengguang.wu, bp, andy.shevchenko,
patrik.r.jakobsson, airlied, kys, haiyangz, sthemmin,
dmitry.torokhov, frowand.list, keith.busch, jonathan.derrick,
lorenzo.pieralisi, bhelgaas, tglx, brijesh.singh, jglisse,
thomas.lendacky, gregkh, baiyaowei, richard.weiyang, devel,
linux-input, linux-nvdimm, devicetree, linux-pci, ebiederm,
vgoyal, dyoung, yinghai, monstr, davem, chris, jcmvbkbc, gustavo,
maarten.lankhorst, seanpaul, linux-parisc, linuxppc-dev, kexec
In-Reply-To: <20180725064813.GI6480@MiWiFi-R3L-srv>
On Wed 25-07-18 14:48:13, Baoquan He wrote:
> On 07/23/18 at 04:34pm, Michal Hocko wrote:
> > On Thu 19-07-18 23:17:53, Baoquan He wrote:
> > > Kexec has been a formal feature in our distro, and customers owning
> > > those kind of very large machine can make use of this feature to speed
> > > up the reboot process. On uefi machine, the kexec_file loading will
> > > search place to put kernel under 4G from top to down. As we know, the
> > > 1st 4G space is DMA32 ZONE, dma, pci mmcfg, bios etc all try to consume
> > > it. It may have possibility to not be able to find a usable space for
> > > kernel/initrd. From the top down of the whole memory space, we don't
> > > have this worry.
> >
> > I do not have the full context here but let me note that you should be
> > careful when doing top-down reservation because you can easily get into
> > hotplugable memory and break the hotremove usecase. We even warn when
> > this is done. See memblock_find_in_range_node
>
> Kexec read kernel/initrd file into buffer, just search usable positions
> for them to do the later copying. You can see below struct kexec_segment,
> for the old kexec_load, kernel/initrd are read into user space buffer,
> the @buf stores the user space buffer address, @mem stores the position
> where kernel/initrd will be put. In kernel, it calls
> kimage_load_normal_segment() to copy user space buffer to intermediate
> pages which are allocated with flag GFP_KERNEL. These intermediate pages
> are recorded as entries, later when user execute "kexec -e" to trigger
> kexec jumping, it will do the final copying from the intermediate pages
> to the real destination pages which @mem pointed. Because we can't touch
> the existed data in 1st kernel when do kexec kernel loading. With my
> understanding, GFP_KERNEL will make those intermediate pages be
> allocated inside immovable area, it won't impact hotplugging. But the
> @mem we searched in the whole system RAM might be lost along with
> hotplug. Hence we need do kexec kernel again when hotplug event is
> detected.
I am not sure I am following. If @mem is placed at movable node then the
memory hotremove simply won't work, because we are seeing reserved pages
and do not know what to do about them. They are not migrateable.
Allocating intermediate pages from other nodes doesn't really help.
The memblock code warns exactly for that reason.
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* Re: [PATCH 2/3] selftests/powerpc: Only run some tests on ppc64le
From: Gustavo Romero @ 2018-07-26 12:54 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev
In-Reply-To: <20180726122459.9293-2-mpe@ellerman.id.au>
Hi Michael,
On 07/26/2018 09:24 AM, Michael Ellerman wrote:
> These tests are currently failing on (some) big endian systems. Until
> we can fix that, skip them unless we're on ppc64le.
I can take a look at this.
Is that the same issue related to the gcc version we discussed a month ago?
If not, could you provide the crash logs as a starting point?
Thanks,
Gustavo
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
> ---
> tools/testing/selftests/powerpc/tm/tm-sigreturn.c | 1 +
> tools/testing/selftests/powerpc/tm/tm-tar.c | 1 +
> tools/testing/selftests/powerpc/tm/tm-vmxcopy.c | 1 +
> 3 files changed, 3 insertions(+)
>
> diff --git a/tools/testing/selftests/powerpc/tm/tm-sigreturn.c b/tools/testing/selftests/powerpc/tm/tm-sigreturn.c
> index 85d63449243b..9a6017a1d769 100644
> --- a/tools/testing/selftests/powerpc/tm/tm-sigreturn.c
> +++ b/tools/testing/selftests/powerpc/tm/tm-sigreturn.c
> @@ -55,6 +55,7 @@ int tm_sigreturn(void)
> uint64_t ret = 0;
>
> SKIP_IF(!have_htm());
> + SKIP_IF(!is_ppc64le());
>
> memset(&sa, 0, sizeof(sa));
> sa.sa_handler = handler;
> diff --git a/tools/testing/selftests/powerpc/tm/tm-tar.c b/tools/testing/selftests/powerpc/tm/tm-tar.c
> index 2d2fcc2b7a60..f31fe5a28ddb 100644
> --- a/tools/testing/selftests/powerpc/tm/tm-tar.c
> +++ b/tools/testing/selftests/powerpc/tm/tm-tar.c
> @@ -26,6 +26,7 @@ int test_tar(void)
> int i;
>
> SKIP_IF(!have_htm());
> + SKIP_IF(!is_ppc64le());
>
> for (i = 0; i < num_loops; i++)
> {
> diff --git a/tools/testing/selftests/powerpc/tm/tm-vmxcopy.c b/tools/testing/selftests/powerpc/tm/tm-vmxcopy.c
> index 0274de7b11f3..fe52811584ae 100644
> --- a/tools/testing/selftests/powerpc/tm/tm-vmxcopy.c
> +++ b/tools/testing/selftests/powerpc/tm/tm-vmxcopy.c
> @@ -46,6 +46,7 @@ int test_vmxcopy()
> uint64_t aborted = 0;
>
> SKIP_IF(!have_htm());
> + SKIP_IF(!is_ppc64le());
>
> fd = mkstemp(tmpfile);
> assert(fd >= 0);
>
^ permalink raw reply
* [PATCH] Adds __init annotation at mmu_init_secondary func
From: Alexey Spirkov @ 2018-07-26 12:52 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
linuxppc-dev@lists.ozlabs.org
Cc: trivial@kernel.org, andrew@ncrmnt.org
mmu_init_secondary function called at initialization sequence
but it misses __init annotation. As result modpost warning is generated.
Some building systems sensitive to such kind of warnings.
Signed-off-by: Alexey Spirkov <alexeis@astrosoft.ru>
---
arch/powerpc/mm/44x_mmu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/mm/44x_mmu.c b/arch/powerpc/mm/44x_mmu.c
index 82b1ff7..12d9251 100644
--- a/arch/powerpc/mm/44x_mmu.c
+++ b/arch/powerpc/mm/44x_mmu.c
@@ -229,7 +229,7 @@ void setup_initial_memory_limit(phys_addr_t first_membl=
ock_base,
}
=20
#ifdef CONFIG_SMP
-void mmu_init_secondary(int cpu)
+void __init mmu_init_secondary(int cpu)
{
unsigned long addr;
unsigned long memstart =3D memstart_addr & ~(PPC_PIN_SIZE - 1);
--=20
2.9.5
^ permalink raw reply related
* [PATCH] powerpc/64s: Make rfi_flush_fallback a little more robust
From: Michael Ellerman @ 2018-07-26 12:42 UTC (permalink / raw)
To: linuxppc-dev; +Cc: npiggin, anton
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>
---
arch/powerpc/kernel/exceptions-64s.S | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S
index f7cc12aa3dc6..a6fa85916273 100644
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -1518,6 +1518,8 @@ TRAMP_REAL_BEGIN(stf_barrier_fallback)
TRAMP_REAL_BEGIN(rfi_flush_fallback)
SET_SCRATCH0(r13);
GET_PACA(r13);
+ std r1,PACA_EXRFI+EX_R12(r13)
+ ld r1,PACAKSAVE(r13)
std r9,PACA_EXRFI+EX_R9(r13)
std r10,PACA_EXRFI+EX_R10(r13)
std r11,PACA_EXRFI+EX_R11(r13)
@@ -1552,12 +1554,15 @@ TRAMP_REAL_BEGIN(rfi_flush_fallback)
ld r9,PACA_EXRFI+EX_R9(r13)
ld r10,PACA_EXRFI+EX_R10(r13)
ld r11,PACA_EXRFI+EX_R11(r13)
+ ld r1,PACA_EXRFI+EX_R12(r13)
GET_SCRATCH0(r13);
rfid
TRAMP_REAL_BEGIN(hrfi_flush_fallback)
SET_SCRATCH0(r13);
GET_PACA(r13);
+ std r1,PACA_EXRFI+EX_R12(r13)
+ ld r1,PACAKSAVE(r13)
std r9,PACA_EXRFI+EX_R9(r13)
std r10,PACA_EXRFI+EX_R10(r13)
std r11,PACA_EXRFI+EX_R11(r13)
@@ -1592,6 +1597,7 @@ TRAMP_REAL_BEGIN(hrfi_flush_fallback)
ld r9,PACA_EXRFI+EX_R9(r13)
ld r10,PACA_EXRFI+EX_R10(r13)
ld r11,PACA_EXRFI+EX_R11(r13)
+ ld r1,PACA_EXRFI+EX_R12(r13)
GET_SCRATCH0(r13);
hrfid
--
2.14.1
^ permalink raw reply related
* [PATCH 3/3] selftests/powerpc: Give some tests longer to run
From: Michael Ellerman @ 2018-07-26 12:24 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20180726122459.9293-1-mpe@ellerman.id.au>
Some of these long running tests can time out on heavily loaded
systems, give them longer to run.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
tools/testing/selftests/powerpc/benchmarks/futex_bench.c | 1 +
tools/testing/selftests/powerpc/benchmarks/mmap_bench.c | 2 ++
tools/testing/selftests/powerpc/pmu/ebb/instruction_count_test.c | 1 +
tools/testing/selftests/powerpc/pmu/ebb/lost_exception_test.c | 1 +
tools/testing/selftests/powerpc/stringloops/memcmp.c | 1 +
5 files changed, 6 insertions(+)
diff --git a/tools/testing/selftests/powerpc/benchmarks/futex_bench.c b/tools/testing/selftests/powerpc/benchmarks/futex_bench.c
index 2fc711d9150d..d58e4dc50fcd 100644
--- a/tools/testing/selftests/powerpc/benchmarks/futex_bench.c
+++ b/tools/testing/selftests/powerpc/benchmarks/futex_bench.c
@@ -38,5 +38,6 @@ int test_futex(void)
int main(void)
{
+ test_harness_set_timeout(300);
return test_harness(test_futex, "futex_bench");
}
diff --git a/tools/testing/selftests/powerpc/benchmarks/mmap_bench.c b/tools/testing/selftests/powerpc/benchmarks/mmap_bench.c
index 7a0a462a2272..033de0560d99 100644
--- a/tools/testing/selftests/powerpc/benchmarks/mmap_bench.c
+++ b/tools/testing/selftests/powerpc/benchmarks/mmap_bench.c
@@ -84,5 +84,7 @@ int main(int argc, char *argv[])
exit(1);
}
}
+
+ test_harness_set_timeout(300);
return test_harness(test_mmap, "mmap_bench");
}
diff --git a/tools/testing/selftests/powerpc/pmu/ebb/instruction_count_test.c b/tools/testing/selftests/powerpc/pmu/ebb/instruction_count_test.c
index ae9a79086111..35a3426e341c 100644
--- a/tools/testing/selftests/powerpc/pmu/ebb/instruction_count_test.c
+++ b/tools/testing/selftests/powerpc/pmu/ebb/instruction_count_test.c
@@ -162,5 +162,6 @@ int instruction_count(void)
int main(void)
{
+ test_harness_set_timeout(300);
return test_harness(instruction_count, "instruction_count");
}
diff --git a/tools/testing/selftests/powerpc/pmu/ebb/lost_exception_test.c b/tools/testing/selftests/powerpc/pmu/ebb/lost_exception_test.c
index eb8acb78bc6c..2ed7ad33f7a3 100644
--- a/tools/testing/selftests/powerpc/pmu/ebb/lost_exception_test.c
+++ b/tools/testing/selftests/powerpc/pmu/ebb/lost_exception_test.c
@@ -98,5 +98,6 @@ static int lost_exception(void)
int main(void)
{
+ test_harness_set_timeout(300);
return test_harness(lost_exception, "lost_exception");
}
diff --git a/tools/testing/selftests/powerpc/stringloops/memcmp.c b/tools/testing/selftests/powerpc/stringloops/memcmp.c
index b5cf71727b2d..b1fa7546957f 100644
--- a/tools/testing/selftests/powerpc/stringloops/memcmp.c
+++ b/tools/testing/selftests/powerpc/stringloops/memcmp.c
@@ -154,5 +154,6 @@ static int testcases(void)
int main(void)
{
+ test_harness_set_timeout(300);
return test_harness(testcases, "memcmp");
}
--
2.14.1
^ permalink raw reply related
* [PATCH 2/3] selftests/powerpc: Only run some tests on ppc64le
From: Michael Ellerman @ 2018-07-26 12:24 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20180726122459.9293-1-mpe@ellerman.id.au>
These tests are currently failing on (some) big endian systems. Until
we can fix that, skip them unless we're on ppc64le.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
tools/testing/selftests/powerpc/tm/tm-sigreturn.c | 1 +
tools/testing/selftests/powerpc/tm/tm-tar.c | 1 +
tools/testing/selftests/powerpc/tm/tm-vmxcopy.c | 1 +
3 files changed, 3 insertions(+)
diff --git a/tools/testing/selftests/powerpc/tm/tm-sigreturn.c b/tools/testing/selftests/powerpc/tm/tm-sigreturn.c
index 85d63449243b..9a6017a1d769 100644
--- a/tools/testing/selftests/powerpc/tm/tm-sigreturn.c
+++ b/tools/testing/selftests/powerpc/tm/tm-sigreturn.c
@@ -55,6 +55,7 @@ int tm_sigreturn(void)
uint64_t ret = 0;
SKIP_IF(!have_htm());
+ SKIP_IF(!is_ppc64le());
memset(&sa, 0, sizeof(sa));
sa.sa_handler = handler;
diff --git a/tools/testing/selftests/powerpc/tm/tm-tar.c b/tools/testing/selftests/powerpc/tm/tm-tar.c
index 2d2fcc2b7a60..f31fe5a28ddb 100644
--- a/tools/testing/selftests/powerpc/tm/tm-tar.c
+++ b/tools/testing/selftests/powerpc/tm/tm-tar.c
@@ -26,6 +26,7 @@ int test_tar(void)
int i;
SKIP_IF(!have_htm());
+ SKIP_IF(!is_ppc64le());
for (i = 0; i < num_loops; i++)
{
diff --git a/tools/testing/selftests/powerpc/tm/tm-vmxcopy.c b/tools/testing/selftests/powerpc/tm/tm-vmxcopy.c
index 0274de7b11f3..fe52811584ae 100644
--- a/tools/testing/selftests/powerpc/tm/tm-vmxcopy.c
+++ b/tools/testing/selftests/powerpc/tm/tm-vmxcopy.c
@@ -46,6 +46,7 @@ int test_vmxcopy()
uint64_t aborted = 0;
SKIP_IF(!have_htm());
+ SKIP_IF(!is_ppc64le());
fd = mkstemp(tmpfile);
assert(fd >= 0);
--
2.14.1
^ permalink raw reply related
* [PATCH 1/3] selftests/powerpc: Add a helper for checking if we're on ppc64le
From: Michael Ellerman @ 2018-07-26 12:24 UTC (permalink / raw)
To: linuxppc-dev
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>
---
tools/testing/selftests/powerpc/include/utils.h | 2 ++
tools/testing/selftests/powerpc/utils.c | 17 +++++++++++++++++
2 files changed, 19 insertions(+)
diff --git a/tools/testing/selftests/powerpc/include/utils.h b/tools/testing/selftests/powerpc/include/utils.h
index 735815b3ad7f..c58c370828b4 100644
--- a/tools/testing/selftests/powerpc/include/utils.h
+++ b/tools/testing/selftests/powerpc/include/utils.h
@@ -48,6 +48,8 @@ static inline bool have_hwcap2(unsigned long ftr2)
}
#endif
+bool is_ppc64le(void);
+
/* Yes, this is evil */
#define FAIL_IF(x) \
do { \
diff --git a/tools/testing/selftests/powerpc/utils.c b/tools/testing/selftests/powerpc/utils.c
index d46916867a6f..aa8fc1e6365b 100644
--- a/tools/testing/selftests/powerpc/utils.c
+++ b/tools/testing/selftests/powerpc/utils.c
@@ -11,8 +11,10 @@
#include <link.h>
#include <sched.h>
#include <stdio.h>
+#include <string.h>
#include <sys/stat.h>
#include <sys/types.h>
+#include <sys/utsname.h>
#include <unistd.h>
#include "utils.h"
@@ -104,3 +106,18 @@ int pick_online_cpu(void)
printf("No cpus in affinity mask?!\n");
return -1;
}
+
+bool is_ppc64le(void)
+{
+ struct utsname uts;
+ int rc;
+
+ errno = 0;
+ rc = uname(&uts);
+ if (rc) {
+ perror("uname");
+ return false;
+ }
+
+ return strcmp(uts.machine, "ppc64le") == 0;
+}
--
2.14.1
^ permalink raw reply related
* Re: [PATCH v4 00/11] hugetlb: Factorize hugetlb architecture primitives
From: Michael Ellerman @ 2018-07-26 11:46 UTC (permalink / raw)
To: Mike Kravetz, Alex Ghiti, Michal Hocko
Cc: linux, catalin.marinas, will.deacon, tony.luck, fenghua.yu, ralf,
paul.burton, jhogan, jejb, deller, benh, paulus, ysato, dalias,
davem, tglx, mingo, hpa, x86, arnd, linux-arm-kernel,
linux-kernel, linux-ia64, linux-mips, linux-parisc, linuxppc-dev,
linux-sh, sparclinux, linux-arch, Naoya Horiguchi,
Aneesh Kumar K . V
In-Reply-To: <75195a7d-3d0f-4e55-92cc-4ad772683c75@oracle.com>
Mike Kravetz <mike.kravetz@oracle.com> writes:
> On 07/20/2018 11:37 AM, Alex Ghiti wrote:
>> Does anyone have any suggestion about those patches ?
>
> I only took a quick look. From the hugetlb perspective, I like the
> idea of moving routines to a common file. If any of the arch owners
> (or anyone else) agree, I can do a review of the series.
The conversions look pretty good to me. If you want to give it a review
then from my point of view it could go in -mm to shake out any bugs.
cheers
^ permalink raw reply
* [PATCH 1/2] KVM: PPC: Book3S HV: Allow creating max number of VCPUs on POWER9
From: Paul Mackerras @ 2018-07-26 5:43 UTC (permalink / raw)
To: kvm, kvm-ppc, linuxppc-dev; +Cc: Sam Bobroff, David Gibson
Commit 1e175d2 ("KVM: PPC: Book3S HV: Pack VCORE IDs to access full
VCPU ID space", 2018-07-25) allowed use of VCPU IDs up to
KVM_MAX_VCPU_ID on POWER9 in all guest SMT modes and guest emulated
hardware SMT modes. However, with the current definition of
KVM_MAX_VCPU_ID, a guest SMT mode of 1 and an emulated SMT mode of 8,
it is only possible to create KVM_MAX_VCPUS / 2 VCPUS, because
threads_per_subcore is 4 on POWER9 CPUs. (Using an emulated SMT mode
of 8 is useful when migrating VMs to or from POWER8 hosts.)
This increases KVM_MAX_VCPU_ID to 8 * KVM_MAX_VCPUS when HV KVM is
configured in, so that a full complement of KVM_MAX_VCPUS VCPUs can
be created on POWER9 in all guest SMT modes and emulated hardware
SMT modes.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
---
This and the next patch apply on my kvm-ppc-next branch, which
includes Sam Bobroff's patch "KVM: PPC: Book3S HV: Pack VCORE IDs to
access full VCPU ID space".
arch/powerpc/include/asm/kvm_host.h | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/kvm_host.h b/arch/powerpc/include/asm/kvm_host.h
index 5b9e660..906bcbdf 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -42,7 +42,14 @@
#define KVM_USER_MEM_SLOTS 512
#include <asm/cputhreads.h>
-#define KVM_MAX_VCPU_ID (threads_per_subcore * KVM_MAX_VCORES)
+
+#ifdef CONFIG_KVM_BOOK3S_HV_POSSIBLE
+#include <asm/kvm_book3s_asm.h> /* for MAX_SMT_THREADS */
+#define KVM_MAX_VCPU_ID (MAX_SMT_THREADS * KVM_MAX_VCORES)
+
+#else
+#define KVM_MAX_VCPU_ID KVM_MAX_VCPUS
+#endif /* CONFIG_KVM_BOOK3S_HV_POSSIBLE */
#define __KVM_HAVE_ARCH_INTC_INITIALIZED
--
2.7.4
^ permalink raw reply related
* [PATCH 2/2] KVM: PPC: Book3S HV: Read kvm->arch.emul_smt_mode under kvm->lock
From: Paul Mackerras @ 2018-07-26 5:44 UTC (permalink / raw)
To: kvm, kvm-ppc, linuxppc-dev; +Cc: Sam Bobroff, David Gibson
Commit 1e175d2 ("KVM: PPC: Book3S HV: Pack VCORE IDs to access full
VCPU ID space", 2018-07-25) added code that uses kvm->arch.emul_smt_mode
before any VCPUs are created. However, userspace can change
kvm->arch.emul_smt_mode at any time up until the first VCPU is created.
Hence it is (theoretically) possible for the check in
kvmppc_core_vcpu_create_hv() to race with another userspace thread
changing kvm->arch.emul_smt_mode.
This fixes it by moving the test that uses kvm->arch.emul_smt_mode into
the block where kvm->lock is held.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
---
arch/powerpc/kvm/book3s_hv.c | 17 ++++++++---------
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
index 785245e..113f815 100644
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -1989,16 +1989,10 @@ static struct kvm_vcpu *kvmppc_core_vcpu_create_hv(struct kvm *kvm,
unsigned int id)
{
struct kvm_vcpu *vcpu;
- int err = -EINVAL;
+ int err;
int core;
struct kvmppc_vcore *vcore;
- if (id >= (KVM_MAX_VCPUS * kvm->arch.emul_smt_mode) &&
- cpu_has_feature(CPU_FTR_ARCH_300)) {
- pr_devel("DNCI: VCPU ID too high\n");
- goto out;
- }
-
err = -ENOMEM;
vcpu = kmem_cache_zalloc(kvm_vcpu_cache, GFP_KERNEL);
if (!vcpu)
@@ -2055,8 +2049,13 @@ static struct kvm_vcpu *kvmppc_core_vcpu_create_hv(struct kvm *kvm,
vcore = NULL;
err = -EINVAL;
if (cpu_has_feature(CPU_FTR_ARCH_300)) {
- BUG_ON(kvm->arch.smt_mode != 1);
- core = kvmppc_pack_vcpu_id(kvm, id);
+ if (id >= (KVM_MAX_VCPUS * kvm->arch.emul_smt_mode)) {
+ pr_devel("KVM: VCPU ID too high\n");
+ core = KVM_MAX_VCORES;
+ } else {
+ BUG_ON(kvm->arch.smt_mode != 1);
+ core = kvmppc_pack_vcpu_id(kvm, id);
+ }
} else {
core = id / kvm->arch.smt_mode;
}
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v4 00/11] hugetlb: Factorize hugetlb architecture primitives
From: Alex Ghiti @ 2018-07-26 5:41 UTC (permalink / raw)
To: Michael Ellerman, Michal Hocko
Cc: linux, catalin.marinas, will.deacon, tony.luck, fenghua.yu, ralf,
paul.burton, jhogan, jejb, deller, benh, paulus, ysato, dalias,
davem, tglx, mingo, hpa, x86, arnd, linux-arm-kernel,
linux-kernel, linux-ia64, linux-mips, linux-parisc, linuxppc-dev,
linux-sh, sparclinux, linux-arch, Naoya Horiguchi, Mike Kravetz
In-Reply-To: <87d0vehx16.fsf@concordia.ellerman.id.au>
Hi everyone,
This is the result of the build for all arches tackled in this series
rebased on 4.18-rc6:
arm:
versatile_defconfig: without huge page OK
keystone_defconfig: with huge page OK
arm64:
defconfig: with huge page OK
ia64:
generic_defconfig: with huge page OK
mips:
Paul Burton tested cavium octeon with huge page OK
parisc:
generic-64bit_defconfig: with huge page does not link
generic-64bit_defconfig: without huge page does not link
BUT not because of this series, any feedback welcome.
powerpc:
ppc64_defconfig: without huge page OK
ppc64_defconfig: with huge page OK
sh:
dreamcast_defconfig: with huge page OK
sparc:
sparc32_defconfig: without huge page OK
sparc64:
sparc64_defconfig: with huge page OK
x86:
with huge page OK
Alex
On 07/23/2018 02:00 PM, Michael Ellerman wrote:
> Alex Ghiti <alex@ghiti.fr> writes:
>
>> Does anyone have any suggestion about those patches ?
> Cross compiling it for some non-x86 arches would be a good start :)
>
> There are cross compilers available here:
>
> https://mirrors.edge.kernel.org/pub/tools/crosstool/
>
>
> cheers
>
>> On 07/09/2018 02:16 PM, Michal Hocko wrote:
>>> [CC hugetlb guys - http://lkml.kernel.org/r/20180705110716.3919-1-alex@ghiti.fr]
>>>
>>> On Thu 05-07-18 11:07:05, Alexandre Ghiti wrote:
>>>> In order to reduce copy/paste of functions across architectures and then
>>>> make riscv hugetlb port (and future ports) simpler and smaller, this
>>>> patchset intends to factorize the numerous hugetlb primitives that are
>>>> defined across all the architectures.
>>>>
>>>> Except for prepare_hugepage_range, this patchset moves the versions that
>>>> are just pass-through to standard pte primitives into
>>>> asm-generic/hugetlb.h by using the same #ifdef semantic that can be
>>>> found in asm-generic/pgtable.h, i.e. __HAVE_ARCH_***.
>>>>
>>>> s390 architecture has not been tackled in this serie since it does not
>>>> use asm-generic/hugetlb.h at all.
>>>> powerpc could be factorized a bit more (cf huge_ptep_set_wrprotect).
>>>>
>>>> This patchset has been compiled on x86 only.
>>>>
>>>> Changelog:
>>>>
>>>> v4:
>>>> Fix powerpc build error due to misplacing of #include
>>>> <asm-generic/hugetlb.h> outside of #ifdef CONFIG_HUGETLB_PAGE, as
>>>> pointed by Christophe Leroy.
>>>>
>>>> v1, v2, v3:
>>>> Same version, just problems with email provider and misuse of
>>>> --batch-size option of git send-email
>>>>
>>>> Alexandre Ghiti (11):
>>>> hugetlb: Harmonize hugetlb.h arch specific defines with pgtable.h
>>>> hugetlb: Introduce generic version of hugetlb_free_pgd_range
>>>> hugetlb: Introduce generic version of set_huge_pte_at
>>>> hugetlb: Introduce generic version of huge_ptep_get_and_clear
>>>> hugetlb: Introduce generic version of huge_ptep_clear_flush
>>>> hugetlb: Introduce generic version of huge_pte_none
>>>> hugetlb: Introduce generic version of huge_pte_wrprotect
>>>> hugetlb: Introduce generic version of prepare_hugepage_range
>>>> hugetlb: Introduce generic version of huge_ptep_set_wrprotect
>>>> hugetlb: Introduce generic version of huge_ptep_set_access_flags
>>>> hugetlb: Introduce generic version of huge_ptep_get
>>>>
>>>> arch/arm/include/asm/hugetlb-3level.h | 32 +---------
>>>> arch/arm/include/asm/hugetlb.h | 33 +----------
>>>> arch/arm64/include/asm/hugetlb.h | 39 +++---------
>>>> arch/ia64/include/asm/hugetlb.h | 47 ++-------------
>>>> arch/mips/include/asm/hugetlb.h | 40 +++----------
>>>> arch/parisc/include/asm/hugetlb.h | 33 +++--------
>>>> arch/powerpc/include/asm/book3s/32/pgtable.h | 2 +
>>>> arch/powerpc/include/asm/book3s/64/pgtable.h | 1 +
>>>> arch/powerpc/include/asm/hugetlb.h | 43 ++------------
>>>> arch/powerpc/include/asm/nohash/32/pgtable.h | 2 +
>>>> arch/powerpc/include/asm/nohash/64/pgtable.h | 1 +
>>>> arch/sh/include/asm/hugetlb.h | 54 ++---------------
>>>> arch/sparc/include/asm/hugetlb.h | 40 +++----------
>>>> arch/x86/include/asm/hugetlb.h | 72 +----------------------
>>>> include/asm-generic/hugetlb.h | 88 +++++++++++++++++++++++++++-
>>>> 15 files changed, 143 insertions(+), 384 deletions(-)
>>>>
>>>> --
>>>> 2.16.2
^ permalink raw reply
* Re: [PATCH v4 1/1] KVM: PPC: Book3S HV: pack VCORE IDs to access full VCPU ID space
From: Paul Mackerras @ 2018-07-26 3:22 UTC (permalink / raw)
To: Sam Bobroff; +Cc: linuxppc-dev, kvm, kvm-ppc, david, clg
In-Reply-To: <dc8e985d05d7de08cce080dfe6e70beeed2a50a1.1532499120.git.sbobroff@linux.ibm.com>
On Wed, Jul 25, 2018 at 04:12:02PM +1000, Sam Bobroff wrote:
> From: Sam Bobroff <sam.bobroff@au1.ibm.com>
>
> It is not currently possible to create the full number of possible
> VCPUs (KVM_MAX_VCPUS) on Power9 with KVM-HV when the guest uses less
> threads per core than it's core stride (or "VSMT mode"). This is
> because the VCORE ID and XIVE offsets to grow beyond KVM_MAX_VCPUS
> even though the VCPU ID is less than KVM_MAX_VCPU_ID.
>
> To address this, "pack" the VCORE ID and XIVE offsets by using
> knowledge of the way the VCPU IDs will be used when there are less
> guest threads per core than the core stride. The primary thread of
> each core will always be used first. Then, if the guest uses more than
> one thread per core, these secondary threads will sequentially follow
> the primary in each core.
>
> So, the only way an ID above KVM_MAX_VCPUS can be seen, is if the
> VCPUs are being spaced apart, so at least half of each core is empty
> and IDs between KVM_MAX_VCPUS and (KVM_MAX_VCPUS * 2) can be mapped
> into the second half of each core (4..7, in an 8-thread core).
>
> Similarly, if IDs above KVM_MAX_VCPUS * 2 are seen, at least 3/4 of
> each core is being left empty, and we can map down into the second and
> third quarters of each core (2, 3 and 5, 6 in an 8-thread core).
>
> Lastly, if IDs above KVM_MAX_VCPUS * 4 are seen, only the primary
> threads are being used and 7/8 of the core is empty, allowing use of
> the 1, 5, 3 and 7 thread slots.
>
> (Strides less than 8 are handled similarly.)
>
> This allows the VCORE ID or offset to be calculated quickly from the
> VCPU ID or XIVE server numbers, without access to the VCPU structure.
>
> Signed-off-by: Sam Bobroff <sam.bobroff@au1.ibm.com>
I noticed a problem:
> @@ -1989,10 +1989,15 @@ static struct kvm_vcpu *kvmppc_core_vcpu_create_hv(struct kvm *kvm,
> unsigned int id)
> {
> struct kvm_vcpu *vcpu;
> - int err;
> + int err = -EINVAL;
> int core;
> struct kvmppc_vcore *vcore;
>
> + if (id >= (KVM_MAX_VCPUS * kvm->arch.emul_smt_mode)) {
> + WARN_ONCE(true, "DNCI: VCPU ID too high\n");
> + goto out;
> + }
On POWER8, kvm->arch.emul_smt_mode will be either 1 or 0, so this test
needs to be conditional on CPU_FTR_ARCH_300. I'll fix it.
Also, kvm->arch.emul_smt_mode can change at any time until the first
vcore is created, so this test should be done while holding kvm->lock.
Paul.
^ permalink raw reply
* Re: [PATCH 0/7] powerpc: Modernize unhandled signals message
From: Michael Ellerman @ 2018-07-26 2:20 UTC (permalink / raw)
To: Murilo Opsfelder Araujo, Michael Neuling
Cc: linux-kernel, Alastair D'Silva, Andrew Donnellan,
Balbir Singh, Benjamin Herrenschmidt, Christophe Leroy, Cyril Bur,
Eric W . Biederman, Nicholas Piggin, Paul Mackerras, Simon Guo,
Sukadev Bhattiprolu, Tobin C . Harding, linuxppc-dev
In-Reply-To: <20180725193647.GA23643@kermit-br-ibm-com>
Murilo Opsfelder Araujo <muriloo@linux.ibm.com> writes:
> On Wed, Jul 25, 2018 at 05:00:21PM +1000, Michael Neuling wrote:
>> On Tue, 2018-07-24 at 16:27 -0300, Murilo Opsfelder Araujo wrote:
>> > This series was inspired by the need to modernize and display more
>> > informative messages about unhandled signals.
...
>>
>> Nice.. the instruction dump would have been very handy when debugging the PCR
>> init issue I had a month or so back.
These things may be related :)
>> What happens if we get a sudden flood of these from different processes that
>> overlap their output? Are we going to be able to match up the process with
>> instruction dump?
>
> As to the flood of messages, ___ratelimit() makes me think that we'll
> likely see some warn messages informing how many show_signal_msg()
> callbacks were suppressed, instead of interleaved messages and
> instruction dumps.
>
> As to matching process with instruction dump, I believe we'd need more
> information to glue them together.
>
> What if we modify show_instructions() to accept a string prefix to be
> printed along with each line?
>
>> Should we prefix every line with the PID to avoid this?
>
> That's possible. An alternative would be prefixing each line with the
> process name and its PID, as in the first line. For example:
>
> pandafault[10758]: segfault (11) at 00000000100007d0 nip 000000001000061c lr 00007fffabc85100 code 2 in pandafault[10000000+10000]
> pandafault[10758]: Instruction dump:
> pandafault[10758]: 4bfffeec 4bfffee8 3c401002 38427f00 fbe1fff8 f821ffc1 7c3f0b78 3d22fffe
> pandafault[10758]: 392988d0 f93f0020 e93f0020 39400048 <99490000> 39200000 7d234b78 383f0040
>
> The above can be interleaved with other messages and we'll still be able
> to match process and its corresponding instruction dump.
Yeah prefixing with the comm and pid is nice.
Also the "Instruction dump:" line is a waste of space.
I prefer the x86 format, where it's prefixed with "code:", eg:
pandafault[10758]: segfault (11) at 00000000100007d0 nip 000000001000061c lr 00007fffabc85100 code 2 in pandafault[10000000+10000]
pandafault[10758]: code: 4bfffeec 4bfffee8 3c401002 38427f00 fbe1fff8 f821ffc1 7c3f0b78 3d22fffe
pandafault[10758]: code: 392988d0 f93f0020 e93f0020 39400048 <99490000> 39200000 7d234b78 383f0040
cheers
^ permalink raw reply
* Re: [PATCH 0/7] powerpc: Modernize unhandled signals message
From: Michael Neuling @ 2018-07-26 2:11 UTC (permalink / raw)
To: Murilo Opsfelder Araujo
Cc: linux-kernel, Alastair D'Silva, Andrew Donnellan,
Balbir Singh, Benjamin Herrenschmidt, Christophe Leroy, Cyril Bur,
Eric W . Biederman, Michael Ellerman, Nicholas Piggin,
Paul Mackerras, Simon Guo, Sukadev Bhattiprolu, Tobin C . Harding,
linuxppc-dev
In-Reply-To: <20180725193647.GA23643@kermit-br-ibm-com>
> > Should we prefix every line with the PID to avoid this?
>=20
> That's possible. An alternative would be prefixing each line with the
> process name and its PID, as in the first line. For example:
>=20
> pandafault[10758]: segfault (11) at 00000000100007d0 nip 000000001000=
061c lr 00007fffabc85100 code 2 in pandafault[10000000+10000]
> pandafault[10758]: Instruction dump:
> pandafault[10758]: 4bfffeec 4bfffee8 3c401002 38427f00 fbe1fff8 f821f=
fc1 7c3f0b78 3d22fffe
> pandafault[10758]: 392988d0 f93f0020 e93f0020 39400048 <99490000> 392=
00000 7d234b78 383f0040
>=20
> The above can be interleaved with other messages and we'll still be able
> to match process and its corresponding instruction dump.
LGTM.
Thanks!
Mikey
^ permalink raw reply
* [PATCH] powerpc/pasemi: Use pr_err/pr_warn... for kernel messages
From: Darren Stevens @ 2018-07-25 20:45 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Christian Zigotzky, Olof Johansson
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>
---
arch/powerpc/platforms/pasemi/dma_lib.c | 6 ++--
arch/powerpc/platforms/pasemi/gpio_mdio.c | 2 +-
arch/powerpc/platforms/pasemi/idle.c | 4 +--
arch/powerpc/platforms/pasemi/iommu.c | 2 +-
arch/powerpc/platforms/pasemi/misc.c | 3 +-
arch/powerpc/platforms/pasemi/pci.c | 4 +--
arch/powerpc/platforms/pasemi/setup.c | 53 ++++++++++++++---------------
7 files changed, 36 insertions(+), 38 deletions(-)
diff --git a/arch/powerpc/platforms/pasemi/dma_lib.c b/arch/powerpc/platforms/pasemi/dma_lib.c
index 2c72263..c80f72c 100644
--- a/arch/powerpc/platforms/pasemi/dma_lib.c
+++ b/arch/powerpc/platforms/pasemi/dma_lib.c
@@ -531,7 +531,7 @@ int pasemi_dma_init(void)
iob_pdev = pci_get_device(PCI_VENDOR_ID_PASEMI, 0xa001, NULL);
if (!iob_pdev) {
BUG();
- printk(KERN_WARNING "Can't find I/O Bridge\n");
+ pr_warn("Can't find I/O Bridge\n");
err = -ENODEV;
goto out;
}
@@ -540,7 +540,7 @@ int pasemi_dma_init(void)
dma_pdev = pci_get_device(PCI_VENDOR_ID_PASEMI, 0xa007, NULL);
if (!dma_pdev) {
BUG();
- printk(KERN_WARNING "Can't find DMA controller\n");
+ pr_warn("Can't find DMA controller\n");
err = -ENODEV;
goto out;
}
@@ -623,7 +623,7 @@ int pasemi_dma_init(void)
pasemi_write_dma_reg(PAS_DMA_TXF_CFLG0, 0xffffffff);
pasemi_write_dma_reg(PAS_DMA_TXF_CFLG1, 0xffffffff);
- printk(KERN_INFO "PA Semi PWRficient DMA library initialized "
+ pr_info("PA Semi PWRficient DMA library initialized "
"(%d tx, %d rx channels)\n", num_txch, num_rxch);
out:
diff --git a/arch/powerpc/platforms/pasemi/gpio_mdio.c b/arch/powerpc/platforms/pasemi/gpio_mdio.c
index c23e609..6f35a2a 100644
--- a/arch/powerpc/platforms/pasemi/gpio_mdio.c
+++ b/arch/powerpc/platforms/pasemi/gpio_mdio.c
@@ -256,7 +256,7 @@ static int gpio_mdio_probe(struct platform_device *ofdev)
err = of_mdiobus_register(new_bus, np);
if (err != 0) {
- printk(KERN_ERR "%s: Cannot register as MDIO bus, err %d\n",
+ pr_err("%s: Cannot register as MDIO bus, err %d\n",
new_bus->name, err);
goto out_free_irq;
}
diff --git a/arch/powerpc/platforms/pasemi/idle.c b/arch/powerpc/platforms/pasemi/idle.c
index 44e0d92..8bb4e80 100644
--- a/arch/powerpc/platforms/pasemi/idle.c
+++ b/arch/powerpc/platforms/pasemi/idle.c
@@ -78,13 +78,13 @@ static int pasemi_system_reset_exception(struct pt_regs *regs)
static int __init pasemi_idle_init(void)
{
#ifndef CONFIG_PPC_PASEMI_CPUFREQ
- printk(KERN_WARNING "No cpufreq driver, powersavings modes disabled\n");
+ pr_warn("No cpufreq driver, powersavings modes disabled\n");
current_mode = 0;
#endif
ppc_md.system_reset_exception = pasemi_system_reset_exception;
ppc_md.power_save = modes[current_mode].entry;
- printk(KERN_INFO "Using PA6T idle loop (%s)\n", modes[current_mode].name);
+ pr_info("Using PA6T idle loop (%s)\n", modes[current_mode].name);
return 0;
}
diff --git a/arch/powerpc/platforms/pasemi/iommu.c b/arch/powerpc/platforms/pasemi/iommu.c
index 78b80cb..f06c83f 100644
--- a/arch/powerpc/platforms/pasemi/iommu.c
+++ b/arch/powerpc/platforms/pasemi/iommu.c
@@ -210,7 +210,7 @@ static int __init iob_init(struct device_node *dn)
/* For 2G space, 8x64 pages (2^21 bytes) is max total l2 size */
iob_l2_base = (u32 *)__va(memblock_alloc_base(1UL<<21, 1UL<<21, 0x80000000));
- printk(KERN_INFO "IOBMAP L2 allocated at: %p\n", iob_l2_base);
+ pr_info("IOBMAP L2 allocated at: %p\n", iob_l2_base);
/* Allocate a spare page to map all invalid IOTLB pages. */
tmp = memblock_alloc(IOBMAP_PAGE_SIZE, IOBMAP_PAGE_SIZE);
diff --git a/arch/powerpc/platforms/pasemi/misc.c b/arch/powerpc/platforms/pasemi/misc.c
index 8571e7b..f60f4b7 100644
--- a/arch/powerpc/platforms/pasemi/misc.c
+++ b/arch/powerpc/platforms/pasemi/misc.c
@@ -69,8 +69,7 @@ static int __init pasemi_register_i2c_devices(void)
addr = of_get_property(node, "reg", &len);
if (!addr || len < sizeof(int) ||
*addr > (1 << 10) - 1) {
- printk(KERN_WARNING
- "pasemi_register_i2c_devices: "
+ pr_warn("pasemi_register_i2c_devices: "
"invalid i2c device entry\n");
continue;
}
diff --git a/arch/powerpc/platforms/pasemi/pci.c b/arch/powerpc/platforms/pasemi/pci.c
index aea9ff2..c7c8607 100644
--- a/arch/powerpc/platforms/pasemi/pci.c
+++ b/arch/powerpc/platforms/pasemi/pci.c
@@ -205,7 +205,7 @@ static int __init pas_add_bridge(struct device_node *dev)
setup_pa_pxp(hose);
- printk(KERN_INFO "Found PA-PXP PCI host bridge.\n");
+ pr_info("Found PA-PXP PCI host bridge.\n");
/* Interpret the "ranges" property */
pci_process_bridge_OF_ranges(hose, dev, 1);
@@ -219,7 +219,7 @@ void __init pas_pci_init(void)
root = of_find_node_by_path("/");
if (!root) {
- printk(KERN_CRIT "pas_pci_init: can't find root "
+ pr_crit("pas_pci_init: can't find root "
"of device tree\n");
return;
}
diff --git a/arch/powerpc/platforms/pasemi/setup.c b/arch/powerpc/platforms/pasemi/setup.c
index d0b8ae5..9a6eb04 100644
--- a/arch/powerpc/platforms/pasemi/setup.c
+++ b/arch/powerpc/platforms/pasemi/setup.c
@@ -207,8 +207,7 @@ static __init void pas_init_IRQ(void)
break;
}
if (!mpic_node) {
- printk(KERN_ERR
- "Failed to locate the MPIC interrupt controller\n");
+ pr_err("Failed to locate the MPIC interrupt controller\n");
return;
}
@@ -217,12 +216,12 @@ static __init void pas_init_IRQ(void)
naddr = of_n_addr_cells(root);
opprop = of_get_property(root, "platform-open-pic", &opplen);
if (!opprop) {
- printk(KERN_ERR "No platform-open-pic property.\n");
+ pr_err("No platform-open-pic property.\n");
of_node_put(root);
return;
}
openpic_addr = of_read_number(opprop, naddr);
- printk(KERN_DEBUG "OpenPIC addr: %lx\n", openpic_addr);
+ pr_debug("OpenPIC addr: %lx\n", openpic_addr);
mpic_flags = MPIC_LARGE_VECTORS | MPIC_NO_BIAS | MPIC_NO_RESET;
@@ -265,72 +264,72 @@ static int pas_machine_check_handler(struct pt_regs *regs)
srr1 = regs->msr;
if (nmi_virq && mpic_get_mcirq() == nmi_virq) {
- printk(KERN_ERR "NMI delivered\n");
+ pr_err("NMI delivered\n");
debugger(regs);
mpic_end_irq(irq_get_irq_data(nmi_virq));
goto out;
}
dsisr = mfspr(SPRN_DSISR);
- printk(KERN_ERR "Machine Check on CPU %d\n", cpu);
- printk(KERN_ERR "SRR0 0x%016lx SRR1 0x%016lx\n", srr0, srr1);
- printk(KERN_ERR "DSISR 0x%016lx DAR 0x%016lx\n", dsisr, regs->dar);
- printk(KERN_ERR "BER 0x%016lx MER 0x%016lx\n", mfspr(SPRN_PA6T_BER),
+ pr_err("Machine Check on CPU %d\n", cpu);
+ pr_err("SRR0 0x%016lx SRR1 0x%016lx\n", srr0, srr1);
+ pr_err("DSISR 0x%016lx DAR 0x%016lx\n", dsisr, regs->dar);
+ pr_err("BER 0x%016lx MER 0x%016lx\n", mfspr(SPRN_PA6T_BER),
mfspr(SPRN_PA6T_MER));
- printk(KERN_ERR "IER 0x%016lx DER 0x%016lx\n", mfspr(SPRN_PA6T_IER),
+ pr_err("IER 0x%016lx DER 0x%016lx\n", mfspr(SPRN_PA6T_IER),
mfspr(SPRN_PA6T_DER));
- printk(KERN_ERR "Cause:\n");
+ pr_err("Cause:\n");
if (srr1 & 0x200000)
- printk(KERN_ERR "Signalled by SDC\n");
+ pr_err("Signalled by SDC\n");
if (srr1 & 0x100000) {
- printk(KERN_ERR "Load/Store detected error:\n");
+ pr_err("Load/Store detected error:\n");
if (dsisr & 0x8000)
- printk(KERN_ERR "D-cache ECC double-bit error or bus error\n");
+ pr_err("D-cache ECC double-bit error or bus error\n");
if (dsisr & 0x4000)
- printk(KERN_ERR "LSU snoop response error\n");
+ pr_err("LSU snoop response error\n");
if (dsisr & 0x2000) {
- printk(KERN_ERR "MMU SLB multi-hit or invalid B field\n");
+ pr_err("MMU SLB multi-hit or invalid B field\n");
dump_slb = 1;
}
if (dsisr & 0x1000)
- printk(KERN_ERR "Recoverable Duptags\n");
+ pr_err("Recoverable Duptags\n");
if (dsisr & 0x800)
- printk(KERN_ERR "Recoverable D-cache parity error count overflow\n");
+ pr_err("Recoverable D-cache parity error count overflow\n");
if (dsisr & 0x400)
- printk(KERN_ERR "TLB parity error count overflow\n");
+ pr_err("TLB parity error count overflow\n");
}
if (srr1 & 0x80000)
- printk(KERN_ERR "Bus Error\n");
+ pr_err("Bus Error\n");
if (srr1 & 0x40000) {
- printk(KERN_ERR "I-side SLB multiple hit\n");
+ pr_err("I-side SLB multiple hit\n");
dump_slb = 1;
}
if (srr1 & 0x20000)
- printk(KERN_ERR "I-cache parity error hit\n");
+ pr_err("I-cache parity error hit\n");
if (num_mce_regs == 0)
- printk(KERN_ERR "No MCE registers mapped yet, can't dump\n");
+ pr_err("No MCE registers mapped yet, can't dump\n");
else
- printk(KERN_ERR "SoC debug registers:\n");
+ pr_err("SoC debug registers:\n");
for (i = 0; i < num_mce_regs; i++)
- printk(KERN_ERR "%s: 0x%08x\n", mce_regs[i].name,
+ pr_err("%s: 0x%08x\n", mce_regs[i].name,
in_le32(mce_regs[i].addr));
if (dump_slb) {
unsigned long e, v;
int i;
- printk(KERN_ERR "slb contents:\n");
+ pr_err("slb contents:\n");
for (i = 0; i < mmu_slb_size; i++) {
asm volatile("slbmfee %0,%1" : "=r" (e) : "r" (i));
asm volatile("slbmfev %0,%1" : "=r" (v) : "r" (i));
- printk(KERN_ERR "%02d %016lx %016lx\n", i, e, v);
+ pr_err("%02d %016lx %016lx\n", i, e, v);
}
}
^ permalink raw reply related
* [PATCH] powerpc/pasemi: Seach for PCI root bus by compatible property
From: Darren Stevens @ 2018-07-25 20:55 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Christian Zigotzky, Olof Johansson
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>
---
This works on the Amigaone X1000, I don't know if this method of
finding the pci bus was there bcause of earlier firmwares.
diff --git a/arch/powerpc/platforms/pasemi/pci.c b/arch/powerpc/platforms/pasemi/pci.c
index c7c8607..be62380 100644
--- a/arch/powerpc/platforms/pasemi/pci.c
+++ b/arch/powerpc/platforms/pasemi/pci.c
@@ -216,6 +216,7 @@ static int __init pas_add_bridge(struct device_node *dev)
void __init pas_pci_init(void)
{
struct device_node *np, *root;
+ int res;
root = of_find_node_by_path("/");
if (!root) {
@@ -226,11 +227,11 @@ void __init pas_pci_init(void)
pci_set_flags(PCI_SCAN_ALL_PCIE_DEVS);
- for (np = NULL; (np = of_get_next_child(root, np)) != NULL;)
- if (np->name && !strcmp(np->name, "pxp") && !pas_add_bridge(np))
- of_node_get(np);
-
- of_node_put(root);
+ np = of_find_compatible_node(root, NULL, "pasemi,rootbus");
+ if (np) {
+ res = pas_add_bridge(np);
+ of_node_put(np);
+ }
}
void __iomem *pasemi_pci_getcfgaddr(struct pci_dev *dev, int offset)
^ permalink raw reply related
* Re: [PATCH 7/7] powerpc/traps: Show instructions on exceptions
From: Murilo Opsfelder Araujo @ 2018-07-25 20:51 UTC (permalink / raw)
To: LEROY Christophe
Cc: linuxppc-dev, Tobin C . Harding, Sukadev Bhattiprolu, Simon Guo,
Paul Mackerras, Nicholas Piggin, Michael Neuling,
Michael Ellerman, Eric W . Biederman, Cyril Bur,
Benjamin Herrenschmidt, Balbir Singh, Andrew Donnellan,
Alastair D'Silva, linux-kernel
In-Reply-To: <20180725180134.Horde.BdhyE2b-TXhoVB7W8bsBhg1@messagerie.si.c-s.fr>
Hi, Christophe.
On Wed, Jul 25, 2018 at 06:01:34PM +0200, LEROY Christophe wrote:
> Murilo Opsfelder Araujo <muriloo@linux.ibm.com> a écrit :
>
> > Move show_instructions() declaration to arch/powerpc/include/asm/stacktrace.h
> > and include asm/stracktrace.h in arch/powerpc/kernel/process.c, which
> > contains
> > the implementation.
> >
> > Modify show_instructions() not to call __kernel_text_address(), allowing
> > userspace instruction dump. probe_kernel_address(), which returns -EFAULT if
> > something goes wrong, is still being called.
> >
> > Call show_instructions() in arch/powerpc/kernel/traps.c to dump
> > instructions at
> > faulty location, useful to debugging.
>
> Shouldn't this part be in a second patch ?
Makes sense. Perhaps I should split this patch in two: one to remove
__kernel_text_address() check in show_instructions(), and another to
call show_instructions() in show_signal_msg().
> Wouldn't it be better to also see regs in addition if we want to use this to
> understand what happened ?
> So you could call show_regs() instead of show_instructions() ?
I see that show_regs() prints more information and calls
show_instructions() at the end if in privileged state.
I'm not sure about which situations we might want to call show_regs() -
and display a bunch of information - or just dump instructions for some
signals.
Isn't calling show_regs() in this case considered overkill?
Cheers
Murilo
^ permalink raw reply
* Re: [PATCH] net: ethernet: fs-enet: Use generic CRC32 implementation
From: David Miller @ 2018-07-25 20:42 UTC (permalink / raw)
To: krzk; +Cc: pantelis.antoniou, linuxppc-dev, netdev, linux-kernel, ebiggers3
In-Reply-To: <20180723162020.6221-1-krzk@kernel.org>
From: Krzysztof Kozlowski <krzk@kernel.org>
Date: Mon, 23 Jul 2018 18:20:20 +0200
> Use generic kernel CRC32 implementation because it:
> 1. Should be faster (uses lookup tables),
> 2. Removes duplicated CRC generation code,
> 3. Uses well-proven algorithm instead of coding it one more time.
>
> Suggested-by: Eric Biggers <ebiggers3@gmail.com>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Applied.
^ permalink raw reply
* Re: [PATCH 2/7] powerpc/traps: Return early in show_signal_msg()
From: Murilo Opsfelder Araujo @ 2018-07-25 20:31 UTC (permalink / raw)
To: LEROY Christophe
Cc: linuxppc-dev, Tobin C . Harding, Sukadev Bhattiprolu, Simon Guo,
Paul Mackerras, Nicholas Piggin, Michael Neuling,
Michael Ellerman, Eric W . Biederman, Cyril Bur,
Benjamin Herrenschmidt, Balbir Singh, Andrew Donnellan,
Alastair D'Silva, linux-kernel
In-Reply-To: <20180725174228.Horde.-PsCOyKHj9skAHIMbqyLDg1@messagerie.si.c-s.fr>
Hi, Christophe.
On Wed, Jul 25, 2018 at 05:42:28PM +0200, LEROY Christophe wrote:
> Murilo Opsfelder Araujo <muriloo@linux.ibm.com> a écrit :
>
> > Modify logic of show_signal_msg() to return early, if possible. Replace
> > printk_ratelimited() by printk() and a default rate limit burst to limit
> > displaying unhandled signals messages.
>
> Can you explain more the benefits of this change ?
Mainly is to improve readability of the function.
The conditions to display the message were coupled together in one
single `if` statement.
Besides that, patch 5/7 adds a call to print_vma_addr(), which is not
aware of any rate limit - it simply calls printk().
So splitting out the rate limit check outside show_signal_msg() makes it
easier to the caller decide if it wants to respect a printk rate limit
or not.
Cheers
Murilo
^ permalink raw reply
* Re: [PATCH 6/7] powerpc/traps: Print signal name for unhandled signals
From: Murilo Opsfelder Araujo @ 2018-07-25 20:06 UTC (permalink / raw)
To: LEROY Christophe
Cc: linuxppc-dev, Tobin C . Harding, Sukadev Bhattiprolu, Simon Guo,
Paul Mackerras, Nicholas Piggin, Michael Neuling,
Michael Ellerman, Eric W . Biederman, Cyril Bur,
Benjamin Herrenschmidt, Balbir Singh, Andrew Donnellan,
Alastair D'Silva, linux-kernel
In-Reply-To: <20180725174927.Horde.Sfg4oyTmcaLgHIJr3Gf-oQ1@messagerie.si.c-s.fr>
Hi, Christophe.
On Wed, Jul 25, 2018 at 05:49:27PM +0200, LEROY Christophe wrote:
> Murilo Opsfelder Araujo <muriloo@linux.ibm.com> a écrit :
>
> > This adds a human-readable name in the unhandled signal message.
> >
> > Before this patch, a page fault looked like:
> >
> > Jul 11 16:04:11 localhost kernel: pandafault[6303]: unhandled signal
> > 11 at 00000000100007d0 nip 000000001000061c lr 00007fff93c55100 code 2
> > in pandafault[10000000+10000]
> >
> > After this patch, a page fault looks like:
> >
> > Jul 11 18:14:48 localhost kernel: pandafault[6352]: segfault (11) at
> > 000000013a2a09f8 nip 000000013a2a086c lr 00007fffb63e5100 code 2 in
> > pandafault[13a2a0000+10000]
> >
> > Signed-off-by: Murilo Opsfelder Araujo <muriloo@linux.ibm.com>
> > ---
> > arch/powerpc/kernel/traps.c | 43 +++++++++++++++++++++++++++++++++----
> > 1 file changed, 39 insertions(+), 4 deletions(-)
> >
> > diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
> > index e6c43ef9fb50..e55ee639d010 100644
> > --- a/arch/powerpc/kernel/traps.c
> > +++ b/arch/powerpc/kernel/traps.c
> > @@ -96,6 +96,41 @@ EXPORT_SYMBOL(__debugger_fault_handler);
> > #define TM_DEBUG(x...) do { } while(0)
> > #endif
> >
> > +static const char *signames[SIGRTMIN + 1] = {
> > + "UNKNOWN",
> > + "SIGHUP", // 1
> > + "SIGINT", // 2
> > + "SIGQUIT", // 3
> > + "SIGILL", // 4
> > + "unhandled trap", // 5 = SIGTRAP
> > + "SIGABRT", // 6 = SIGIOT
> > + "bus error", // 7 = SIGBUS
> > + "floating point exception", // 8 = SIGFPE
> > + "illegal instruction", // 9 = SIGILL
> > + "SIGUSR1", // 10
> > + "segfault", // 11 = SIGSEGV
> > + "SIGUSR2", // 12
> > + "SIGPIPE", // 13
> > + "SIGALRM", // 14
> > + "SIGTERM", // 15
> > + "SIGSTKFLT", // 16
> > + "SIGCHLD", // 17
> > + "SIGCONT", // 18
> > + "SIGSTOP", // 19
> > + "SIGTSTP", // 20
> > + "SIGTTIN", // 21
> > + "SIGTTOU", // 22
> > + "SIGURG", // 23
> > + "SIGXCPU", // 24
> > + "SIGXFSZ", // 25
> > + "SIGVTALRM", // 26
> > + "SIGPROF", // 27
> > + "SIGWINCH", // 28
> > + "SIGIO", // 29 = SIGPOLL = SIGLOST
> > + "SIGPWR", // 30
> > + "SIGSYS", // 31 = SIGUNUSED
> > +};
> > +
> > /*
> > * Trap & Exception support
> > */
> > @@ -314,10 +349,10 @@ static void show_signal_msg(int signr, struct
> > pt_regs *regs, int code,
> > if (!unhandled_signal(current, signr))
> > return;
> >
> > - pr_info("%s[%d]: unhandled signal %d at "REG_FMT \
> > - " nip "REG_FMT" lr "REG_FMT" code %x",
> > - current->comm, current->pid, signr, addr,
> > - regs->nip, regs->link, code);
> > + pr_info("%s[%d]: %s (%d) at "REG_FMT" nip "REG_FMT \
> > + " lr "REG_FMT" code %x",
> > + current->comm, current->pid, signames[signr],
> > + signr, addr, regs->nip, regs->link, code);
>
> Are we sure that signr is always within the limits of the table ?
Looking at the code, we only pass the following signals:
SIGBUS
SIGFPE
SIGILL
SIGSEGV
SIGTRAP
All of them are within the limits of the table. We've added other
signals for completeness.
Cheers
Murilo
^ 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