* Re: [PATCH v2 05/17] compat_ioctl: move more drivers to generic_compat_ioctl_ptrarg
From: Jonathan Cameron @ 2018-09-17 9:33 UTC (permalink / raw)
To: Arnd Bergmann
Cc: viro, linux-fsdevel, Greg Kroah-Hartman, David S. Miller, devel,
linux-kernel, qat-linux, linux-crypto, linux-media, dri-devel,
linaro-mm-sig, amd-gfx, linux-input, linux-iio, linux-rdma,
linux-nvdimm, linux-nvme, linux-pci, platform-driver-x86,
linux-remoteproc, sparclinux, linux-scsi, linux-usb, linux-fbdev,
linuxppc-dev, linux-btrfs, ceph-devel, linux-wireless, netdev
In-Reply-To: <20180912151134.436719-1-arnd@arndb.de>
On Wed, 12 Sep 2018 17:08:52 +0200
Arnd Bergmann <arnd@arndb.de> wrote:
> The .ioctl and .compat_ioctl file operations have the same prototype so
> they can both point to the same function, which works great almost all
> the time when all the commands are compatible.
>
> One exception is the s390 architecture, where a compat pointer is only
> 31 bit wide, and converting it into a 64-bit pointer requires calling
> compat_ptr(). Most drivers here will ever run in s390, but since we now
> have a generic helper for it, it's easy enough to use it consistently.
>
> I double-checked all these drivers to ensure that all ioctl arguments
> are used as pointers or are ignored, but are not interpreted as integer
> values.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
For IIO part.
Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Thanks,
> diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
> index a062cfddc5af..22844b94b0e9 100644
> --- a/drivers/iio/industrialio-core.c
> +++ b/drivers/iio/industrialio-core.c
> @@ -1630,7 +1630,7 @@ static const struct file_operations iio_buffer_fileops = {
> .owner = THIS_MODULE,
> .llseek = noop_llseek,
> .unlocked_ioctl = iio_ioctl,
> - .compat_ioctl = iio_ioctl,
> + .compat_ioctl = generic_compat_ioctl_ptrarg,
> };
>
^ permalink raw reply
* Re: [PATCH 4.4.y] crypto: vmx - Fix sleep-in-atomic bugs
From: Greg Kroah-Hartman @ 2018-09-17 11:47 UTC (permalink / raw)
To: Ondrej Mosnacek; +Cc: stable, Herbert Xu, linux-crypto, linuxppc-dev
In-Reply-To: <20180910074204.10812-1-omosnace@redhat.com>
On Mon, Sep 10, 2018 at 09:42:04AM +0200, Ondrej Mosnacek wrote:
> commit 0522236d4f9c5ab2e79889cb020d1acbe5da416e upstream.
>
> Conflicts:
> drivers/crypto/vmx/
> aes_cbc.c - adapted enable/disable calls to v4.4 state
> aes_xts.c - did not exist yet in v4.4
We don't need these lines here... I'll go hand edit it out...
^ permalink raw reply
* Re: [PATCH 4.4.y] crypto: vmx - Fix sleep-in-atomic bugs
From: Greg Kroah-Hartman @ 2018-09-17 11:47 UTC (permalink / raw)
To: Ondrej Mosnacek; +Cc: stable, Herbert Xu, linux-crypto, linuxppc-dev
In-Reply-To: <20180910074204.10812-1-omosnace@redhat.com>
On Mon, Sep 10, 2018 at 09:42:04AM +0200, Ondrej Mosnacek wrote:
> commit 0522236d4f9c5ab2e79889cb020d1acbe5da416e upstream.
>
> Conflicts:
> drivers/crypto/vmx/
> aes_cbc.c - adapted enable/disable calls to v4.4 state
> aes_xts.c - did not exist yet in v4.4
Now applied, thanks.
greg k-h
^ permalink raw reply
* [PATCH 1/2] powerpc: initial stack protector (-fstack-protector) support
From: Christophe Leroy @ 2018-09-17 12:15 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: linux-kernel, linuxppc-dev
Partialy copied from commit c743f38013aef ("ARM: initial stack protector
(-fstack-protector) support")
This is the very basic stuff without the changing canary upon
task switch yet. Just the Kconfig option and a constant canary
value initialized at boot time.
This patch was tentatively added in the past (commit 6533b7c16ee5
("powerpc: Initial stack protector (-fstack-protector) support"))
but had to be reverted (commit f2574030b0e3 ("powerpc: Revert the
initial stack protector support") because GCC implementing it
differently whether it had been built with libc support or not.
Now, GCC offers the possibility to manually set the
stack-protector mode (global or tls) regardless of libc support.
This time, the patch selects HAVE_STACKPROTECTOR only if
-mstack-protector-guard=global is supported by GCC.
$ echo CORRUPT_STACK > /sys/kernel/debug/provoke-crash/DIRECT
[ 134.943666] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: lkdtm_CORRUPT_STACK+0x64/0x64
[ 134.943666]
[ 134.955414] CPU: 0 PID: 283 Comm: sh Not tainted 4.18.0-s3k-dev-12143-ga3272be41209 #835
[ 134.963380] Call Trace:
[ 134.965860] [c6615d60] [c001f76c] panic+0x118/0x260 (unreliable)
[ 134.971775] [c6615dc0] [c001f654] panic+0x0/0x260
[ 134.976435] [c6615dd0] [c032c368] lkdtm_CORRUPT_STACK_STRONG+0x0/0x64
[ 134.982769] [c6615e00] [ffffffff] 0xffffffff
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
---
arch/powerpc/Kconfig | 1 +
arch/powerpc/Makefile | 4 +++
arch/powerpc/include/asm/stackprotector.h | 41 +++++++++++++++++++++++++++++++
arch/powerpc/kernel/Makefile | 4 +++
arch/powerpc/kernel/process.c | 6 +++++
5 files changed, 56 insertions(+)
create mode 100644 arch/powerpc/include/asm/stackprotector.h
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index db0b6eebbfa5..3f5776ed99d3 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -181,6 +181,7 @@ config PPC
select HAVE_ARCH_SECCOMP_FILTER
select HAVE_ARCH_TRACEHOOK
select HAVE_CBPF_JIT if !PPC64
+ select HAVE_STACKPROTECTOR if $(cc-option,-mstack-protector-guard=global)
select HAVE_CONTEXT_TRACKING if PPC64
select HAVE_DEBUG_KMEMLEAK
select HAVE_DEBUG_STACKOVERFLOW
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index 8397c7bd5880..0dbfdb6a145d 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -112,6 +112,10 @@ LDFLAGS += -m elf$(BITS)$(LDEMULATION)
KBUILD_ARFLAGS += --target=elf$(BITS)-$(GNUTARGET)
endif
+ifdef CONFIG_STACKPROTECTOR
+KBUILD_CFLAGS += -mstack-protector-guard=global
+endif
+
LDFLAGS_vmlinux-y := -Bstatic
LDFLAGS_vmlinux-$(CONFIG_RELOCATABLE) := -pie
LDFLAGS_vmlinux := $(LDFLAGS_vmlinux-y)
diff --git a/arch/powerpc/include/asm/stackprotector.h b/arch/powerpc/include/asm/stackprotector.h
new file mode 100644
index 000000000000..2556e227cdb2
--- /dev/null
+++ b/arch/powerpc/include/asm/stackprotector.h
@@ -0,0 +1,41 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * GCC stack protector support.
+ *
+ * Stack protector works by putting predefined pattern at the start of
+ * the stack frame and verifying that it hasn't been overwritten when
+ * returning from the function. The pattern is called stack canary
+ * and gcc expects it to be defined by a global variable called
+ * "__stack_chk_guard" on PPC. This unfortunately means that on SMP
+ * we cannot have a different canary value per task.
+ */
+
+#ifndef _ASM_STACKPROTECTOR_H
+#define _ASM_STACKPROTECTOR_H
+
+#include <linux/random.h>
+#include <linux/version.h>
+#include <asm/reg.h>
+
+extern unsigned long __stack_chk_guard;
+
+/*
+ * Initialize the stackprotector canary value.
+ *
+ * NOTE: this must only be called from functions that never return,
+ * and it must always be inlined.
+ */
+static __always_inline void boot_init_stack_canary(void)
+{
+ unsigned long canary;
+
+ /* Try to get a semi random initial value. */
+ get_random_bytes(&canary, sizeof(canary));
+ canary ^= mftb();
+ canary ^= LINUX_VERSION_CODE;
+
+ current->stack_canary = canary;
+ __stack_chk_guard = current->stack_canary;
+}
+
+#endif /* _ASM_STACKPROTECTOR_H */
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index 3b66f2c19c84..0556a7243d2a 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -20,6 +20,10 @@ CFLAGS_prom_init.o += $(DISABLE_LATENT_ENTROPY_PLUGIN)
CFLAGS_btext.o += $(DISABLE_LATENT_ENTROPY_PLUGIN)
CFLAGS_prom.o += $(DISABLE_LATENT_ENTROPY_PLUGIN)
+# -fstack-protector triggers protection checks in this code,
+# but it is being used too early to link to meaningful stack_chk logic.
+CFLAGS_prom_init.o += $(call cc-option, -fno-stack-protector)
+
ifdef CONFIG_FUNCTION_TRACER
# Do not trace early boot code
CFLAGS_REMOVE_cputable.o = -mno-sched-epilog $(CC_FLAGS_FTRACE)
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index 913c5725cdb2..8e9e90e8d773 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -69,6 +69,12 @@
#include <linux/kprobes.h>
#include <linux/kdebug.h>
+#ifdef CONFIG_STACKPROTECTOR
+#include <linux/stackprotector.h>
+unsigned long __stack_chk_guard __read_mostly;
+EXPORT_SYMBOL(__stack_chk_guard);
+#endif
+
/* Transactional Memory debug */
#ifdef TM_DEBUG_SW
#define TM_DEBUG(x...) printk(KERN_INFO x)
--
2.13.3
^ permalink raw reply related
* [PATCH 2/2] powerpc/32: stack protector: change the canary value per task
From: Christophe Leroy @ 2018-09-17 12:15 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: linux-kernel, linuxppc-dev
In-Reply-To: <9f7efcc085685717bb4c7b3a575138a1a1cd15ed.1537186089.git.christophe.leroy@c-s.fr>
Partially copied from commit df0698be14c66 ("ARM: stack protector:
change the canary value per task")
A new random value for the canary is stored in the task struct whenever
a new task is forked. This is meant to allow for different canary values
per task. On powerpc, GCC expects the canary value to be found in a global
variable called __stack_chk_guard. So this variable has to be updated
with the value stored in the task struct whenever a task switch occurs.
Because the variable GCC expects is global, this cannot work on SMP
unfortunately. So, on SMP, the same initial canary value is kept
throughout, making this feature a bit less effective although it is still
useful.
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
---
I would have liked to use -mstack-protector-guard=tls -mstack-protector-guard-reg=r2
-mstack-protector-guard-offset=offsetof(struct task_struct, stack_canary) but I have
not found how set the value of offsetof(struct task_struct, stack_canary) in Makefile.
Any idea ?
arch/powerpc/kernel/asm-offsets.c | 3 +++
arch/powerpc/kernel/entry_32.S | 5 +++++
2 files changed, 8 insertions(+)
diff --git a/arch/powerpc/kernel/asm-offsets.c b/arch/powerpc/kernel/asm-offsets.c
index 89cf15566c4e..cb02d23764ca 100644
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -89,6 +89,9 @@ int main(void)
DEFINE(THREAD_INFO_GAP, _ALIGN_UP(sizeof(struct thread_info), 16));
OFFSET(KSP_LIMIT, thread_struct, ksp_limit);
#endif /* CONFIG_PPC64 */
+#ifdef CONFIG_CC_STACKPROTECTOR
+ DEFINE(TSK_STACK_CANARY, offsetof(struct task_struct, stack_canary));
+#endif
#ifdef CONFIG_LIVEPATCH
OFFSET(TI_livepatch_sp, thread_info, livepatch_sp);
diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S
index e58c3f467db5..0cdb4170a21d 100644
--- a/arch/powerpc/kernel/entry_32.S
+++ b/arch/powerpc/kernel/entry_32.S
@@ -721,6 +721,11 @@ BEGIN_FTR_SECTION
mtspr SPRN_SPEFSCR,r0 /* restore SPEFSCR reg */
END_FTR_SECTION_IFSET(CPU_FTR_SPE)
#endif /* CONFIG_SPE */
+#if defined(CONFIG_CC_STACKPROTECTOR) && !defined(CONFIG_SMP)
+ lwz r0, TSK_STACK_CANARY(r2)
+ lis r4, __stack_chk_guard@ha
+ stw r0, __stack_chk_guard@l(r4)
+#endif
lwz r0,_CCR(r1)
mtcrf 0xFF,r0
--
2.13.3
^ permalink raw reply related
* Re: [PATCH] powerpc: fix csum_ipv6_magic() on little endian platforms
From: Christophe LEROY @ 2018-09-17 12:27 UTC (permalink / raw)
To: Michael Ellerman
Cc: Xin Long, benh, paulus, jishi, LKML, linuxppc-dev, stable,
netdev@vger.kernel.org, David Miller
In-Reply-To: <CADvbK_c+VVoC=tcX4z-NbX6xGHfkzzNuBXoMHFJfZdiBMzX3+w@mail.gmail.com>
Hi Michael,
Le 10/09/2018 à 16:28, Xin Long a écrit :
> On Mon, Sep 10, 2018 at 2:09 PM Christophe Leroy
> <christophe.leroy@c-s.fr> wrote:
>>
>> On little endian platforms, csum_ipv6_magic() keeps len and proto in
>> CPU byte order. This generates a bad results leading to ICMPv6 packets
>> from other hosts being dropped by powerpc64le platforms.
>>
>> In order to fix this, len and proto should be converted to network
>> byte order ie bigendian byte order. However checksumming 0x12345678
>> and 0x56341278 provide the exact same result so it is enough to
>> rotate the sum of len and proto by 1 byte.
>>
>> PPC32 only support bigendian so the fix is needed for PPC64 only
>>
>> Fixes: e9c4943a107b ("powerpc: Implement csum_ipv6_magic in assembly")
>> Reported-by: Jianlin Shi <jishi@redhat.com>
>> Reported-by: Xin Long <lucien.xin@gmail.com>
>> Cc: <stable@vger.kernel.org> # 4.18+
>> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
>> ---
>> arch/powerpc/lib/checksum_64.S | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/arch/powerpc/lib/checksum_64.S b/arch/powerpc/lib/checksum_64.S
>> index 886ed94b9c13..2a68c43e13f5 100644
>> --- a/arch/powerpc/lib/checksum_64.S
>> +++ b/arch/powerpc/lib/checksum_64.S
>> @@ -443,6 +443,9 @@ _GLOBAL(csum_ipv6_magic)
>> addc r0, r8, r9
>> ld r10, 0(r4)
>> ld r11, 8(r4)
>> +#ifndef CONFIG_CPU_BIG_ENDIAN
>> + rotldi r5, r5, 8
>> +#endif
>> adde r0, r0, r10
>> add r5, r5, r7
>> adde r0, r0, r11
>> --
>> 2.13.3
>>
> Tested-by: Xin Long <lucien.xin@gmail.com>
>
Could you take this fix for 4.19 ?
Unless someone takes it through the netdev tree ?
Thanks
Christophe
^ permalink raw reply
* Re: [PATCH 1/2] powerpc: initial stack protector (-fstack-protector) support
From: kbuild test robot @ 2018-09-17 16:21 UTC (permalink / raw)
To: Christophe Leroy
Cc: kbuild-all, Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman, linux-kernel, linuxppc-dev
In-Reply-To: <9f7efcc085685717bb4c7b3a575138a1a1cd15ed.1537186089.git.christophe.leroy@c-s.fr>
[-- Attachment #1: Type: text/plain, Size: 1868 bytes --]
Hi Christophe,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on powerpc/next]
[also build test ERROR on v4.19-rc4 next-20180913]
[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/Christophe-Leroy/powerpc-initial-stack-protector-fstack-protector-support/20180917-202227
base: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
config: powerpc-ppc6xx_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 errors (new ones prefixed by >>):
arch/powerpc/platforms/powermac/bootx_init.o: In function `bootx_printf':
>> bootx_init.c:(.init.text+0x2bc): undefined reference to `__stack_chk_fail_local'
arch/powerpc/platforms/powermac/bootx_init.o: In function `bootx_add_display_props.isra.1':
bootx_init.c:(.init.text+0x750): undefined reference to `__stack_chk_fail_local'
arch/powerpc/platforms/powermac/bootx_init.o: In function `bootx_scan_dt_build_struct':
bootx_init.c:(.init.text+0xa84): undefined reference to `__stack_chk_fail_local'
arch/powerpc/platforms/powermac/bootx_init.o: In function `bootx_init':
bootx_init.c:(.init.text+0xf48): undefined reference to `__stack_chk_fail_local'
powerpc-linux-gnu-ld: .tmp_vmlinux1: hidden symbol `__stack_chk_fail_local' isn't defined
powerpc-linux-gnu-ld: final link failed: Bad value
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 29220 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] powerpc/32: stack protector: change the canary value per task
From: Segher Boessenkool @ 2018-09-17 16:49 UTC (permalink / raw)
To: Christophe Leroy
Cc: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
linuxppc-dev, linux-kernel
In-Reply-To: <7bd67c4ccdd202f2125b7fc0ed0332d0d020690b.1537186089.git.christophe.leroy@c-s.fr>
On Mon, Sep 17, 2018 at 12:15:08PM +0000, Christophe Leroy wrote:
> I would have liked to use -mstack-protector-guard=tls -mstack-protector-guard-reg=r2
> -mstack-protector-guard-offset=offsetof(struct task_struct, stack_canary) but I have
> not found how set the value of offsetof(struct task_struct, stack_canary) in Makefile.
By far the easiest is to have the canary at a fixed offset from r2.
Segher
^ permalink raw reply
* Re: [PATCH] powerpc: Disable -Wbuiltin-requires-header when setjmp is used
From: Nick Desaulniers @ 2018-09-17 17:13 UTC (permalink / raw)
To: joel; +Cc: linuxppc-dev, Stephen Hines
In-Reply-To: <20180917074621.25066-1-joel@jms.id.au>
On Mon, Sep 17, 2018 at 12:46 AM Joel Stanley <joel@jms.id.au> wrote:
>
> The powerpc kernel uses setjmp which causes a warning when building with
> clang:
>
> CC arch/powerpc/xmon/xmon.o
> In file included from arch/powerpc/xmon/xmon.c:51:
> ./arch/powerpc/include/asm/setjmp.h:15:13: error: declaration of
> built-in function 'setjmp' requires inclusion of the header <setjmp.h>
> [-Werror,-Wbuiltin-requires-header]
> extern long setjmp(long *);
> ^
> ./arch/powerpc/include/asm/setjmp.h:16:13: error: declaration of
> built-in function 'longjmp' requires inclusion of the header <setjmp.h>
> [-Werror,-Wbuiltin-requires-header]
> extern void longjmp(long *, long);
> ^
>
> This *is* the header and we're not using the built-in setjump but
> rather the one in arch/powerpc/kernel/misc.S. As the compiler warning
> does not make sense, it for the files where setjmp is used.
>
> Signed-off-by: Joel Stanley <joel@jms.id.au>
Joel, thanks for reporting the issue in
https://github.com/ClangBuiltLinux/linux/issues/59
and sending the patch to fix. I think it would be good to credit
Stephen with the Suggested-by tag:
Suggested-by: Stephen Hines <srhines@google.com>
> ---
> We could instead disable this for all of the kernel as I don't think the
> warning is going to ever provide useful information for the kernel.
I'd be curious to see more than one failure to be able to discern
whether this flag should always be disabled or if it could flag actual
bugs. I assume the intent of the flag is "don't name
functions/headers that would conflict with the C standard library."
While the kernel uses `-nostdinc`, I still kind of empathize with the
intent of the flag. I worry about system headers somehow getting
included rather than the kernel provided ones, especially because some
Makefiles in the kernel overwrite KBUILD_CFLAGS.
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
>
> arch/powerpc/kernel/Makefile | 3 +++
> arch/powerpc/xmon/Makefile | 3 +++
> 2 files changed, 6 insertions(+)
>
> diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
> index 1e64cfe22a83..9845a94f5f68 100644
> --- a/arch/powerpc/kernel/Makefile
> +++ b/arch/powerpc/kernel/Makefile
> @@ -7,6 +7,9 @@ CFLAGS_ptrace.o += -DUTS_MACHINE='"$(UTS_MACHINE)"'
>
> subdir-ccflags-$(CONFIG_PPC_WERROR) := -Werror
>
> +# Disable clang warning for using setjmp without setjmp.h header
> +CFLAGS_crash.o += $(call cc-disable-warning, builtin-requires-header)
> +
> ifdef CONFIG_PPC64
> CFLAGS_prom_init.o += $(NO_MINIMAL_TOC)
> endif
> diff --git a/arch/powerpc/xmon/Makefile b/arch/powerpc/xmon/Makefile
> index 93cc1f1b8b61..a38db48f9f6d 100644
> --- a/arch/powerpc/xmon/Makefile
> +++ b/arch/powerpc/xmon/Makefile
> @@ -14,6 +14,9 @@ ccflags-$(CONFIG_PPC64) := $(NO_MINIMAL_TOC)
>
> obj-y += xmon.o nonstdio.o spr_access.o
>
> +# Disable clang warning for using setjmp without setjmp.h header
> +subdir-ccflags-y := $(call cc-disable-warning, builtin-requires-header)
> +
> ifdef CONFIG_XMON_DISASSEMBLY
> obj-y += ppc-dis.o ppc-opc.o
> obj-$(CONFIG_SPU_BASE) += spu-dis.o spu-opc.o
> --
> 2.17.1
>
--
Thanks,
~Nick Desaulniers
^ permalink raw reply
* Re: [PATCH 3/3] mm: optimise pte dirty/accessed bit setting by demand based pte insertion
From: Nicholas Piggin @ 2018-09-17 17:53 UTC (permalink / raw)
To: Guenter Roeck
Cc: linux-mm, linux-arch, linux-kernel, linuxppc-dev, Andrew Morton,
Linus Torvalds, Ley Foon Tan, nios2-dev
In-Reply-To: <20180905142951.GA15680@roeck-us.net>
On Wed, 5 Sep 2018 07:29:51 -0700
Guenter Roeck <linux@roeck-us.net> wrote:
> Hi,
>
> On Tue, Aug 28, 2018 at 09:20:34PM +1000, Nicholas Piggin wrote:
> > Similarly to the previous patch, this tries to optimise dirty/accessed
> > bits in ptes to avoid access costs of hardware setting them.
> >
>
> This patch results in silent nios2 boot failures, silent meaning that
> the boot stalls.
Okay I just got back to looking at this. The reason for the hang is
I think a bug in the nios2 TLB code, but maybe other archs have similar
issues.
In case of a missing / !present Linux pte, nios2 installs a TLB entry
with no permissions via its fast TLB exception handler (software TLB
fill). Then it relies on that causing a TLB permission exception in a
slower handler that calls handle_mm_fault to set the Linux pte and
flushes the old TLB. Then the fast exception handler will find the new
Linux pte.
With this patch, nios2 has a case where handle_mm_fault does not flush
the old TLB, which results in the TLB permission exception continually
being retried.
What happens now is that fault paths like do_read_fault will install a
Linux pte with the young bit clear and return. That will cause nios2 to
fault again but this time go down the bottom of handle_pte_fault and to
the access flags update with the young bit set. The young bit is seen to
be different, so that causes ptep_set_access_flags to do a TLB flush and
that finally allows the fast TLB handler to fire and pick up the new
Linux pte.
With this patch, the young bit is set in the first handle_mm_fault, so
the second handle_mm_fault no longer sees the ptes are different and
does not flush the TLB. The spurious fault handler also does not flush
them unless FAULT_FLAG_WRITE is set.
What nios2 should do is invalidate the TLB in update_mmu_cache. What it
*really* should do is install the new TLB entry, I have some patches to
make that work in qemu I can submit. But I would like to try getting
these dirty/accessed bit optimisation in 4.20, so I will send a simple
path to just do the TLB invalidate that could go in Andrew's git tree.
Is that agreeable with the nios2 maintainers?
Thanks,
Nick
^ permalink raw reply
* [PATCH] powerpc/pseries: Disable CPU hotplug across migrations
From: Nathan Fontenot @ 2018-09-17 19:14 UTC (permalink / raw)
To: linuxppc-dev
When performing partition migrations all present CPUs must be online
as all present CPUs must make the H_JOIN call as part of the migration
process. Once all present CPUs make the H_JOIN call, one CPU is returned
to make the rtas call to perform the migration to the destination system.
During testing of migration and changing the SMT state we have found
instances where CPUs are offlined, as part of the SMT state change,
before they make the H_JOIN call. This results in a hung system where
every CPU is either in H_JOIN or offline.
To prevent this this patch disables CPU hotplug during the migration
process.
Signed-off-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
---
arch/powerpc/kernel/rtas.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
index 8afd146bc9c7..2c7ed31c736e 100644
--- a/arch/powerpc/kernel/rtas.c
+++ b/arch/powerpc/kernel/rtas.c
@@ -981,6 +981,7 @@ int rtas_ibm_suspend_me(u64 handle)
goto out;
}
+ cpu_hotplug_disable();
stop_topology_update();
/* Call function on all CPUs. One of us will make the
@@ -995,6 +996,7 @@ int rtas_ibm_suspend_me(u64 handle)
printk(KERN_ERR "Error doing global join\n");
start_topology_update();
+ cpu_hotplug_enable();
/* Take down CPUs not online prior to suspend */
cpuret = rtas_offline_cpus_mask(offline_mask);
^ permalink raw reply related
* Re: [PATCH] powerpc/pseries: Disable CPU hotplug across migrations
From: Tyrel Datwyler @ 2018-09-17 20:41 UTC (permalink / raw)
To: Nathan Fontenot, linuxppc-dev
In-Reply-To: <153721164232.32706.4283915467151746975.stgit@ltcalpine2-lp14.aus.stglabs.ibm.com>
On 09/17/2018 12:14 PM, Nathan Fontenot wrote:
> When performing partition migrations all present CPUs must be online
> as all present CPUs must make the H_JOIN call as part of the migration
> process. Once all present CPUs make the H_JOIN call, one CPU is returned
> to make the rtas call to perform the migration to the destination system.
>
> During testing of migration and changing the SMT state we have found
> instances where CPUs are offlined, as part of the SMT state change,
> before they make the H_JOIN call. This results in a hung system where
> every CPU is either in H_JOIN or offline.
>
> To prevent this this patch disables CPU hotplug during the migration
> process.
>
> Signed-off-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
Reviewed-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
^ permalink raw reply
* Re: [PATCH v2 2/5] powerpc/boot: Fix crt0.S syntax for clang
From: Nick Desaulniers @ 2018-09-17 20:41 UTC (permalink / raw)
To: segher; +Cc: joel, linuxppc-dev
In-Reply-To: <20180914210840.GT23155@gate.crashing.org>
On Fri, Sep 14, 2018 at 2:08 PM Segher Boessenkool
<segher@kernel.crashing.org> wrote:
>
> On Fri, Sep 14, 2018 at 10:47:08AM -0700, Nick Desaulniers wrote:
> > On Thu, Sep 13, 2018 at 9:07 PM Joel Stanley <joel@jms.id.au> wrote:
> > > 10: addis r12,r12,(-RELACOUNT)@ha
> > > - cmpdi r12,RELACOUNT@l
> > > + cmpdi r12,(RELACOUNT)@l
> >
> > Yep, as we can see above, when RELACOUNT is negated, it's wrapped in
> > parens.
Looks like this was just fixed in Clang-8:
https://bugs.llvm.org/show_bug.cgi?id=38945
https://reviews.llvm.org/D52188
--
Thanks,
~Nick Desaulniers
^ permalink raw reply
* Re: [PATCH -next] fsl/qe: Fix copy-paste error in ucc_get_tdm_sync_shift
From: Li Yang @ 2018-09-17 21:09 UTC (permalink / raw)
To: yuehaibing
Cc: Zhao Qiang, lkml,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
linuxppc-dev
In-Reply-To: <20180915111005.10028-1-yuehaibing@huawei.com>
On Sat, Sep 15, 2018 at 6:11 AM YueHaibing <yuehaibing@huawei.com> wrote:
>
> if 'mode' is COMM_DIR_TX, 'shift' should use TX_SYNC_SHIFT_BASE
>
> Fixes: bb8b2062aff3 ("fsl/qe: setup clock source for TDM mode")
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Thanks for submitting the patch, but there is already the same fix in
the queue from Zhao Qiang and Dan Carpenter.
> ---
> drivers/soc/fsl/qe/ucc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/soc/fsl/qe/ucc.c b/drivers/soc/fsl/qe/ucc.c
> index c646d87..681f7d4 100644
> --- a/drivers/soc/fsl/qe/ucc.c
> +++ b/drivers/soc/fsl/qe/ucc.c
> @@ -626,7 +626,7 @@ static u32 ucc_get_tdm_sync_shift(enum comm_dir mode, u32 tdm_num)
> {
> u32 shift;
>
> - shift = (mode == COMM_DIR_RX) ? RX_SYNC_SHIFT_BASE : RX_SYNC_SHIFT_BASE;
> + shift = (mode == COMM_DIR_RX) ? RX_SYNC_SHIFT_BASE : TX_SYNC_SHIFT_BASE;
> shift -= tdm_num * 2;
>
> return shift;
> --
> 1.8.3.1
>
>
^ permalink raw reply
* [PATCH 4.4 24/56] perf tools: Allow overriding MAX_NR_CPUS at compile time
From: Greg Kroah-Hartman @ 2018-09-17 22:41 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Christophe Leroy, Alexander Shishkin,
Peter Zijlstra, linuxppc-dev, Arnaldo Carvalho de Melo,
Sasha Levin
In-Reply-To: <20180917213827.913122591@linuxfoundation.org>
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christophe Leroy <christophe.leroy@c-s.fr>
[ Upstream commit 21b8732eb4479b579bda9ee38e62b2c312c2a0e5 ]
After update of kernel, the perf tool doesn't run anymore on my 32MB RAM
powerpc board, but still runs on a 128MB RAM board:
~# strace perf
execve("/usr/sbin/perf", ["perf"], [/* 12 vars */]) = -1 ENOMEM (Cannot allocate memory)
--- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=0} ---
+++ killed by SIGSEGV +++
Segmentation fault
objdump -x shows that .bss section has a huge size of 24Mbytes:
27 .bss 016baca8 101cebb8 101cebb8 001cd988 2**3
With especially the following objects having quite big size:
10205f80 l O .bss 00140000 runtime_cycles_stats
10345f80 l O .bss 00140000 runtime_stalled_cycles_front_stats
10485f80 l O .bss 00140000 runtime_stalled_cycles_back_stats
105c5f80 l O .bss 00140000 runtime_branches_stats
10705f80 l O .bss 00140000 runtime_cacherefs_stats
10845f80 l O .bss 00140000 runtime_l1_dcache_stats
10985f80 l O .bss 00140000 runtime_l1_icache_stats
10ac5f80 l O .bss 00140000 runtime_ll_cache_stats
10c05f80 l O .bss 00140000 runtime_itlb_cache_stats
10d45f80 l O .bss 00140000 runtime_dtlb_cache_stats
10e85f80 l O .bss 00140000 runtime_cycles_in_tx_stats
10fc5f80 l O .bss 00140000 runtime_transaction_stats
11105f80 l O .bss 00140000 runtime_elision_stats
11245f80 l O .bss 00140000 runtime_topdown_total_slots
11385f80 l O .bss 00140000 runtime_topdown_slots_retired
114c5f80 l O .bss 00140000 runtime_topdown_slots_issued
11605f80 l O .bss 00140000 runtime_topdown_fetch_bubbles
11745f80 l O .bss 00140000 runtime_topdown_recovery_bubbles
This is due to commit 4d255766d28b1 ("perf: Bump max number of cpus
to 1024"), because many tables are sized with MAX_NR_CPUS
This patch gives the opportunity to redefine MAX_NR_CPUS via
$ make EXTRA_CFLAGS=-DMAX_NR_CPUS=1
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: linuxppc-dev@lists.ozlabs.org
Link: http://lkml.kernel.org/r/20170922112043.8349468C57@po15668-vm-win7.idsi0.si.c-s.fr
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
tools/perf/perf.h | 2 ++
1 file changed, 2 insertions(+)
--- a/tools/perf/perf.h
+++ b/tools/perf/perf.h
@@ -29,7 +29,9 @@ static inline unsigned long long rdclock
return ts.tv_sec * 1000000000ULL + ts.tv_nsec;
}
+#ifndef MAX_NR_CPUS
#define MAX_NR_CPUS 1024
+#endif
extern const char *input_name;
extern bool perf_host, perf_guest;
^ permalink raw reply
* [PATCH 4.9 31/70] perf tools: Allow overriding MAX_NR_CPUS at compile time
From: Greg Kroah-Hartman @ 2018-09-17 22:42 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Christophe Leroy, Alexander Shishkin,
Peter Zijlstra, linuxppc-dev, Arnaldo Carvalho de Melo,
Sasha Levin
In-Reply-To: <20180917211649.099135838@linuxfoundation.org>
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christophe Leroy <christophe.leroy@c-s.fr>
[ Upstream commit 21b8732eb4479b579bda9ee38e62b2c312c2a0e5 ]
After update of kernel, the perf tool doesn't run anymore on my 32MB RAM
powerpc board, but still runs on a 128MB RAM board:
~# strace perf
execve("/usr/sbin/perf", ["perf"], [/* 12 vars */]) = -1 ENOMEM (Cannot allocate memory)
--- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=0} ---
+++ killed by SIGSEGV +++
Segmentation fault
objdump -x shows that .bss section has a huge size of 24Mbytes:
27 .bss 016baca8 101cebb8 101cebb8 001cd988 2**3
With especially the following objects having quite big size:
10205f80 l O .bss 00140000 runtime_cycles_stats
10345f80 l O .bss 00140000 runtime_stalled_cycles_front_stats
10485f80 l O .bss 00140000 runtime_stalled_cycles_back_stats
105c5f80 l O .bss 00140000 runtime_branches_stats
10705f80 l O .bss 00140000 runtime_cacherefs_stats
10845f80 l O .bss 00140000 runtime_l1_dcache_stats
10985f80 l O .bss 00140000 runtime_l1_icache_stats
10ac5f80 l O .bss 00140000 runtime_ll_cache_stats
10c05f80 l O .bss 00140000 runtime_itlb_cache_stats
10d45f80 l O .bss 00140000 runtime_dtlb_cache_stats
10e85f80 l O .bss 00140000 runtime_cycles_in_tx_stats
10fc5f80 l O .bss 00140000 runtime_transaction_stats
11105f80 l O .bss 00140000 runtime_elision_stats
11245f80 l O .bss 00140000 runtime_topdown_total_slots
11385f80 l O .bss 00140000 runtime_topdown_slots_retired
114c5f80 l O .bss 00140000 runtime_topdown_slots_issued
11605f80 l O .bss 00140000 runtime_topdown_fetch_bubbles
11745f80 l O .bss 00140000 runtime_topdown_recovery_bubbles
This is due to commit 4d255766d28b1 ("perf: Bump max number of cpus
to 1024"), because many tables are sized with MAX_NR_CPUS
This patch gives the opportunity to redefine MAX_NR_CPUS via
$ make EXTRA_CFLAGS=-DMAX_NR_CPUS=1
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: linuxppc-dev@lists.ozlabs.org
Link: http://lkml.kernel.org/r/20170922112043.8349468C57@po15668-vm-win7.idsi0.si.c-s.fr
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
tools/perf/perf.h | 2 ++
1 file changed, 2 insertions(+)
--- a/tools/perf/perf.h
+++ b/tools/perf/perf.h
@@ -22,7 +22,9 @@ static inline unsigned long long rdclock
return ts.tv_sec * 1000000000ULL + ts.tv_nsec;
}
+#ifndef MAX_NR_CPUS
#define MAX_NR_CPUS 1024
+#endif
extern const char *input_name;
extern bool perf_host, perf_guest;
^ permalink raw reply
* Re: [PATCH RFC 1/4] PCI: hotplug: Add parameter to put devices to reset during rescan
From: Bjorn Helgaas @ 2018-09-17 22:59 UTC (permalink / raw)
To: Sergey Miroshnichenko
Cc: Sam Bobroff, linux-pci, Bjorn Helgaas, linux, Russell Currey,
linuxppc-dev, Benjamin Herrenschmidt, Oliver OHalloran
In-Reply-To: <6b913e12-e8c8-30c1-5269-3029ddb00a4d@yadro.com>
[+cc Russell, Ben, Oliver, linuxppc-dev]
On Mon, Sep 17, 2018 at 11:55:43PM +0300, Sergey Miroshnichenko wrote:
> Hello Sam,
>
> On 9/17/18 8:28 AM, Sam Bobroff wrote:
> > Hi Sergey,
> >
> > On Fri, Sep 14, 2018 at 07:14:01PM +0300, Sergey Miroshnichenko wrote:
> >> Introduce a new command line option "pci=pcie_movable_bars" that indicates
> >> support of PCIe hotplug without prior reservation of memory regions by
> >> BIOS/bootloader.
> >>
> >> If a new PCIe device has been hot-plugged between two active ones, which
> >> have no (or not big enough) gap between their BARs, allocating new BARs
> >> requires to move BARs of the following working devices:
> >>
> >> 1) dev 4
> >> |
> >> v
> >> .. | dev 3 | dev 3 | dev 5 | dev 7 |
> >> .. | BAR 0 | BAR 1 | BAR 0 | BAR 0 |
> >>
> >> 2) dev 4
> >> |
> >> v
> >> .. | dev 3 | dev 3 | --> --> | dev 5 | dev 7 |
> >> .. | BAR 0 | BAR 1 | --> --> | BAR 0 | BAR 0 |
> >>
> >> 3)
> >>
> >> .. | dev 3 | dev 3 | dev 4 | dev 4 | dev 5 | dev 7 |
> >> .. | BAR 0 | BAR 1 | BAR 0 | BAR 1 | BAR 0 | BAR 0 |
> >>
> >> Not only BARs, but also bridge windows can be updated during a PCIe rescan,
> >> threatening all memory transactions during this procedure, so the PCI
> >> subsystem will instruct the drivers to pause by calling the reset_prepare()
> >> and reset_done() callbacks.
> >>
> >> If a device may be affected by BAR movement, the BAR changes tracking must
> >> be implemented in its driver.
> >>
> >> Signed-off-by: Sergey Miroshnichenko <s.miroshnichenko@yadro.com>
> >> ---
> >> .../admin-guide/kernel-parameters.txt | 6 +++
> >> drivers/pci/pci.c | 2 +
> >> drivers/pci/probe.c | 43 +++++++++++++++++++
> >> include/linux/pci.h | 1 +
> >> 4 files changed, 52 insertions(+)
> >>
> >> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> >> index 64a3bf54b974..f8132a709061 100644
> >> --- a/Documentation/admin-guide/kernel-parameters.txt
> >> +++ b/Documentation/admin-guide/kernel-parameters.txt
> >> @@ -3311,6 +3311,12 @@
> >> bridges without forcing it upstream. Note:
> >> this removes isolation between devices and
> >> may put more devices in an IOMMU group.
> >> + pcie_movable_bars Arrange a space at runtime for BARs of
> >> + hotplugged PCIe devices - usable if bootloader
> >> + doesn't reserve memory regions for them. Freeing
> >> + a space may require moving BARs of active devices
> >> + to higher addresses, so device drivers will be
> >> + paused during rescan.
> >>
> >> pcie_aspm= [PCIE] Forcibly enable or disable PCIe Active State Power
> >> Management.
> >> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> >> index 1835f3a7aa8d..5f07a59b5924 100644
> >> --- a/drivers/pci/pci.c
> >> +++ b/drivers/pci/pci.c
> >> @@ -6105,6 +6105,8 @@ static int __init pci_setup(char *str)
> >> pci_add_flags(PCI_SCAN_ALL_PCIE_DEVS);
> >> } else if (!strncmp(str, "disable_acs_redir=", 18)) {
> >> disable_acs_redir_param = str + 18;
> >> + } else if (!strncmp(str, "pcie_movable_bars", 17)) {
> >> + pci_add_flags(PCI_MOVABLE_BARS);
> >> } else {
> >> printk(KERN_ERR "PCI: Unknown option `%s'\n",
> >> str);
> >> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> >> index 201f9e5ff55c..bdaafc48dc4c 100644
> >> --- a/drivers/pci/probe.c
> >> +++ b/drivers/pci/probe.c
> >> @@ -3138,6 +3138,45 @@ unsigned int pci_rescan_bus_bridge_resize(struct pci_dev *bridge)
> >> return max;
> >> }
> >>
> >> +/*
> >> + * Put all devices of the bus and its children to reset
> >> + */
> >> +static void pci_bus_reset_prepare(struct pci_bus *bus)
> >> +{
> >> + struct pci_dev *dev;
> >> +
> >> + list_for_each_entry(dev, &bus->devices, bus_list) {
> >> + struct pci_bus *child = dev->subordinate;
> >> +
> >> + if (child) {
> >> + pci_bus_reset_prepare(child);
> >> + } else if (dev->driver &&
> >> + dev->driver->err_handler &&
> >> + dev->driver->err_handler->reset_prepare) {
> >> + dev->driver->err_handler->reset_prepare(dev);
> >> + }
> >
> > What about devices with drivers that don't have reset_prepare()? It
> > looks like it will just reconfigure them anyway. Is that right?
> >
>
> It is possible that unprepared driver without these hooks will get BARs
> moved, I should put a warning message there. There three ways we can see
> to make this safe:
> - add the reset_prepare()/reset_done() hooks to *every* PCIe driver;
> - refuse BAR movement if at least one unprepared driver has been
> encountered during rescan;
> - reduce the number of drivers which can be affected to some
> controllable value and prepare them on demand.
>
> Applying the second proposal as a major restriction seems fairly
> reasonable, but for our particular setups and use-cases it is probably
> too stiff:
> - we've noticed that devices connected directly to the root bridge
> don't get moved BARs, and this covers our x86_64 servers: we only
> insert/remove devices into "second-level" and "lower" bridges there, but
> not root;
> - on PowerNV we have system devices (network interfaces, USB hub, etc.)
> grouped into dedicated domain, with all other domains ready for hotplug,
> and only these domains can be rescanned.
>
> With our scenarios currently reduced to these two, we can live with just
> a few drivers "prepared" for now: NVME and few Ethernet adapters, this
> gives us a possibility to use this feature before "converting" *all* the
> drivers, and even have the NVidia cards running on a closed proprietary
> driver.
>
> Should we make this behavior adjustable with something like
> "pcie_movable_bars=safe" and "pcie_movable_bars=always" ?
I like the overall idea of this a lot.
- Why do we need a command line parameter to enable this? Can't we
do it unconditionally and automatically when it's possible? We
could have a chicken switch to *disable* it in case this breaks
something horribly, but I would like this functionality to be
always available without a special option.
- I'm not sure the existence of .reset_done() is evidence that a
driver is prepared for its BARs to move. I don't see any
documentation that refers to BAR movement, and I doubt it's been
tested. But I only see 5 implementations in the tree, so it'd be
easy to verify.
- I think your second proposal above sounds right: we should regard
any device whose driver lacks .reset_done() as immovable. We will
likely be able to move some devices but not others. Implementing
.reset_done() will increase flexibility but it shouldn't be a
requirement for all drivers.
> >> + }
> >> +}
> >> +
> >> +/*
> >> + * Complete the reset of all devices for the bus and its children
> >> + */
> >> +static void pci_bus_reset_done(struct pci_bus *bus)
> >> +{
> >> + struct pci_dev *dev;
> >> +
> >> + list_for_each_entry(dev, &bus->devices, bus_list) {
> >> + struct pci_bus *child = dev->subordinate;
> >> +
> >> + if (child) {
> >> + pci_bus_reset_done(child);
> >> + } else if (dev->driver && dev->driver->err_handler &&
> >> + dev->driver->err_handler->reset_done) {
> >> + dev->driver->err_handler->reset_done(dev);
> >> + }
> >> + }
> >> +}
> >> +
> >> /**
> >> * pci_rescan_bus - Scan a PCI bus for devices
> >> * @bus: PCI bus to scan
> >> @@ -3151,8 +3190,12 @@ unsigned int pci_rescan_bus(struct pci_bus *bus)
> >> {
> >> unsigned int max;
> >>
> >> + if (pci_has_flag(PCI_MOVABLE_BARS))
> >> + pci_bus_reset_prepare(bus);
> >> max = pci_scan_child_bus(bus);
> >> pci_assign_unassigned_bus_resources(bus);
> >> + if (pci_has_flag(PCI_MOVABLE_BARS))
> >> + pci_bus_reset_done(bus);
> >> pci_bus_add_devices(bus);
> >>
> >> return max;
> >> diff --git a/include/linux/pci.h b/include/linux/pci.h
> >> index 6925828f9f25..a8cb1a367c34 100644
> >> --- a/include/linux/pci.h
> >> +++ b/include/linux/pci.h
> >> @@ -847,6 +847,7 @@ enum {
> >> PCI_ENABLE_PROC_DOMAINS = 0x00000010, /* Enable domains in /proc */
> >> PCI_COMPAT_DOMAIN_0 = 0x00000020, /* ... except domain 0 */
> >> PCI_SCAN_ALL_PCIE_DEVS = 0x00000040, /* Scan all, not just dev 0 */
> >> + PCI_MOVABLE_BARS = 0x00000080, /* Runtime BAR reassign after hotplug */
> >> };
> >>
> >> /* These external functions are only available when PCI support is enabled */
> >> --
> >> 2.17.1
> >>
^ permalink raw reply
* [PATCH 4.14 046/126] perf tools: Allow overriding MAX_NR_CPUS at compile time
From: Greg Kroah-Hartman @ 2018-09-17 22:41 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Christophe Leroy, Alexander Shishkin,
Peter Zijlstra, linuxppc-dev, Arnaldo Carvalho de Melo,
Sasha Levin
In-Reply-To: <20180917211703.481236999@linuxfoundation.org>
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christophe Leroy <christophe.leroy@c-s.fr>
[ Upstream commit 21b8732eb4479b579bda9ee38e62b2c312c2a0e5 ]
After update of kernel, the perf tool doesn't run anymore on my 32MB RAM
powerpc board, but still runs on a 128MB RAM board:
~# strace perf
execve("/usr/sbin/perf", ["perf"], [/* 12 vars */]) = -1 ENOMEM (Cannot allocate memory)
--- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=0} ---
+++ killed by SIGSEGV +++
Segmentation fault
objdump -x shows that .bss section has a huge size of 24Mbytes:
27 .bss 016baca8 101cebb8 101cebb8 001cd988 2**3
With especially the following objects having quite big size:
10205f80 l O .bss 00140000 runtime_cycles_stats
10345f80 l O .bss 00140000 runtime_stalled_cycles_front_stats
10485f80 l O .bss 00140000 runtime_stalled_cycles_back_stats
105c5f80 l O .bss 00140000 runtime_branches_stats
10705f80 l O .bss 00140000 runtime_cacherefs_stats
10845f80 l O .bss 00140000 runtime_l1_dcache_stats
10985f80 l O .bss 00140000 runtime_l1_icache_stats
10ac5f80 l O .bss 00140000 runtime_ll_cache_stats
10c05f80 l O .bss 00140000 runtime_itlb_cache_stats
10d45f80 l O .bss 00140000 runtime_dtlb_cache_stats
10e85f80 l O .bss 00140000 runtime_cycles_in_tx_stats
10fc5f80 l O .bss 00140000 runtime_transaction_stats
11105f80 l O .bss 00140000 runtime_elision_stats
11245f80 l O .bss 00140000 runtime_topdown_total_slots
11385f80 l O .bss 00140000 runtime_topdown_slots_retired
114c5f80 l O .bss 00140000 runtime_topdown_slots_issued
11605f80 l O .bss 00140000 runtime_topdown_fetch_bubbles
11745f80 l O .bss 00140000 runtime_topdown_recovery_bubbles
This is due to commit 4d255766d28b1 ("perf: Bump max number of cpus
to 1024"), because many tables are sized with MAX_NR_CPUS
This patch gives the opportunity to redefine MAX_NR_CPUS via
$ make EXTRA_CFLAGS=-DMAX_NR_CPUS=1
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: linuxppc-dev@lists.ozlabs.org
Link: http://lkml.kernel.org/r/20170922112043.8349468C57@po15668-vm-win7.idsi0.si.c-s.fr
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
tools/perf/perf.h | 2 ++
1 file changed, 2 insertions(+)
--- a/tools/perf/perf.h
+++ b/tools/perf/perf.h
@@ -24,7 +24,9 @@ static inline unsigned long long rdclock
return ts.tv_sec * 1000000000ULL + ts.tv_nsec;
}
+#ifndef MAX_NR_CPUS
#define MAX_NR_CPUS 1024
+#endif
extern const char *input_name;
extern bool perf_host, perf_guest;
^ permalink raw reply
* [PATCH 4.18 084/158] perf tools: Allow overriding MAX_NR_CPUS at compile time
From: Greg Kroah-Hartman @ 2018-09-17 22:41 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Christophe Leroy, Alexander Shishkin,
Peter Zijlstra, linuxppc-dev, Arnaldo Carvalho de Melo,
Sasha Levin
In-Reply-To: <20180917211710.383360696@linuxfoundation.org>
4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christophe Leroy <christophe.leroy@c-s.fr>
[ Upstream commit 21b8732eb4479b579bda9ee38e62b2c312c2a0e5 ]
After update of kernel, the perf tool doesn't run anymore on my 32MB RAM
powerpc board, but still runs on a 128MB RAM board:
~# strace perf
execve("/usr/sbin/perf", ["perf"], [/* 12 vars */]) = -1 ENOMEM (Cannot allocate memory)
--- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=0} ---
+++ killed by SIGSEGV +++
Segmentation fault
objdump -x shows that .bss section has a huge size of 24Mbytes:
27 .bss 016baca8 101cebb8 101cebb8 001cd988 2**3
With especially the following objects having quite big size:
10205f80 l O .bss 00140000 runtime_cycles_stats
10345f80 l O .bss 00140000 runtime_stalled_cycles_front_stats
10485f80 l O .bss 00140000 runtime_stalled_cycles_back_stats
105c5f80 l O .bss 00140000 runtime_branches_stats
10705f80 l O .bss 00140000 runtime_cacherefs_stats
10845f80 l O .bss 00140000 runtime_l1_dcache_stats
10985f80 l O .bss 00140000 runtime_l1_icache_stats
10ac5f80 l O .bss 00140000 runtime_ll_cache_stats
10c05f80 l O .bss 00140000 runtime_itlb_cache_stats
10d45f80 l O .bss 00140000 runtime_dtlb_cache_stats
10e85f80 l O .bss 00140000 runtime_cycles_in_tx_stats
10fc5f80 l O .bss 00140000 runtime_transaction_stats
11105f80 l O .bss 00140000 runtime_elision_stats
11245f80 l O .bss 00140000 runtime_topdown_total_slots
11385f80 l O .bss 00140000 runtime_topdown_slots_retired
114c5f80 l O .bss 00140000 runtime_topdown_slots_issued
11605f80 l O .bss 00140000 runtime_topdown_fetch_bubbles
11745f80 l O .bss 00140000 runtime_topdown_recovery_bubbles
This is due to commit 4d255766d28b1 ("perf: Bump max number of cpus
to 1024"), because many tables are sized with MAX_NR_CPUS
This patch gives the opportunity to redefine MAX_NR_CPUS via
$ make EXTRA_CFLAGS=-DMAX_NR_CPUS=1
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: linuxppc-dev@lists.ozlabs.org
Link: http://lkml.kernel.org/r/20170922112043.8349468C57@po15668-vm-win7.idsi0.si.c-s.fr
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
tools/perf/perf.h | 2 ++
1 file changed, 2 insertions(+)
--- a/tools/perf/perf.h
+++ b/tools/perf/perf.h
@@ -25,7 +25,9 @@ static inline unsigned long long rdclock
return ts.tv_sec * 1000000000ULL + ts.tv_nsec;
}
+#ifndef MAX_NR_CPUS
#define MAX_NR_CPUS 1024
+#endif
extern const char *input_name;
extern bool perf_host, perf_guest;
^ permalink raw reply
* RE: [PATCH] powerpc/mpc85xx: fix issues in clock node
From: Andy Tang @ 2018-09-18 0:43 UTC (permalink / raw)
To: Andy Tang, oss@buserror.net
Cc: robh+dt@kernel.org, mark.rutland@arm.com,
benh@kernel.crashing.org, devicetree@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20180911021224.30558-1-andy.tang@nxp.com>
SGkgU2NvdHQsDQoNCkNvdWxkIHlvdSBwbGVhc2UgdGFrZSBhIGxvb2sgYXQgdGhpcyBwYXRjaD8N
Cg0KVGhhbmtzLA0KQW5keQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206
IGFuZHkudGFuZ0BueHAuY29tIDxhbmR5LnRhbmdAbnhwLmNvbT4NCj4gU2VudDogMjAxOMTqOdTC
MTHI1SAxMDoxMg0KPiBUbzogb3NzQGJ1c2Vycm9yLm5ldA0KPiBDYzogcm9iaCtkdEBrZXJuZWwu
b3JnOyBtYXJrLnJ1dGxhbmRAYXJtLmNvbTsNCj4gYmVuaEBrZXJuZWwuY3Jhc2hpbmcub3JnOyBk
ZXZpY2V0cmVlQHZnZXIua2VybmVsLm9yZzsNCj4gbGludXhwcGMtZGV2QGxpc3RzLm96bGFicy5v
cmc7IEFuZHkgVGFuZyA8YW5keS50YW5nQG54cC5jb20+DQo+IFN1YmplY3Q6IFtQQVRDSF0gcG93
ZXJwYy9tcGM4NXh4OiBmaXggaXNzdWVzIGluIGNsb2NrIG5vZGUNCj4gDQo+IEZyb206IFl1YW50
aWFuIFRhbmcgPGFuZHkudGFuZ0BueHAuY29tPg0KPiANCj4gVGhlIGNvbXBhdGlibGUgc3RyaW5n
IGlzIG5vdCBjb3JyZWN0IGluIHRoZSBjbG9jayBub2RlLg0KPiBUaGUgY2xvY2tzIHByb3BlcnR5
IHJlZmVycyB0byB0aGUgd3Jvbmcgbm9kZSB0b28uDQo+IFRoaXMgcGF0Y2ggaXMgdG8gZml4IHRo
ZW0uDQo+IA0KPiBTaWduZWQtb2ZmLWJ5OiBUYW5nIFl1YW50aWFuIDxhbmR5LnRhbmdAbnhwLmNv
bT4NCj4gLS0tDQo+ICBhcmNoL3Bvd2VycGMvYm9vdC9kdHMvZnNsL3QxMDIzc2ktcG9zdC5kdHNp
IHwgICAgOCArKysrLS0tLQ0KPiAgMSBmaWxlcyBjaGFuZ2VkLCA0IGluc2VydGlvbnMoKyksIDQg
ZGVsZXRpb25zKC0pDQo+IA0KPiBkaWZmIC0tZ2l0IGEvYXJjaC9wb3dlcnBjL2Jvb3QvZHRzL2Zz
bC90MTAyM3NpLXBvc3QuZHRzaQ0KPiBiL2FyY2gvcG93ZXJwYy9ib290L2R0cy9mc2wvdDEwMjNz
aS1wb3N0LmR0c2kNCj4gaW5kZXggNDkwOGFmNS4uNzYzY2FmNCAxMDA2NDQNCj4gLS0tIGEvYXJj
aC9wb3dlcnBjL2Jvb3QvZHRzL2ZzbC90MTAyM3NpLXBvc3QuZHRzaQ0KPiArKysgYi9hcmNoL3Bv
d2VycGMvYm9vdC9kdHMvZnNsL3QxMDIzc2ktcG9zdC5kdHNpDQo+IEBAIC0zNDgsNyArMzQ4LDcg
QEANCj4gIAkJbXV4MDogbXV4MEAwIHsNCj4gIAkJCSNjbG9jay1jZWxscyA9IDwwPjsNCj4gIAkJ
CXJlZyA9IDwweDAgND47DQo+IC0JCQljb21wYXRpYmxlID0gImZzbCxjb3JlLW11eC1jbG9jayI7
DQo+ICsJCQljb21wYXRpYmxlID0gImZzbCxxb3JpcS1jb3JlLW11eC0yLjAiOw0KPiAgCQkJY2xv
Y2tzID0gPCZwbGwwIDA+LCA8JnBsbDAgMT47DQo+ICAJCQljbG9jay1uYW1lcyA9ICJwbGwwXzAi
LCAicGxsMF8xIjsNCj4gIAkJCWNsb2NrLW91dHB1dC1uYW1lcyA9ICJjbXV4MCI7DQo+IEBAIC0z
NTYsOSArMzU2LDkgQEANCj4gIAkJbXV4MTogbXV4MUAyMCB7DQo+ICAJCQkjY2xvY2stY2VsbHMg
PSA8MD47DQo+ICAJCQlyZWcgPSA8MHgyMCA0PjsNCj4gLQkJCWNvbXBhdGlibGUgPSAiZnNsLGNv
cmUtbXV4LWNsb2NrIjsNCj4gLQkJCWNsb2NrcyA9IDwmcGxsMCAwPiwgPCZwbGwwIDE+Ow0KPiAt
CQkJY2xvY2stbmFtZXMgPSAicGxsMF8wIiwgInBsbDBfMSI7DQo+ICsJCQljb21wYXRpYmxlID0g
ImZzbCxxb3JpcS1jb3JlLW11eC0yLjAiOw0KPiArCQkJY2xvY2tzID0gPCZwbGwxIDA+LCA8JnBs
bDEgMT47DQo+ICsJCQljbG9jay1uYW1lcyA9ICJwbGwxXzAiLCAicGxsMV8xIjsNCj4gIAkJCWNs
b2NrLW91dHB1dC1uYW1lcyA9ICJjbXV4MSI7DQo+ICAJCX07DQo+ICAJfTsNCj4gLS0NCj4gMS43
LjENCg0K
^ permalink raw reply
* Re: [PATCH v2 2/5] powerpc/boot: Fix crt0.S syntax for clang
From: Joel Stanley @ 2018-09-18 1:08 UTC (permalink / raw)
To: Nick Desaulniers; +Cc: Segher Boessenkool, linuxppc-dev
In-Reply-To: <CAKwvOd=gf_G4SaZh3feqBZgZh=WXisRvJosrYzq20gtSOsao5Q@mail.gmail.com>
On Tue, 18 Sep 2018 at 06:11, Nick Desaulniers <ndesaulniers@google.com> wrote:
>
> On Fri, Sep 14, 2018 at 2:08 PM Segher Boessenkool
> <segher@kernel.crashing.org> wrote:
> >
> > On Fri, Sep 14, 2018 at 10:47:08AM -0700, Nick Desaulniers wrote:
> > > On Thu, Sep 13, 2018 at 9:07 PM Joel Stanley <joel@jms.id.au> wrote:
> > > > 10: addis r12,r12,(-RELACOUNT)@ha
> > > > - cmpdi r12,RELACOUNT@l
> > > > + cmpdi r12,(RELACOUNT)@l
> > >
> > > Yep, as we can see above, when RELACOUNT is negated, it's wrapped in
> > > parens.
>
> Looks like this was just fixed in Clang-8:
> https://bugs.llvm.org/show_bug.cgi?id=38945
> https://reviews.llvm.org/D52188
Nice!
mpe, given we need the local references to labels fix which is also in
clang-8 I suggest we drop this patch.
Cheers,
Joel
^ permalink raw reply
* Re: [RFC PATCH 05/11] powerpc/tm: Function that updates the failure code
From: Michael Neuling @ 2018-09-18 1:29 UTC (permalink / raw)
To: Breno Leitao, linuxppc-dev; +Cc: paulus, gromero, mpe, ldufour
In-Reply-To: <1536781219-13938-6-git-send-email-leitao@debian.org>
On Wed, 2018-09-12 at 16:40 -0300, Breno Leitao wrote:
> Now the transaction reclaims happens very earlier in the trap handler, an=
d
> it is impossible to know precisely, at that early time, what should be se=
t
> as the failure cause for some specific cases, as, if the task will be
> rescheduled, thus, the transaction abort case should be updated from
> TM_CAUSE_MISC to TM_CAUSE_RESCHED, for example.
Please add comments to where this is used (in EXCEPTION_COMMON macro I thin=
k)
that say this might happen.
>=20
> This patch creates a function that will update TEXASR special purpose
> register in the task thread and set the failure code which will be
> moved to the live register afterward.
>=20
> Signed-off-by: Breno Leitao <leitao@debian.org>
> ---
> arch/powerpc/kernel/process.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>=20
> diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.=
c
> index 54fddf03b97a..fe063c0142e3 100644
> --- a/arch/powerpc/kernel/process.c
> +++ b/arch/powerpc/kernel/process.c
> @@ -85,6 +85,7 @@ extern unsigned long _get_SP(void);
> * other paths that we should never reach with suspend disabled.
> */
> bool tm_suspend_disabled __ro_after_init =3D false;
> +static void tm_fix_failure_cause(struct task_struct *task, uint8_t cause=
);
> =20
> static void check_if_tm_restore_required(struct task_struct *tsk)
> {
> @@ -988,6 +989,14 @@ void tm_recheckpoint(struct thread_struct *thread)
> local_irq_restore(flags);
> }
> =20
> +/* Change thread->tm.texasr failure code */
> +static void tm_fix_failure_cause(struct task_struct *task, uint8_t cause=
)
> +{
> + /* Clear the cause first */
> + task->thread.tm_texasr &=3D ~TEXASR_FC;
> + task->thread.tm_texasr |=3D (unsigned long) cause << 56;
> +}
> +
> static inline void tm_recheckpoint_new_task(struct task_struct *new)
> {
> if (!cpu_has_feature(CPU_FTR_TM))
^ permalink raw reply
* Re: [RFC PATCH 01/11] powerpc/tm: Reclaim transaction on kernel entry
From: Michael Neuling @ 2018-09-18 1:31 UTC (permalink / raw)
To: Breno Leitao, linuxppc-dev; +Cc: paulus, gromero, mpe, ldufour
In-Reply-To: <1536781219-13938-2-git-send-email-leitao@debian.org>
On Wed, 2018-09-12 at 16:40 -0300, Breno Leitao wrote:
> This patch creates a macro that will be invoked on all entrance to the
> kernel, so, in kernel space the transaction will be completely reclaimed
> and not suspended anymore.
There are still some calls to tm_reclaim_current() in process.c. Should the=
se
probably go now, right?
Mikey
> This patchset checks if we are coming from PR, if not, skip. This is usef=
ul
> when there is a irq_replay() being called after recheckpoint, when the IR=
Q
> is re-enable. In this case, we do not want to re-reclaim and
> re-recheckpoint, thus, if not coming from PR, skip it completely.
>=20
> This macro does not care about TM SPR also, it will only be saved and
> restore in the context switch code now on.
>=20
> This macro will return 0 or 1 in r3 register, to specify if a reclaim was
> executed or not.
>=20
> This patchset is based on initial work done by Cyril:
> https://patchwork.ozlabs.org/cover/875341/
>=20
> Signed-off-by: Breno Leitao <leitao@debian.org>
> ---
> arch/powerpc/include/asm/exception-64s.h | 46 ++++++++++++++++++++++++
> arch/powerpc/kernel/entry_64.S | 10 ++++++
> arch/powerpc/kernel/exceptions-64s.S | 12 +++++--
> 3 files changed, 66 insertions(+), 2 deletions(-)
>=20
> diff --git a/arch/powerpc/include/asm/exception-64s.h
> b/arch/powerpc/include/asm/exception-64s.h
> index a86feddddad0..db90b6d7826e 100644
> --- a/arch/powerpc/include/asm/exception-64s.h
> +++ b/arch/powerpc/include/asm/exception-64s.h
> @@ -36,6 +36,7 @@
> */
> #include <asm/head-64.h>
> #include <asm/feature-fixups.h>
> +#include <asm/tm.h>
> =20
> /* PACA save area offsets (exgen, exmc, etc) */
> #define EX_R9 0
> @@ -686,10 +687,54 @@ BEGIN_FTR_SECTION \
> beql ppc64_runlatch_on_trampoline; \
> END_FTR_SECTION_IFSET(CPU_FTR_CTRL)
> =20
> +#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
> +
> +/*
> + * This macro will reclaim a transaction if called when coming from user=
space
> + * (MSR.PR =3D 1) and if the transaction state is active or suspended.
> + *
> + * Since we don't want to reclaim when coming from kernel, for instance =
after
> + * a trechkpt. or a IRQ replay, the live MSR is not useful and instead o=
f it
> the
> + * MSR from thread stack is used to check the MSR.PR bit.
> + * This macro has one argument which is the cause that will be used by
> treclaim.
> + * and returns in r3 '1' if the reclaim happens or '0' if reclaim didn't
> + * happen, which is useful to know what registers were clobbered.
> + *
> + * NOTE: If addition registers are clobbered here, make sure the callee
> + * function restores them before proceeding.
> + */
> +#define TM_KERNEL_ENTRY(cause) =09
> \
> + ld r3, _MSR(r1); \
> + andi. r0, r3, MSR_PR; /* Coming from userspace? */ \
> + beq 1f; /* Skip reclaim if MSR.PR !=3D 1 */ \
> + rldicl. r0, r3, (64-MSR_TM_LG), 63; /* Is TM enabled? */ \
> + beq 1f; /* Skip reclaim if TM is off */ \
> + rldicl. r0, r3, (64-MSR_TS_LG), 62; /* Is active */ \
> + beq 1f; /* Skip reclaim if neither */ \
> + /* \
> + * If there is a transaction active or suspended, save the \
> + * non-volatile GPRs if they are not already saved. \
> + */ \
> + bl save_nvgprs; \
> + /* \
> + * Soft disable the IRQs, otherwise it might cause a CPU hang. \
> + */ \
> + RECONCILE_IRQ_STATE(r10, r11); \
> + li r3, cause; \
> + bl tm_reclaim_current; \
> + li r3, 1; /* Reclaim happened */ \
> + b 2f; \
> +1: li r3, 0; /* Reclaim didn't happen */ \
> +2:
> +#else
> +#define TM_KERNEL_ENTRY(cause)
> +#endif
> +
> #define EXCEPTION_COMMON(area, trap, label, hdlr, ret, additions) \
> EXCEPTION_PROLOG_COMMON(trap, area); \
> /* Volatile regs are potentially clobbered here */ \
> additions; \
> + TM_KERNEL_ENTRY(TM_CAUSE_MISC); \
> addi r3,r1,STACK_FRAME_OVERHEAD; \
> bl hdlr; \
> b ret
> @@ -704,6 +749,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_CTRL)
> EXCEPTION_PROLOG_COMMON_3(trap); \
> /* Volatile regs are potentially clobbered here */ \
> additions; \
> + TM_KERNEL_ENTRY(TM_CAUSE_MISC); \
> addi r3,r1,STACK_FRAME_OVERHEAD; \
> bl hdlr
> =20
> diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_6=
4.S
> index 2206912ea4f0..c38677b7442c 100644
> --- a/arch/powerpc/kernel/entry_64.S
> +++ b/arch/powerpc/kernel/entry_64.S
> @@ -131,6 +131,16 @@ BEGIN_FW_FTR_SECTION
> END_FW_FTR_SECTION_IFSET(FW_FEATURE_SPLPAR)
> #endif /* CONFIG_VIRT_CPU_ACCOUNTING_NATIVE && CONFIG_PPC_SPLPAR */
> =20
> +#if CONFIG_PPC_TRANSACTIONAL_MEM
> + TM_KERNEL_ENTRY(TM_CAUSE_SYSCALL)
> + cmpdi r3, 0x1
> + bne 44f
> + /* Restore from r4 to r12 */
> + REST_8GPRS(4,r1)
> +44: /* treclaim was not called, just restore r3 and r0 */
> + REST_GPR(3, r1)
> + REST_GPR(0, r1)
> +#endif
> /*
> * A syscall should always be called with interrupts enabled
> * so we just unconditionally hard-enable here. When some kind
> diff --git a/arch/powerpc/kernel/exceptions-64s.S
> b/arch/powerpc/kernel/exceptions-64s.S
> index ea04dfb8c092..78aba71a4b2d 100644
> --- a/arch/powerpc/kernel/exceptions-64s.S
> +++ b/arch/powerpc/kernel/exceptions-64s.S
> @@ -805,6 +805,7 @@ EXC_COMMON_BEGIN(alignment_common)
> std r3,_DAR(r1)
> std r4,_DSISR(r1)
> bl save_nvgprs
> + TM_KERNEL_ENTRY(TM_CAUSE_ALIGNMENT)
> RECONCILE_IRQ_STATE(r10, r11)
> addi r3,r1,STACK_FRAME_OVERHEAD
> bl alignment_exception
> @@ -839,6 +840,8 @@ EXC_COMMON_BEGIN(program_check_common)
> b 3f /* Jump into the macro !! */
> 1: EXCEPTION_PROLOG_COMMON(0x700, PACA_EXGEN)
> bl save_nvgprs
> + ld r3, _MSR(r1)
> + TM_KERNEL_ENTRY(TM_CAUSE_FAC_UNAV)
> RECONCILE_IRQ_STATE(r10, r11)
> addi r3,r1,STACK_FRAME_OVERHEAD
> bl program_check_exception
> @@ -1738,7 +1741,9 @@ do_hash_page:
> =20
> /* Here we have a page fault that hash_page can't handle. */
> handle_page_fault:
> -11: andis. r0,r4,DSISR_DABRMATCH@h
> +11: TM_KERNEL_ENTRY(TM_CAUSE_TLBI)
> + ld r4,_DSISR(r1)
> + andis. r0,r4,DSISR_DABRMATCH@h
> bne- handle_dabr_fault
> ld r4,_DAR(r1)
> ld r5,_DSISR(r1)
> @@ -1769,6 +1774,8 @@ handle_dabr_fault:
> */
> 13: bl save_nvgprs
> mr r5,r3
> + TM_KERNEL_ENTRY(TM_CAUSE_TLBI)
> + REST_GPR(3,r1)
> addi r3,r1,STACK_FRAME_OVERHEAD
> ld r4,_DAR(r1)
> bl low_hash_fault
> @@ -1783,7 +1790,8 @@ handle_dabr_fault:
> * the access, or panic if there isn't a handler.
> */
> 77: bl save_nvgprs
> - mr r4,r3
> + TM_KERNEL_ENTRY(TM_CAUSE_TLBI)
> + ld r4,_DAR(r1)
> addi r3,r1,STACK_FRAME_OVERHEAD
> li r5,SIGSEGV
> bl bad_page_fault
^ permalink raw reply
* Re: [RFC PATCH 05/11] powerpc/tm: Function that updates the failure code
From: Michael Neuling @ 2018-09-18 3:27 UTC (permalink / raw)
To: Breno Leitao, linuxppc-dev; +Cc: paulus, gromero, mpe, ldufour
In-Reply-To: <1536781219-13938-6-git-send-email-leitao@debian.org>
On Wed, 2018-09-12 at 16:40 -0300, Breno Leitao wrote:
> Now the transaction reclaims happens very earlier in the trap handler, an=
d
> it is impossible to know precisely, at that early time, what should be se=
t
> as the failure cause for some specific cases, as, if the task will be
> rescheduled, thus, the transaction abort case should be updated from
> TM_CAUSE_MISC to TM_CAUSE_RESCHED, for example.
>=20
> This patch creates a function that will update TEXASR special purpose
> register in the task thread and set the failure code which will be
> moved to the live register afterward.
>=20
> Signed-off-by: Breno Leitao <leitao@debian.org>
> ---
> arch/powerpc/kernel/process.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>=20
> diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.=
c
> index 54fddf03b97a..fe063c0142e3 100644
> --- a/arch/powerpc/kernel/process.c
> +++ b/arch/powerpc/kernel/process.c
> @@ -85,6 +85,7 @@ extern unsigned long _get_SP(void);
> * other paths that we should never reach with suspend disabled.
> */
> bool tm_suspend_disabled __ro_after_init =3D false;
> +static void tm_fix_failure_cause(struct task_struct *task, uint8_t cause=
);
> =20
> static void check_if_tm_restore_required(struct task_struct *tsk)
> {
> @@ -988,6 +989,14 @@ void tm_recheckpoint(struct thread_struct *thread)
> local_irq_restore(flags);
> }
> =20
> +/* Change thread->tm.texasr failure code */
> +static void tm_fix_failure_cause(struct task_struct *task, uint8_t cause=
)
I would just call this tm_change_failure_cause() and drop the comment above=
.
> +{
> + /* Clear the cause first */
> + task->thread.tm_texasr &=3D ~TEXASR_FC;
> + task->thread.tm_texasr |=3D (unsigned long) cause << 56;
56 =3D=3D TEXASR_FC_LG;
> +}
> +
> static inline void tm_recheckpoint_new_task(struct task_struct *new)
> {
> if (!cpu_has_feature(CPU_FTR_TM))
^ permalink raw reply
* [PATCH v2] powerpc/configs: Update skiroot defconfig
From: Joel Stanley @ 2018-09-18 3:36 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Stewart Smith
Disable new features from recent releases, and clean out some other
unused options:
- Enable EXPERT, so we can disable some things
- Disable non-powerpc BPF decoders
- Disable TASKSTATS
- Disable unused syscalls
- Set more things to be modules
- Turn off unused network vendors
- PPC_OF_BOOT_TRAMPOLINE and FB_OF are unused on powernv
- Drop unused Radeon and Matrox GPU drivers
- IPV6 support landed in petitboot
- Bringup related command line powersave=off dropped, switch to quiet
Set CONFIG_I2C_CHARDEV=y as the module is not loaded automatically, and
without this i2cget etc. will fail in the skiroot environment.
This defconfig gets us build coverage of KERNEL_XZ, which was broken in
the 4.19 merge window for powerpc.
Signed-off-by: Joel Stanley <joel@jms.id.au>
---
v2: re-sync with version used in op-build
---
arch/powerpc/configs/skiroot_defconfig | 154 +++++++++++++++++--------
1 file changed, 108 insertions(+), 46 deletions(-)
diff --git a/arch/powerpc/configs/skiroot_defconfig b/arch/powerpc/configs/skiroot_defconfig
index 6bd5e7261335..cfdd08897a06 100644
--- a/arch/powerpc/configs/skiroot_defconfig
+++ b/arch/powerpc/configs/skiroot_defconfig
@@ -3,20 +3,17 @@ CONFIG_ALTIVEC=y
CONFIG_VSX=y
CONFIG_NR_CPUS=2048
CONFIG_CPU_LITTLE_ENDIAN=y
+CONFIG_KERNEL_XZ=y
# CONFIG_SWAP is not set
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
# CONFIG_CROSS_MEMORY_ATTACH is not set
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
-CONFIG_TASKSTATS=y
-CONFIG_TASK_DELAY_ACCT=y
-CONFIG_TASK_XACCT=y
-CONFIG_TASK_IO_ACCOUNTING=y
+# CONFIG_CPU_ISOLATION is not set
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=20
-CONFIG_RELAY=y
CONFIG_BLK_DEV_INITRD=y
# CONFIG_RD_GZIP is not set
# CONFIG_RD_BZIP2 is not set
@@ -24,8 +21,14 @@ CONFIG_BLK_DEV_INITRD=y
# CONFIG_RD_LZO is not set
# CONFIG_RD_LZ4 is not set
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
+CONFIG_EXPERT=y
+# CONFIG_SGETMASK_SYSCALL is not set
+# CONFIG_SYSFS_SYSCALL is not set
+# CONFIG_SHMEM is not set
+# CONFIG_AIO is not set
CONFIG_PERF_EVENTS=y
# CONFIG_COMPAT_BRK is not set
+CONFIG_SLAB_FREELIST_HARDENED=y
CONFIG_JUMP_LABEL=y
CONFIG_STRICT_KERNEL_RWX=y
CONFIG_MODULES=y
@@ -35,7 +38,9 @@ CONFIG_MODULE_SIG_FORCE=y
CONFIG_MODULE_SIG_SHA512=y
CONFIG_PARTITION_ADVANCED=y
# CONFIG_IOSCHED_DEADLINE is not set
+# CONFIG_PPC_VAS is not set
# CONFIG_PPC_PSERIES is not set
+# CONFIG_PPC_OF_BOOT_TRAMPOLINE is not set
CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y
CONFIG_CPU_IDLE=y
CONFIG_HZ_100=y
@@ -48,8 +53,9 @@ CONFIG_NUMA=y
CONFIG_PPC_64K_PAGES=y
CONFIG_SCHED_SMT=y
CONFIG_CMDLINE_BOOL=y
-CONFIG_CMDLINE="console=tty0 console=hvc0 powersave=off"
+CONFIG_CMDLINE="console=tty0 console=hvc0 ipr.fast_reboot=1 quiet"
# CONFIG_SECCOMP is not set
+# CONFIG_PPC_MEM_KEYS is not set
CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_UNIX=y
@@ -60,7 +66,6 @@ CONFIG_SYN_COOKIES=y
# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
# CONFIG_INET_XFRM_MODE_TUNNEL is not set
# CONFIG_INET_XFRM_MODE_BEET is not set
-# CONFIG_IPV6 is not set
CONFIG_DNS_RESOLVER=y
# CONFIG_WIRELESS is not set
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
@@ -73,8 +78,10 @@ CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=65536
CONFIG_VIRTIO_BLK=m
CONFIG_BLK_DEV_NVME=m
-CONFIG_EEPROM_AT24=y
+CONFIG_NVME_MULTIPATH=y
+CONFIG_EEPROM_AT24=m
# CONFIG_CXL is not set
+# CONFIG_OCXL is not set
CONFIG_BLK_DEV_SD=m
CONFIG_BLK_DEV_SR=m
CONFIG_BLK_DEV_SR_VENDOR=y
@@ -85,7 +92,6 @@ CONFIG_SCSI_FC_ATTRS=y
CONFIG_SCSI_CXGB3_ISCSI=m
CONFIG_SCSI_CXGB4_ISCSI=m
CONFIG_SCSI_BNX2_ISCSI=m
-CONFIG_BE2ISCSI=m
CONFIG_SCSI_AACRAID=m
CONFIG_MEGARAID_NEWGEN=y
CONFIG_MEGARAID_MM=m
@@ -102,7 +108,7 @@ CONFIG_SCSI_VIRTIO=m
CONFIG_SCSI_DH=y
CONFIG_SCSI_DH_ALUA=m
CONFIG_ATA=y
-CONFIG_SATA_AHCI=y
+CONFIG_SATA_AHCI=m
# CONFIG_ATA_SFF is not set
CONFIG_MD=y
CONFIG_BLK_DEV_MD=m
@@ -119,25 +125,72 @@ CONFIG_DM_SNAPSHOT=m
CONFIG_DM_MIRROR=m
CONFIG_DM_ZERO=m
CONFIG_DM_MULTIPATH=m
+# CONFIG_NET_VENDOR_3COM is not set
+# CONFIG_NET_VENDOR_ADAPTEC is not set
+# CONFIG_NET_VENDOR_AGERE is not set
+# CONFIG_NET_VENDOR_ALACRITECH is not set
CONFIG_ACENIC=m
CONFIG_ACENIC_OMIT_TIGON_I=y
-CONFIG_TIGON3=y
+# CONFIG_NET_VENDOR_AMAZON is not set
+# CONFIG_NET_VENDOR_AMD is not set
+# CONFIG_NET_VENDOR_AQUANTIA is not set
+# CONFIG_NET_VENDOR_ARC is not set
+# CONFIG_NET_VENDOR_ATHEROS is not set
+CONFIG_TIGON3=m
CONFIG_BNX2X=m
-CONFIG_CHELSIO_T1=y
+# CONFIG_NET_VENDOR_BROCADE is not set
+# CONFIG_NET_CADENCE is not set
+# CONFIG_NET_VENDOR_CAVIUM is not set
+CONFIG_CHELSIO_T1=m
+# CONFIG_NET_VENDOR_CISCO is not set
+# CONFIG_NET_VENDOR_CORTINA is not set
+# CONFIG_NET_VENDOR_DEC is not set
+# CONFIG_NET_VENDOR_DLINK is not set
CONFIG_BE2NET=m
-CONFIG_S2IO=m
-CONFIG_E100=m
+# CONFIG_NET_VENDOR_EZCHIP is not set
+# CONFIG_NET_VENDOR_HP is not set
+# CONFIG_NET_VENDOR_HUAWEI is not set
CONFIG_E1000=m
-CONFIG_E1000E=m
+CONFIG_IGB=m
CONFIG_IXGB=m
CONFIG_IXGBE=m
+CONFIG_I40E=m
+CONFIG_S2IO=m
+# CONFIG_NET_VENDOR_MARVELL is not set
CONFIG_MLX4_EN=m
+# CONFIG_MLX4_CORE_GEN2 is not set
CONFIG_MLX5_CORE=m
-CONFIG_MLX5_CORE_EN=y
+# CONFIG_NET_VENDOR_MICREL is not set
CONFIG_MYRI10GE=m
+# CONFIG_NET_VENDOR_NATSEMI is not set
+# CONFIG_NET_VENDOR_NETRONOME is not set
+# CONFIG_NET_VENDOR_NI is not set
+# CONFIG_NET_VENDOR_NVIDIA is not set
+# CONFIG_NET_VENDOR_OKI is not set
+# CONFIG_NET_PACKET_ENGINE is not set
CONFIG_QLGE=m
CONFIG_NETXEN_NIC=m
+# CONFIG_NET_VENDOR_QUALCOMM is not set
+# CONFIG_NET_VENDOR_RDC is not set
+# CONFIG_NET_VENDOR_REALTEK is not set
+# CONFIG_NET_VENDOR_RENESAS is not set
+# CONFIG_NET_VENDOR_ROCKER is not set
+# CONFIG_NET_VENDOR_SAMSUNG is not set
+# CONFIG_NET_VENDOR_SEEQ is not set
CONFIG_SFC=m
+# CONFIG_NET_VENDOR_SILAN is not set
+# CONFIG_NET_VENDOR_SIS is not set
+# CONFIG_NET_VENDOR_SMSC is not set
+# CONFIG_NET_VENDOR_SOCIONEXT is not set
+# CONFIG_NET_VENDOR_STMICRO is not set
+# CONFIG_NET_VENDOR_SUN is not set
+# CONFIG_NET_VENDOR_SYNOPSYS is not set
+# CONFIG_NET_VENDOR_TEHUTI is not set
+# CONFIG_NET_VENDOR_TI is not set
+# CONFIG_NET_VENDOR_VIA is not set
+# CONFIG_NET_VENDOR_WIZNET is not set
+# CONFIG_NET_VENDOR_XILINX is not set
+CONFIG_PHYLIB=y
# CONFIG_USB_NET_DRIVERS is not set
# CONFIG_WLAN is not set
CONFIG_INPUT_EVDEV=y
@@ -149,39 +202,51 @@ CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_IPMI_HANDLER=y
CONFIG_IPMI_DEVICE_INTERFACE=y
CONFIG_IPMI_POWERNV=y
+CONFIG_IPMI_WATCHDOG=y
CONFIG_HW_RANDOM=y
+CONFIG_TCG_TPM=y
CONFIG_TCG_TIS_I2C_NUVOTON=y
+CONFIG_I2C=y
# CONFIG_I2C_COMPAT is not set
CONFIG_I2C_CHARDEV=y
# CONFIG_I2C_HELPER_AUTO is not set
-CONFIG_DRM=y
-CONFIG_DRM_RADEON=y
+CONFIG_I2C_ALGOBIT=y
+CONFIG_I2C_OPAL=m
+CONFIG_PPS=y
+CONFIG_SENSORS_IBMPOWERNV=m
+CONFIG_DRM=m
CONFIG_DRM_AST=m
+CONFIG_FB=y
CONFIG_FIRMWARE_EDID=y
-CONFIG_FB_MODE_HELPERS=y
-CONFIG_FB_OF=y
-CONFIG_FB_MATROX=y
-CONFIG_FB_MATROX_MILLENIUM=y
-CONFIG_FB_MATROX_MYSTIQUE=y
-CONFIG_FB_MATROX_G=y
-# CONFIG_LCD_CLASS_DEVICE is not set
-# CONFIG_BACKLIGHT_GENERIC is not set
# CONFIG_VGA_CONSOLE is not set
+CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_LOGO=y
# CONFIG_LOGO_LINUX_MONO is not set
# CONFIG_LOGO_LINUX_VGA16 is not set
+CONFIG_HID_GENERIC=m
+CONFIG_HID_A4TECH=y
+CONFIG_HID_BELKIN=y
+CONFIG_HID_CHERRY=y
+CONFIG_HID_CHICONY=y
+CONFIG_HID_CYPRESS=y
+CONFIG_HID_EZKEY=y
+CONFIG_HID_ITE=y
+CONFIG_HID_KENSINGTON=y
+CONFIG_HID_LOGITECH=y
+CONFIG_HID_MICROSOFT=y
+CONFIG_HID_MONTEREY=y
CONFIG_USB_HIDDEV=y
-CONFIG_USB=y
-CONFIG_USB_MON=y
-CONFIG_USB_XHCI_HCD=y
-CONFIG_USB_EHCI_HCD=y
+CONFIG_USB=m
+CONFIG_USB_XHCI_HCD=m
+CONFIG_USB_EHCI_HCD=m
# CONFIG_USB_EHCI_HCD_PPC_OF is not set
-CONFIG_USB_OHCI_HCD=y
-CONFIG_USB_STORAGE=y
+CONFIG_USB_OHCI_HCD=m
+CONFIG_USB_STORAGE=m
CONFIG_RTC_CLASS=y
+CONFIG_RTC_DRV_OPAL=m
CONFIG_RTC_DRV_GENERIC=m
CONFIG_VIRT_DRIVERS=y
-CONFIG_VIRTIO_PCI=y
+CONFIG_VIRTIO_PCI=m
# CONFIG_IOMMU_SUPPORT is not set
CONFIG_EXT4_FS=m
CONFIG_EXT4_FS_POSIX_ACL=y
@@ -195,10 +260,9 @@ CONFIG_UDF_FS=m
CONFIG_MSDOS_FS=m
CONFIG_VFAT_FS=m
CONFIG_PROC_KCORE=y
-CONFIG_TMPFS=y
-CONFIG_TMPFS_POSIX_ACL=y
# CONFIG_MISC_FILESYSTEMS is not set
# CONFIG_NETWORK_FILESYSTEMS is not set
+CONFIG_NLS=y
CONFIG_NLS_DEFAULT="utf8"
CONFIG_NLS_CODEPAGE_437=y
CONFIG_NLS_ASCII=y
@@ -207,26 +271,24 @@ CONFIG_NLS_UTF8=y
CONFIG_CRC16=y
CONFIG_CRC_ITU_T=y
CONFIG_LIBCRC32C=y
+# CONFIG_XZ_DEC_X86 is not set
+# CONFIG_XZ_DEC_IA64 is not set
+# CONFIG_XZ_DEC_ARM is not set
+# CONFIG_XZ_DEC_ARMTHUMB is not set
+# CONFIG_XZ_DEC_SPARC is not set
CONFIG_PRINTK_TIME=y
CONFIG_MAGIC_SYSRQ=y
-CONFIG_DEBUG_KERNEL=y
CONFIG_DEBUG_STACKOVERFLOW=y
CONFIG_SOFTLOCKUP_DETECTOR=y
+CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC=y
CONFIG_HARDLOCKUP_DETECTOR=y
CONFIG_BOOTPARAM_HARDLOCKUP_PANIC=y
-CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC=y
CONFIG_WQ_WATCHDOG=y
-CONFIG_SCHEDSTATS=y
+# CONFIG_SCHED_DEBUG is not set
# CONFIG_FTRACE is not set
+# CONFIG_RUNTIME_TESTING_MENU is not set
CONFIG_XMON=y
CONFIG_XMON_DEFAULT=y
-CONFIG_SECURITY=y
-CONFIG_IMA=y
-CONFIG_EVM=y
+CONFIG_ENCRYPTED_KEYS=y
# CONFIG_CRYPTO_ECHAINIV is not set
-CONFIG_CRYPTO_ECB=y
-CONFIG_CRYPTO_CMAC=y
-CONFIG_CRYPTO_MD4=y
-CONFIG_CRYPTO_ARC4=y
-CONFIG_CRYPTO_DES=y
# CONFIG_CRYPTO_HW is not set
--
2.17.1
^ 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