Re: Widespread crashes in -next, bisected to 'mm: drop HASH_ADAPT'

Guenter Roeck writes: > Hi, > > my qemu tests of next-20170519 show the following results: > total: 122 pass: 30 fail: 92 > > I won't bother listing all of the failures; they are available at > http://kerneltests.org/builders. I bisected one (openrisc, because > it

Re: [PATCH] powerpc/64: Use tick accounting by default

Hi Michael, > > ppc64 is the only architecture that turns on > > VIRT_CPU_ACCOUNTING_NATIVE by default. The overhead of this option > > is extremely high - a context switch microbenchmark using > > sched_yield() is almost 20% slower. > > Running on what? It should all be nop'ed out unless

Re: [PATCH] powerpc/64: Use tick accounting by default

On Mon, 22 May 2017 14:15:57 +1000 Michael Ellerman wrote: > Anton Blanchard writes: > > > From: Anton Blanchard > > > > ppc64 is the only architecture that turns on VIRT_CPU_ACCOUNTING_NATIVE > > by default. The overhead of this option

Re: [PATCH 2/2] powerpc: Make feature-fixup tests fortify-safe

On 22/05/17 11:32, Daniel Axtens wrote: Testing the fortified string functions[1] would cause a kernel panic on boot in test_feature_fixups() due to a buffer overflow in memcmp. This boils down to things like this: extern unsigned int ftr_fixup_test1; extern unsigned int

Re: [PATCH 1/2] powerpc: Don't fortify prom_init

On 22/05/17 11:32, Daniel Axtens wrote: prom_init is a bit special; in theory it should be able to be linked separately to the kernel. To keep this from getting too complex, the symbols that prom_init.c uses are checked. Fortification adds symbols, and it gets quite messy as it includes things

Re: [PATCH] KVM: PPC: hypervisor large decrementer support

Just FYI, this was written over a year ago and never tested since it pre-dated KVM support on P9. It's possible the real mode KVM bits have grown an extra decremented usages since then. If so they will probably need updating to use the GET_DEC() macro. On Mon, May 22, 2017 at 1:55 PM, Oliver

Re: [PATCH] powerpc/64: Use tick accounting by default

Anton Blanchard writes: > From: Anton Blanchard > > ppc64 is the only architecture that turns on VIRT_CPU_ACCOUNTING_NATIVE > by default. The overhead of this option is extremely high - a context > switch microbenchmark using sched_yield() is almost 20%

Re: [RFC][PATCH] powerpc/64s: stop using r14 register

Nicholas Piggin writes: > On Mon, 22 May 2017 08:09:19 +1000 > Benjamin Herrenschmidt wrote: > >> On Mon, 2017-05-22 at 00:00 +1000, Nicholas Piggin wrote: >> > I'd like to take over the r14 register for use as a per-cpu kernel >> > register similar to the

[PATCH] KVM: PPC: hypervisor large decrementer support

Power ISAv3 extends the width of the decrementer register from 32 bits. The enlarged register width is implementation dependent, but reads from these registers are automatically sign extended to produce a 64 bit output when operating in large mode. The HDEC always operates in large mode while the

[PATCH 0/2] powerpc: fortify support

This series provides arch-specific support for Daniel Micay's fortified string functions on powerpc. Fortified string functions provied some compile and run time bounds checking on commonly used string functions. It's cool - currently it picks up a lot of random things so it will require some

[PATCH 2/2] powerpc: Make feature-fixup tests fortify-safe

