Re: pkeys on POWER: Access rights not reset on execve

On 05/19/2018 03:50 AM, Andy Lutomirski wrote: Now another thread calls pkey_alloc(), so UAMR is asynchronously changed, and the thread will write zero to the relevant AMR bits. If I understand correctly, this means that the decision to mask off unallocated keys via UAMR effectively forces the

Re: [PATCH 1/2] m68k: Set default dma mask for platform devices

On Fri, 18 May 2018, Christoph Hellwig wrote: > > This implementation of arch_setup_pdev_archdata() differs from the > > powerpc one, in that this one avoids clobbering a device dma mask > > which has already been initialized. > > I think your implementation should move into the generic

Re: pkeys on POWER: Default AMR, UAMOR values

On 05/19/2018 02:52 AM, Ram Pai wrote: The POWER semantics make it very hard for a multithreaded program to meaningfully use protection keys to prevent accidental access to important memory. And you can change access rights for unallocated keys (unallocated at thread start time, allocated

Re: pkeys on POWER: Access rights not reset on execve

On 05/19/2018 03:19 AM, Ram Pai wrote: New AMR value (PID 112291, before execl): 0x0c00 AMR (PID 112291): 0x0c00 The issue is here. The second line is after the execl (printed from the start of main), and the AMR value is not reset to zero. Allocated key (PID

[PATCH 3/3] powerpc/64: hard disable irqs on the panic()ing CPU

Similar to previous patches, hard disable interrupts when a CPU is in panic. This reduces the chance the watchdog has to interfere with the panic, and avoids any other type of masked interrupt being executed when crashing which minimises the length of the crash path. Signed-off-by: Nicholas

[PATCH 2/3] powerpc: smp_send_stop do not offline stopped CPUs

Marking CPUs stopped by smp_send_stop as offline can cause warnings due to cross-CPU wakeups. This trace was noticed on a busy system running a sysrq+c crash test, after the injected crash: WARNING: CPU: 51 PID: 1546 at kernel/sched/core.c:1179 set_task_cpu+0x22c/0x240 CPU: 51 PID: 1546 Comm:

[PATCH 1/3] powerpc/64: hard disable irqs in panic_smp_self_stop

Similarly to commit 855bfe0de1 ("powerpc: hard disable irqs in smp_send_stop loop"), irqs should be hard disabled by panic_smp_self_stop. Signed-off-by: Nicholas Piggin --- arch/powerpc/kernel/setup_64.c | 8 1 file changed, 8 insertions(+) diff --git

[PATCH 0/3] further reduce warnings and watchdogs in crash/shutdown paths

Patches 1 and 3 are more of the same, just upgrading local_irq_disable to hard_irq_disable in places. Patch 2 fixes a warning people have been hitting in crash testing on busy systems. Thanks, Nick Nicholas Piggin (3): powerpc/64: hard disable irqs in panic_smp_self_stop powerpc:

Re: pkeys on POWER: Access rights not reset on execve

On Fri, May 18, 2018 at 6:19 PM Ram Pai wrote: > However the fundamental issue is still the same, as mentioned in the > other thread. > "Should the permissions on a key be allowed to be changed, if the key > is not allocated in the first place?". > my answer is NO. Lets

Re: pkeys on POWER: Access rights not reset on execve

On Fri, May 18, 2018 at 04:27:14PM +0200, Florian Weimer wrote: > This test program: > > #include > #include > #include > #include > #include > #include > > /* Return the value of the AMR register. */ > static inline unsigned long int > pkey_read (void) > { > unsigned long int result; >

Re: pkeys on POWER: Default AMR, UAMOR values

On Fri, May 18, 2018 at 11:13:30PM +0200, Florian Weimer wrote: > On 05/18/2018 09:39 PM, Andy Lutomirski wrote: > >The difference is that x86 starts out with deny-all instead of allow-all. Ah!. this explains the discrepency. But still does not explain one thing.. see below. > >The POWER

Re: pkeys on POWER: Default AMR, UAMOR values

On 05/18/2018 09:39 PM, Andy Lutomirski wrote: The difference is that x86 starts out with deny-all instead of allow-all. The POWER semantics make it very hard for a multithreaded program to meaningfully use protection keys to prevent accidental access to important memory. And you can change

Re: pkeys on POWER: Default AMR, UAMOR values

On 05/18/2018 07:44 PM, Ram Pai wrote: Florian, is the behavior on x86 any different? A key allocated in the context off one thread is not meaningful in the context of any other thread. Since thread B was created prior to the creation of the key, and the key was created in the context of thread

Re: [RFC v3 1/4] powerpc/hotplug/drcinfo: Fix bugs parsing ibm,drc-info structs

See below. On 05/18/2018 02:57 PM, Nathan Fontenot wrote: > On 05/17/2018 05:41 PM, Michael Bringmann wrote: >> [Replace/withdraw previous patch submission to ensure that testing >> of related patches on similar hardware progresses together.] >> >> This patch fixes a memory parsing bug when using

Re: [RFC v4 2/3] powerpc migration/cpu: Associativity & cpu changes

On 05/18/2018 02:28 PM, Nathan Fontenot wrote: > On 05/17/2018 05:26 PM, Michael Bringmann wrote: >> powerpc migration/cpu: Now apply changes to the associativity of cpus >> for the topology of LPARS in Post Migration events. Recognize more >> changes to the associativity of memory blocks

Re: [RFC v4 1/3] powerpc migration/drmem: Modify DRMEM code to export more features

See below. On 05/18/2018 02:17 PM, Nathan Fontenot wrote: > On 05/17/2018 05:26 PM, Michael Bringmann wrote: >> powerpc migration/drmem: Export many of the functions of DRMEM to >> parse "ibm,dynamic-memory" and "ibm,dynamic-memory-v2" during >> hotplug operations and for Post Migration events.

Re: [RFC v3 1/4] powerpc/hotplug/drcinfo: Fix bugs parsing ibm,drc-info structs

On 05/17/2018 05:41 PM, Michael Bringmann wrote: > [Replace/withdraw previous patch submission to ensure that testing > of related patches on similar hardware progresses together.] > > This patch fixes a memory parsing bug when using of_prop_next_u32 > calls at the start of a structure.

Re: [PATCH bpf v2 5/6] tools: bpftool: resolve calls without using imm field

On Fri, 18 May 2018 18:20:38 +0530, Sandipan Das wrote: > Currently, we resolve the callee's address for a JITed function > call by using the imm field of the call instruction as an offset > from __bpf_call_base. If bpf_jit_kallsyms is enabled, we further > use this address to get the callee's

Re: pkeys on POWER: Default AMR, UAMOR values

On Fri, May 18, 2018 at 10:45 AM Ram Pai wrote: > On Fri, May 18, 2018 at 03:17:14PM +0200, Florian Weimer wrote: > > I'm working on adding POWER pkeys support to glibc. The coding work > > is done, but I'm faced with some test suite failures. > > > > Unlike the default x86

Re: [RFC v4 2/3] powerpc migration/cpu: Associativity & cpu changes

On 05/17/2018 05:26 PM, Michael Bringmann wrote: > powerpc migration/cpu: Now apply changes to the associativity of cpus > for the topology of LPARS in Post Migration events. Recognize more > changes to the associativity of memory blocks described by the > 'cpu' properties when processing the

Re: [RFC v4 1/3] powerpc migration/drmem: Modify DRMEM code to export more features

On 05/17/2018 05:26 PM, Michael Bringmann wrote: > powerpc migration/drmem: Export many of the functions of DRMEM to > parse "ibm,dynamic-memory" and "ibm,dynamic-memory-v2" during > hotplug operations and for Post Migration events. > > Also modify the DRMEM initialization code to allow it to, >

Re: [PATCH] crypto: reorder paes test lexicographically

On Fri, May 11, 2018 at 09:04:06AM +0100, Gilad Ben-Yossef wrote: > Due to a snafu "paes" testmgr tests were not ordered > lexicographically, which led to boot time warnings. > Reorder the tests as needed. > > Fixes: a794d8d ("crypto: ccree - enable support for hardware keys") > Reported-by:

Re: [PATCH] crypto: nx: fix spelling mistake: "seqeunce" -> "sequence"

On Wed, May 09, 2018 at 10:16:36AM +0100, Colin King wrote: > From: Colin Ian King > > Trivial fix to spelling mistake in CSB_ERR error message text > > Signed-off-by: Colin Ian King Patch applied. Thanks. -- Email: Herbert Xu

Re: [PATCH 07/14] powerpc: Add support for restartable sequences

- On May 17, 2018, at 7:50 PM, Boqun Feng boqun.f...@gmail.com wrote: [...] >> > I think you're right. So we have to introduce callsite to rseq_syscall() >> > in syscall path, something like: >> > >> > diff --git a/arch/powerpc/kernel/entry_64.S >> > b/arch/powerpc/kernel/entry_64.S >> >

Re: pkeys on POWER: Default AMR, UAMOR values

On Fri, May 18, 2018 at 03:17:14PM +0200, Florian Weimer wrote: > I'm working on adding POWER pkeys support to glibc. The coding work > is done, but I'm faced with some test suite failures. > > Unlike the default x86 configuration, on POWER, existing threads > have full access to newly allocated

Re: [PATCH bpf v2 1/6] bpf: support 64-bit offsets for bpf function calls

On 05/18/2018 08:45 PM, Daniel Borkmann wrote: > On 05/18/2018 02:50 PM, Sandipan Das wrote: >> The imm field of a bpf instruction is a signed 32-bit integer. >> For JIT bpf-to-bpf function calls, it stores the offset of the >> start address of the callee's JITed image from __bpf_call_base. >> >>

Re: [PATCH bpf v2 4/6] tools: bpf: sync bpf uapi header

On Fri, May 18, 2018 at 5:50 AM, Sandipan Das wrote: > Syncing the bpf.h uapi header with tools so that struct > bpf_prog_info has the two new fields for passing on the > addresses of the kernel symbols corresponding to each > function in a JITed program. > >

Re: [PATCH bpf v2 2/6] bpf: powerpc64: add JIT support for multi-function programs

On 05/18/2018 06:05 PM, Naveen N. Rao wrote: > Daniel Borkmann wrote: >> On 05/18/2018 02:50 PM, Sandipan Das wrote: >>> This adds support for bpf-to-bpf function calls in the powerpc64 >>> JIT compiler. The JIT compiler converts the bpf call instructions >>> to native branch instructions. After a

Re: [PATCH bpf v2 2/6] bpf: powerpc64: add JIT support for multi-function programs

Daniel Borkmann wrote: On 05/18/2018 02:50 PM, Sandipan Das wrote: This adds support for bpf-to-bpf function calls in the powerpc64 JIT compiler. The JIT compiler converts the bpf call instructions to native branch instructions. After a round of the usual passes, the start addresses of the

Re: [PATCH bpf v2 6/6] bpf: fix JITed dump for multi-function programs via syscall

On 05/18/2018 02:50 PM, Sandipan Das wrote: > Currently, for multi-function programs, we cannot get the JITed > instructions using the bpf system call's BPF_OBJ_GET_INFO_BY_FD > command. Because of this, userspace tools such as bpftool fail > to identify a multi-function program as being JITed or

Re: [PATCH bpf v2 3/6] bpf: get kernel symbol addresses via syscall

On 05/18/2018 02:50 PM, Sandipan Das wrote: > This adds new two new fields to struct bpf_prog_info. For > multi-function programs, these fields can be used to pass > a list of kernel symbol addresses for all functions in a > given program and to userspace using the bpf system call > with the

Re: [PATCH bpf v2 1/6] bpf: support 64-bit offsets for bpf function calls

On 05/18/2018 02:50 PM, Sandipan Das wrote: > The imm field of a bpf instruction is a signed 32-bit integer. > For JIT bpf-to-bpf function calls, it stores the offset of the > start address of the callee's JITed image from __bpf_call_base. > > For some architectures, such as powerpc64, this

Re: [PATCH bpf v2 2/6] bpf: powerpc64: add JIT support for multi-function programs

On 05/18/2018 02:50 PM, Sandipan Das wrote: > This adds support for bpf-to-bpf function calls in the powerpc64 > JIT compiler. The JIT compiler converts the bpf call instructions > to native branch instructions. After a round of the usual passes, > the start addresses of the JITed images for the

Re: [PATCH 0/7] Miscellaneous patches and bug fixes

Uma, > This patch series adds few improvements to the cxlflash driver and it > also contains couple of bug fixes. Applied to 4.18/scsi-queue, thank you! -- Martin K. Petersen Oracle Linux Engineering

Re: [PATCH v2 5/5] powerpc/lib: inline memcmp() for small constant sizes

On Fri, May 18, 2018 at 12:35:48PM +0200, Christophe Leroy wrote: > On 05/17/2018 03:55 PM, Segher Boessenkool wrote: > >On Thu, May 17, 2018 at 12:49:58PM +0200, Christophe Leroy wrote: > >>In my 8xx configuration, I get 208 calls to memcmp() > >Could you show results with a more recent GCC?

[PATCH] powerpc/32: Implement csum_ipv6_magic in assembly

The generic csum_ipv6_magic() generates a pretty bad result : 0: 81 23 00 00 lwz r9,0(r3) 4: 81 03 00 04 lwz r8,4(r3) 8: 7c e7 4a 14 add r7,r7,r9 c: 7d 29 38 10 subfc r9,r9,r7 10: 7d 4a 51 10 subfe r10,r10,r10 14: 7d 27 42

Re: pkeys on POWER: Default AMR, UAMOR values

On Fri, May 18, 2018 at 6:17 AM Florian Weimer wrote: > I'm working on adding POWER pkeys support to glibc. The coding work is > done, but I'm faced with some test suite failures. > Unlike the default x86 configuration, on POWER, existing threads have > full access to newly

pkeys on POWER: Access rights not reset on execve

This test program: #include #include #include #include #include #include /* Return the value of the AMR register. */ static inline unsigned long int pkey_read (void) { unsigned long int result; __asm__ volatile ("mfspr %0, 13" : "=r" (result)); return result; } /* Overwrite the

[GIT PULL] Please pull powerpc/linux.git powerpc-4.17-6 tag

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Linus, Please pull some more powerpc fixes for 4.17: The following changes since commit 6c0a8f6b5a45ac892a763b6299bd3c5324fc5e02: powerpc/pseries: Fix CONFIG_NUMA=n build (2018-05-08 14:59:56 +1000) are available in the git repository at:

Re: [PATCH 1/2] powerpc: Detect the presence of big-core with interleaved threads

"Gautham R. Shenoy" writes: > diff --git a/arch/powerpc/kernel/setup-common.c > b/arch/powerpc/kernel/setup-common.c > index 0af5c11..884dff2 100644 > --- a/arch/powerpc/kernel/setup-common.c > +++ b/arch/powerpc/kernel/setup-common.c > @@ -436,8 +438,56 @@ static void

pkeys on POWER: Default AMR, UAMOR values

I'm working on adding POWER pkeys support to glibc. The coding work is done, but I'm faced with some test suite failures. Unlike the default x86 configuration, on POWER, existing threads have full access to newly allocated keys. Or, more precisely, in this scenario: * Thread A launches

Re: [PATCH 1/2] powerpc: Detect the presence of big-core with interleaved threads

Gautham R Shenoy writes: ... >> > @@ -565,7 +615,16 @@ void __init smp_setup_cpu_maps(void) >> >vdso_data->processorCount = num_present_cpus(); >> > #endif /* CONFIG_PPC64 */ >> > >> > -/* Initialize CPU <=> thread mapping/ >> > + dn =

Re: [PATCH 2/2] powerpc: Enable ASYM_SMT on interleaved big-core systems

Gautham R Shenoy writes: > On Mon, May 14, 2018 at 01:22:07PM +1000, Michael Neuling wrote: >> On Fri, 2018-05-11 at 16:47 +0530, Gautham R. Shenoy wrote: >> > From: "Gautham R. Shenoy" >> > >> > Each of the SMT4 cores forming a fused-core are

[PATCH v2] powerpc/lib: Adjust .balign inside string functions for PPC32

commit 87a156fb18fe1 ("Align hot loops of some string functions") degraded the performance of string functions by adding useless nops A simple benchmark on an 8xx calling 10x a memchr() that matches the first byte runs in 41668 TB ticks before this patch and in 35986 TB ticks after this

Re: [PATCH 2/2] powerpc/ptrace: Fix setting 512B aligned breakpoints with PTRACE_SET_DEBUGREG

Michael Neuling writes: > In this change: > e2a800beac powerpc/hw_brk: Fix off by one error when validating DAWR region > end > > We fixed setting the DAWR end point to its max value via > PPC_PTRACE_SETHWDEBUG. Unfortunately we broke PTRACE_SET_DEBUGREG when > setting a 512

[PATCH bpf v2 6/6] bpf: fix JITed dump for multi-function programs via syscall

Currently, for multi-function programs, we cannot get the JITed instructions using the bpf system call's BPF_OBJ_GET_INFO_BY_FD command. Because of this, userspace tools such as bpftool fail to identify a multi-function program as being JITed or not. With the JIT enabled and the test program

[PATCH bpf v2 5/6] tools: bpftool: resolve calls without using imm field

Currently, we resolve the callee's address for a JITed function call by using the imm field of the call instruction as an offset from __bpf_call_base. If bpf_jit_kallsyms is enabled, we further use this address to get the callee's kernel symbol's name. For some architectures, such as powerpc64,

[PATCH bpf v2 4/6] tools: bpf: sync bpf uapi header

Syncing the bpf.h uapi header with tools so that struct bpf_prog_info has the two new fields for passing on the addresses of the kernel symbols corresponding to each function in a JITed program. Signed-off-by: Sandipan Das --- tools/include/uapi/linux/bpf.h | 2 ++

[PATCH bpf v2 3/6] bpf: get kernel symbol addresses via syscall

This adds new two new fields to struct bpf_prog_info. For multi-function programs, these fields can be used to pass a list of kernel symbol addresses for all functions in a given program and to userspace using the bpf system call with the BPF_OBJ_GET_INFO_BY_FD command. When bpf_jit_kallsyms is

[PATCH bpf v2 2/6] bpf: powerpc64: add JIT support for multi-function programs

This adds support for bpf-to-bpf function calls in the powerpc64 JIT compiler. The JIT compiler converts the bpf call instructions to native branch instructions. After a round of the usual passes, the start addresses of the JITed images for the callee functions are known. Finally, to fixup the

[PATCH bpf v2 1/6] bpf: support 64-bit offsets for bpf function calls

The imm field of a bpf instruction is a signed 32-bit integer. For JIT bpf-to-bpf function calls, it stores the offset of the start address of the callee's JITed image from __bpf_call_base. For some architectures, such as powerpc64, this offset may be as large as 64 bits and cannot be accomodated

[PATCH bpf v2 0/6] bpf: enhancements for multi-function programs

This patch series introduces the following: [1] Support for bpf-to-bpf function calls in the powerpc64 JIT compiler. [2] Provide a way for resolving function calls because of the way JITed images are allocated in powerpc64. [3] Fix to get JITed instruction dumps for multi-function programs

Re: [PATCH-RESEND] cxl: Disable prefault_mode in Radix mode

Le 18/05/2018 à 11:42, Vaibhav Jain a écrit : From: Vaibhav Jain Currently we see a kernel-oops reported on Power-9 while attaching a context to an AFU, with radix-mode and sysfs attr 'prefault_mode' set to anything other than 'none'. The backtrace of the oops is of

Re: [PATCH 07/14] powerpc: Add support for restartable sequences

Mathieu Desnoyers writes: > - On May 16, 2018, at 9:19 PM, Boqun Feng boqun.f...@gmail.com wrote: >> On Wed, May 16, 2018 at 04:13:16PM -0400, Mathieu Desnoyers wrote: >>> - On May 16, 2018, at 12:18 PM, Peter Zijlstra pet...@infradead.org >>> wrote: >>> >

Re: [PATCH v2 00/10] KVM: PPC: reimplement mmio emulation with analyse_instr()

On Mon, May 07, 2018 at 02:20:06PM +0800, wei.guo.si...@gmail.com wrote: > From: Simon Guo > > We already have analyse_instr() which analyzes instructions for the > instruction > type, size, addtional flags, etc. What kvmppc_emulate_loadstore() did is > somehow >

Re: [PATCH 1/3] powerpc/io: Add __raw_writeq_be() __raw_rm_writeq_be()

Samuel Mendoza-Jonas writes: > On Mon, 2018-05-14 at 22:50 +1000, Michael Ellerman wrote: >> Add byte-swapping versions of __raw_writeq() and __raw_rm_writeq(). >> >> This allows us to avoid sparse warnings caused by passing __be64 to >> __raw_writeq(), which takes

Re: [PATCH v2 5/5] powerpc/lib: inline memcmp() for small constant sizes

On 05/17/2018 03:55 PM, Segher Boessenkool wrote: On Thu, May 17, 2018 at 12:49:58PM +0200, Christophe Leroy wrote: In my 8xx configuration, I get 208 calls to memcmp() Within those 208 calls, about half of them have constant sizes, 46 have a size of 8, 17 have a size of 16, only a few have a

[PATCH-RESEND] cxl: Disable prefault_mode in Radix mode

From: Vaibhav Jain Currently we see a kernel-oops reported on Power-9 while attaching a context to an AFU, with radix-mode and sysfs attr 'prefault_mode' set to anything other than 'none'. The backtrace of the oops is of this form: Unable to handle kernel paging request

[PATCH] powerpc: fix spelling mistake: "Discharching" -> "Discharging"

From: Colin Ian King Trivial fix to spelling mistake in battery_charging array Signed-off-by: Colin Ian King --- arch/powerpc/kernel/rtas-proc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Re: [PATCH 4.9 27/33] futex: Remove duplicated code and fix undefined behaviour

On Fri, May 18, 2018 at 10:30:24AM +0200, Jiri Slaby wrote: > On 05/18/2018, 10:16 AM, Greg Kroah-Hartman wrote: > > 4.9-stable review patch. If anyone has any objections, please let me know. > > > > -- > > > > From: Jiri Slaby > > > > commit

Re: [PATCH 4.9 27/33] futex: Remove duplicated code and fix undefined behaviour

On 05/18/2018, 10:16 AM, Greg Kroah-Hartman wrote: > 4.9-stable review patch. If anyone has any objections, please let me know. > > -- > > From: Jiri Slaby > > commit 30d6e0a4190d37740e9447e4e4815f06992dd8c3 upstream. ... > --- a/kernel/futex.c > +++

[PATCH 4.9 27/33] futex: Remove duplicated code and fix undefined behaviour

4.9-stable review patch. If anyone has any objections, please let me know. -- From: Jiri Slaby commit 30d6e0a4190d37740e9447e4e4815f06992dd8c3 upstream. There is code duplicated over all architecture's headers for futex_atomic_op_inuser. Namely op decoding,

[PATCH] powerpc/perf: Remove sched_task function defined for thread-imc

Call trace observed while running perf-fuzzer: [ 329.228068] CPU: 43 PID: 9088 Comm: perf_fuzzer Not tainted 4.13.0-32-generic #35~lp1746225 [ 329.228070] task: c03f776ac900 task.stack: c03f77728000 [ 329.228071] NIP: c0299b70 LR: c02a4534 CTR: c029bb80 [

[PATCH] cxl: Disable prefault_mode in Radix mode

From: Vaibhav Jain On Power-8 the AFU attr prefault_mode tried to improve storage fault performance by prefaulting process segments. However Power-9 radix mode doesn't have Storage-Segments and prefaulting Pages is too fine grained. So this patch updates

Re: [PATCH 1/3] powerpc/io: Add __raw_writeq_be() __raw_rm_writeq_be()

On Mon, 2018-05-14 at 22:50 +1000, Michael Ellerman wrote: > Add byte-swapping versions of __raw_writeq() and __raw_rm_writeq(). > > This allows us to avoid sparse warnings caused by passing __be64 to > __raw_writeq(), which takes unsigned long: > >

Re: [PATCH v4 3/4] powerpc/64: add 32 bytes prechecking before using VMX optimization on memcmp()

Hi Michael, On Fri, May 18, 2018 at 12:13:52AM +1000, Michael Ellerman wrote: > wei.guo.si...@gmail.com writes: > > From: Simon Guo > > > > This patch is based on the previous VMX patch on memcmp(). > > > > To optimize ppc64 memcmp() with VMX instruction, we need to think