* Re: [PATCH v5] pseries: prevent free CPU ids to be reused on another node
From: Michael Ellerman @ 2021-08-18 13:38 UTC (permalink / raw)
To: paulus, benh, mpe, Laurent Dufour; +Cc: nathanl, linuxppc-dev, linux-kernel
In-Reply-To: <20210429174908.16613-1-ldufour@linux.ibm.com>
On Thu, 29 Apr 2021 19:49:08 +0200, Laurent Dufour wrote:
> When a CPU is hot added, the CPU ids are taken from the available mask from
> the lower possible set. If that set of values was previously used for CPU
> attached to a different node, this seems to application like if these CPUs
> have migrated from a node to another one which is not expected in real
> life.
>
> To prevent this, it is needed to record the CPU ids used for each node and
> to not reuse them on another node. However, to prevent CPU hot plug to
> fail, in the case the CPU ids is starved on a node, the capability to reuse
> other nodes’ free CPU ids is kept. A warning is displayed in such a case
> to warn the user.
>
> [...]
Applied to powerpc/next.
[1/1] pseries: prevent free CPU ids to be reused on another node
https://git.kernel.org/powerpc/c/bd1dd4c5f5286df0148b5b316f37c583b8f55fa1
cheers
^ permalink raw reply
* Re: [PATCH v4 0/5] nvmem: nintendo-otp: Add new driver for the Wii and Wii U OTP
From: Michael Ellerman @ 2021-08-18 13:38 UTC (permalink / raw)
To: linuxppc-dev, Emmanuel Gil Peyrot, devicetree, Rob Herring
Cc: linux-kernel, Srinivas Kandagatla, Ash Logan, Paul Mackerras,
Jonathan Neuschäfer
In-Reply-To: <20210801073822.12452-1-linkmauve@linkmauve.fr>
On Sun, 1 Aug 2021 09:38:17 +0200, Emmanuel Gil Peyrot wrote:
> The OTP is a read-only memory area which contains various keys and
> signatures used to decrypt, encrypt or verify various pieces of storage.
>
> Its size depends on the console, it is 128 bytes on the Wii and
> 1024 bytes on the Wii U (split into eight 128 bytes banks).
>
> It can be used directly by writing into one register and reading from
> the other one, without any additional synchronisation.
>
> [...]
Patches 3-5 applied to powerpc/next.
[3/5] powerpc: wii.dts: Reduce the size of the control area
https://git.kernel.org/powerpc/c/b11748e693166679acc13c8a4328a71efe1d4a89
[4/5] powerpc: wii.dts: Expose the OTP on this platform
https://git.kernel.org/powerpc/c/562a610b4c5119034aed300f6ae212ec7a20c4b4
[5/5] powerpc: wii_defconfig: Enable OTP by default
https://git.kernel.org/powerpc/c/140a89b7bfe65e9649c4a3678f74c32556834ec1
cheers
^ permalink raw reply
* Re: [PATCH 1/3] powerpc: remove unused zInstall target from arch/powerpc/boot/Makefile
From: Michael Ellerman @ 2021-08-18 13:38 UTC (permalink / raw)
To: Masahiro Yamada, Michael Ellerman, Paul Mackerras, linuxppc-dev,
Benjamin Herrenschmidt
Cc: Jordan Niethe, Nick Desaulniers, Gustavo A. R. Silva,
Nicholas Piggin, linux-kernel, Bill Wendling, Joel Stanley
In-Reply-To: <20210729141937.445051-1-masahiroy@kernel.org>
On Thu, 29 Jul 2021 23:19:35 +0900, Masahiro Yamada wrote:
> Commit c913e5f95e54 ("powerpc/boot: Don't install zImage.* from make
> install") added the zInstall target to arch/powerpc/boot/Makefile,
> but you cannot use it since the corresponding hook is missing in
> arch/powerpc/Makefile.
>
> It has never worked since its addition. Nobody has complained about
> it for 7 years, which means this code was unneeded.
>
> [...]
Applied to powerpc/next.
[1/3] powerpc: remove unused zInstall target from arch/powerpc/boot/Makefile
https://git.kernel.org/powerpc/c/156ca4e650bfb9a4259b427069caa11b5a4df3d4
[2/3] powerpc: make the install target not depend on any build artifact
https://git.kernel.org/powerpc/c/9bef456b20581e630ef9a13555ca04fed65a859d
[3/3] powerpc: move the install rule to arch/powerpc/Makefile
https://git.kernel.org/powerpc/c/86ff0bce2e9665c8b074930fe6caed615da070c1
cheers
^ permalink raw reply
* Re: [PATCHv2 0/3] Subject: [PATCHv2 0/3] Make cache-object aware of L3 siblings by parsing "ibm, thread-groups" property
From: Michael Ellerman @ 2021-08-18 13:38 UTC (permalink / raw)
To: linuxppc-dev, Parth Shah; +Cc: parths1229, mikey, svaidy, srikar, ego
In-Reply-To: <20210728175607.591679-1-parth@linux.ibm.com>
On Wed, 28 Jul 2021 23:26:04 +0530, Parth Shah wrote:
> Changes from v1 -> v2:
> - Based on Gautham's comments, use a separate thread_group_l3_cache_map
> and modify parsing code to build cache_map for L3. This makes the
> cache_map building code isolated from the parsing code.
> v1 can be found at:
> https://lists.ozlabs.org/pipermail/linuxppc-dev/2021-June/230680.html
>
> [...]
Applied to powerpc/next.
[1/3] powerpc/cacheinfo: Lookup cache by dt node and thread-group id
https://git.kernel.org/powerpc/c/a4bec516b9c0823d7e2bb8c8928c98b535cf9adf
[2/3] powerpc/cacheinfo: Remove the redundant get_shared_cpu_map()
https://git.kernel.org/powerpc/c/69aa8e078545bc14d84a8b4b3cb914ac8f9f280e
[3/3] powerpc/smp: Use existing L2 cache_map cpumask to find L3 cache siblings
https://git.kernel.org/powerpc/c/e9ef81e1079b0c4c374fba0f9affa7129c7c913b
cheers
^ permalink raw reply
* Re: [PATCH] cpuidle: pseries: Mark pseries_idle_proble() as __init
From: Michael Ellerman @ 2021-08-18 13:38 UTC (permalink / raw)
To: Michael Ellerman, Nathan Chancellor
Cc: Gautham R. Shenoy, linux-pm, Nick Desaulniers, linux-kernel,
clang-built-linux, Paul Mackerras, linuxppc-dev
In-Reply-To: <20210803211547.1093820-1-nathan@kernel.org>
On Tue, 3 Aug 2021 14:15:47 -0700, Nathan Chancellor wrote:
> After commit 7cbd631d4dec ("cpuidle: pseries: Fixup CEDE0 latency only
> for POWER10 onwards"), pseries_idle_probe() is no longer inlined when
> compiling with clang, which causes a modpost warning:
>
> WARNING: modpost: vmlinux.o(.text+0xc86a54): Section mismatch in
> reference from the function pseries_idle_probe() to the function
> .init.text:fixup_cede0_latency()
> The function pseries_idle_probe() references
> the function __init fixup_cede0_latency().
> This is often because pseries_idle_probe lacks a __init
> annotation or the annotation of fixup_cede0_latency is wrong.
>
> [...]
Applied to powerpc/next.
[1/1] cpuidle: pseries: Mark pseries_idle_proble() as __init
https://git.kernel.org/powerpc/c/d04691d373e75c83424b85c0e68e4a3f9370c10d
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/64s/perf: Always use SIAR for kernel interrupts
From: Michael Ellerman @ 2021-08-18 13:38 UTC (permalink / raw)
To: linuxppc-dev, Nicholas Piggin; +Cc: Athira Rajeev, Madhavan Srinivasan
In-Reply-To: <20210720141504.420110-1-npiggin@gmail.com>
On Wed, 21 Jul 2021 00:15:04 +1000, Nicholas Piggin wrote:
> If an interrupt is taken in kernel mode, always use SIAR for it rather than
> looking at regs_sipr. This prevents samples piling up around interrupt
> enable (hard enable or interrupt replay via soft enable) in PMUs / modes
> where the PR sample indication is not in synch with SIAR.
>
> This results in better sampling of interrupt entry and exit in particular.
Applied to powerpc/next.
[1/1] powerpc/64s/perf: Always use SIAR for kernel interrupts
https://git.kernel.org/powerpc/c/cf9c615cde49fb5d2480549c8c955a0a387798d3
cheers
^ permalink raw reply
* Re: [PATCH v2 0/1] cpufreq:powernv: Fix init_chip_info initialization in numa=off
From: Michael Ellerman @ 2021-08-18 13:38 UTC (permalink / raw)
To: pratik.r.sampat, rjw, Pratik R. Sampat, linux-kernel, linux-pm,
linuxppc-dev, stable, mpe
In-Reply-To: <20210728120500.87549-1-psampat@linux.ibm.com>
On Wed, 28 Jul 2021 17:34:59 +0530, Pratik R. Sampat wrote:
> v1: https://lkml.org/lkml/2021/7/26/1509
> Changelog v1-->v2:
> Based on comments from Gautham,
> 1. Included a #define for MAX_NR_CHIPS instead of hardcoding the
> allocation.
>
> Pratik R. Sampat (1):
> cpufreq:powernv: Fix init_chip_info initialization in numa=off
>
> [...]
Applied to powerpc/next.
[1/1] cpufreq:powernv: Fix init_chip_info initialization in numa=off
https://git.kernel.org/powerpc/c/f34ee9cb2c5ac5af426fee6fa4591a34d187e696
cheers
^ permalink raw reply
* Re: [PATCH 3/3] powerpc: move the install rule to arch/powerpc/Makefile
From: Masahiro Yamada @ 2021-08-18 13:58 UTC (permalink / raw)
To: Nick Desaulniers
Cc: Linux Kernel Mailing List, Nicholas Piggin, Gustavo A. R. Silva,
Jordan Niethe, Paul Mackerras, Bill Wendling, Miguel Ojeda,
linuxppc-dev, Joel Stanley
In-Reply-To: <CAKwvOdkRuxaUvAi4ik2SiDgEeNOX6D76aBtHDBPyDVTumWskLg@mail.gmail.com>
On Sat, Jul 31, 2021 at 5:30 AM Nick Desaulniers
<ndesaulniers@google.com> wrote:
>
> On Thu, Jul 29, 2021 at 7:22 AM Masahiro Yamada <masahiroy@kernel.org> wrote:
> >
> > Currently, the install target in arch/powerpc/Makefile descends into
> > arch/powerpc/boot/Makefile to invoke the shell script, but there is no
> > good reason to do so.
>
> Sure, but there are more arch/ subdirs that DO invoke install.sh from
> arch/<arch>/boot/Makefile than, not:
>
> arch/<arch>/boot/Makefile:
> - parisc
> - nios2
> - arm
> - nds32
> - sparc
> - riscv
> - 390
> - ppc (this patch)
> - x86
> - arm64
I sent patches for these architectures.
Check LKML.
> arch/<arch>/Makefile:
> - ia64
> - m68k
>
> Patch is fine, but right now the tree is a bit inconsistent.
>
> >
> > arch/powerpc/Makefile can run the shell script directly.
> >
> > Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
> > ---
> >
> > arch/powerpc/Makefile | 3 ++-
> > arch/powerpc/boot/Makefile | 6 ------
> > 2 files changed, 2 insertions(+), 7 deletions(-)
> >
> > diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
> > index 6505d66f1193..9aaf1abbc641 100644
> > --- a/arch/powerpc/Makefile
> > +++ b/arch/powerpc/Makefile
> > @@ -407,7 +407,8 @@ endef
> >
> > PHONY += install
> > install:
> > - $(Q)$(MAKE) $(build)=$(boot) install
> > + sh -x $(srctree)/$(boot)/install.sh "$(KERNELRELEASE)" vmlinux \
> > + System.map "$(INSTALL_PATH)"
> >
> > archclean:
> > $(Q)$(MAKE) $(clean)=$(boot)
> > diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
> > index 0d165bd98b61..10c0fb306f15 100644
> > --- a/arch/powerpc/boot/Makefile
> > +++ b/arch/powerpc/boot/Makefile
> > @@ -444,12 +444,6 @@ $(obj)/zImage: $(addprefix $(obj)/, $(image-y))
> > $(obj)/zImage.initrd: $(addprefix $(obj)/, $(initrd-y))
> > $(Q)rm -f $@; ln $< $@
> >
> > -# Only install the vmlinux
> > -install:
> > - sh -x $(srctree)/$(src)/install.sh "$(KERNELRELEASE)" vmlinux System.map "$(INSTALL_PATH)"
> > -
> > -PHONY += install
> > -
> > # anything not in $(targets)
> > clean-files += $(image-) $(initrd-) cuImage.* dtbImage.* treeImage.* \
> > zImage zImage.initrd zImage.chrp zImage.coff zImage.holly \
> > --
> > 2.27.0
> >
>
>
> --
> Thanks,
> ~Nick Desaulniers
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* Re: [PATCH v2] powerpc/mm: Fix set_memory_*() against concurrent accesses
From: Murilo Opsfelder Araújo @ 2021-08-18 14:29 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev
Cc: lvivier, jniethe5, aneesh.kumar, npiggin, farosas
In-Reply-To: <20210818120518.3603172-1-mpe@ellerman.id.au>
On 8/18/21 9:05 AM, Michael Ellerman wrote:
> Laurent reported that STRICT_MODULE_RWX was causing intermittent crashes
> on one of his systems:
>
> kernel tried to execute exec-protected page (c008000004073278) - exploit attempt? (uid: 0)
> BUG: Unable to handle kernel instruction fetch
> Faulting instruction address: 0xc008000004073278
> Oops: Kernel access of bad area, sig: 11 [#1]
> LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries
> Modules linked in: drm virtio_console fuse drm_panel_orientation_quirks ...
> CPU: 3 PID: 44 Comm: kworker/3:1 Not tainted 5.14.0-rc4+ #12
> Workqueue: events control_work_handler [virtio_console]
> NIP: c008000004073278 LR: c008000004073278 CTR: c0000000001e9de0
> REGS: c00000002e4ef7e0 TRAP: 0400 Not tainted (5.14.0-rc4+)
> MSR: 800000004280b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 24002822 XER: 200400cf
> ...
> NIP fill_queue+0xf0/0x210 [virtio_console]
> LR fill_queue+0xf0/0x210 [virtio_console]
> Call Trace:
> fill_queue+0xb4/0x210 [virtio_console] (unreliable)
> add_port+0x1a8/0x470 [virtio_console]
> control_work_handler+0xbc/0x1e8 [virtio_console]
> process_one_work+0x290/0x590
> worker_thread+0x88/0x620
> kthread+0x194/0x1a0
> ret_from_kernel_thread+0x5c/0x64
>
> Jordan, Fabiano & Murilo were able to reproduce and identify that the
> problem is caused by the call to module_enable_ro() in do_init_module(),
> which happens after the module's init function has already been called.
>
> Our current implementation of change_page_attr() is not safe against
> concurrent accesses, because it invalidates the PTE before flushing the
> TLB and then installing the new PTE. That leaves a window in time where
> there is no valid PTE for the page, if another CPU tries to access the
> page at that time we see something like the fault above.
>
> We can't simply switch to set_pte_at()/flush TLB, because our hash MMU
> code doesn't handle a set_pte_at() of a valid PTE. See [1].
>
> But we do have pte_update(), which replaces the old PTE with the new,
> meaning there's no window where the PTE is invalid. And the hash MMU
> version hash__pte_update() deals with synchronising the hash page table
> correctly.
>
> [1]: https://lore.kernel.org/linuxppc-dev/87y318wp9r.fsf@linux.ibm.com/
>
> Fixes: 1f9ad21c3b38 ("powerpc/mm: Implement set_memory() routines")
> Reported-by: Laurent Vivier <lvivier@redhat.com>
> Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com>
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Reviewed-by: Murilo Opsfelder Araújo <muriloo@linux.ibm.com>
> ---
> arch/powerpc/mm/pageattr.c | 23 ++++++++++-------------
> 1 file changed, 10 insertions(+), 13 deletions(-)
>
> v2: Use pte_update(..., ~0, pte_val(pte), ...) as suggested by Fabiano,
> and ptep_get() as suggested by Christophe.
>
> diff --git a/arch/powerpc/mm/pageattr.c b/arch/powerpc/mm/pageattr.c
> index 0876216ceee6..edea388e9d3f 100644
> --- a/arch/powerpc/mm/pageattr.c
> +++ b/arch/powerpc/mm/pageattr.c
> @@ -18,16 +18,12 @@
> /*
> * Updates the attributes of a page in three steps:
> *
> - * 1. invalidate the page table entry
> - * 2. flush the TLB
> - * 3. install the new entry with the updated attributes
> - *
> - * Invalidating the pte means there are situations where this will not work
> - * when in theory it should.
> - * For example:
> - * - removing write from page whilst it is being executed
> - * - setting a page read-only whilst it is being read by another CPU
> + * 1. take the page_table_lock
> + * 2. install the new entry with the updated attributes
> + * 3. flush the TLB
> *
> + * This sequence is safe against concurrent updates, and also allows updating the
> + * attributes of a page currently being executed or accessed.
> */
> static int change_page_attr(pte_t *ptep, unsigned long addr, void *data)
> {
> @@ -36,9 +32,7 @@ static int change_page_attr(pte_t *ptep, unsigned long addr, void *data)
>
> spin_lock(&init_mm.page_table_lock);
>
> - /* invalidate the PTE so it's safe to modify */
> - pte = ptep_get_and_clear(&init_mm, addr, ptep);
> - flush_tlb_kernel_range(addr, addr + PAGE_SIZE);
> + pte = ptep_get(ptep);
>
> /* modify the PTE bits as desired, then apply */
> switch (action) {
> @@ -59,11 +53,14 @@ static int change_page_attr(pte_t *ptep, unsigned long addr, void *data)
> break;
> }
>
> - set_pte_at(&init_mm, addr, ptep, pte);
> + pte_update(&init_mm, addr, ptep, ~0UL, pte_val(pte), 0);
>
> /* See ptesync comment in radix__set_pte_at() */
> if (radix_enabled())
> asm volatile("ptesync": : :"memory");
> +
> + flush_tlb_kernel_range(addr, addr + PAGE_SIZE);
> +
> spin_unlock(&init_mm.page_table_lock);
>
> return 0;
>
> base-commit: cbc06f051c524dcfe52ef0d1f30647828e226d30
>
--
Murilo
^ permalink raw reply
* Re: [PATCH v2 1/2] powerpc/bug: Remove specific powerpc BUG_ON() and WARN_ON() on PPC32
From: Segher Boessenkool @ 2021-08-18 15:06 UTC (permalink / raw)
To: Nicholas Piggin; +Cc: linux-kernel, Paul Mackerras, linuxppc-dev
In-Reply-To: <1628834356.pr4zgn1xf1.astroid@bobo.none>
On Fri, Aug 13, 2021 at 04:08:13PM +1000, Nicholas Piggin wrote:
> This one possibly the branches end up in predictors, whereas conditional
> trap is always just speculated not to hit. Branches may also have a
> throughput limit on execution whereas trap could be more (1 per cycle
> vs 4 per cycle on POWER9).
I thought only *taken* branches are just one per cycle? And those
branches are only taken for the exceptional condition (or the case where
we do not care about performance, anyway, if we do have an error most of
the time ;-) )
> On typical ppc32 CPUs, maybe it's a more obvious win. As you say there
> is the CFAR issue as well which makes it a problem for 64s. It would
> have been nice if it could use the same code though.
On 64-bit the code looks better for the no-error path as well.
> Maybe one day gcc's __builtin_trap() will become smart enough around
> conditional statements that it it generates better code and tries to
> avoid branches.
Internally *all* traps are conditional, in GCC. It also can optimise
them quite well. There must be something in the kernel macros that
prevents good optimisation.
Segher
^ permalink raw reply
* [PATCH 1/1] selftests/powerpc: Add memmove_64 test
From: Ritesh Harjani @ 2021-08-18 15:50 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Aneesh Kumar K . V, Ritesh Harjani, Vaibhav Jain
While debugging an issue, we wanted to check whether the arch specific
kernel memmove implementation is correct. This selftest could help test that.
Suggested-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Suggested-by: Vaibhav Jain <vaibhav@linux.ibm.com>
Signed-off-by: Ritesh Harjani <riteshh@linux.ibm.com>
---
tools/testing/selftests/powerpc/Makefile | 1 +
.../selftests/powerpc/memmoveloop/.gitignore | 2 +
.../selftests/powerpc/memmoveloop/Makefile | 19 +++++++
.../powerpc/memmoveloop/asm/asm-compat.h | 0
.../powerpc/memmoveloop/asm/export.h | 4 ++
.../powerpc/memmoveloop/asm/feature-fixups.h | 0
.../selftests/powerpc/memmoveloop/asm/kasan.h | 0
.../powerpc/memmoveloop/asm/ppc_asm.h | 39 +++++++++++++
.../powerpc/memmoveloop/asm/processor.h | 0
.../selftests/powerpc/memmoveloop/mem_64.S | 1 +
.../selftests/powerpc/memmoveloop/memcpy_64.S | 1 +
.../selftests/powerpc/memmoveloop/stubs.S | 8 +++
.../selftests/powerpc/memmoveloop/validate.c | 56 +++++++++++++++++++
13 files changed, 131 insertions(+)
create mode 100644 tools/testing/selftests/powerpc/memmoveloop/.gitignore
create mode 100644 tools/testing/selftests/powerpc/memmoveloop/Makefile
create mode 100644 tools/testing/selftests/powerpc/memmoveloop/asm/asm-compat.h
create mode 100644 tools/testing/selftests/powerpc/memmoveloop/asm/export.h
create mode 100644 tools/testing/selftests/powerpc/memmoveloop/asm/feature-fixups.h
create mode 100644 tools/testing/selftests/powerpc/memmoveloop/asm/kasan.h
create mode 100644 tools/testing/selftests/powerpc/memmoveloop/asm/ppc_asm.h
create mode 100644 tools/testing/selftests/powerpc/memmoveloop/asm/processor.h
create mode 120000 tools/testing/selftests/powerpc/memmoveloop/mem_64.S
create mode 120000 tools/testing/selftests/powerpc/memmoveloop/memcpy_64.S
create mode 100644 tools/testing/selftests/powerpc/memmoveloop/stubs.S
create mode 100644 tools/testing/selftests/powerpc/memmoveloop/validate.c
diff --git a/tools/testing/selftests/powerpc/Makefile b/tools/testing/selftests/powerpc/Makefile
index 0830e63818c1..d110b3e5cbcd 100644
--- a/tools/testing/selftests/powerpc/Makefile
+++ b/tools/testing/selftests/powerpc/Makefile
@@ -16,6 +16,7 @@ export CFLAGS
SUB_DIRS = alignment \
benchmarks \
cache_shape \
+ memmoveloop \
copyloops \
dscr \
mm \
diff --git a/tools/testing/selftests/powerpc/memmoveloop/.gitignore b/tools/testing/selftests/powerpc/memmoveloop/.gitignore
new file mode 100644
index 000000000000..56c1426013d5
--- /dev/null
+++ b/tools/testing/selftests/powerpc/memmoveloop/.gitignore
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0-only
+memmove_64
diff --git a/tools/testing/selftests/powerpc/memmoveloop/Makefile b/tools/testing/selftests/powerpc/memmoveloop/Makefile
new file mode 100644
index 000000000000..d58d8c100099
--- /dev/null
+++ b/tools/testing/selftests/powerpc/memmoveloop/Makefile
@@ -0,0 +1,19 @@
+# SPDX-License-Identifier: GPL-2.0
+CFLAGS += -m64
+CFLAGS += -I$(CURDIR)
+CFLAGS += -D SELFTEST
+CFLAGS += -maltivec
+
+ASFLAGS = $(CFLAGS) -Wa,-mpower4
+
+TEST_GEN_PROGS := memmove_64
+EXTRA_SOURCES := validate.c ../harness.c stubs.S
+CPPFLAGS += -D TEST_MEMMOVE=test_memmove
+
+top_srcdir = ../../../../..
+include ../../lib.mk
+
+$(OUTPUT)/memmove_64: mem_64.S memcpy_64.S $(EXTRA_SOURCES)
+ $(CC) $(CPPFLAGS) $(CFLAGS) \
+ -D TEST_MEMMOVE=test_memmove \
+ -o $@ $^
diff --git a/tools/testing/selftests/powerpc/memmoveloop/asm/asm-compat.h b/tools/testing/selftests/powerpc/memmoveloop/asm/asm-compat.h
new file mode 100644
index 000000000000..e69de29bb2d1
diff --git a/tools/testing/selftests/powerpc/memmoveloop/asm/export.h b/tools/testing/selftests/powerpc/memmoveloop/asm/export.h
new file mode 100644
index 000000000000..e6b80d5fbd14
--- /dev/null
+++ b/tools/testing/selftests/powerpc/memmoveloop/asm/export.h
@@ -0,0 +1,4 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#define EXPORT_SYMBOL(x)
+#define EXPORT_SYMBOL_GPL(x)
+#define EXPORT_SYMBOL_KASAN(x)
diff --git a/tools/testing/selftests/powerpc/memmoveloop/asm/feature-fixups.h b/tools/testing/selftests/powerpc/memmoveloop/asm/feature-fixups.h
new file mode 100644
index 000000000000..e69de29bb2d1
diff --git a/tools/testing/selftests/powerpc/memmoveloop/asm/kasan.h b/tools/testing/selftests/powerpc/memmoveloop/asm/kasan.h
new file mode 100644
index 000000000000..e69de29bb2d1
diff --git a/tools/testing/selftests/powerpc/memmoveloop/asm/ppc_asm.h b/tools/testing/selftests/powerpc/memmoveloop/asm/ppc_asm.h
new file mode 100644
index 000000000000..117005c56e19
--- /dev/null
+++ b/tools/testing/selftests/powerpc/memmoveloop/asm/ppc_asm.h
@@ -0,0 +1,39 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __SELFTESTS_POWERPC_PPC_ASM_H
+#define __SELFTESTS_POWERPC_PPC_ASM_H
+#include <ppc-asm.h>
+
+#define CONFIG_ALTIVEC
+
+#define r1 1
+
+#define R14 r14
+#define R15 r15
+#define R16 r16
+#define R17 r17
+#define R18 r18
+#define R19 r19
+#define R20 r20
+#define R21 r21
+#define R22 r22
+#define R29 r29
+#define R30 r30
+#define R31 r31
+
+#define STACKFRAMESIZE 256
+#define STK_REG(i) (112 + ((i)-14)*8)
+
+#define _GLOBAL(A) FUNC_START(test_ ## A)
+#define _GLOBAL_TOC(A) _GLOBAL(A)
+#define _GLOBAL_TOC_KASAN(A) _GLOBAL(A)
+#define _GLOBAL_KASAN(A) _GLOBAL(A)
+
+#define PPC_MTOCRF(A, B) mtocrf A, B
+
+#define BEGIN_FTR_SECTION
+#define FTR_SECTION_ELSE
+#define ALT_FTR_SECTION_END_IFCLR(x)
+#define ALT_FTR_SECTION_END(x, y)
+#define END_FTR_SECTION_IFCLR(x)
+
+#endif /* __SELFTESTS_POWERPC_PPC_ASM_H */
diff --git a/tools/testing/selftests/powerpc/memmoveloop/asm/processor.h b/tools/testing/selftests/powerpc/memmoveloop/asm/processor.h
new file mode 100644
index 000000000000..e69de29bb2d1
diff --git a/tools/testing/selftests/powerpc/memmoveloop/mem_64.S b/tools/testing/selftests/powerpc/memmoveloop/mem_64.S
new file mode 120000
index 000000000000..db254c9a5f5c
--- /dev/null
+++ b/tools/testing/selftests/powerpc/memmoveloop/mem_64.S
@@ -0,0 +1 @@
+../../../../../arch/powerpc/lib/mem_64.S
\ No newline at end of file
diff --git a/tools/testing/selftests/powerpc/memmoveloop/memcpy_64.S b/tools/testing/selftests/powerpc/memmoveloop/memcpy_64.S
new file mode 120000
index 000000000000..cce33fb6f9d8
--- /dev/null
+++ b/tools/testing/selftests/powerpc/memmoveloop/memcpy_64.S
@@ -0,0 +1 @@
+../../../../../arch/powerpc/lib/memcpy_64.S
\ No newline at end of file
diff --git a/tools/testing/selftests/powerpc/memmoveloop/stubs.S b/tools/testing/selftests/powerpc/memmoveloop/stubs.S
new file mode 100644
index 000000000000..d9baa832fa49
--- /dev/null
+++ b/tools/testing/selftests/powerpc/memmoveloop/stubs.S
@@ -0,0 +1,8 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#include <asm/ppc_asm.h>
+
+FUNC_START(memcpy)
+ b test_memcpy
+
+FUNC_START(backwards_memcpy)
+ b test_backwards_memcpy
diff --git a/tools/testing/selftests/powerpc/memmoveloop/validate.c b/tools/testing/selftests/powerpc/memmoveloop/validate.c
new file mode 100644
index 000000000000..52f7d32bb3fe
--- /dev/null
+++ b/tools/testing/selftests/powerpc/memmoveloop/validate.c
@@ -0,0 +1,56 @@
+// SPDX-License-Identifier: GPL-2.0
+#include <malloc.h>
+#include <stdlib.h>
+#include <string.h>
+#include <assert.h>
+#include "utils.h"
+
+void *TEST_MEMMOVE(const void *s1, const void *s2, size_t n);
+
+#define BUF_LEN 65536
+#define MAX_OFFSET 512
+
+size_t max(size_t a, size_t b)
+{
+ if (a >= b) return a;
+ return b;
+}
+
+static int testcase_run(void)
+{
+ size_t i, src_off, dst_off, len;
+
+ char *usermap = memalign(BUF_LEN, BUF_LEN);
+ char *kernelmap = memalign(BUF_LEN, BUF_LEN);
+
+ assert(usermap != NULL);
+ assert(kernelmap != NULL);
+
+ memset(usermap, 0, BUF_LEN);
+ memset(kernelmap, 0, BUF_LEN);
+
+ for (i = 0; i < BUF_LEN; i++) {
+ usermap[i] = i & 0xff;
+ kernelmap[i] = i & 0xff;
+ }
+
+ for (src_off = 0; src_off < MAX_OFFSET; src_off++) {
+ for (dst_off = 0; dst_off < MAX_OFFSET; dst_off++) {
+ for (len = 1; len < MAX_OFFSET - max(src_off, dst_off); len++) {
+
+ memmove(usermap + dst_off, usermap + src_off, len);
+ TEST_MEMMOVE(kernelmap + dst_off, kernelmap + src_off, len);
+ if (memcmp(usermap, kernelmap, MAX_OFFSET) != 0) {
+ printf("memmove failed at %ld %ld %ld\n", src_off, dst_off, len);
+ abort();
+ }
+ }
+ }
+ }
+ return 0;
+}
+
+int main(void)
+{
+ return test_harness(testcase_run, "memmove");
+}
--
2.31.1
^ permalink raw reply related
* Re: [PATCH v2] powerpc/mm: Fix set_memory_*() against concurrent accesses
From: Laurent Vivier @ 2021-08-18 16:03 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev; +Cc: jniethe5, npiggin, aneesh.kumar, farosas
In-Reply-To: <20210818120518.3603172-1-mpe@ellerman.id.au>
On 18/08/2021 14:05, Michael Ellerman wrote:
> Laurent reported that STRICT_MODULE_RWX was causing intermittent crashes
> on one of his systems:
>
> kernel tried to execute exec-protected page (c008000004073278) - exploit attempt? (uid: 0)
> BUG: Unable to handle kernel instruction fetch
> Faulting instruction address: 0xc008000004073278
> Oops: Kernel access of bad area, sig: 11 [#1]
> LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries
> Modules linked in: drm virtio_console fuse drm_panel_orientation_quirks ...
> CPU: 3 PID: 44 Comm: kworker/3:1 Not tainted 5.14.0-rc4+ #12
> Workqueue: events control_work_handler [virtio_console]
> NIP: c008000004073278 LR: c008000004073278 CTR: c0000000001e9de0
> REGS: c00000002e4ef7e0 TRAP: 0400 Not tainted (5.14.0-rc4+)
> MSR: 800000004280b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 24002822 XER: 200400cf
> ...
> NIP fill_queue+0xf0/0x210 [virtio_console]
> LR fill_queue+0xf0/0x210 [virtio_console]
> Call Trace:
> fill_queue+0xb4/0x210 [virtio_console] (unreliable)
> add_port+0x1a8/0x470 [virtio_console]
> control_work_handler+0xbc/0x1e8 [virtio_console]
> process_one_work+0x290/0x590
> worker_thread+0x88/0x620
> kthread+0x194/0x1a0
> ret_from_kernel_thread+0x5c/0x64
>
> Jordan, Fabiano & Murilo were able to reproduce and identify that the
> problem is caused by the call to module_enable_ro() in do_init_module(),
> which happens after the module's init function has already been called.
>
> Our current implementation of change_page_attr() is not safe against
> concurrent accesses, because it invalidates the PTE before flushing the
> TLB and then installing the new PTE. That leaves a window in time where
> there is no valid PTE for the page, if another CPU tries to access the
> page at that time we see something like the fault above.
>
> We can't simply switch to set_pte_at()/flush TLB, because our hash MMU
> code doesn't handle a set_pte_at() of a valid PTE. See [1].
>
> But we do have pte_update(), which replaces the old PTE with the new,
> meaning there's no window where the PTE is invalid. And the hash MMU
> version hash__pte_update() deals with synchronising the hash page table
> correctly.
>
> [1]: https://lore.kernel.org/linuxppc-dev/87y318wp9r.fsf@linux.ibm.com/
>
> Fixes: 1f9ad21c3b38 ("powerpc/mm: Implement set_memory() routines")
> Reported-by: Laurent Vivier <lvivier@redhat.com>
> Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com>
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
> ---
> arch/powerpc/mm/pageattr.c | 23 ++++++++++-------------
> 1 file changed, 10 insertions(+), 13 deletions(-)
>
> v2: Use pte_update(..., ~0, pte_val(pte), ...) as suggested by Fabiano,
> and ptep_get() as suggested by Christophe.
>
> diff --git a/arch/powerpc/mm/pageattr.c b/arch/powerpc/mm/pageattr.c
> index 0876216ceee6..edea388e9d3f 100644
> --- a/arch/powerpc/mm/pageattr.c
> +++ b/arch/powerpc/mm/pageattr.c
> @@ -18,16 +18,12 @@
> /*
> * Updates the attributes of a page in three steps:
> *
> - * 1. invalidate the page table entry
> - * 2. flush the TLB
> - * 3. install the new entry with the updated attributes
> - *
> - * Invalidating the pte means there are situations where this will not work
> - * when in theory it should.
> - * For example:
> - * - removing write from page whilst it is being executed
> - * - setting a page read-only whilst it is being read by another CPU
> + * 1. take the page_table_lock
> + * 2. install the new entry with the updated attributes
> + * 3. flush the TLB
> *
> + * This sequence is safe against concurrent updates, and also allows updating the
> + * attributes of a page currently being executed or accessed.
> */
> static int change_page_attr(pte_t *ptep, unsigned long addr, void *data)
> {
> @@ -36,9 +32,7 @@ static int change_page_attr(pte_t *ptep, unsigned long addr, void *data)
>
> spin_lock(&init_mm.page_table_lock);
>
> - /* invalidate the PTE so it's safe to modify */
> - pte = ptep_get_and_clear(&init_mm, addr, ptep);
> - flush_tlb_kernel_range(addr, addr + PAGE_SIZE);
> + pte = ptep_get(ptep);
>
> /* modify the PTE bits as desired, then apply */
> switch (action) {
> @@ -59,11 +53,14 @@ static int change_page_attr(pte_t *ptep, unsigned long addr, void *data)
> break;
> }
>
> - set_pte_at(&init_mm, addr, ptep, pte);
> + pte_update(&init_mm, addr, ptep, ~0UL, pte_val(pte), 0);
>
> /* See ptesync comment in radix__set_pte_at() */
> if (radix_enabled())
> asm volatile("ptesync": : :"memory");
> +
> + flush_tlb_kernel_range(addr, addr + PAGE_SIZE);
> +
> spin_unlock(&init_mm.page_table_lock);
>
> return 0;
>
> base-commit: cbc06f051c524dcfe52ef0d1f30647828e226d30
>
Tested-by: Laurent Vivier <lvivier@redhat.com>
^ permalink raw reply
* Re: [PATCH] ASoC: fsl_rpmsg: Check -EPROBE_DEFER for getting clocks
From: Mark Brown @ 2021-08-18 16:26 UTC (permalink / raw)
To: tiwai, Xiubo.Lee, festevam, nicoleotsuka, timur, alsa-devel,
perex, Shengjiu Wang
Cc: Mark Brown, linuxppc-dev, linux-kernel
In-Reply-To: <1629266614-6942-1-git-send-email-shengjiu.wang@nxp.com>
On Wed, 18 Aug 2021 14:03:34 +0800, Shengjiu Wang wrote:
> The devm_clk_get() may return -EPROBE_DEFER, then clocks
> will be assigned to NULL wrongly. As the clocks are
> optional so we can use devm_clk_get_optional() instead of
> devm_clk_get().
>
>
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[1/1] ASoC: fsl_rpmsg: Check -EPROBE_DEFER for getting clocks
commit: 2fbbcffea5b6adbfe90ffc842a6b3eb2d7e381ed
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* Re: [PATCH v3 3/3] powerpc/perf: Fix the check for SIAR value
From: kajoljain @ 2021-08-18 17:00 UTC (permalink / raw)
To: Christophe Leroy, mpe, linuxppc-dev; +Cc: atrajeev, maddy, rnsastry
In-Reply-To: <1a32a009-160d-a665-f6a5-2a2be53ae2bd@csgroup.eu>
On 8/18/21 6:58 PM, Christophe Leroy wrote:
>
>
> Le 18/08/2021 à 15:19, Kajol Jain a écrit :
>> Incase of random sampling, there can be scenarios where
>> Sample Instruction Address Register(SIAR) may not latch
>> to the sampled instruction and could result in
>> the value of 0. In these scenarios it is preferred to
>> return regs->nip. These corner cases are seen in the
>> previous generation (p9) also.
>>
>> Patch adds the check for SIAR value along with use_siar and
>> siar_valid checks so that the function will return regs->nip
>> incase SIAR is zero.
>>
>> Patch drops the code under PPMU_P10_DD1 flag check
>> which handles SIAR 0 case only for Power10 DD1.
>>
>> Fixes: 2ca13a4cc56c9 ("powerpc/perf: Use regs->nip when SIAR is zero")
>> Signed-off-by: Kajol Jain <kjain@linux.ibm.com>
>> ---
>>
>> Changelog:
>> - Drop adding new ternary condition to check siar value.
>> - Remove siar check specific for PPMU_P10_DD1 and add
>> it along with common checks as suggested by Christophe Leroy
>> and Michael Ellermen
>>
>> arch/powerpc/perf/core-book3s.c | 7 +------
>> 1 file changed, 1 insertion(+), 6 deletions(-)
>>
>> diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
>> index 23ec89a59893..55efbba7572b 100644
>> --- a/arch/powerpc/perf/core-book3s.c
>> +++ b/arch/powerpc/perf/core-book3s.c
>> @@ -2254,12 +2254,7 @@ unsigned long perf_instruction_pointer(struct pt_regs *regs)
>> bool use_siar = regs_use_siar(regs);
>> unsigned long siar = mfspr(SPRN_SIAR);
>> - if (ppmu && (ppmu->flags & PPMU_P10_DD1)) {
>> - if (siar)
>> - return siar;
>> - else
>> - return regs->nip;
>> - } else if (use_siar && siar_valid(regs))
>> + if (use_siar && siar_valid(regs) && siar)
>
> You can probably now do
>
> + if (regs_use_siar(regs) && siar_valid(regs) && siar)
>
> and remove use_siar
Hi Christophe,
I will update it. Thanks for pointing it.
Thanks,
Kajol Jain
>
>> return siar + perf_ip_adjust(regs);
>> else
>> return regs->nip;
>>
^ permalink raw reply
* [PATCH v4 1/3] powerpc/perf: Use stack siar instead of mfspr
From: Kajol Jain @ 2021-08-18 17:15 UTC (permalink / raw)
To: mpe, linuxppc-dev, christophe.leroy; +Cc: kjain, atrajeev, maddy, rnsastry
Minor optimization in the 'perf_instruction_pointer' function code by
making use of stack siar instead of mfspr.
Fixes: 75382aa72f06 ("powerpc/perf: Move code to select SIAR or pt_regs
into perf_read_regs")
Signed-off-by: Kajol Jain <kjain@linux.ibm.com>
---
arch/powerpc/perf/core-book3s.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
index bb0ee716de91..1b464aad29c4 100644
--- a/arch/powerpc/perf/core-book3s.c
+++ b/arch/powerpc/perf/core-book3s.c
@@ -2260,7 +2260,7 @@ unsigned long perf_instruction_pointer(struct pt_regs *regs)
else
return regs->nip;
} else if (use_siar && siar_valid(regs))
- return mfspr(SPRN_SIAR) + perf_ip_adjust(regs);
+ return siar + perf_ip_adjust(regs);
else if (use_siar)
return 0; // no valid instruction pointer
else
--
2.26.2
^ permalink raw reply related
* [PATCH v4 2/3] powerpc/perf: Drop the case of returning 0 as instruction pointer
From: Kajol Jain @ 2021-08-18 17:15 UTC (permalink / raw)
To: mpe, linuxppc-dev, christophe.leroy; +Cc: kjain, atrajeev, maddy, rnsastry
In-Reply-To: <20210818171556.36912-1-kjain@linux.ibm.com>
Drop the case of returning 0 as instruction pointer since kernel
never executes at 0 and userspace almost never does either.
Fixes: e6878835ac47 ("powerpc/perf: Sample only if SIAR-Valid
bit is set in P7+")
Signed-off-by: Kajol Jain <kjain@linux.ibm.com>
---
arch/powerpc/perf/core-book3s.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
index 1b464aad29c4..23ec89a59893 100644
--- a/arch/powerpc/perf/core-book3s.c
+++ b/arch/powerpc/perf/core-book3s.c
@@ -2261,8 +2261,6 @@ unsigned long perf_instruction_pointer(struct pt_regs *regs)
return regs->nip;
} else if (use_siar && siar_valid(regs))
return siar + perf_ip_adjust(regs);
- else if (use_siar)
- return 0; // no valid instruction pointer
else
return regs->nip;
}
--
2.26.2
^ permalink raw reply related
* [PATCH v4 3/3] powerpc/perf: Fix the check for SIAR value
From: Kajol Jain @ 2021-08-18 17:15 UTC (permalink / raw)
To: mpe, linuxppc-dev, christophe.leroy; +Cc: kjain, atrajeev, maddy, rnsastry
In-Reply-To: <20210818171556.36912-1-kjain@linux.ibm.com>
Incase of random sampling, there can be scenarios where
Sample Instruction Address Register(SIAR) may not latch
to the sampled instruction and could result in
the value of 0. In these scenarios it is preferred to
return regs->nip. These corner cases are seen in the
previous generation (p9) also.
Patch adds the check for SIAR value along with regs_use_siar
and siar_valid checks so that the function will return
regs->nip incase SIAR is zero.
Patch drops the code under PPMU_P10_DD1 flag check
which handles SIAR 0 case only for Power10 DD1.
Fixes: 2ca13a4cc56c9 ("powerpc/perf: Use regs->nip when SIAR is zero")
Signed-off-by: Kajol Jain <kjain@linux.ibm.com>
---
Changelog:
v3 -> v4
- Remove use_siar variable and directly using regs_use_siar call as
suggested by Christophe Leroy
v2 -> v3
- Drop adding new ternary condition to check siar value.
- Remove siar check specific for PPMU_P10_DD1 and add
it along with common checks as suggested by Christophe Leroy
and Michael Ellermen
arch/powerpc/perf/core-book3s.c | 8 +-------
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
index 23ec89a59893..b0a589409039 100644
--- a/arch/powerpc/perf/core-book3s.c
+++ b/arch/powerpc/perf/core-book3s.c
@@ -2251,15 +2251,9 @@ unsigned long perf_misc_flags(struct pt_regs *regs)
*/
unsigned long perf_instruction_pointer(struct pt_regs *regs)
{
- bool use_siar = regs_use_siar(regs);
unsigned long siar = mfspr(SPRN_SIAR);
- if (ppmu && (ppmu->flags & PPMU_P10_DD1)) {
- if (siar)
- return siar;
- else
- return regs->nip;
- } else if (use_siar && siar_valid(regs))
+ if (regs_use_siar(regs) && siar_valid(regs) && siar)
return siar + perf_ip_adjust(regs);
else
return regs->nip;
--
2.26.2
^ permalink raw reply related
* Re: [PATCH v8 2/3] tty: hvc: pass DMA capable memory to put_chars()
From: kernel test robot @ 2021-08-18 17:41 UTC (permalink / raw)
To: Xianting Tian, gregkh, jirislaby, amit, arnd, osandov
Cc: kbuild-all, Xianting Tian, shile.zhang, linux-kernel,
virtualization, clang-built-linux, linuxppc-dev
In-Reply-To: <20210818082122.166881-3-xianting.tian@linux.alibaba.com>
[-- Attachment #1: Type: text/plain, Size: 2642 bytes --]
Hi Xianting,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on tty/tty-testing]
[also build test WARNING on char-misc/char-misc-testing soc/for-next v5.14-rc6 next-20210818]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url: https://github.com/0day-ci/linux/commits/Xianting-Tian/make-hvc-pass-dma-capable-memory-to-its-backend/20210818-162408
base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git tty-testing
config: arm64-randconfig-r025-20210818 (attached as .config)
compiler: clang version 14.0.0 (https://github.com/llvm/llvm-project d2b574a4dea5b718e4386bf2e26af0126e5978ce)
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# install arm64 cross compiling tool for clang build
# apt-get install binutils-aarch64-linux-gnu
# https://github.com/0day-ci/linux/commit/e1b7662dafceb07a6905b64da2f1be27498c4a46
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review Xianting-Tian/make-hvc-pass-dma-capable-memory-to-its-backend/20210818-162408
git checkout e1b7662dafceb07a6905b64da2f1be27498c4a46
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
All warnings (new ones prefixed by >>):
>> drivers/tty/hvc/hvc_console.c:880:39: warning: incompatible integer to pointer conversion passing 'char' to parameter of type 'const char *'; take the address with & [-Wint-conversion]
n = hp->ops->put_chars(hp->vtermno, hp->out_ch, 1);
^~~~~~~~~~
&
1 warning generated.
vim +880 drivers/tty/hvc/hvc_console.c
870
871 static void hvc_poll_put_char(struct tty_driver *driver, int line, char ch)
872 {
873 struct tty_struct *tty = driver->ttys[0];
874 struct hvc_struct *hp = tty->driver_data;
875 int n;
876
877 hp->out_ch = ch;
878
879 do {
> 880 n = hp->ops->put_chars(hp->vtermno, hp->out_ch, 1);
881 } while (n <= 0);
882 }
883 #endif
884
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 33988 bytes --]
^ permalink raw reply
* [PATCH] soc: fsl: guts: Fix a resource leak in the error handling path of 'fsl_guts_probe()'
From: Christophe JAILLET @ 2021-08-18 21:21 UTC (permalink / raw)
To: leoyang.li
Cc: kernel-janitors, Christophe JAILLET, linuxppc-dev, linux-kernel,
linux-arm-kernel
If an error occurs after 'of_find_node_by_path()', the reference taken for
'root' will never be released and some memory will leak.
Instead of adding an error handling path and modifying all the
'return -SOMETHING' into 'goto errorpath', use 'devm_add_action_or_reset()'
to release the reference when needed.
Simplify the remove function accordingly.
As an extra benefit, the 'root' global variable can now be removed as well.
Fixes: 3c0d64e867ed ("soc: fsl: guts: reuse machine name from device tree")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
---
Compile tested only
---
drivers/soc/fsl/guts.c | 16 ++++++++++++++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c
index d5e9a5f2c087..4d9476c7b87c 100644
--- a/drivers/soc/fsl/guts.c
+++ b/drivers/soc/fsl/guts.c
@@ -28,7 +28,6 @@ struct fsl_soc_die_attr {
static struct guts *guts;
static struct soc_device_attribute soc_dev_attr;
static struct soc_device *soc_dev;
-static struct device_node *root;
/* SoC die attribute definition for QorIQ platform */
@@ -136,14 +135,23 @@ static u32 fsl_guts_get_svr(void)
return svr;
}
+static void fsl_guts_put_root(void *data)
+{
+ struct device_node *root = data;
+
+ of_node_put(root);
+}
+
static int fsl_guts_probe(struct platform_device *pdev)
{
struct device_node *np = pdev->dev.of_node;
struct device *dev = &pdev->dev;
+ struct device_node *root;
struct resource *res;
const struct fsl_soc_die_attr *soc_die;
const char *machine;
u32 svr;
+ int ret;
/* Initialize guts */
guts = devm_kzalloc(dev, sizeof(*guts), GFP_KERNEL);
@@ -159,6 +167,10 @@ static int fsl_guts_probe(struct platform_device *pdev)
/* Register soc device */
root = of_find_node_by_path("/");
+ ret = devm_add_action_or_reset(dev, fsl_guts_put_root, root);
+ if (ret)
+ return ret;
+
if (of_property_read_string(root, "model", &machine))
of_property_read_string_index(root, "compatible", 0, &machine);
if (machine)
@@ -197,7 +209,7 @@ static int fsl_guts_probe(struct platform_device *pdev)
static int fsl_guts_remove(struct platform_device *dev)
{
soc_device_unregister(soc_dev);
- of_node_put(root);
+
return 0;
}
--
2.30.2
^ permalink raw reply related
* Re: [PATCH v2 61/63] powerpc: Split memset() to avoid multi-field overflow
From: Kees Cook @ 2021-08-18 22:30 UTC (permalink / raw)
To: Christophe Leroy
Cc: Rasmus Villemoes, clang-built-linux, Greg Kroah-Hartman,
Wang Wensheng, linux-staging, linux-wireless, linux-kernel,
Qinglang Miao, Gustavo A. R. Silva, linux-block, Hulk Robot,
dri-devel, netdev, Andrew Morton, linuxppc-dev, linux-kbuild,
linux-hardening
In-Reply-To: <7630b0bc-4389-6283-d8b9-c532df916d60@csgroup.eu>
On Wed, Aug 18, 2021 at 08:42:18AM +0200, Christophe Leroy wrote:
>
>
> Le 18/08/2021 à 08:05, Kees Cook a écrit :
> > In preparation for FORTIFY_SOURCE performing compile-time and run-time
> > field bounds checking for memset(), avoid intentionally writing across
> > neighboring fields.
> >
> > Instead of writing across a field boundary with memset(), move the call
> > to just the array, and an explicit zeroing of the prior field.
> >
> > Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> > Cc: Qinglang Miao <miaoqinglang@huawei.com>
> > Cc: "Gustavo A. R. Silva" <gustavoars@kernel.org>
> > Cc: Hulk Robot <hulkci@huawei.com>
> > Cc: Wang Wensheng <wangwensheng4@huawei.com>
> > Cc: linuxppc-dev@lists.ozlabs.org
> > Signed-off-by: Kees Cook <keescook@chromium.org>
> > Reviewed-by: Michael Ellerman <mpe@ellerman.id.au>
> > Link: https://lore.kernel.org/lkml/87czqsnmw9.fsf@mpe.ellerman.id.au
> > ---
> > drivers/macintosh/smu.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/macintosh/smu.c b/drivers/macintosh/smu.c
> > index 94fb63a7b357..59ce431da7ef 100644
> > --- a/drivers/macintosh/smu.c
> > +++ b/drivers/macintosh/smu.c
> > @@ -848,7 +848,8 @@ int smu_queue_i2c(struct smu_i2c_cmd *cmd)
> > cmd->read = cmd->info.devaddr & 0x01;
> > switch(cmd->info.type) {
> > case SMU_I2C_TRANSFER_SIMPLE:
> > - memset(&cmd->info.sublen, 0, 4);
> > + cmd->info.sublen = 0;
> > + memset(&cmd->info.subaddr, 0, 3);
>
> subaddr[] is a table, should the & be avoided ?
It results in the same thing, but it's better form to not have the &; I
will fix this.
> And while at it, why not use sizeof(subaddr) instead of 3 ?
Agreed. :)
Thanks!
--
Kees Cook
^ permalink raw reply
* [PATCH] powerpc/tau: Add 'static' storage qualifier to 'tau_work' definition
From: Finn Thain @ 2021-08-19 0:46 UTC (permalink / raw)
To: Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras
Cc: linuxppc-dev, linux-kernel
This patch prevents the following sparse warning.
arch/powerpc/kernel/tau_6xx.c:199:1: sparse: sparse: symbol 'tau_work'
was not declared. Should it be static?
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Finn Thain <fthain@linux-m68k.org>
---
arch/powerpc/kernel/tau_6xx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/tau_6xx.c b/arch/powerpc/kernel/tau_6xx.c
index b9a047d92ec0..8e83d19fe8fa 100644
--- a/arch/powerpc/kernel/tau_6xx.c
+++ b/arch/powerpc/kernel/tau_6xx.c
@@ -164,7 +164,7 @@ static void tau_work_func(struct work_struct *work)
queue_work(tau_workq, work);
}
-DECLARE_WORK(tau_work, tau_work_func);
+static DECLARE_WORK(tau_work, tau_work_func);
/*
* setup the TAU
--
2.26.3
^ permalink raw reply related
* Re: [PATCH v7 1/2] tty: hvc: pass DMA capable memory to put_chars()
From: Xianting TIan @ 2021-08-19 3:00 UTC (permalink / raw)
To: Jiri Slaby, gregkh, amit, arnd, osandov
Cc: linuxppc-dev, linux-kernel, virtualization
In-Reply-To: <5b728c71-a754-b3ef-4ad3-6e33db1b7647@kernel.org>
在 2021/8/18 上午11:17, Jiri Slaby 写道:
> Hi,
>
> On 17. 08. 21, 15:22, Xianting Tian wrote:
>> As well known, hvc backend can register its opertions to hvc backend.
>> the opertions contain put_chars(), get_chars() and so on.
>
> "operations". And there too:
>
>> Some hvc backend may do dma in its opertions. eg, put_chars() of
>> virtio-console. But in the code of hvc framework, it may pass DMA
>> incapable memory to put_chars() under a specific configuration, which
>> is explained in commit c4baad5029(virtio-console: avoid DMA from stack):
>> 1, c[] is on stack,
>> hvc_console_print():
>> char c[N_OUTBUF] __ALIGNED__;
>> cons_ops[index]->put_chars(vtermnos[index], c, i);
>> 2, ch is on stack,
>> static void hvc_poll_put_char(,,char ch)
>> {
>> struct tty_struct *tty = driver->ttys[0];
>> struct hvc_struct *hp = tty->driver_data;
>> int n;
>>
>> do {
>> n = hp->ops->put_chars(hp->vtermno, &ch, 1);
>> } while (n <= 0);
>> }
>>
>> Commit c4baad5029 is just the fix to avoid DMA from stack memory, which
>> is passed to virtio-console by hvc framework in above code. But I think
>> the fix is aggressive, it directly uses kmemdup() to alloc new buffer
>> from kmalloc area and do memcpy no matter the memory is in kmalloc area
>> or not. But most importantly, it should better be fixed in the hvc
>> framework, by changing it to never pass stack memory to the put_chars()
>> function in the first place. Otherwise, we still face the same issue if
>> a new hvc backend using dma added in the furture.
>>
>> We make 'char c[N_OUTBUF]' part of 'struct hvc_struct', so hp->c is no
>> longer the stack memory. we can use it in above two cases.
>
> In fact, you need only a single char for the poll case
> (hvc_poll_put_char), so hvc_struct needs to contain only c, not an array.
>
> OTOH, you need c[N_OUTBUF] in the console case (hvc_console_print),
> but not whole hvc_struct. So cons_hvcs should be an array of structs
> composed of only the lock and the buffer.
>
> Hum.
>
> Or maybe rethink and take care of the console case by kmemdup and be
> done with that case? What problem do you have with allocating 16
> bytes? It should be quite easy and really fast (lockless) in most
> cases. On the contrary, your solution has to take a spinlock to access
> the global buffer.
As I replyed before, this issue may can be solved just by adjust the
alignment to L1_CACHE_BYTES or at least 16:
#define __ALIGNED__ __attribute__((__aligned__(L1_CACHE_BYTES)))
Then, c[16] won't cross the pages, that is to say c[16]'s physical
address is continuous. Could you comment this?
I submitted v8, I found it still can't solve ths issue, even we create
'char out_buf[N_OUTBUF]' and 'chat out_ch' be part of 'struct
hvc_struct', and use it separately, we still need lock to protect each
buf. When we invloced lock, it will impact the hvc performance.
So we can back to the original intention of this solution, just fix the
kmemdup issue in virtio_console driver?
>
>> Other fix is use L1_CACHE_BYTES as the alignment, use 'sizeof(long)' as
>> dma alignment is wrong. And use struct_size() to calculate size of
>> hvc_struct.
>
> This ought to be in separate patches.
>
> thanks,
^ permalink raw reply
* Re: [PATCH v4 1/3] powerpc/perf: Use stack siar instead of mfspr
From: Nageswara Sastry @ 2021-08-19 5:52 UTC (permalink / raw)
To: Kajol Jain, mpe, linuxppc-dev, christophe.leroy; +Cc: atrajeev, maddy
In-Reply-To: <20210818171556.36912-1-kjain@linux.ibm.com>
On 18/08/21 10:45 pm, Kajol Jain wrote:
> Minor optimization in the 'perf_instruction_pointer' function code by
> making use of stack siar instead of mfspr.
>
> Fixes: 75382aa72f06 ("powerpc/perf: Move code to select SIAR or pt_regs
> into perf_read_regs")
> Signed-off-by: Kajol Jain <kjain@linux.ibm.com>
Tested this patch series, not seeing any '0' values.
Tested-by: Nageswara R Sastry <rnsastry@linux.ibm.com>
example output:
# perf report -D | grep addr
0 26236879714 0x3dcc8 [0x38]: PERF_RECORD_SAMPLE(IP, 0x1): 1446/1446:
0xc000000000113584 period: 1 addr: 0
0 26236882500 0x3dd00 [0x38]: PERF_RECORD_SAMPLE(IP, 0x1): 1446/1446:
0xc000000000113584 period: 1 addr: 0
0 26236883436 0x3dd38 [0x38]: PERF_RECORD_SAMPLE(IP, 0x1): 1446/1446:
0xc000000000113584 period: 10 addr: 0
...
> ---
> arch/powerpc/perf/core-book3s.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
> index bb0ee716de91..1b464aad29c4 100644
> --- a/arch/powerpc/perf/core-book3s.c
> +++ b/arch/powerpc/perf/core-book3s.c
> @@ -2260,7 +2260,7 @@ unsigned long perf_instruction_pointer(struct pt_regs *regs)
> else
> return regs->nip;
> } else if (use_siar && siar_valid(regs))
> - return mfspr(SPRN_SIAR) + perf_ip_adjust(regs);
> + return siar + perf_ip_adjust(regs);
> else if (use_siar)
> return 0; // no valid instruction pointer
> else
>
--
Thanks and Regards
R.Nageswara Sastry
^ permalink raw reply
* Re: [PATCH] powerpc/perf/hv-gpci: Fix the logic to compute counter value from the hcall result buffer.
From: Nageswara Sastry @ 2021-08-19 6:15 UTC (permalink / raw)
To: Kajol Jain, mpe, linuxppc-dev; +Cc: suka, maddy, atrajeev
In-Reply-To: <20210813082158.429023-1-kjain@linux.ibm.com>
On 13/08/21 1:51 pm, Kajol Jain wrote:
> H_GetPerformanceCounterInfo (0xF080) hcall returns the counter data in the
> result buffer. Result buffer has specific format defined in the PAPR
> specification. One of the field is counter offset and width of the counter
> data returned.
>
> Counter data are returned in a unsigned char array. To
> get the final counter data, these values should be left shifted
> byte at a time. But commit 220a0c609ad17 ("powerpc/perf: Add support
> for the hv gpci (get performance counter info) interface") made the
> shifting bitwise. Because of this, hcall counters values could end up
> in lower side, which messes the counter prev vs now calculation. This
> lead to huge counter value reporting
>
> [command]#: perf stat -e hv_gpci/system_tlbie_count_and_time_tlbie_instructions_issued/
> -C 0 -I 1000
> time counts unit events
> 1.000078854 18,446,744,073,709,535,232 hv_gpci/system_tlbie_count_and_time_tlbie_instructions_issued/
> 2.000213293 0 hv_gpci/system_tlbie_count_and_time_tlbie_instructions_issued/
> 3.000320107 0 hv_gpci/system_tlbie_count_and_time_tlbie_instructions_issued/
> 4.000428392 0 hv_gpci/system_tlbie_count_and_time_tlbie_instructions_issued/
> 5.000537864 0 hv_gpci/system_tlbie_count_and_time_tlbie_instructions_issued/
> 6.000649087 0 hv_gpci/system_tlbie_count_and_time_tlbie_instructions_issued/
> 7.000760312 0 hv_gpci/system_tlbie_count_and_time_tlbie_instructions_issued/
> 8.000865218 16,448 hv_gpci/system_tlbie_count_and_time_tlbie_instructions_issued/
> 9.000978985 18,446,744,073,709,535,232 hv_gpci/system_tlbie_count_and_time_tlbie_instructions_issued/
> 10.001088891 16,384 hv_gpci/system_tlbie_count_and_time_tlbie_instructions_issued/
> 11.001201435 0 hv_gpci/system_tlbie_count_and_time_tlbie_instructions_issued/
> 12.001307937 18,446,744,073,709,535,232 hv_gpci/system_tlbie_count_and_time_tlbie_instructions_issued/
>
> Patch here fixes the shifting logic to make is byte-wise with which no more the issue seen.
>
> Fixes: e4f226b1580b3 ("powerpc/perf/hv-gpci: Increase request buffer size")
> Reported-by: Nageswara R Sastry<rnsastry@linux.ibm.com>
> Signed-off-by: Kajol Jain <kjain@linux.ibm.com>
Tested-by: Nageswara R Sastry<rnsastry@linux.ibm.com>
Now not seeing huge numbers.
# perf stat -e
hv_gpci/system_tlbie_count_and_time_tlbie_instructions_issued/ -C 0 -I 1000
# time counts unit events
1.001023931 26,624
hv_gpci/system_tlbie_count_and_time_tlbie_instructions_issued/
2.002176767 0
hv_gpci/system_tlbie_count_and_time_tlbie_instructions_issued/
3.003296382 0
hv_gpci/system_tlbie_count_and_time_tlbie_instructions_issued/
4.004385311 33,280
hv_gpci/system_tlbie_count_and_time_tlbie_instructions_issued/
> ---
> arch/powerpc/perf/hv-gpci.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/perf/hv-gpci.c b/arch/powerpc/perf/hv-gpci.c
> index d48413e28c39..c756228a081f 100644
> --- a/arch/powerpc/perf/hv-gpci.c
> +++ b/arch/powerpc/perf/hv-gpci.c
> @@ -175,7 +175,7 @@ static unsigned long single_gpci_request(u32 req, u32 starting_index,
> */
> count = 0;
> for (i = offset; i < offset + length; i++)
> - count |= arg->bytes[i] << (i - offset);
> + count |= (u64)(arg->bytes[i]) << ((length - 1 - (i - offset)) * 8);
>
> *value = count;
> out:
>
--
Thanks and Regards
R.Nageswara Sastry
^ permalink raw reply
* [PATCH 1/3] powerpc: Remove MSR_PR check in interrupt_exit_{user/kernel}_prepare()
From: Christophe Leroy @ 2021-08-19 6:30 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman, npiggin
Cc: linuxppc-dev, linux-kernel
In those hot functions that are called at every interrupt, any saved
cycle is worth it.
interrupt_exit_user_prepare() and interrupt_exit_kernel_prepare() are
called from three places:
- From entry_32.S
- From interrupt_64.S
- From interrupt_exit_user_restart() and interrupt_exit_kernel_restart()
In entry_32.S, there are inambiguously called based on MSR_PR:
interrupt_return:
lwz r4,_MSR(r1)
addi r3,r1,STACK_FRAME_OVERHEAD
andi. r0,r4,MSR_PR
beq .Lkernel_interrupt_return
bl interrupt_exit_user_prepare
...
.Lkernel_interrupt_return:
bl interrupt_exit_kernel_prepare
In interrupt_64.S, that's similar:
interrupt_return_\srr\():
ld r4,_MSR(r1)
andi. r0,r4,MSR_PR
beq interrupt_return_\srr\()_kernel
interrupt_return_\srr\()_user: /* make backtraces match the _kernel variant */
addi r3,r1,STACK_FRAME_OVERHEAD
bl interrupt_exit_user_prepare
...
interrupt_return_\srr\()_kernel:
addi r3,r1,STACK_FRAME_OVERHEAD
bl interrupt_exit_kernel_prepare
In interrupt_exit_user_restart() and interrupt_exit_kernel_restart(),
MSR_PR is verified respectively by BUG_ON(!user_mode(regs)) and
BUG_ON(user_mode(regs)) prior to calling interrupt_exit_user_prepare()
and interrupt_exit_kernel_prepare().
The verification in interrupt_exit_user_prepare() and
interrupt_exit_kernel_prepare() are therefore useless and can be removed.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Acked-by: Nicholas Piggin <npiggin@gmail.com>
---
arch/powerpc/kernel/interrupt.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/powerpc/kernel/interrupt.c b/arch/powerpc/kernel/interrupt.c
index 21bbd615ca41..f26caf911ab5 100644
--- a/arch/powerpc/kernel/interrupt.c
+++ b/arch/powerpc/kernel/interrupt.c
@@ -465,7 +465,6 @@ notrace unsigned long interrupt_exit_user_prepare(struct pt_regs *regs)
if (!IS_ENABLED(CONFIG_BOOKE) && !IS_ENABLED(CONFIG_40x))
BUG_ON(!(regs->msr & MSR_RI));
- BUG_ON(!(regs->msr & MSR_PR));
BUG_ON(arch_irq_disabled_regs(regs));
CT_WARN_ON(ct_state() == CONTEXT_USER);
@@ -499,7 +498,6 @@ notrace unsigned long interrupt_exit_kernel_prepare(struct pt_regs *regs)
if (!IS_ENABLED(CONFIG_BOOKE) && !IS_ENABLED(CONFIG_40x) &&
unlikely(!(regs->msr & MSR_RI)))
unrecoverable_exception(regs);
- BUG_ON(regs->msr & MSR_PR);
/*
* CT_WARN_ON comes here via program_check_exception,
* so avoid recursion.
--
2.25.0
^ permalink raw reply related
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