Re: [RESEND PATCH v2] powerpc/mce: Fix SLB rebolting during MCE recovery path.

2018-08-22 Thread Michael Ellerman
Mahesh J Salgaonkar writes: > From: Mahesh Salgaonkar > > With the powerpc next commit e7e81847478 (powerpc/mce: Fix SLB rebolting > during MCE recovery path.), That commit description is wrong, I'll fix it up. cheers > the SLB error recovery is broken. The new > change now does not add index

[RESEND PATCH v2] powerpc/mce: Fix SLB rebolting during MCE recovery path.

2018-08-22 Thread Mahesh J Salgaonkar
From: Mahesh Salgaonkar With the powerpc next commit e7e81847478 (powerpc/mce: Fix SLB rebolting during MCE recovery path.), the SLB error recovery is broken. The new change now does not add index value to RB[52-63] that selects the SLB entry while rebolting, instead it assumes that the shadow sa

Re: [PATCH v2] poewrpc/mce: Fix SLB rebolting during MCE recovery path.

2018-08-22 Thread Mahesh Jagannath Salgaonkar
On 08/23/2018 10:26 AM, Mahesh J Salgaonkar wrote: > From: Mahesh Salgaonkar > > With the powrpc next commit e7e81847478 (poewrpc/mce: Fix SLB rebolting > during MCE recovery path.), the SLB error recovery is broken. The new > change now does not add index value to RB[52-63] that selects the SLB

Re: [PATCH 01/20] kernel/dma/direct: take DMA offset into account in dma_direct_supported

2018-08-22 Thread Benjamin Herrenschmidt
On Thu, 2018-08-23 at 07:24 +0200, Christoph Hellwig wrote: > > Well, iommus can have bypass regions, which we also use for > > performance, so we do at dma_set_mask() time "swap" the ops around, and > > in that case, we do want to check the mask against the actual top of > > memory... > > That is

Re: [PATCH 02/20] kernel/dma/direct: refine dma_direct_alloc zone selection

