[PATCH 6/6] selftests: powerpc/pmu: Link ebb tests with -no-pie
When running the ebb tests after building on a ppc64le Ubuntu machine: $ pmu/ebb/reg_access_test: error while loading shared libraries: R_PPC64_ADDR16_HI reloc at 0x00013a965130 for symbol `' out of range This is because the Ubuntu toolchain builds has PIE enabled by default. Change it to be always off instead. Signed-off-by: Joel Stanley --- tools/testing/selftests/powerpc/pmu/ebb/Makefile | 3 +++ 1 file changed, 3 insertions(+) diff --git a/tools/testing/selftests/powerpc/pmu/ebb/Makefile b/tools/testing/selftests/powerpc/pmu/ebb/Makefile index bd5dfa509272..23f4caf48ffc 100644 --- a/tools/testing/selftests/powerpc/pmu/ebb/Makefile +++ b/tools/testing/selftests/powerpc/pmu/ebb/Makefile @@ -5,6 +5,9 @@ noarg: # The EBB handler is 64-bit code and everything links against it CFLAGS += -m64 +# Toolchains may build PIE by default which breaks the assembly +LDFLAGS += -no-pie + TEST_GEN_PROGS := reg_access_test event_attributes_test cycles_test\ cycles_with_freeze_test pmc56_overflow_test\ ebb_vs_cpu_event_test cpu_event_vs_ebb_test\ -- 2.19.1
[PATCH 5/6] selftests: powerpc/signal: Fix signal_tm CFLAGS
signal_tm tries to build with -mhtm but it currently does not. The targets is modified in lib.mk to add the $(OUTPUT) prefix. The makefile needs to specify that modifying the rules, or else it does not match and we miss out on the extra flag. Signed-off-by: Joel Stanley --- tools/testing/selftests/powerpc/signal/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/testing/selftests/powerpc/signal/Makefile b/tools/testing/selftests/powerpc/signal/Makefile index 25d0973df5b3..209a958dca12 100644 --- a/tools/testing/selftests/powerpc/signal/Makefile +++ b/tools/testing/selftests/powerpc/signal/Makefile @@ -2,7 +2,7 @@ TEST_GEN_PROGS := signal signal_tm CFLAGS += -maltivec -signal_tm: CFLAGS += -mhtm +$(OUTPUT)/signal_tm: CFLAGS += -mhtm top_srcdir = ../../../../.. include ../../lib.mk -- 2.19.1
[PATCH 4/6] selftests: powerpc/signal: Make tests build
According to lib.mk, TEST_PROGS is for shell scripts. It appears we need to define the programs as TEST_GEN_PROGS to ensure they are built. The definition must also happen below the inclusion of lib.mk. Signed-off-by: Joel Stanley --- tools/testing/selftests/powerpc/signal/Makefile | 7 ++- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/tools/testing/selftests/powerpc/signal/Makefile b/tools/testing/selftests/powerpc/signal/Makefile index d34a7c7710db..25d0973df5b3 100644 --- a/tools/testing/selftests/powerpc/signal/Makefile +++ b/tools/testing/selftests/powerpc/signal/Makefile @@ -1,7 +1,5 @@ # SPDX-License-Identifier: GPL-2.0 -TEST_PROGS := signal signal_tm - -$(TEST_PROGS): ../harness.c ../utils.c signal.S +TEST_GEN_PROGS := signal signal_tm CFLAGS += -maltivec signal_tm: CFLAGS += -mhtm @@ -9,5 +7,4 @@ signal_tm: CFLAGS += -mhtm top_srcdir = ../../../../.. include ../../lib.mk -clean: - rm -f $(TEST_PROGS) *.o +$(TEST_GEN_PROGS): ../harness.c ../utils.c signal.S -- 2.19.1
[PATCH 3/6] selftests: powerpc/ptrace: Fix linking against pthread
Some of the ptrace tests require -ptrace when linking: /usr/bin/ld: /tmp/ccH32S9w.o: in function `init_child_sync': core-pkey.c:(.text+0x1d64): undefined reference to `sem_init' The targets for these tests are modfied in lib.mk to add the $(OUTPUT) prefix. The makefile needs to specify that modifying those rules, or else they do not match and we miss out on the extra flags. Signed-off-by: Joel Stanley --- tools/testing/selftests/powerpc/ptrace/Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/testing/selftests/powerpc/ptrace/Makefile b/tools/testing/selftests/powerpc/ptrace/Makefile index 58de6d4a0cf4..8d3f006c98cc 100644 --- a/tools/testing/selftests/powerpc/ptrace/Makefile +++ b/tools/testing/selftests/powerpc/ptrace/Makefile @@ -9,7 +9,7 @@ include ../../lib.mk CFLAGS += -m64 -I../../../../../usr/include -I../tm -mhtm -fno-pie -ptrace-pkey core-pkey: child.h -ptrace-pkey core-pkey: LDLIBS += -pthread +$(OUTPUT)/ptrace-pkey $(OUTPUT)/core-pkey: child.h +$(OUTPUT)/ptrace-pkey $(OUTPUT)/core-pkey: LDLIBS += -pthread $(TEST_GEN_PROGS): ../harness.c ../utils.c ../lib/reg.S ptrace.h -- 2.19.1
[PATCH 2/6] selftests: powerpc/ptrace: Remove clean rule
When running 'make ptrace': make[1]: Entering directory 'tools/testing/selftests/powerpc/ptrace' Makefile:18: warning: overriding recipe for target 'clean' ../../lib.mk:137: warning: ignoring old recipe for target 'clean' The rule is unnecessary as TEST_GEN_FILES are cleaned up by the rule in lib.mk. Signed-off-by: Joel Stanley --- tools/testing/selftests/powerpc/ptrace/Makefile | 3 --- 1 file changed, 3 deletions(-) diff --git a/tools/testing/selftests/powerpc/ptrace/Makefile b/tools/testing/selftests/powerpc/ptrace/Makefile index e9a3850aae86..58de6d4a0cf4 100644 --- a/tools/testing/selftests/powerpc/ptrace/Makefile +++ b/tools/testing/selftests/powerpc/ptrace/Makefile @@ -13,6 +13,3 @@ ptrace-pkey core-pkey: child.h ptrace-pkey core-pkey: LDLIBS += -pthread $(TEST_GEN_PROGS): ../harness.c ../utils.c ../lib/reg.S ptrace.h - -clean: - rm -f $(TEST_GEN_PROGS) *.o -- 2.19.1
[PATCH 1/6] selftests: powerpc/ptrace: Make tests build
According to lib.mk, TEST_PROGS is for shell scripts. It appears we need to define the programs as TEST_GEN_PROGS to ensure they are built. Signed-off-by: Joel Stanley --- tools/testing/selftests/powerpc/ptrace/Makefile | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/tools/testing/selftests/powerpc/ptrace/Makefile b/tools/testing/selftests/powerpc/ptrace/Makefile index 6ac71b629276..e9a3850aae86 100644 --- a/tools/testing/selftests/powerpc/ptrace/Makefile +++ b/tools/testing/selftests/powerpc/ptrace/Makefile @@ -1,5 +1,5 @@ # SPDX-License-Identifier: GPL-2.0 -TEST_PROGS := ptrace-gpr ptrace-tm-gpr ptrace-tm-spd-gpr \ +TEST_GEN_PROGS := ptrace-gpr ptrace-tm-gpr ptrace-tm-spd-gpr \ ptrace-tar ptrace-tm-tar ptrace-tm-spd-tar ptrace-vsx ptrace-tm-vsx \ ptrace-tm-spd-vsx ptrace-tm-spr ptrace-hwbreak ptrace-pkey core-pkey \ perf-hwbreak ptrace-syscall @@ -12,7 +12,7 @@ CFLAGS += -m64 -I../../../../../usr/include -I../tm -mhtm -fno-pie ptrace-pkey core-pkey: child.h ptrace-pkey core-pkey: LDLIBS += -pthread -$(TEST_PROGS): ../harness.c ../utils.c ../lib/reg.S ptrace.h +$(TEST_GEN_PROGS): ../harness.c ../utils.c ../lib/reg.S ptrace.h clean: - rm -f $(TEST_PROGS) *.o + rm -f $(TEST_GEN_PROGS) *.o -- 2.19.1
[PATCH 0/6] selftests: powerpc build fixes
This series fixes issues I encountered building and running the selftests on a Ubuntu Cosmic ppc64le system. Joel Stanley (6): selftests: powerpc/ptrace: Make tests build selftests: powerpc/ptrace: Remove clean rule selftests: powerpc/ptrace: Fix linking against pthread selftests: powerpc/signal: Make tests build selftests: powerpc/signal: Fix signal_tm CFLAGS selftests: powerpc/pmu: Link ebb tests with -no-pie tools/testing/selftests/powerpc/pmu/ebb/Makefile | 3 +++ tools/testing/selftests/powerpc/ptrace/Makefile | 11 --- tools/testing/selftests/powerpc/signal/Makefile | 9 +++-- 3 files changed, 10 insertions(+), 13 deletions(-) -- 2.19.1
Re: [PATCH] net/wan/fsl_ucc_hdlc: error counters
From: Mathias Thore Date: Mon, 22 Oct 2018 14:55:50 +0200 > Extract error information from rx and tx buffer descriptors, > and update error counters. > > Signed-off-by: Mathias Thore Applied.
[PATCH] powerpc/pseries: add missing cpumask.h include file
Build error is encountered when inlcuding if no explicit or
implicit include of cpumask.h exists in the including file.
In file included from arch/powerpc/platforms/pseries/hotplug-pci.c:3:0:
./arch/powerpc/include/asm/rtas.h:360:34: error: unknown type name
'cpumask_var_t'
extern int rtas_online_cpus_mask(cpumask_var_t cpus);
^
./arch/powerpc/include/asm/rtas.h:361:35: error: unknown type name
'cpumask_var_t'
extern int rtas_offline_cpus_mask(cpumask_var_t cpus);
Fixes: 120496ac2d2d ("powerpc: Bring all threads online prior to
migration/hibernation")
Signed-off-by: Tyrel Datwyler
---
arch/powerpc/include/asm/rtas.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/include/asm/rtas.h b/arch/powerpc/include/asm/rtas.h
index 71e393c..06b8dd3 100644
--- a/arch/powerpc/include/asm/rtas.h
+++ b/arch/powerpc/include/asm/rtas.h
@@ -5,6 +5,7 @@
#include
#include
#include
+#include
/*
* Definitions for talking to the RTAS on CHRP machines.
--
2.7.4
Pull request: scottwood/linux.git next
This contains a couple device tree updates, and a fix for a missing prototype warning. The following changes since commit a0e102914aa3f619a5bc68a0d33e17d1788cdf4c: powerpc/io: remove old GCC version implementation (2018-10-19 00:56:17 +1100) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/scottwood/linux.git next for you to fetch changes up to b6ae3550c8e2ca8f7ce1b7f04585dc12a0eb5cbd: powerpc/8xx: add missing header in 8xx_mmu.c (2018-10-22 19:11:58 -0500) Camelia Groza (1): powerpc/dts/fsl: t2080rdb: reorder the Cortina PHY XFI lanes Christophe Leroy (2): powerpc/8xx: Add DT node for using the SEC engine of the MPC885 powerpc/8xx: add missing header in 8xx_mmu.c arch/powerpc/boot/dts/fsl/t2080rdb.dts | 4 ++-- arch/powerpc/boot/dts/mpc885ads.dts| 13 - arch/powerpc/mm/8xx_mmu.c | 1 + 3 files changed, 15 insertions(+), 3 deletions(-)
Re: [PATCH v5 00/18] of: overlay: validation checks, subsequent fixes
On Thu, Oct 18, 2018 at 5:48 PM wrote:
>
> From: Frank Rowand
>
> Add checks to (1) overlay apply process and (2) memory freeing
> triggered by overlay release. The checks are intended to detect
> possible memory leaks and invalid overlays.
I've tested v5, nothing new to report.
Alan
>
> The checks revealed bugs in existing code. Fixed the bugs.
>
> While fixing bugs, noted other issues, which are fixed in
> separate patches.
>
> * Powerpc folks: I was not able to test the patches that
> * directly impact Powerpc systems that use dynamic
> * devicetree. Please review that code carefully and
> * test. The specific patches are: 03/16, 04/16, 07/16
>
> FPGA folks:
>
> I made the validation checks that should result in an
> invalid live devicetree report "ERROR" and cause the overlay apply
> to fail.
>
> I made the memory leak validation tests report "WARNING" and allow
> the overlay apply to complete successfully. Please let me know
> if you encounter the warnings. There are at least two paths
> forward to deal with the cases that trigger the warning: (1) change
> the warning to an error and fail the overlay apply, or (2) find a
> way to detect the potential memory leaks and free the memory
> appropriately.
>
> ALL people:
>
> The validations do _not_ address another major concern I have with
> releasing overlays, which is use after free errors.
>
> Changes since v4:
> - 01/18: make error message format consistent, error first, path last
> - 09/18: create of_prop_val_eq() and change open code to use it
> - 09/18: remove extra blank lines
>
> Changes since v3:
> - 01/18: Add expected value of refcount for destroy cset entry error. Also
> explain the cause of the error.
>
> - 09/18: for errors of an overlay changing the value of #size-cells or
> #address-cells, return -EINVAL so that overlay apply will fail
> - 09/18: for errors of an overlay changing the value of #size-cells or
> #address-cells, make the message more direct.
> Old message:
> OF: overlay: ERROR: overlay and/or live tree #size-cells invalid in
> node /soc/base_fpga_region
> New message:
> OF: overlay: ERROR: changing value of /soc/base_fpga_region/#size-cells
> not allowed
>
> - 13/18: Update patch comment header to state that this patch modifies the
> previous patch to not return immediately on fragment error and
> explain this is not a performance issue.
> - 13/18: remove redundant "overlay" from two error messages. "OF: overlay:"
> is already present in pr_fmt()
>
> Changes since v2:
>
> - 13/18: Use continue to reduce indentation in find_dup_cset_node_entry()
> and find_dup_cset_prop()
>
> Changes since v1:
>
> - move patch 16/16 to 17/18
> - move patch 15/16 to 18/18
> - new patch 15/18
> - new patch 16/18
>
> - 05/18: add_changeset_node() header comment: incorrect comment for @target
>
> - 18/18: add same fix for of_parse_phandle_with_args()
> - 18/18: add same fix for of_parse_phandle_with_args_map()
>
>
> *** BLURB HERE ***
>
> Frank Rowand (18):
> of: overlay: add tests to validate kfrees from overlay removal
> of: overlay: add missing of_node_put() after add new node to changeset
> of: overlay: add missing of_node_get() in __of_attach_node_sysfs
> powerpc/pseries: add of_node_put() in dlpar_detach_node()
> of: overlay: use prop add changeset entry for property in new nodes
> of: overlay: do not duplicate properties from overlay for new nodes
> of: dynamic: change type of of_{at,de}tach_node() to void
> of: overlay: reorder fields in struct fragment
> of: overlay: validate overlay properties #address-cells and
> #size-cells
> of: overlay: make all pr_debug() and pr_err() messages unique
> of: overlay: test case of two fragments adding same node
> of: overlay: check prevents multiple fragments add or delete same node
> of: overlay: check prevents multiple fragments touching same property
> of: unittest: remove unused of_unittest_apply_overlay() argument
> of: overlay: set node fields from properties when add new overlay node
> of: unittest: allow base devicetree to have symbol metadata
> of: unittest: find overlays[] entry by name instead of index
> of: unittest: initialize args before calling of_*parse_*()
>
> arch/powerpc/platforms/pseries/dlpar.c | 15 +-
> arch/powerpc/platforms/pseries/reconfig.c | 6 +-
> drivers/of/dynamic.c | 68 +++--
> drivers/of/kobj.c | 4 +-
> drivers/of/overlay.c | 292
> -
> drivers/of/unittest-data/Makefile | 2 +
> .../of/unittest-data/overlay_bad_add_dup_node.dts | 28 ++
> .../of/unittest-data/overlay_bad_add_dup_prop.dts | 24 ++
> drivers/of/unittest-data/overlay_base.dts | 1 +
> drivers/of/unittest.c | 96 +--
> incl
[PATCH] selftests/powerpc: Fix ptrace tm failure
Test ptrace-tm-spd-gpr fails on current kernel (4.19) due to a segmentation fault that happens on the child process prior to setting cptr[2] = 1. This causes the parent process to wait forever at 'while (!pptr[2])' and the test to be killed by the test harness framework by timeout, thus, failing. The segmentation fault happens because of a inline assembly being generated as: 0x1355c lfsf0, 0(0) This is reading memory position 0x0 and causing the segmentation fault. This code is being generated by ASM_LOAD_FPR_SINGLE_PRECISION(flt_4), where flt_4 is passed to the inline assembly block as: [flt_4] "r" (&d) Since the inline assembly 'r' constraint means any GPR, gpr0 is being chosen, thus causing this issue when issuing a Load Floating-Point Single instruction. This patch simply changes the constraint to 'b', which specify that this register will be used as base, and r0 is not allowed to be used, avoiding this issue. Other than that, removing flt_2 register from the input operands, since it is not used by the inline assembly code at all. Cc: sta...@vger.kernel.org Signed-off-by: Breno Leitao --- tools/testing/selftests/powerpc/ptrace/ptrace-tm-spd-gpr.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/testing/selftests/powerpc/ptrace/ptrace-tm-spd-gpr.c b/tools/testing/selftests/powerpc/ptrace/ptrace-tm-spd-gpr.c index 327fa943c7f3..dbdffa2e2c82 100644 --- a/tools/testing/selftests/powerpc/ptrace/ptrace-tm-spd-gpr.c +++ b/tools/testing/selftests/powerpc/ptrace/ptrace-tm-spd-gpr.c @@ -67,8 +67,8 @@ void tm_spd_gpr(void) "3: ;" : [res] "=r" (result), [texasr] "=r" (texasr) : [gpr_1]"i"(GPR_1), [gpr_2]"i"(GPR_2), [gpr_4]"i"(GPR_4), - [sprn_texasr] "i" (SPRN_TEXASR), [flt_1] "r" (&a), - [flt_2] "r" (&b), [flt_4] "r" (&d) + [sprn_texasr] "i" (SPRN_TEXASR), [flt_1] "b" (&a), + [flt_4] "b" (&d) : "memory", "r5", "r6", "r7", "r8", "r9", "r10", "r11", "r12", "r13", "r14", "r15", "r16", "r17", "r18", "r19", "r20", "r21", "r22", "r23", -- 2.19.0
Re: [v9 2/7] dmaengine: fsldma: Adding macro FSL_DMA_IN/OUT implement for ARM platform
Hi Peng,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linux-sof-driver/master]
[also build test WARNING on v4.19 next-20181019]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Peng-Ma/dmaengine-fsldma-Replace-DMA_IN-OUT-by-FSL_DMA_IN-OUT/20181017-232444
base: https://github.com/thesofproject/linux master
config: powerpc-xes_mpc85xx_defconfig (attached as .config)
compiler: powerpc-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=powerpc
All warnings (new ones prefixed by >>):
In file included from drivers/dma/fsldma.c:41:0:
drivers/dma/fsldma.h: In function 'fsl_ioread64':
>> drivers/dma/fsldma.h:210:17: warning: passing argument 1 of 'in_le32' makes
>> pointer from integer without a cast [-Wint-conversion]
return in_le32(fsl_addr) | in_le32(fsl_addr + 1) << 32;
^~~~
In file included from include/linux/io.h:25:0,
from include/linux/irq.h:20,
from arch/powerpc/include/asm/hardirq.h:6,
from include/linux/hardirq.h:9,
from include/linux/interrupt.h:11,
from include/linux/pci.h:32,
from drivers/dma/fsldma.c:29:
arch/powerpc/include/asm/io.h:172:15: note: expected 'const volatile u32 *
{aka const volatile unsigned int *}' but argument is of type 'u32 {aka unsigned
int}'
DEF_MMIO_IN_X(in_le32, 32, lwbrx);
^
arch/powerpc/include/asm/io.h:131:23: note: in definition of macro
'DEF_MMIO_IN_X'
static inline u##size name(const volatile u##size __iomem *addr) \
^~~~
In file included from drivers/dma/fsldma.c:41:0:
drivers/dma/fsldma.h:210:37: warning: passing argument 1 of 'in_le32' makes
pointer from integer without a cast [-Wint-conversion]
return in_le32(fsl_addr) | in_le32(fsl_addr + 1) << 32;
^~~~
In file included from include/linux/io.h:25:0,
from include/linux/irq.h:20,
from arch/powerpc/include/asm/hardirq.h:6,
from include/linux/hardirq.h:9,
from include/linux/interrupt.h:11,
from include/linux/pci.h:32,
from drivers/dma/fsldma.c:29:
arch/powerpc/include/asm/io.h:172:15: note: expected 'const volatile u32 *
{aka const volatile unsigned int *}' but argument is of type 'u32 {aka unsigned
int}'
DEF_MMIO_IN_X(in_le32, 32, lwbrx);
^
arch/powerpc/include/asm/io.h:131:23: note: in definition of macro
'DEF_MMIO_IN_X'
static inline u##size name(const volatile u##size __iomem *addr) \
^~~~
In file included from drivers/dma/fsldma.c:41:0:
>> drivers/dma/fsldma.h:210:51: warning: left shift count >= width of type
>> [-Wshift-count-overflow]
return in_le32(fsl_addr) | in_le32(fsl_addr + 1) << 32;
^~
drivers/dma/fsldma.h: In function 'fsl_ioread64be':
>> drivers/dma/fsldma.h:223:17: warning: passing argument 1 of 'in_be32' makes
>> pointer from integer without a cast [-Wint-conversion]
return in_be32(fsl_addr + 1) | in_be32(fsl_addr) << 32;
^~~~
In file included from include/linux/io.h:25:0,
from include/linux/irq.h:20,
from arch/powerpc/include/asm/hardirq.h:6,
from include/linux/hardirq.h:9,
from include/linux/interrupt.h:11,
from include/linux/pci.h:32,
from drivers/dma/fsldma.c:29:
arch/powerpc/include/asm/io.h:170:15: note: expected 'const volatile u32 *
{aka const volatile unsigned int *}' but argument is of type 'u32 {aka unsigned
int}'
DEF_MMIO_IN_D(in_be32, 32, lwz);
^
arch/powerpc/include/asm/io.h:149:23: note: in definition of macro
'DEF_MMIO_IN_D'
static inline u##size name(const volatile u##size __iomem *addr) \
^~~~
In file included from drivers/dma/fsldma.c:41:0:
drivers/dma/fsldma.h:223:41: warning: passing argument 1 of 'in_be32' makes
pointer from integer without a cast [-Wint-conversion]
return in_be32(fsl_addr + 1) | in_be32(fsl_addr) << 32;
^~~~
In file included from include/linux/io.h:25:0,
from include/linux/irq.h:20,
from arch/powerpc/include/asm/hardirq.h:6,
from include/linux/hardirq.h:9,
from include/linux/interrupt.h:11,
from incl
[PATCH 4/9] powerpc/xive: Define xive_do_source_eoi as static
Sparse shows that xive_do_source_eoi() file is defined without any
declaration, thus, it should be a static function.
arch/powerpc/sysdev/xive/common.c:312:6: warning: symbol
'xive_do_source_eoi' was not declared. Should it be static?
This patch simply turns this symbol into static.
Signed-off-by: Breno Leitao
---
arch/powerpc/sysdev/xive/common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/sysdev/xive/common.c
b/arch/powerpc/sysdev/xive/common.c
index 959a2a62f233..6a6178357529 100644
--- a/arch/powerpc/sysdev/xive/common.c
+++ b/arch/powerpc/sysdev/xive/common.c
@@ -309,7 +309,7 @@ static void xive_do_queue_eoi(struct xive_cpu *xc)
* EOI an interrupt at the source. There are several methods
* to do this depending on the HW version and source type
*/
-void xive_do_source_eoi(u32 hw_irq, struct xive_irq_data *xd)
+static void xive_do_source_eoi(u32 hw_irq, struct xive_irq_data *xd)
{
/* If the XIVE supports the new "store EOI facility, use it */
if (xd->flags & XIVE_IRQ_FLAG_STORE_EOI)
--
2.19.0
[PATCH 2/9] powerpc/eeh: Declare pci_ers_result_name() as static
Function pci_ers_result_name() is a static function, although not declared
as such. This was detected by sparse in the following warning
arch/powerpc/kernel/eeh_driver.c:63:12: warning: symbol
'pci_ers_result_name' was not declared. Should it be static?
This patch simply declares the function a static.
Signed-off-by: Breno Leitao
---
arch/powerpc/kernel/eeh_driver.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/eeh_driver.c b/arch/powerpc/kernel/eeh_driver.c
index 67619b4b3f96..c325dedfee73 100644
--- a/arch/powerpc/kernel/eeh_driver.c
+++ b/arch/powerpc/kernel/eeh_driver.c
@@ -60,7 +60,7 @@ static int eeh_result_priority(enum pci_ers_result result)
}
};
-const char *pci_ers_result_name(enum pci_ers_result result)
+static const char *pci_ers_result_name(enum pci_ers_result result)
{
switch (result) {
case PCI_ERS_RESULT_NONE:
--
2.19.0
[PATCH 9/9] powerpc/pkey: Define functions as static
Sparse tool is showing some warnings on pkeys.c file, mainly related to
storage class identifiers. There are static variables and functions not
declared as such. The same thing happens with an extern function, which
misses the header inclusion.
arch/powerpc/mm/pkeys.c:14:6: warning: symbol
'pkey_execute_disable_supported' was not declared. Should it be static?
arch/powerpc/mm/pkeys.c:16:6: warning: symbol 'pkeys_devtree_defined'
was not declared. Should it be static?
arch/powerpc/mm/pkeys.c:19:6: warning: symbol 'pkey_amr_mask' was not
declared. Should it be static?
arch/powerpc/mm/pkeys.c:20:6: warning: symbol 'pkey_iamr_mask' was not
declared. Should it be static?
arch/powerpc/mm/pkeys.c:21:6: warning: symbol 'pkey_uamor_mask' was not
declared. Should it be static?
arch/powerpc/mm/pkeys.c:22:6: warning: symbol 'execute_only_key' was
not declared. Should it be static?
arch/powerpc/mm/pkeys.c:60:5: warning: symbol 'pkey_initialize' was not
declared. Should it be static?
arch/powerpc/mm/pkeys.c:404:6: warning: symbol
'arch_vma_access_permitted' was not declared. Should it be static?
This patch fix al the warning, basically turning all global variables that
are not declared as extern at asm/pkeys.h into static.
It also includes asm/mmu_context.h header, which contains the definition of
arch_vma_access_permitted.
Signed-off-by: Breno Leitao
---
arch/powerpc/mm/pkeys.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/mm/pkeys.c b/arch/powerpc/mm/pkeys.c
index b271b283c785..04b60a8f6e69 100644
--- a/arch/powerpc/mm/pkeys.c
+++ b/arch/powerpc/mm/pkeys.c
@@ -6,20 +6,21 @@
*/
#include
+#include
#include
#include
#include
DEFINE_STATIC_KEY_TRUE(pkey_disabled);
-bool pkey_execute_disable_supported;
int pkeys_total; /* Total pkeys as per device tree */
-bool pkeys_devtree_defined;/* pkey property exported by device tree */
u32 initial_allocation_mask; /* Bits set for the initially allocated keys */
u32 reserved_allocation_mask; /* Bits set for reserved keys */
-u64 pkey_amr_mask;/* Bits in AMR not to be touched */
-u64 pkey_iamr_mask; /* Bits in AMR not to be touched */
-u64 pkey_uamor_mask; /* Bits in UMOR not to be touched */
-int execute_only_key = 2;
+static bool pkey_execute_disable_supported;
+static bool pkeys_devtree_defined; /* property exported by device tree */
+static u64 pkey_amr_mask; /* Bits in AMR not to be touched */
+static u64 pkey_iamr_mask; /* Bits in AMR not to be touched */
+static u64 pkey_uamor_mask;/* Bits in UMOR not to be touched */
+static int execute_only_key = 2;
#define AMR_BITS_PER_PKEY 2
#define AMR_RD_BIT 0x1UL
@@ -57,7 +58,7 @@ static inline bool pkey_mmu_enabled(void)
return cpu_has_feature(CPU_FTR_PKEY);
}
-int pkey_initialize(void)
+static int pkey_initialize(void)
{
int os_reserved, i;
--
2.19.0
[PATCH 8/9] powerpc/perf: Declare static identifier a such
There are three symbols (two variables and a function) that are being used
solely in the same file (imc-pmu.c), thus, these symbols should be static,
but they are not. This was detected by sparse:
arch/powerpc/perf/imc-pmu.c:31:20: warning: symbol 'nest_imc_refc' was
not declared. Should it be static?
arch/powerpc/perf/imc-pmu.c:37:20: warning: symbol 'core_imc_refc' was
not declared. Should it be static?
arch/powerpc/perf/imc-pmu.c:46:16: warning: symbol 'imc_event_to_pmu'
was not declared. Should it be static?
This patch simply adds the 'static' storage-class definition to these
symbols, thus, restricting their usage only in the imc-pmu.c file.
Signed-off-by: Breno Leitao
---
arch/powerpc/perf/imc-pmu.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/perf/imc-pmu.c b/arch/powerpc/perf/imc-pmu.c
index 1fafc32b12a0..1c693c7726f7 100644
--- a/arch/powerpc/perf/imc-pmu.c
+++ b/arch/powerpc/perf/imc-pmu.c
@@ -28,13 +28,13 @@ static DEFINE_MUTEX(nest_init_lock);
static DEFINE_PER_CPU(struct imc_pmu_ref *, local_nest_imc_refc);
static struct imc_pmu **per_nest_pmu_arr;
static cpumask_t nest_imc_cpumask;
-struct imc_pmu_ref *nest_imc_refc;
+static struct imc_pmu_ref *nest_imc_refc;
static int nest_pmus;
/* Core IMC data structures and variables */
static cpumask_t core_imc_cpumask;
-struct imc_pmu_ref *core_imc_refc;
+static struct imc_pmu_ref *core_imc_refc;
static struct imc_pmu *core_imc_pmu;
/* Thread IMC data structures and variables */
@@ -43,7 +43,7 @@ static DEFINE_PER_CPU(u64 *, thread_imc_mem);
static struct imc_pmu *thread_imc_pmu;
static int thread_imc_mem_size;
-struct imc_pmu *imc_event_to_pmu(struct perf_event *event)
+static struct imc_pmu *imc_event_to_pmu(struct perf_event *event)
{
return container_of(event->pmu, struct imc_pmu, pmu);
}
--
2.19.0
[PATCH 6/9] powerpc/lib: Declare static methods
Functions do_stf_{entry,exit}_barrier_fixups are static but not declared as
such. This was detected by `sparse` tool with the following warning:
arch/powerpc/lib/feature-fixups.c:121:6: warning: symbol
'do_stf_entry_barrier_fixups' was not declared. Should it be static?
arch/powerpc/lib/feature-fixups.c:171:6: warning: symbol
'do_stf_exit_barrier_fixups' was not declared. Should it be static?
This patch declares both functions as static, as they are only called by
do_stf_barrier_fixups(), which is in the same source code file.
Signed-off-by: Breno Leitao
---
arch/powerpc/lib/feature-fixups.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/lib/feature-fixups.c
b/arch/powerpc/lib/feature-fixups.c
index e613b02bb2f0..ca8478503f18 100644
--- a/arch/powerpc/lib/feature-fixups.c
+++ b/arch/powerpc/lib/feature-fixups.c
@@ -118,7 +118,7 @@ void do_feature_fixups(unsigned long value, void
*fixup_start, void *fixup_end)
}
#ifdef CONFIG_PPC_BOOK3S_64
-void do_stf_entry_barrier_fixups(enum stf_barrier_type types)
+static void do_stf_entry_barrier_fixups(enum stf_barrier_type types)
{
unsigned int instrs[3], *dest;
long *start, *end;
@@ -168,7 +168,7 @@ void do_stf_entry_barrier_fixups(enum stf_barrier_type
types)
: "unknown");
}
-void do_stf_exit_barrier_fixups(enum stf_barrier_type types)
+static void do_stf_exit_barrier_fixups(enum stf_barrier_type types)
{
unsigned int instrs[6], *dest;
long *start, *end;
--
2.19.0
[PATCH 7/9] powerpc/scom: Return NULL instead of 0
Function scom_map_device() returns data type 'scom_map_t', which is a typedef for 'void *'. This functions is currently returning NULL and zero, which causes the following warning by 'sparse': arch/powerpc/sysdev/scom.c:63:24: warning: Using plain integer as NULL pointer arch/powerpc/sysdev/scom.c:86:24: warning: Using plain integer as NULL pointer This patch simply replaces zero by NULL. Signed-off-by: Breno Leitao --- arch/powerpc/sysdev/scom.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/sysdev/scom.c b/arch/powerpc/sysdev/scom.c index 0f6fd5d04d33..a707b24a7ddb 100644 --- a/arch/powerpc/sysdev/scom.c +++ b/arch/powerpc/sysdev/scom.c @@ -60,7 +60,7 @@ scom_map_t scom_map_device(struct device_node *dev, int index) parent = scom_find_parent(dev); if (parent == NULL) - return 0; + return NULL; /* * We support "scom-reg" properties for adding scom registers @@ -83,7 +83,7 @@ scom_map_t scom_map_device(struct device_node *dev, int index) size >>= 2; if (index >= (size / (2*cells))) - return 0; + return NULL; reg = of_read_number(&prop[index * cells * 2], cells); cnt = of_read_number(&prop[index * cells * 2 + cells], cells); -- 2.19.0
[PATCH 5/9] powerpc/xmon: Define static functions
Currently sparse is complaining about three issues on the xmon code. Two
storage classes issues and a dereferencing a 'noderef' pointer. These are
the warnings:
arch/powerpc/xmon/xmon.c:2783:1: warning: symbol 'dump_log_buf' was not
declared. Should it be static?
arch/powerpc/xmon/xmon.c:2989:6: warning: symbol 'format_pte' was not
declared. Should it be static?
arch/powerpc/xmon/xmon.c:2983:30: warning: dereference of noderef
expression
This patch fixes all of them, turning both functions static and
dereferencing a pointer calling rcu_dereference() instead of a
straightforward dereference.
Signed-off-by: Breno Leitao
---
arch/powerpc/xmon/xmon.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
index 4264aedc7775..5c7187923a72 100644
--- a/arch/powerpc/xmon/xmon.c
+++ b/arch/powerpc/xmon/xmon.c
@@ -2779,7 +2779,7 @@ print_address(unsigned long addr)
xmon_print_symbol(addr, "\t# ", "");
}
-void
+static void
dump_log_buf(void)
{
struct kmsg_dumper dumper = { .active = 1 };
@@ -2980,13 +2980,13 @@ static void show_task(struct task_struct *tsk)
printf("%px %016lx %6d %6d %c %2d %s\n", tsk,
tsk->thread.ksp,
- tsk->pid, tsk->parent->pid,
+ tsk->pid, rcu_dereference(tsk->parent)->pid,
state, task_thread_info(tsk)->cpu,
tsk->comm);
}
#ifdef CONFIG_PPC_BOOK3S_64
-void format_pte(void *ptep, unsigned long pte)
+static void format_pte(void *ptep, unsigned long pte)
{
printf("ptep @ 0x%016lx = 0x%016lx\n", (unsigned long)ptep, pte);
printf("Maps physical address = 0x%016lx\n", pte & PTE_RPN_MASK);
--
2.19.0
[PATCH 1/9] powerpc/64s: Include cpu header
Current powerpc security.c file is defining functions, as
cpu_show_meltdown(), cpu_show_spectre_v{1,2} and others, that are being
declared at linux/cpu.h header without including the header file that
contains these declarations.
This is being reported by sparse, which thinks that these functions are
static, due to the lack of declaration:
arch/powerpc/kernel/security.c:105:9: warning: symbol
'cpu_show_meltdown' was not declared. Should it be static?
arch/powerpc/kernel/security.c:139:9: warning: symbol
'cpu_show_spectre_v1' was not declared. Should it be static?
arch/powerpc/kernel/security.c:161:9: warning: symbol
'cpu_show_spectre_v2' was not declared. Should it be static?
arch/powerpc/kernel/security.c:209:6: warning: symbol 'stf_barrier' was
not declared. Should it be static?
arch/powerpc/kernel/security.c:289:9: warning: symbol
'cpu_show_spec_store_bypass' was not declared. Should it be static?
This patch simply includes the proper header (linux/cpu.h) to match
function definition and declaration.
Signed-off-by: Breno Leitao
---
arch/powerpc/kernel/security.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/kernel/security.c b/arch/powerpc/kernel/security.c
index f6f469fc4073..9703dce36307 100644
--- a/arch/powerpc/kernel/security.c
+++ b/arch/powerpc/kernel/security.c
@@ -4,6 +4,7 @@
//
// Copyright 2018, Michael Ellerman, IBM Corporation.
+#include
#include
#include
#include
--
2.19.0
[PATCH 3/9] powerpc/mm: Remove extern from function definition
Function huge_ptep_set_access_flags() has the 'extern' keyword in the
function definition and also in the function declaration. This causes a
warning in 'sparse' since the 'extern' storage class should be used only on
symbol declarations.
arch/powerpc/mm/pgtable.c:232:12: warning: function
'huge_ptep_set_access_flags' with external linkage has definition
This patch removes the keyword from the definition part, while keeps it in
the declaration part.
Signed-off-by: Breno Leitao
---
arch/powerpc/mm/pgtable.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/mm/pgtable.c b/arch/powerpc/mm/pgtable.c
index d71c669c..213933b78077 100644
--- a/arch/powerpc/mm/pgtable.c
+++ b/arch/powerpc/mm/pgtable.c
@@ -229,7 +229,7 @@ int ptep_set_access_flags(struct vm_area_struct *vma,
unsigned long address,
}
#ifdef CONFIG_HUGETLB_PAGE
-extern int huge_ptep_set_access_flags(struct vm_area_struct *vma,
+int huge_ptep_set_access_flags(struct vm_area_struct *vma,
unsigned long addr, pte_t *ptep,
pte_t pte, int dirty)
{
--
2.19.0
Re: [PATCH] powerpc: Fix stack protector crashes on CPU hotplug
On Fri, 2018-10-19 at 16:59 +1100, Michael Ellerman wrote:
> Recently in commit 7241d26e8175 ("powerpc/64: properly initialise
> the stackprotector canary on SMP.") we fixed a crash with stack
> protector on SMP by initialising the stack canary in
> cpu_idle_thread_init().
>
> But this can also causes crashes, when a CPU comes back online after
> being offline:
>
> Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in:
> pnv_smp_cpu_kill_self+0x2a0/0x2b0
> CPU: 1 PID: 0 Comm: swapper/1 Not tainted
> 4.19.0-rc3-gcc-7.3.1-00168-g4ffe713b7587 #94
> Call Trace:
> dump_stack+0xb0/0xf4 (unreliable)
> panic+0x144/0x328
> __stack_chk_fail+0x2c/0x30
> pnv_smp_cpu_kill_self+0x2a0/0x2b0
> cpu_die+0x48/0x70
> arch_cpu_idle_dead+0x20/0x40
> do_idle+0x274/0x390
> cpu_startup_entry+0x38/0x50
> start_secondary+0x5e4/0x600
> start_secondary_prolog+0x10/0x14
>
> Looking at the stack we see that the canary value in the stack frame
> doesn't match the canary in the task/paca. That is because we have
> reinitialised the task/paca value, but then the CPU coming online has
> returned into a function using the old canary value. That causes the
> comparison to fail.
>
> Instead we can call boot_init_stack_canary() from start_secondary()
> which never returns. This is essentially what the generic code does in
> cpu_startup_entry() under #ifdef X86, we should make that non-x86
> specific in a future patch.
>
> Fixes: 7241d26e8175 ("powerpc/64: properly initialise the stackprotector
> canary on SMP.")
> Reported-by: Joel Stanley
> Signed-off-by: Michael Ellerman
> ---
> arch/powerpc/kernel/smp.c | 10 +++---
> 1 file changed, 3 insertions(+), 7 deletions(-)
>
> diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
> index 8e3a5da24d59..951c476faffc 100644
> --- a/arch/powerpc/kernel/smp.c
> +++ b/arch/powerpc/kernel/smp.c
> @@ -61,6 +61,7 @@
> #include
> #include
> #include
> +#include
>
> #ifdef DEBUG
> #include
> @@ -1014,16 +1015,9 @@ static void cpu_idle_thread_init(unsigned int cpu,
> struct task_struct *idle)
> {
> struct thread_info *ti = task_thread_info(idle);
>
> -#ifdef CONFIG_STACKPROTECTOR
> - idle->stack_canary = get_random_canary();
> -#endif
> -
> #ifdef CONFIG_PPC64
> paca_ptrs[cpu]->__current = idle;
> paca_ptrs[cpu]->kstack = (unsigned long)ti + THREAD_SIZE -
> STACK_FRAME_OVERHEAD;
> -#ifdef CONFIG_STACKPROTECTOR
> - paca_ptrs[cpu]->canary = idle->stack_canary;
> -#endif
> #endif
> ti->cpu = cpu;
> secondary_ti = current_set[cpu] = ti;
> @@ -1316,6 +1310,8 @@ void start_secondary(void *unused)
> notify_cpu_starting(cpu);
> set_cpu_online(cpu, true);
>
> + boot_init_stack_canary();
> +
> local_irq_enable();
>
> /* We can enable ftrace for secondary cpus now */
Tested-by: Abdul Haleem
--
Regard's
Abdul Haleem
IBM Linux Technology Centre
[PATCH] selftests: powerpc: Fix warning for security subdir
typing 'make' inside tools/testing/selftests/powerpc gave a build warning: BUILD_TARGET=tools/testing/selftests/powerpc/security; mkdir -p $BUILD_TARGET; make OUTPUT=$BUILD_TARGET -k -C security all make[1]: Entering directory 'tools/testing/selftests/powerpc/security' ../../lib.mk:20: ../../../../scripts/subarch.include: No such file or directory make[1]: *** No rule to make target '../../../../scripts/subarch.include'. make[1]: Failed to remake makefile '../../../../scripts/subarch.include'. The build is one level deeper than lib.mk thinks it is. Set top_srcdir to set things straight. Note that the test program is still built. Signed-off-by: Joel Stanley --- tools/testing/selftests/powerpc/security/Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/testing/selftests/powerpc/security/Makefile b/tools/testing/selftests/powerpc/security/Makefile index 44690f1bb26a..85861c46b445 100644 --- a/tools/testing/selftests/powerpc/security/Makefile +++ b/tools/testing/selftests/powerpc/security/Makefile @@ -1,6 +1,7 @@ # SPDX-License-Identifier: GPL-2.0+ TEST_GEN_PROGS := rfi_flush +top_srcdir = ../../../../.. CFLAGS += -I../../../../../usr/include -- 2.19.1
Re: [PATCH] powerpc/pseries: Export maximum memory value
On Wednesday 10 October 2018 09:50 PM, Nathan Fontenot wrote:
> On 10/10/2018 05:22 AM, Aravinda Prasad wrote:
>> This patch exports the maximum possible amount of memory
>> configured on the system via /proc/powerpc/lparcfg.
>>
>> Signed-off-by: Aravinda Prasad
>> ---
>> arch/powerpc/platforms/pseries/lparcfg.c | 13 +
>> 1 file changed, 13 insertions(+)
>>
>> diff --git a/arch/powerpc/platforms/pseries/lparcfg.c
>> b/arch/powerpc/platforms/pseries/lparcfg.c
>> index 7c872dc..aa82f55 100644
>> --- a/arch/powerpc/platforms/pseries/lparcfg.c
>> +++ b/arch/powerpc/platforms/pseries/lparcfg.c
>> @@ -26,6 +26,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>> #include
>> #include
>> @@ -36,6 +37,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> #include "pseries.h"
>>
>> @@ -433,6 +435,16 @@ static void parse_em_data(struct seq_file *m)
>> seq_printf(m, "power_mode_data=%016lx\n", retbuf[0]);
>> }
>>
>> +static void maxmem_data(struct seq_file *m)
>> +{
>> +unsigned long maxmem = 0;
>> +
>> +maxmem += drmem_info->n_lmbs * drmem_info->lmb_size;
>> +maxmem += hugetlb_total_pages() * PAGE_SIZE;
>> +
>> +seq_printf(m, "MaxMem=%ld\n", maxmem);
>
> Should this be MaxPossibleMem?
>
> At least for the drmem memory the value calculated is the maximum possible
> memory. I wonder if calling it MaxMem would lead users to think they have
> that much memory available to them.
Nathan,
I feel MaxMem makes more sense because, we use "Minimum memory",
"Desired memory" and "Maximum memory" in the LPAR profile configuration
and MaxMem is in fact displaying the value of this "Maximum memory"
profile value.
So I want to keep it as "MaxMem". Let me know if you think otherwise.
Regards,
Aravinda
>
> -Nathan
>
>> +}
>> +
>> static int pseries_lparcfg_data(struct seq_file *m, void *v)
>> {
>> int partition_potential_processors;
>> @@ -491,6 +503,7 @@ static int pseries_lparcfg_data(struct seq_file *m, void
>> *v)
>> seq_printf(m, "slb_size=%d\n", mmu_slb_size);
>> #endif
>> parse_em_data(m);
>> +maxmem_data(m);
>>
>> return 0;
>> }
>>
--
Regards,
Aravinda
Re: powerpc/msi: Fix compile error on mpc83xx
On Fri, 2018-10-19 at 06:12:50 UTC, Christophe Leroy wrote:
> mpic_get_primary_version() is not defined when not using MPIC.
> The compile error log like:
>
> arch/powerpc/sysdev/built-in.o: In function `fsl_of_msi_probe':
> fsl_msi.c:(.text+0x150c): undefined reference to
> `fsl_mpic_primary_get_version'
>
> Signed-off-by: Jia Hongtao
> Signed-off-by: Scott Wood
> Reported-by: Radu Rendec
> Fixes: 807d38b73b6 ("powerpc/mpic: Add get_version API both for internal and
> external use")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Christophe Leroy
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/0f99153def98134403c9149128e59d
cheers
Re: powerpc: Fix stack protector crashes on CPU hotplug
On Fri, 2018-10-19 at 05:59:27 UTC, Michael Ellerman wrote:
> Recently in commit 7241d26e8175 ("powerpc/64: properly initialise
> the stackprotector canary on SMP.") we fixed a crash with stack
> protector on SMP by initialising the stack canary in
> cpu_idle_thread_init().
>
> But this can also causes crashes, when a CPU comes back online after
> being offline:
>
> Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in:
> pnv_smp_cpu_kill_self+0x2a0/0x2b0
> CPU: 1 PID: 0 Comm: swapper/1 Not tainted
> 4.19.0-rc3-gcc-7.3.1-00168-g4ffe713b7587 #94
> Call Trace:
> dump_stack+0xb0/0xf4 (unreliable)
> panic+0x144/0x328
> __stack_chk_fail+0x2c/0x30
> pnv_smp_cpu_kill_self+0x2a0/0x2b0
> cpu_die+0x48/0x70
> arch_cpu_idle_dead+0x20/0x40
> do_idle+0x274/0x390
> cpu_startup_entry+0x38/0x50
> start_secondary+0x5e4/0x600
> start_secondary_prolog+0x10/0x14
>
> Looking at the stack we see that the canary value in the stack frame
> doesn't match the canary in the task/paca. That is because we have
> reinitialised the task/paca value, but then the CPU coming online has
> returned into a function using the old canary value. That causes the
> comparison to fail.
>
> Instead we can call boot_init_stack_canary() from start_secondary()
> which never returns. This is essentially what the generic code does in
> cpu_startup_entry() under #ifdef X86, we should make that non-x86
> specific in a future patch.
>
> Fixes: 7241d26e8175 ("powerpc/64: properly initialise the stackprotector
> canary on SMP.")
> Reported-by: Joel Stanley
> Signed-off-by: Michael Ellerman
> Reviewed-by: Christophe Leroy
Applied to powerpc next.
https://git.kernel.org/powerpc/c/b6aeddea74b08518289fc86545297c
cheers
Re: powerpc/time: Fix clockevent_decrementer initalisation for PR KVM
On Fri, 2018-10-19 at 04:23:19 UTC, Michael Ellerman wrote:
> In the recent commit 8b78fdb045de ("powerpc/time: Use
> clockevents_register_device(), fixing an issue with large
> decrementer") we changed the way we initialise the decrementer
> clockevent(s).
>
> We no longer initialise the mult & shift values of
> decrementer_clockevent itself.
>
> This has the effect of breaking PR KVM, because it uses those values
> in kvmppc_emulate_dec(). The symptom is guest kernels spin forever
> mid-way through boot.
>
> For now fix it by assigning back to decrementer_clockevent the mult
> and shift values.
>
> Fixes: 8b78fdb045de ("powerpc/time: Use clockevents_register_device(), fixing
> an issue with large decrementer")
> Signed-off-by: Michael Ellerman
> Acked-by: Anton Blanchard
Applied to powerpc next.
https://git.kernel.org/powerpc/c/b4d16ab58c41ff0125822464bdff07
cheers
Re: [1/6] powerpc/mm/radix: Fix off-by-one in split mapping logic
On Fri, 2018-10-19 at 04:13:29 UTC, Michael Ellerman wrote: > When we have CONFIG_STRICT_KERNEL_RWX enabled, we try to split the > kernel linear (1:1) mapping so that the kernel text is in a separate > page to kernel data, so we can mark the former read-only. > > We could achieve that just by always using 64K pages for the linear > mapping, but we try to be smarter. Instead we use huge pages when > possible, and only switch to smaller pages when necessary. > > However we have an off-by-one bug in that logic, which causes us to > calculate the wrong boundary between text and data. > > For example with the end of the kernel text at 16M we see: > > radix-mmu: Mapped 0x-0x0120 with 64.0 KiB pages > radix-mmu: Mapped 0x0120-0x4000 with 2.00 MiB pages > radix-mmu: Mapped 0x4000-0x0001 with 1.00 GiB pages > > ie. we mapped from 0 to 18M with 64K pages, even though the boundary > between text and data is at 16M. > > With the fix we see we're correctly hitting the 16M boundary: > > radix-mmu: Mapped 0x-0x0100 with 64.0 KiB pages > radix-mmu: Mapped 0x0100-0x4000 with 2.00 MiB pages > radix-mmu: Mapped 0x4000-0x0001 with 1.00 GiB pages > > Signed-off-by: Michael Ellerman Series applied to powerpc next. https://git.kernel.org/powerpc/c/5c6499b7041b43807dfaeda28aa87f cheers
Re: powerpc/mm: Fix page table dump to work on Radix
On Fri, 2018-10-19 at 04:12:50 UTC, Michael Ellerman wrote: > When we're running on Book3S with the Radix MMU enabled the page table > dump currently prints the wrong addresses because it uses the wrong > start address. > > Fix it to use PAGE_OFFSET rather than KERN_VIRT_START. > > Signed-off-by: Michael Ellerman Applied to powerpc next. https://git.kernel.org/powerpc/c/0d923962ab69c27cca664a2d535e90 cheers
Re: selftests/powerpc: Fix out-of-tree build errors
On Fri, 2018-10-19 at 04:06:16 UTC, Michael Ellerman wrote: > Some of our Makefiles don't do the right thing when building the > selftests with O=, fix them up. > > Signed-off-by: Michael Ellerman Applied to powerpc next. https://git.kernel.org/powerpc/c/d8a2fe29d3c97038c8efcc328d5e79 cheers
Re: powerpc/ftrace: Handle large kernel configs
On Tue, 2018-10-16 at 20:25:00 UTC, "Naveen N. Rao" wrote: > Currently, we expect to be able to reach ftrace_caller() from all > ftrace-enabled functions through a single relative branch. With large > kernel configs, we see functions outside of 32MB of ftrace_caller() > causing ftrace_init() to bail. > > In such configurations, gcc/ld emits two types of trampolines for mcount(): > 1. A long_branch, which has a single branch to mcount() for functions that >are one hop away from mcount(): > c19e8544 <00031b56.long_branch._mcount>: > c19e8544: 4a 69 3f ac b c007c4f0 > <._mcount> > > 2. A plt_branch, for functions that are farther away from mcount(): > c51f33f8 <0008ba04.plt_branch._mcount>: > c51f33f8: 3d 82 ff a4 addis r12,r2,-92 > c51f33fc: e9 8c 04 20 ld r12,1056(r12) > c51f3400: 7d 89 03 a6 mtctr r12 > c51f3404: 4e 80 04 20 bctr > > We can reuse those trampolines for ftrace if we can have those > trampolines go to ftrace_caller() instead. However, with ABIv2, we > cannot depend on r2 being valid. As such, we use only the long_branch > trampolines by patching those to instead branch to ftrace_caller or > ftrace_regs_caller. > > In addition, we add additional trampolines around .text and .init.text > to catch locations that are covered by the plt branches. This allows > ftrace to work with most large kernel configurations. > > For now, we always patch the trampolines to go to ftrace_regs_caller, > which is slightly inefficient. This can be optimized further at a later > point. > > Signed-off-by: Naveen N. Rao Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/67361cf80712867329a9cd3ff0e317 cheers
Re: [v3] powerpc/pseries: Export raw per-CPU VPA data via debugfs
On Tue, 2018-10-16 at 11:50:05 UTC, Aravinda Prasad wrote: > This patch exports the raw per-CPU VPA data via debugfs. > A per-CPU file is created which exports the VPA data of > that CPU to help debug some of the VPA related issues or > to analyze the per-CPU VPA related statistics. > > v3: Removed offline CPU check. > > v2: Included offline CPU check and other review comments. > > Signed-off-by: Aravinda Prasad Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/c6c26fb55e8e4b3fc376be56116859 cheers
Re: [1/2] powerpc/uapi: Fix sigcontext definition to use user_pt_regs
On Mon, 2018-10-15 at 12:01:42 UTC, Michael Ellerman wrote:
> My recent patch to split pt_regs between user and kernel missed
> the usage in struct sigcontext.
>
> Because this is a user visible struct it should be using the user
> visible definition, which when we're building for the kernel is called
> struct user_pt_regs.
>
> As far as I can see this hasn't actually caused a bug (yet), because
> we don't use the sizeof() the sigcontext->regs anywhere. But we should
> still fix it to avoid confusion and future bugs.
>
> Fixes: 002af9391bfb ("powerpc: Split user/kernel definitions of struct
> pt_regs")
> Reported-by: Madhavan Srinivasan
> Signed-off-by: Michael Ellerman
Series applied to powerpc next.
https://git.kernel.org/powerpc/c/22a3d03d69dfd3bfc606d199696982
cheers
Re: powerpc/book3s64: fix dump_linuxpagetables "present" flag
On Mon, 2018-10-15 at 06:37:41 UTC, Christophe Leroy wrote:
> Since commit bd0dbb73e013 ("powerpc/mm/books3s: Add new pte bit to
> mark pte temporarily invalid."), _PAGE_PRESENT doesn't mean exactly
> that a page is present. A page is also considered preset when
> _PAGE_INVALID is set.
>
> This patch changes the meaning of "present" and adds a status "valid"
> associated to the _PAGE_PRESENT flag.
>
> Fixes: bd0dbb73e013 ("powerpc/mm/books3s: Add new pte bit to mark pte
> temporarily invalid.")
> Signed-off-by: Christophe Leroy
> Reviewed-by: Aneesh Kumar K.V
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/3ff38e1874863827374b02b4f31c73
cheers
Re: powerpc/mm: Fix WARN_ON with THP NUMA migration
On Sat, 2018-10-13 at 16:48:15 UTC, "Aneesh Kumar K.V" wrote:
> WARNING: CPU: 12 PID: 4322 at /arch/powerpc/mm/pgtable-book3s64.c:76
> set_pmd_at+0x4c/0x2b0
> Modules linked in:
> CPU: 12 PID: 4322 Comm: qemu-system-ppc Tainted: GW
> 4.19.0-rc3-00758-g8f0c636b0542 #36
> NIP: c00872fc LR: c0484eec CTR:
> REGS: c03fba876fe0 TRAP: 0700 Tainted: GW
> (4.19.0-rc3-00758-g8f0c636b0542)
> MSR: 90010282b033 CR:
> 24282884 XER:
> CFAR: c0484ee8 IRQMASK: 0
> GPR00: c0484eec c03fba877268 c1f0ec00 c03fbd229f80
> GPR04: 7c8fe8e0 c03f864c5a38 860300853ec0 0080
> GPR08: 8000 0001 04010080 0001
> GPR12: 2000 c03f5400 c03fce292000 7c902457
> GPR16: 00ff 0001 c1885950
> GPR20: 001c0004807c 0008 c1f49d05
> GPR24: 7c8fe8e0 c20f2468 c03fcd33b090
> GPR28: 7c8fe8e0 c03fbd229f80 c03f864c5a38 860300853ec0
> NIP [c00872fc] set_pmd_at+0x4c/0x2b0
> LR [c0484eec] do_huge_pmd_numa_page+0xb1c/0xc20
> Call Trace:
> [c03fba877268] [c045931c] mpol_misplaced+0x1bc/0x230 (unreliable)
> [c03fba8772c8] [c0484eec] do_huge_pmd_numa_page+0xb1c/0xc20
> [c03fba877398] [c040d344] __handle_mm_fault+0x5e4/0x2300
> [c03fba8774d8] [c040f400] handle_mm_fault+0x3a0/0x420
> [c03fba877528] [c03ff6f4] __get_user_pages+0x2e4/0x560
> [c03fba877628] [c0400314] get_user_pages_unlocked+0x104/0x2a0
> [c03fba8776c8] [c0118f44] __gfn_to_pfn_memslot+0x284/0x6a0
> [c03fba877748] [c01463a0]
> kvmppc_book3s_radix_page_fault+0x360/0x12d0
> [c03fba877838] [c0142228] kvmppc_book3s_hv_page_fault+0x48/0x1300
> [c03fba877988] [c013dc08] kvmppc_vcpu_run_hv+0x1808/0x1b50
> [c03fba877af8] [c0126b44] kvmppc_vcpu_run+0x34/0x50
> [c03fba877b18] [c0123268] kvm_arch_vcpu_ioctl_run+0x288/0x2d0
> [c03fba877b98] [c011253c] kvm_vcpu_ioctl+0x1fc/0x8c0
> [c03fba877d08] [c04e9b24] do_vfs_ioctl+0xa44/0xae0
> [c03fba877db8] [c04e9c44] ksys_ioctl+0x84/0xf0
> [c03fba877e08] [c04e9cd8] sys_ioctl+0x28/0x80
>
> We removed the pte_protnone check earlier with the understanding that we
> mark the pte invalid before the set_pte/set_pmd usage. But the huge pmd
> autonuma still use the set_pmd_at directly. This is ok because a protnone pte
> won't have translation cache in TLB.
>
> Fixes: da7ad366b497 ("powerpc/mm/book3s: Update pmd_present to look at
> _PAGE_PRESENT bit")
> Signed-off-by: Aneesh Kumar K.V
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/dd0e144a632bcf2b5a6f04e2628e32
cheers
Re: powerpc/traps: restore recoverability of machine_check interrupts
On Sat, 2018-10-13 at 09:16:22 UTC, Christophe Leroy wrote:
> commit b96672dd840f ("powerpc: Machine check interrupt is a non-
> maskable interrupt") added a call to nmi_enter() at the beginning of
> machine check restart exception handler. Due to that, in_interrupt()
> always returns true regardless of the state before entering the
> exception, and die() panics even when the system was not already in
> interrupt.
>
> This patch calls nmi_exit() before calling die() in order to restore
> the interrupt state we had before calling nmi_enter()
>
> Fixes: b96672dd840f ("powerpc: Machine check interrupt is a non-maskable
> interrupt")
> Signed-off-by: Christophe Leroy
> Reviewed-by: Nicholas Piggin
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/daf00ae71dad8aa05965713c62558a
cheers
Re: powerpc/kgdb: add kgdb_arch_set/remove_breakpoint()
On Tue, 2018-09-18 at 09:26:03 UTC, Christophe Leroy wrote:
> Generic implementation fails to remove breakpoints after init
> when CONFIG_STRICT_KERNEL_RWX is selected:
>
> [ 13.251285] KGDB: BP remove failed: c001c338
> [ 13.259587] kgdbts: ERROR PUT: end of test buffer on 'do_fork_test' line 8
> expected OK got $E14#aa
> [ 13.268969] KGDB: re-enter exception: ALL breakpoints killed
> [ 13.275099] CPU: 0 PID: 1 Comm: init Not tainted 4.18.0-g82bbb913ffd8 #860
> [ 13.282836] Call Trace:
> [ 13.285313] [c60e1ba0] [c0080ef0] kgdb_handle_exception+0x6f4/0x720
> (unreliable)
> [ 13.292618] [c60e1c30] [c000e97c] kgdb_handle_breakpoint+0x3c/0x98
> [ 13.298709] [c60e1c40] [c000af54] program_check_exception+0x104/0x700
> [ 13.305083] [c60e1c60] [c000e45c] ret_from_except_full+0x0/0x4
> [ 13.310845] [c60e1d20] [c02a22ac] run_simple_test+0x2b4/0x2d4
> [ 13.316532] [c60e1d30] [c0081698] put_packet+0xb8/0x158
> [ 13.321694] [c60e1d60] [c00820b4] gdb_serial_stub+0x230/0xc4c
> [ 13.327374] [c60e1dc0] [c0080af8] kgdb_handle_exception+0x2fc/0x720
> [ 13.333573] [c60e1e50] [c000e928] kgdb_singlestep+0xb4/0xcc
> [ 13.339068] [c60e1e70] [c000ae1c] single_step_exception+0x90/0xac
> [ 13.345100] [c60e1e80] [c000e45c] ret_from_except_full+0x0/0x4
> [ 13.350865] [c60e1f40] [c000e11c] ret_from_syscall+0x0/0x38
> [ 13.356346] Kernel panic - not syncing: Recursive entry to debugger
>
> This patch creates powerpc specific version of
> kgdb_arch_set_breakpoint() and kgdb_arch_remove_breakpoint()
> using patch_instruction()
>
> Fixes: 1e0fc9d1eb2b ("powerpc/Kconfig: Enable STRICT_KERNEL_RWX for some
> configs")
> Signed-off-by: Christophe Leroy
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/fb978ca207743badfe7efd9eebe68b
cheers
Re: [RFC] powerpc/64/module: REL32 relocation range check
On Wed, 2018-08-29 at 11:56:56 UTC, Nicholas Piggin wrote:
> The recent module relocation overflow crash demonstrated that we
> have no range checking on REL32 relative relocations. This patch
> implements a basic check, the same kernel that previously oopsed
> and rebooted now continues with some of these errors when loading
> the module:
>
> module_64: x_tables: REL32 527703503449812 out of range!
>
> Question is whether other relocations (ADDR32, REL16, TOC16, etc.)
> should also have overflow checks.
> ---
> arch/powerpc/kernel/module_64.c | 9 -
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/kernel/module_64.c b/arch/powerpc/kernel/module_64.c
> index a2636c250b7b..2a2fb656d23b 100644
> --- a/arch/powerpc/kernel/module_64.c
> +++ b/arch/powerpc/kernel/module_64.c
> @@ -678,7 +678,14 @@ int apply_relocate_add(Elf64_Shdr *sechdrs,
>
> case R_PPC64_REL32:
> /* 32 bits relative (used by relative exception tables)
> */
> - *(u32 *)location = value - (unsigned long)location;
> + /* Convert value to relative */
> + value -= (unsigned long)location;
> + if (value + 0x8000 > 0x) {
> + pr_err("%s: REL32 %li out of range!\n",
> +me->name, (long int)value);
> + return -ENOEXEC;
> + }
> + *(u32 *)location = value;
> break;
>
> case R_PPC64_TOCSAVE:
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/b851ba02a6f3075f0f99c60c4bc30a
cheers
Re: powerpc/64s/radix: Fix radix__flush_tlb_collapsed_pmd double flushing pmd
On Tue, 2018-08-28 at 08:11:27 UTC, Nicholas Piggin wrote: > Signed-off-by: Nicholas Piggin Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/dd76ff5af35350fd6d5bb5b069e73b cheers
Re: powerpc/sysdev/ipic: check primary_ipic NULL pointer before using it
On Mon, 2018-08-27 at 08:27:27 UTC, Christophe Leroy wrote: > ipic_get_mcp_status() is used by targets implementing NMI > watchdog in target specific machine check handler in order > to known whether a machine check results from a watchdog > NMI reset. > > In case of very early machine check, primary_ipic pointer > might not have been set yet, so ipic_get_mcp_status() needs > to check it for nullity before using it. > > Signed-off-by: Christophe Leroy Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/6beb3381b12793726783a5e9428250 cheers
Re: [v2] powerpc/mm: fix always true/false warning in slice.c
On Thu, 2018-08-02 at 09:25:55 UTC, Christophe Leroy wrote:
> This patch fixes the following warnings (obtained with make W=1).
>
> arch/powerpc/mm/slice.c: In function 'slice_range_to_mask':
> arch/powerpc/mm/slice.c:73:12: error: comparison is always true due to
> limited range of data type [-Werror=type-limits]
> if (start < SLICE_LOW_TOP) {
> ^
> arch/powerpc/mm/slice.c:81:20: error: comparison is always false due to
> limited range of data type [-Werror=type-limits]
> if ((start + len) > SLICE_LOW_TOP) {
> ^
> arch/powerpc/mm/slice.c: In function 'slice_mask_for_free':
> arch/powerpc/mm/slice.c:136:17: error: comparison is always true due to
> limited range of data type [-Werror=type-limits]
> if (high_limit <= SLICE_LOW_TOP)
> ^
> arch/powerpc/mm/slice.c: In function 'slice_check_range_fits':
> arch/powerpc/mm/slice.c:185:12: error: comparison is always true due to
> limited range of data type [-Werror=type-limits]
> if (start < SLICE_LOW_TOP) {
> ^
> arch/powerpc/mm/slice.c:195:39: error: comparison is always false due to
> limited range of data type [-Werror=type-limits]
> if (SLICE_NUM_HIGH && ((start + len) > SLICE_LOW_TOP)) {
>^
> arch/powerpc/mm/slice.c: In function 'slice_scan_available':
> arch/powerpc/mm/slice.c:306:11: error: comparison is always true due to
> limited range of data type [-Werror=type-limits]
> if (addr < SLICE_LOW_TOP) {
>^
> arch/powerpc/mm/slice.c: In function 'get_slice_psize':
> arch/powerpc/mm/slice.c:709:11: error: comparison is always true due to
> limited range of data type [-Werror=type-limits]
> if (addr < SLICE_LOW_TOP) {
>^
>
> Signed-off-by: Christophe Leroy
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/37e9c674e7e6f445e12cb1151017bd
cheers
Re: [v5, 1/3] powerpc/time: isolate scaled cputime accounting in dedicated functions.
On Thu, 2018-08-02 at 07:53:57 UTC, Christophe Leroy wrote: > scaled cputime is only meaningfull when the processor has > SPURR and/or PURR, which means only on PPC64. > > In preparation of the following patch that will remove > CONFIG_ARCH_HAS_SCALED_CPUTIME on PPC32, this patch moves > all scaled cputing accounting logic into dedicated functions. > > This patch doesn't change any functionality. It's only code > reorganisation. > > Signed-off-by: Christophe Leroy Series applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/b38a181c11d0b5e84b40732dbb06cc cheers
Re: selftests/powerpc: Add a test of wild bctr
On Tue, 2018-07-24 at 05:53:22 UTC, Michael Ellerman wrote: > This tests that a bctr (Branch to counter and link), ie. a function > call, to a wildly out-of-bounds address is handled correctly. > > Some old kernel versions didn't handle it correctly, see eg: > > "powerpc/slb: Force a full SLB flush when we insert for a bad EA" > https://lists.ozlabs.org/pipermail/linuxppc-dev/2017-April/157397.html > > Signed-off-by: Michael Ellerman Applied to powerpc next. https://git.kernel.org/powerpc/c/b7683fc66eba91674e52c30f4d8e59 cheers
Re: powerpc/mm: fix missing prototypes in slice.c
On Fri, 2018-06-22 at 13:49:48 UTC, Christophe Leroy wrote: > This patch fixes the following warnings (obtained with make W=1). > > arch/powerpc/mm/slice.c: At top level: > arch/powerpc/mm/slice.c:682:15: error: no previous prototype for > 'arch_get_unmapped_area' [-Werror=missing-prototypes] > unsigned long arch_get_unmapped_area(struct file *filp, >^ > arch/powerpc/mm/slice.c:692:15: error: no previous prototype for > 'arch_get_unmapped_area_topdown' [-Werror=missing-prototypes] > unsigned long arch_get_unmapped_area_topdown(struct file *filp, >^ > > Signed-off-by: Christophe Leroy Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/aa5456abdc20568f5da348209148a9 cheers
Re: [v3] powerpc: Add support for function error injection
On Thu, 2018-06-07 at 09:52:02 UTC, "Naveen N. Rao" wrote: > We implement regs_set_return_value() and override_function_with_return() > for this purpose. > > On powerpc, a return from a function (blr) just branches to the location > contained in the link register. So, we can just update pt_regs rather > than redirecting execution to a dummy function that returns. > > Signed-off-by: Naveen N. Rao > Reviewed-by: Samuel Mendoza-Jonas Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/7cd01b08d35f1b7d55686ed8cd57c9 cheers
Re: powerpc64/module elfv1: Set opd addresses after module relocation
On Tue, 2018-05-29 at 06:51:00 UTC, "Naveen N. Rao" wrote:
> module_frob_arch_sections() is called before the module is moved to its
> final location. The function descriptor section addresses we are setting
> here are thus invalid. Fix this by processing opd section during
> module_finalize()
>
> Fixes: 5633e85b2c313 ("powerpc64: Add .opd based function descriptor
> dereference")
> Cc: sta...@vger.kernel.org # v4.16
> Signed-off-by: Naveen N. Rao
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/59fe7eaf3598a89cbcd72e645b1d08
cheers
Re: [v2,1/2] selftests/powerpc: Move UCONTEXT_NIA() into utils.h
On Mon, 2018-05-21 at 15:13:56 UTC, "Naveen N. Rao" wrote: > ... so that it can be used by others. > > Signed-off-by: Naveen N. Rao Series applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/db3848515aff369404c31ef5a63699 cheers
Re: [v2,1/2] powerpc/mm: Add missing tracepoint for tlbie
On Wed, 2018-03-21 at 14:16:58 UTC, Christophe Leroy wrote:
> commit 0428491cba927 ("powerpc/mm: Trace tlbie(l) instructions")
> added tracepoints for tlbie calls, but _tlbil_va() was forgotten
>
> Fixes: 0428491cba927 ("powerpc/mm: Trace tlbie(l) instructions")
> Signed-off-by: Christophe Leroy
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/cf4a6085151ae3f4e78dd91981833e
cheers
