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 i
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 impleme
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 late
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 11229
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 Piggin
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: kwor
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 a/arch/powerpc/kernel/setup_64.c b
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: smp_send_st
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 debate :)
As a preface,
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;
>
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 semantic
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 acc
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
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
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 descri
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.
>>
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. Depending
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 kern
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 configuration, on POW
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 topo
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,
>
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: Abdul
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
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://
- 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
>> > inde
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
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.
>>
>>
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.
>
> Signed-off-by: Sandipan Das
> ---
>
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
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 JITed
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 n
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 BPF_OB
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 offset
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 ca
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
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? What
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 14
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 allocated keys.
> O
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 AMR
-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:
"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 __init cpu_init_thread_cor
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 thre
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 = of_find_node_by_type(NULL, "cpu");
>> > + if
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 more or less
>> > independent units. Thus when mult
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 patch.
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 byte aligned breakp
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 runni
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, th
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 ++
1 file changed, 2 insertions(+
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 en
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 bran
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
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 f
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 this
form:
Unable to hand
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:
>>> > On Mon, Apr 30, 2018 at 06:44:26
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
> duplicated and it will be good
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 unsigned long:
>>
>> arch/p
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
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 for data at address 0x000
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 a/arch/powerpc/kernel/rtas-proc.c b/arch/powerpc/kernel/rtas-proc.c
index d49063d0b
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 30d6e0a4190d37740e9447e4e4815f06992
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
> +++ b/kernel/futex.c
> @@ -1458
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, access_ok check for
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
[ 329.2
63 matches
Mail list logo