2018-08-22 Thread Christoph Hellwig
On Thu, Aug 23, 2018 at 10:01:45AM +1000, Benjamin Herrenschmidt wrote: > > The general scheme that architectures should implement is: > > > > ZONE_DMA: Any memory below a magic threshold that is lower than > > 32-bit. Only enabled if actually required (usually > > eithe

Re: [PATCH 01/20] kernel/dma/direct: take DMA offset into account in dma_direct_supported

2018-08-22 Thread Christoph Hellwig
On Thu, Aug 23, 2018 at 09:59:18AM +1000, Benjamin Herrenschmidt wrote: > > Yeah, the other platforms that support these devices support ZONE_DMA > > to reliably handle these devices. But there is two other ways the > > current code would actually handle these fine despite the dma_direct > > checks

[PATCH v2] poewrpc/mce: Fix SLB rebolting during MCE recovery path.

2018-08-22 Thread Mahesh J Salgaonkar
From: Mahesh Salgaonkar With the powrpc next commit e7e81847478 (poewrpc/mce: Fix SLB rebolting during MCE recovery path.), the SLB error recovery is broken. The new change now does not add index value to RB[52-63] that selects the SLB entry while rebolting, instead it assumes that the shadow sav

Re: [PATCH] poewrpc/mce: Fix SLB rebolting during MCE recovery path.

2018-08-22 Thread Nicholas Piggin
On Thu, 23 Aug 2018 09:58:31 +0530 Mahesh Jagannath Salgaonkar wrote: > On 08/21/2018 03:57 PM, Nicholas Piggin wrote: > > On Fri, 17 Aug 2018 14:51:47 +0530 > > Mahesh J Salgaonkar wrote: > > > >> From: Mahesh Salgaonkar > >> > >> With the powrpc next commit e7e81847478 (poewrpc/mce: Fix SL

Re: [PATCH] poewrpc/mce: Fix SLB rebolting during MCE recovery path.

2018-08-22 Thread Mahesh Jagannath Salgaonkar
On 08/21/2018 03:57 PM, Nicholas Piggin wrote: > On Fri, 17 Aug 2018 14:51:47 +0530 > Mahesh J Salgaonkar wrote: > >> From: Mahesh Salgaonkar >> >> With the powrpc next commit e7e81847478 (poewrpc/mce: Fix SLB rebolting >> during MCE recovery path.), the SLB error recovery is broken. The >> comm

Re: [PATCH 1/2] macintosh: therm_windtunnel: drop using attach_adapter

2018-08-22 Thread Michael Ellerman
Wolfram Sang writes: > As we now have deferred probing, we can use a custom mechanism and > finally get rid of the legacy interface from the i2c core. > > Signed-off-by: Wolfram Sang > --- > drivers/macintosh/therm_windtunnel.c | 25 +++-- > 1 file changed, 23 insertions(+),

Re: [PATCH 0/2] i2c: remove deprecated attach_adapter callback

2018-08-22 Thread Michael Ellerman
Wolfram Sang writes: > So, I wanted to do this in the next cycle, but Linus seems to want it this > cycle already [1], so here it is: > > Remove the attach_adapter callback from the 2.4 times by converting > the last user to a custom probing mechanism based on deferred probing. We used > this alr

Re: [PATCH] powerpc/xive: Initialize symbol before usage

2018-08-22 Thread Michael Ellerman
Hi Breno, Breno Leitao writes: > Function xive_native_get_ipi() might uses chip_id without it being > initialized. This gives the following error on 'smatch' tool: > > error: uninitialized symbol 'chip_id' Which is correct, it can be used uninitialised. I'm surprised GCC doesn't warn about

Re: Infinite looping observed in __offline_pages

2018-08-22 Thread Aneesh Kumar K.V
On 08/23/2018 12:28 AM, Mike Kravetz wrote: On 08/22/2018 02:30 AM, Aneesh Kumar K.V wrote: commit 2e9d754ac211f2af3731f15df3cd8cd070b4cc54 Author: Aneesh Kumar K.V Date: Tue Aug 21 14:17:55 2018 +0530 mm/hugetlb: filter out hugetlb pages if HUGEPAGE migration is not supported.

Re: DT case sensitivity

2018-08-22 Thread Benjamin Herrenschmidt
On Wed, 2018-08-22 at 20:26 -0500, Rob Herring wrote: > On Wed, Aug 22, 2018 at 8:14 PM Benjamin Herrenschmidt > wrote: > > > > On Wed, 2018-08-22 at 19:47 -0500, Rob Herring wrote: > > > The default DT string handling in the kernel is node names and > > > compatibles are case insensitive and pro

Re: DT case sensitivity

2018-08-22 Thread Rob Herring
On Wed, Aug 22, 2018 at 8:14 PM Benjamin Herrenschmidt wrote: > > On Wed, 2018-08-22 at 19:47 -0500, Rob Herring wrote: > > The default DT string handling in the kernel is node names and > > compatibles are case insensitive and property names are case sensitive > > (Sparc is the the only variation

Re: Odd SIGSEGV issue introduced by commit 6b31d5955cb29 ("mm, oom: fix potential data corruption when oom_reaper races with writer")

2018-08-22 Thread Michael Ellerman
Christophe LEROY writes: > Hello, > > I have an odd issue on my powerpc 8xx board. > > I am running latest 4.14 and get the following SIGSEGV which appears > more or less randomly. > > [9.190354] touch[91]: unhandled signal 11 at 67807b58 nip 777cf114 > lr 777cf100 code 30001 > [ 24.634810

Re: DT case sensitivity

2018-08-22 Thread Benjamin Herrenschmidt
On Wed, 2018-08-22 at 19:47 -0500, Rob Herring wrote: > The default DT string handling in the kernel is node names and > compatibles are case insensitive and property names are case sensitive > (Sparc is the the only variation and is opposite). It seems only PPC > (and perhaps only Power Macs?) nee

DT case sensitivity

2018-08-22 Thread Rob Herring
The default DT string handling in the kernel is node names and compatibles are case insensitive and property names are case sensitive (Sparc is the the only variation and is opposite). It seems only PPC (and perhaps only Power Macs?) needs to support case insensitive comparisons. It was probably a

[PATCH] KVM: PPC: Book3S: Fix guest DMA when guest partially backed by THP pages

2018-08-22 Thread Paul Mackerras
Commit 76fa4975f3ed ("KVM: PPC: Check if IOMMU page is contained in the pinned physical page", 2018-07-17) added some checks to ensure that guest DMA mappings don't attempt to map more than the guest is entitled to access. However, errors in the logic mean that legitimate guest requests to map pag

Re: [PATCH v2] crypto: vmx - Fix sleep-in-atomic bugs

2018-08-22 Thread Marcelo Henrique Cerri
That looks good to me. Maybe Paulo can help testing it. -- Regards, Marcelo On Wed, Aug 22, 2018 at 08:26:31AM +0200, Ondrej Mosnacek wrote: > This patch fixes sleep-in-atomic bugs in AES-CBC and AES-XTS VMX > implementations. The problem is that the blkcipher_* functions should > not be called

Re: [PATCH 02/20] kernel/dma/direct: refine dma_direct_alloc zone selection

2018-08-22 Thread Benjamin Herrenschmidt
On Wed, 2018-08-22 at 08:58 +0200, Christoph Hellwig wrote: > On Thu, Aug 09, 2018 at 09:54:33AM +1000, Benjamin Herrenschmidt wrote: > > On Mon, 2018-07-30 at 18:38 +0200, Christoph Hellwig wrote: > > > We need to take the DMA offset and encryption bit into account when > > > selecting > > > a zo

Re: [PATCH 01/20] kernel/dma/direct: take DMA offset into account in dma_direct_supported

2018-08-22 Thread Benjamin Herrenschmidt
On Wed, 2018-08-22 at 08:53 +0200, Christoph Hellwig wrote: > On Thu, Aug 09, 2018 at 09:44:18AM +1000, Benjamin Herrenschmidt wrote: > > We do have the occasional device with things like 31-bit DMA > > limitation. We know they happens to work because those systems > > can't have enough memory to b

Re: [PATCH 08/20] powerpc/dma: remove the unused dma_nommu_ops export

2018-08-22 Thread Benjamin Herrenschmidt
On Wed, 2018-08-22 at 08:45 +0200, Christoph Hellwig wrote: > On Thu, Aug 09, 2018 at 10:01:16AM +1000, Benjamin Herrenschmidt wrote: > > On Tue, 2018-07-31 at 14:16 +0200, Christoph Hellwig wrote: > > > It turns out cxl actually uses it. So for now skip this patch, > > > although random code in d

Re: [PATCH 10/20] powerpc/dma-noncoherent: don't disable irqs over kmap_atomic

2018-08-22 Thread Benjamin Herrenschmidt
On Wed, 2018-08-22 at 09:02 +0200, Christoph Hellwig wrote: > On Thu, Aug 09, 2018 at 10:27:46AM +1000, Benjamin Herrenschmidt wrote: > > On Mon, 2018-07-30 at 18:38 +0200, Christoph Hellwig wrote: > > > The requirement to disable local irqs over kmap_atomic is long gone, > > > so remove those call

Re: Odd SIGSEGV issue introduced by commit 6b31d5955cb29 ("mm, oom: fix potential data corruption when oom_reaper races with writer")

2018-08-22 Thread Ram Pai
On Wed, Aug 22, 2018 at 10:19:02AM +0200, Christophe LEROY wrote: > > > Le 21/08/2018 à 19:50, Ram Pai a écrit : > >On Tue, Aug 21, 2018 at 04:40:15PM +1000, Michael Ellerman wrote: > >>Christophe LEROY writes: > >>... > >>> > >>>And I bisected its disappearance with commit 99cd1302327a2 ("power

Re: Infinite looping observed in __offline_pages

2018-08-22 Thread Mike Kravetz
On 08/22/2018 02:30 AM, Aneesh Kumar K.V wrote: > commit 2e9d754ac211f2af3731f15df3cd8cd070b4cc54 > Author: Aneesh Kumar K.V > Date: Tue Aug 21 14:17:55 2018 +0530 > > mm/hugetlb: filter out hugetlb pages if HUGEPAGE migration is not > supported. > > When scanning for movable page

[PATCH 1/2] powerpc/mm/books3s: Add new pte bit to mark pte temporarily invalid.

2018-08-22 Thread Aneesh Kumar K.V
When splitting a huge pmd pte, we need to mark the pmd entry invalid. We can do that by clearing _PAGE_PRESENT bit. But then that will be taken as a swap pte. In order to differentiate between the two use a software pte bit when invalidating. For regular pte, due to bd5050e38aec ("powerpc/mm/radix

[PATCH 2/2] powerpc/mm/hash: Only need the Nest MMU workaround for R -> RW transition

2018-08-22 Thread Aneesh Kumar K.V
The Nest MMU workaround is only needed for RW upgrades. Avoid doing that for other pte updates. We also avoid clearing the pte while marking it invalid. This is because other page table walk will find this pte none and can result in unexpected behaviour due to that. Instead we clear _PAGE_PRESENT

Re: [PATCH 2/2] powerpc/mm/hash: Only need the Nest MMU workaround for R -> RW transition

2018-08-22 Thread Aneesh Kumar K.V
On 08/22/2018 10:46 PM, Aneesh Kumar K.V wrote: The Nest MMU workaround is only needed for RW upgrades. Avoid doing that for other pte updates. We also avoid clearing the pte while marking it invalid. This is because other page table walk will find this pte none and can result in unexpected beha

powerpc compile failure: linux/crc32poly.h: No such file or directory

2018-08-22 Thread Meelis Roos
In 4.18 + todays git on 32-bit powerpc: BOOTCC arch/powerpc/boot/decompress.o In file included from arch/powerpc/boot/../../../lib/decompress_unxz.c:233, from arch/powerpc/boot/decompress.c:42: arch/powerpc/boot/../../../lib/xz/xz_crc32.c:18:10: fatal error: linux/crc32poly.h:

Re: [PATCH v11 00/26] Speculative page faults

2018-08-22 Thread Laurent Dufour
On 03/08/2018 08:36, Song, HaiyanX wrote: > Hi Laurent, Hi Haiyan, Sorry for the late answer, I was off a couple of days. > > Thanks for your analysis for the last perf results. > Your mentioned ," the major differences at the head of the perf report is the > 92% testcase which is weirdly not

Re: [PATCH v2 3/4] powerpc/mm: fix a warning when a cache is common to PGD and hugepages

2018-08-22 Thread Aneesh Kumar K.V
On 08/17/2018 04:14 PM, Christophe LEROY wrote: Le 17/08/2018 à 05:32, Aneesh Kumar K.V a écrit : On 08/14/2018 08:24 PM, Christophe Leroy wrote: While implementing TLB miss HW assistance on the 8xx, the following warning was encountered: [  423.732965] WARNING: CPU: 0 PID: 345 at mm/slub.c:

Re: [PATCH v2 3/4] powerpc/mm: fix a warning when a cache is common to PGD and hugepages

2018-08-22 Thread Christophe LEROY
Aneesh, Le 17/08/2018 à 12:44, Christophe LEROY a écrit : Le 17/08/2018 à 05:32, Aneesh Kumar K.V a écrit : On 08/14/2018 08:24 PM, Christophe Leroy wrote: While implementing TLB miss HW assistance on the 8xx, the following warning was encountered: [  423.732965] WARNING: CPU: 0 PID: 345 at

Re: Infinite looping observed in __offline_pages

2018-08-22 Thread Michal Hocko
On Wed 22-08-18 15:00:18, Aneesh Kumar K.V wrote: > > Hi Michal, > > Michal Hocko writes: > > > On Wed 25-07-18 13:11:15, John Allen wrote: > > [...] > >> Does a failure in do_migrate_range indicate that the range is unmigratable > >> and the loop in __offline_pages should terminate and goto fa

Re: [v5] powerpc/topology: Get topology for shared processors at boot

2018-08-22 Thread Michael Ellerman
Srikar Dronamraju writes: > * Michael Ellerman [2018-08-21 20:35:23]: > >> On Fri, 2018-08-17 at 14:54:39 UTC, Srikar Dronamraju wrote: >> > On a shared lpar, Phyp will not update the cpu associativity at boot >> > time. Just after the boot system does recognize itself as a shared lpar and >> > t

Re: [RFC PATCH 1/5] powerpc/64s/hash: convert SLB miss handlers to C

2018-08-22 Thread Michael Ellerman
Nicholas Piggin writes: > On Tue, 21 Aug 2018 16:46:02 +1000 > Michael Ellerman wrote: >> Nicholas Piggin writes: >> > This patch moves SLB miss handlers completely to C, using the standard >> > exception handler macros to set up the stack and branch to C. >> > >> > This can be done because the

Re: Infinite looping observed in __offline_pages

2018-08-22 Thread Aneesh Kumar K.V
Hi Michal, Michal Hocko writes: > On Wed 25-07-18 13:11:15, John Allen wrote: > [...] >> Does a failure in do_migrate_range indicate that the range is unmigratable >> and the loop in __offline_pages should terminate and goto failed_removal? Or >> should we allow a certain number of retrys befo

Patch "net/ethernet/freescale/fman: fix cross-build error" has been added to the 4.4-stable tree

2018-08-22 Thread gregkh
This is a note to let you know that I've just added the patch titled net/ethernet/freescale/fman: fix cross-build error to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is: net-

[PATCH v2] crypto: vmx - Fix sleep-in-atomic bugs

2018-08-22 Thread Ondrej Mosnacek
This patch fixes sleep-in-atomic bugs in AES-CBC and AES-XTS VMX implementations. The problem is that the blkcipher_* functions should not be called in atomic context. The bugs can be reproduced via the AF_ALG interface by trying to encrypt/decrypt sufficiently large buffers (at least 64 KiB) usin

Re: [PATCH] crypto: vmx - Fix sleep-in-atomic bugs

2018-08-22 Thread Ondrej Mosnáček
ut 21. 8. 2018 o 18:41 Marcelo Henrique Cerri napísal(a): > On Tue, Aug 21, 2018 at 05:24:45PM +0200, Ondrej Mosnáček wrote: > > CC: Paulo Flabiano Smorigo , > > linuxppc-dev@lists.ozlabs.org > > > > (Sorry, sent this before reading new e-mails in the thread...) > > > > ut 21. 8. 2018 o 17:18 Ondr

Patch "net/ethernet/freescale/fman: fix cross-build error" has been added to the 4.14-stable tree

2018-08-22 Thread gregkh
This is a note to let you know that I've just added the patch titled net/ethernet/freescale/fman: fix cross-build error to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is: net

Re: Odd SIGSEGV issue introduced by commit 6b31d5955cb29 ("mm, oom: fix potential data corruption when oom_reaper races with writer")

2018-08-22 Thread Christophe LEROY
Le 21/08/2018 à 19:50, Ram Pai a écrit : On Tue, Aug 21, 2018 at 04:40:15PM +1000, Michael Ellerman wrote: Christophe LEROY writes: ... And I bisected its disappearance with commit 99cd1302327a2 ("powerpc: Deliver SEGV signal on pkey violation") Whoa that's weird. Looking at those two

Patch "net/ethernet/freescale/fman: fix cross-build error" has been added to the 4.9-stable tree

2018-08-22 Thread gregkh
This is a note to let you know that I've just added the patch titled net/ethernet/freescale/fman: fix cross-build error to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is: net-

Patch "net/ethernet/freescale/fman: fix cross-build error" has been added to the 4.17-stable tree

2018-08-22 Thread gregkh
This is a note to let you know that I've just added the patch titled net/ethernet/freescale/fman: fix cross-build error to the 4.17-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is: net

Re: [PATCH 17/20] powerpc/dma-swiotlb: use generic swiotlb_dma_ops

2018-08-22 Thread Christoph Hellwig
On Thu, Aug 09, 2018 at 11:57:53AM +1000, Benjamin Herrenschmidt wrote: > Note: We will still need to implement some custom variant of this > for our secure VMs ... > > Basically we'll need to use the existing bounce bufferring as-is but > the condition will be different, it won't be whether the

Re: [PATCH 10/20] powerpc/dma-noncoherent: don't disable irqs over kmap_atomic

2018-08-22 Thread Christoph Hellwig
On Thu, Aug 09, 2018 at 10:27:46AM +1000, Benjamin Herrenschmidt wrote: > On Mon, 2018-07-30 at 18:38 +0200, Christoph Hellwig wrote: > > The requirement to disable local irqs over kmap_atomic is long gone, > > so remove those calls. > > Really ? I'm trying to verify that and getting lost in a mes