Testing the fortified string functions[1] would cause a kernel panic on boot in test_feature_fixups() due to a buffer overflow in memcmp. This boils down to things like this: extern unsigned int ftr_fixup_test1; extern unsigned int ftr_fixup_test1_orig; check(memcmp(_fixup_test1,

[PATCH 1/2] powerpc: Don't fortify prom_init

prom_init is a bit special; in theory it should be able to be linked separately to the kernel. To keep this from getting too complex, the symbols that prom_init.c uses are checked. Fortification adds symbols, and it gets quite messy as it includes things like panic(). So just don't fortify

Re: [RFC][PATCH] powerpc/64s: stop using r14 register

On Mon, 22 May 2017 08:09:19 +1000 Benjamin Herrenschmidt wrote: > On Mon, 2017-05-22 at 00:00 +1000, Nicholas Piggin wrote: > > I'd like to take over the r14 register for use as a per-cpu kernel > > register similar to the way r13 is used for the paca. > > Why not use r13

Re: [PATCH] powerpc: add PPC_FEATURE userspace bits for SCV and DARN instructions

On Sat, 2017-05-20 at 14:29 +1000, Nicholas Piggin wrote: > Providing "scv" support to userspace requires kernel support, so it > must be advertised as independently to the base ISA 3 instruction set. > > The darn instruction relies on firmware enablement, so it has been > decided to split this

Re: [RFC][PATCH] powerpc/64s: stop using r14 register

On Mon, 2017-05-22 at 00:00 +1000, Nicholas Piggin wrote: > I'd like to take over the r14 register for use as a per-cpu kernel > register similar to the way r13 is used for the paca. Why not use r13 instead ? We don't need to access the PACA that often from C code, I thought we could flip them...

Re: [PATCH 2/9] timers: provide a "modern" variant of timers

On Sun, May 21, 2017 at 07:57:53PM +0200, Thomas Gleixner wrote: > On Thu, 18 May 2017, Christoph Hellwig wrote: > > On Thu, May 18, 2017 at 10:24:48AM +0200, Christoph Hellwig wrote: > > > > b) give the union a name (breaks any reference to timer_list->func in C > > > > code): > > > > > > > >

Re: RFC: better timer interface

On Sun, 21 May 2017, Thomas Gleixner wrote: > On Tue, 16 May 2017, Arnd Bergmann wrote: > > On Tue, May 16, 2017 at 5:51 PM, Christoph Hellwig wrote: > > > Yes, that sounds useful to me as well. As you said it's an independent > > > but somewhat related change. I can add it to my

Re: [PATCH 2/9] timers: provide a "modern" variant of timers

On Thu, 18 May 2017, Christoph Hellwig wrote: > On Thu, May 18, 2017 at 10:24:48AM +0200, Christoph Hellwig wrote: > > > b) give the union a name (breaks any reference to timer_list->func in C > > > code): > > > > > > + union { > > > + void(*func)(struct

Re: [PATCH net-next v2] ibmveth: Support to enable LSO/CSO for Trunk VEA.

From: Sivakumar Krishnasamy Date: Fri, 19 May 2017 05:30:38 -0400 ... > Signed-off-by: Sivakumar Krishnasamy Applied, thanks for the more detailed commit message.

Re: RFC: better timer interface

On Tue, 16 May 2017, Arnd Bergmann wrote: > On Tue, May 16, 2017 at 5:51 PM, Christoph Hellwig wrote: > > Yes, that sounds useful to me as well. As you said it's an independent > > but somewhat related change. I can add it to my series, but I'll > > need a suggestions for a good

[RFC][PATCH] powerpc/64s: stop using r14 register

I'd like to take over the r14 register for use as a per-cpu kernel register similar to the way r13 is used for the paca. r14 being the last non-volatile register gcc allocates, appears with about 0.5% the frequency as r31 in (static) instructions. I haven't counted dynamically how many extra

[PATCH 9/9] powerpc/64s: paca EX_CTR is not used with !RELOCATABLE, remove it

Signed-off-by: Nicholas Piggin --- arch/powerpc/include/asm/exception-64s.h | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/include/asm/exception-64s.h b/arch/powerpc/include/asm/exception-64s.h index aaee57f0e5ad..3b768cb668e7 100644 ---

[PATCH 8/9] powerpc/64s: paca EX_R3 can be merged with EX_DAR

EX_R3 is used only for a small section of the bad stack handler. Merge it with EX_DAR. Signed-off-by: Nicholas Piggin --- arch/powerpc/include/asm/exception-64s.h | 16 +++- 1 file changed, 11 insertions(+), 5 deletions(-) diff --git

[PATCH 7/9] powerpc/64s: paca EX_LR can be merged with EX_DAR

EX_LR is used only for a small section of the SLB miss handler. Merge it with EX_DAR. Signed-off-by: Nicholas Piggin --- arch/powerpc/include/asm/exception-64s.h | 17 - 1 file changed, 12 insertions(+), 5 deletions(-) diff --git

[PATCH 6/9] powerpc/64s: paca EX_SRR0 is unused, remove it

Signed-off-by: Nicholas Piggin --- arch/powerpc/include/asm/exception-64s.h | 21 ++--- 1 file changed, 10 insertions(+), 11 deletions(-) diff --git a/arch/powerpc/include/asm/exception-64s.h b/arch/powerpc/include/asm/exception-64s.h index

[PATCH 5/9] powerpc/64s: paca add EX_SIZE definition for exception save areas

Signed-off-by: Nicholas Piggin --- arch/powerpc/include/asm/exception-64s.h | 30 +++--- arch/powerpc/include/asm/paca.h | 12 2 files changed, 27 insertions(+), 15 deletions(-) diff --git

[PATCH 4/9] powerpc/64s: SLB miss handler avoid r3 save/restore

The SLB miss handler uses r3 for the faulting address but r12 is mostly able to be freed up to save r3 in. It just requires SRR1 be reloaded again on error. It would be more conventional to use r12 for SRR1 (and use r11 to save r3), but slb_allocate_realmode clobbers r11 and not r12.

[PATCH 3/9] powerpc/64s: SLB miss already has CTR saved for relocatable kernel

The EXCEPTION_PROLOG_1 used by SLB miss already saves CTR when the kernel is built with CONFIG_RELOCATABLE. So it does not have to be saved and reloaded when branching to slb_miss_realmode. It can be restored from the PACA as usual. Signed-off-by: Nicholas Piggin ---

[PATCH 2/9] powerpc/64s: SLB miss handler avoid saving faulting address into EX_DAR

The EX_DAR save area is only used in exceptional cases. With r3 no longer clobbered by slb_allocate_realmode, saving faulting address to EX_DAR can be deferred to those cases. Signed-off-by: Nicholas Piggin --- arch/powerpc/kernel/exceptions-64s.S | 13 - 1 file

[PATCH 1/9] powerpc/64s: slb_allocate_realmode() preserve r3

One fewer registers clobbered by this function means the SLB miss handler can save one fewer. Signed-off-by: Nicholas Piggin --- arch/powerpc/mm/slb_low.S | 24 ++-- 1 file changed, 14 insertions(+), 10 deletions(-) diff --git a/arch/powerpc/mm/slb_low.S

[PATCH 0/9] Reduce PACA save areas

I want to save another register in the PACA, so I had a look at what we might cut from it first. 3-4 fields are reasonably easy to remove. Nicholas Piggin (9): powerpc/64s: slb_allocate_realmode() preserve r3 powerpc/64s: SLB miss handler avoid saving faulting address into EX_DAR

Re: [PATCH 2/9] timers: provide a "modern" variant of timers

On Sun, May 21, 2017 at 9:00 AM, Christoph Hellwig wrote: > On Thu, May 18, 2017 at 10:57:31AM +0200, Arnd Bergmann wrote: >> How expensive would it be to add another field to timer_list and >> just have both pointers? > > That would add 4/8 bytes to every structure containing a

Re: [PATCH 2/9] timers: provide a "modern" variant of timers

On Thu, May 18, 2017 at 10:57:31AM +0200, Arnd Bergmann wrote: > How expensive would it be to add another field to timer_list and > just have both pointers? That would add 4/8 bytes to every structure containing a timer, so I'd rather avoid it if possible. But one option might be to inflict this

Re: [PATCH 2/9] timers: provide a "modern" variant of timers

On Fri, May 19, 2017 at 10:48:51AM +, David Laight wrote: > From: Christoph Hellwig > > Sent: 16 May 2017 12:48 > > > > The new callback gets a pointer to the timer_list itself, which can > > then be used to get the containing structure using container_of > > instead of casting from and to