Re: [PATCH V2 07/10] powerpc/mm: update PTE frag size

2015-11-27 Thread Aneesh Kumar K.V
"Aneesh Kumar K.V" writes: > "Aneesh Kumar K.V" writes: > >> Now that we don't track 4k subpage information we can use 2K PTE >> fragments. >> >> Signed-off-by: Aneesh Kumar K.V >> --- >>

Re: [PATCH v2 1/5] printk/nmi: Generic solution for safe printk in NMI

2015-11-27 Thread kbuild test robot
Hi Petr, [auto build test ERROR on: powerpc/next] [also build test ERROR on: v4.4-rc2 next-20151127] [cannot apply to: tip/x86/core] url: https://github.com/0day-ci/linux/commits/Petr-Mladek/Cleaning-printk-stuff-in-NMI-context/20151127-191620 base: https://git.kernel.org/pub/scm/linux

[linux-review:Petr-Mladek/Cleaning-printk-stuff-in-NMI-context/20151127-191620] bafdcb831ce105cb7ff2b9e11acfcf3764da11b9 BUILD DONE

2015-11-27 Thread kbuild test robot
https://github.com/0day-ci/linux Petr-Mladek/Cleaning-printk-stuff-in-NMI-context/20151127-191620 bafdcb831ce105cb7ff2b9e11acfcf3764da11b9 printk/nmi: Increase the size of the temporary buffer include/asm-generic/percpu.h:111:2: error: implicit declaration of function 'preempt_disable

Re: [PATCH v2 1/5] printk/nmi: Generic solution for safe printk in NMI

2015-11-27 Thread kbuild test robot
Hi Petr, [auto build test WARNING on powerpc/next] [also build test WARNING on v4.4-rc2 next-20151127] [cannot apply to tip/x86/core] url: https://github.com/0day-ci/linux/commits/Petr-Mladek/Cleaning-printk-stuff-in-NMI-context/20151127-191620 base: https://git.kernel.org/pub/scm/linux

Re: [PATCH v2 1/5] printk/nmi: Generic solution for safe printk in NMI

2015-11-27 Thread Max Filippov
Hi Peter, On Fri, Nov 27, 2015 at 2:09 PM, Petr Mladek wrote: > printk() takes some locks and could not be used a safe way in NMI > context. > > The chance of a deadlock is real especially when printing > stacks from all CPUs. This particular problem has been addressed > on x86

Re: [PATCH] powerpc/cell: Remove the Cell QPACE code.

2015-11-27 Thread Arnd Bergmann
On Thursday 26 November 2015 13:39:09 Thomas Huth wrote: > On 26/11/15 13:09, Michael Ellerman wrote: > > On Thu, 2015-11-26 at 11:47 +0100, Thomas Huth wrote: > > > >> On 26/11/15 01:59, Rashmica Gupta wrote: > > > >>> All users of QPACE have upgraded to QPACE2 so remove the Cell QPACE code. >

Re: [PATCH v2 1/5] printk/nmi: Generic solution for safe printk in NMI

2015-11-27 Thread Petr Mladek
On Fri 2015-11-27 19:49:48, kbuild test robot wrote: > Hi Petr, > > [auto build test WARNING on powerpc/next] > [also build test WARNING on v4.4-rc2 next-20151127] > [cannot apply to tip/x86/core] > > url: > https://github.com/0day-ci/linux/commits/Petr-Mladek/Clea

[PATCH v2 4/5] printk/nmi: Warn when some message has been lost in NMI context

2015-11-27 Thread Petr Mladek
We could not resize the temporary buffer in NMI context. Let's warn if a message is lost. This is rather theoretical. printk() should not be used in NMI. The only sensible use is when we want to print backtrace from all CPUs. The current buffer should be enough for this purpose. Signed-off-by:

[PATCH v2 5/5] printk/nmi: Increase the size of the temporary buffer

2015-11-27 Thread Petr Mladek
Testing has shown that the backtrace sometimes does not fit into the 4kB temporary buffer that is used in NMI context. The warnings are gone when I double the temporary buffer size. Note that this problem existed even in the x86-specific implementation that was added by the commit a9edc8809328

[PATCH v2 1/5] printk/nmi: Generic solution for safe printk in NMI

2015-11-27 Thread Petr Mladek
printk() takes some locks and could not be used a safe way in NMI context. The chance of a deadlock is real especially when printing stacks from all CPUs. This particular problem has been addressed on x86 by the commit a9edc8809328 ("x86/nmi: Perform a safe NMI stack trace on all CPUs"). This

[PATCH v2 3/5] printk/nmi: Try hard to print Oops message in NMI context

2015-11-27 Thread Petr Mladek
Oops messages are important for debugging. We should try hard to get them directly into the ring buffer and print them to the console even in NMI context. This is problematic because the needed locks might already be taken. What we can do, though, is to zap all printk locks. We already do this

[PATCH v2 2/5] printk/nmi: Use IRQ work only when ready

2015-11-27 Thread Petr Mladek
NMIs could happen at any time. This patch makes sure that the safe printk() in NMI will schedule IRQ work only when the related structs are initialized. All pending messages are flushed when the IRQ work is being initialized. Signed-off-by: Petr Mladek --- kernel/printk/nmi.c

[PATCH v2 0/5] Cleaning printk stuff in NMI context

2015-11-27 Thread Petr Mladek
This patch set generalizes the already existing solution for printing NMI messages. The main idea comes from Peter Zijlstra. This second version has only few changes in compare with v1, see below. Peter Zijlstra suggested to improve also handling of the serial console. I looked into tit and it