Just fold the calculation into __phys_to_dma/__dma_to_phys as those are
the only places that should know about it.
Signed-off-by: Christoph Hellwig
Acked-by: Benjamin Herrenschmidt
Tested-by: Christian Zigotzky
---
arch/powerpc/include/asm/dma-direct.h | 8 ++--
arch/powerpc/include/asm/
There is no good reason for this helper, just opencode it.
Signed-off-by: Christoph Hellwig
Tested-by: Christian Zigotzky
---
arch/powerpc/include/asm/dma-mapping.h| 6 --
arch/powerpc/kernel/pci-common.c | 2 +-
arch/powerpc/platforms/cell/iommu.c | 4 ++--
arch/powerpc/
Now that we've switched all the powerpc nommu and swiotlb methods to
use the generic dma_direct_* calls we can remove these ops vectors
entirely and rely on the common direct mapping bypass that avoids
indirect function calls entirely. This also allows to remove a whole
lot of boilerplate code rel
Switch the streaming DMA mapping and ownership transfer methods to the
functionally identical dma_direct_ versions. Factor the cache
maintainance helpers into the form expected by the common code for that.
Signed-off-by: Christoph Hellwig
Tested-by: Christian Zigotzky
---
arch/powerpc/include/
The generic code allows a few nice things such as node local allocations
and dipping into the CMA area. The lookup of the right zone for a given
dma mask works a little different, but the results should be the same.
Signed-off-by: Christoph Hellwig
Tested-by: Christian Zigotzky
---
arch/powerp
The only user left is powerpc, but even there the generic dma-direct
version works just as well, given that we guarantee that the swiotlb
buffer must always be addressable.
Signed-off-by: Christoph Hellwig
Tested-by: Christian Zigotzky
---
arch/powerpc/kernel/dma-swiotlb.c | 2 +-
include/linu
The coherent cache version of this function already is functionally
identicall to the default version, and by defining the
arch_dma_coherent_to_pfn hook the same is ture for the noncoherent
version as well.
Signed-off-by: Christoph Hellwig
Tested-by: Christian Zigotzky
---
arch/powerpc/include/
Use the standard portable helper instead of the powerpc specific one,
which is about to go away.
Signed-off-by: Christoph Hellwig
Acked-by: Benjamin Herrenschmidt
Tested-by: Christian Zigotzky
---
arch/powerpc/kernel/dma.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff
This function is largely identical to the generic version used
everywhere else. Replace it with the generic version.
Signed-off-by: Christoph Hellwig
Tested-by: Christian Zigotzky
---
arch/powerpc/include/asm/dma-mapping.h | 1 -
arch/powerpc/kernel/dma-iommu.c| 2 +-
arch/powerpc/ke
Instead of letting the architecture supply all of dma_set_mask just
give it an additional hook selected by Kconfig.
Signed-off-by: Christoph Hellwig
Tested-by: Christian Zigotzky
---
arch/powerpc/Kconfig | 1 +
arch/powerpc/include/asm/dma-mapping.h | 2 --
arch/powerpc/incl
This function is identical to the generic dma_direct_get_required_mask,
except that the generic version also takes the bus_dma_mask account,
which could lead to incorrect results in the powerpc version.
Signed-off-by: Christoph Hellwig
Tested-by: Christian Zigotzky
---
arch/powerpc/include/asm/
We need to compare the last byte in the dma range and not the one after it
for the bus_dma_mask, just like we do for the regular dma_mask. Fix this
cleanly by merging the two comparisms into one.
Signed-off-by: Christoph Hellwig
Tested-by: Christian Zigotzky
---
arch/powerpc/include/asm/dma-di
The max_direct_dma_addr duplicates the bus_dma_mask field in struct
device. Use the generic field instead.
Signed-off-by: Christoph Hellwig
Tested-by: Christian Zigotzky
---
arch/powerpc/include/asm/device.h | 3 ---
arch/powerpc/include/asm/dma-direct.h | 4 +---
arch/powerpc/kernel/dma
pci_dma_dev_setup_swiotlb is only used by the fsl_pci code, and closely
related to it, so fsl_pci.c seems like a better place for it.
Signed-off-by: Christoph Hellwig
Tested-by: Christian Zigotzky
---
arch/powerpc/include/asm/swiotlb.h | 2 --
arch/powerpc/kernel/dma-swiotlb.c | 11 --
This function is only used by the Cell iommu code, which can keep track
if it is using the iommu internally just as good.
Signed-off-by: Christoph Hellwig
Tested-by: Christian Zigotzky
---
arch/powerpc/include/asm/pci.h | 2 --
arch/powerpc/kernel/pci-common.c| 6 --
arch/powerpc
All iommu capable platforms now always use the iommu code with the
internal bypass, so there is not need for this magic anymore.
Signed-off-by: Christoph Hellwig
Tested-by: Christian Zigotzky
---
arch/powerpc/Kconfig | 4 ---
arch/powerpc/kernel/dma.c | 68 ++--
Unused now.
Signed-off-by: Christoph Hellwig
---
arch/powerpc/include/asm/pci-bridge.h | 2 --
arch/powerpc/kernel/dma.c | 7 ---
2 files changed, 9 deletions(-)
diff --git a/arch/powerpc/include/asm/pci-bridge.h
b/arch/powerpc/include/asm/pci-bridge.h
index 236a7460b6ec..98e8b
Use the generic iommu bypass code instead of overriding set_dma_mask.
Signed-off-by: Christoph Hellwig
---
arch/powerpc/platforms/powernv/pci-ioda.c | 95 ++-
1 file changed, 25 insertions(+), 70 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
b/arch/pow
These devices are not PCIe devices and do not have associated dma map
ops, so this is just dead code.
Signed-off-by: Christoph Hellwig
---
arch/powerpc/platforms/powernv/pci-ioda.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
b/arch/power
This function is completely bogus - the fact that two PCIe devices come
from the same vendor has absolutely nothing to say about the DMA
capabilities and characteristics.
Signed-off-by: Christoph Hellwig
---
arch/powerpc/platforms/powernv/pci-ioda.c | 28 ++-
1 file changed,
Use the generic iommu bypass code instead of overriding set_dma_mask.
Signed-off-by: Christoph Hellwig
---
arch/powerpc/sysdev/dart_iommu.c | 47
1 file changed, 17 insertions(+), 30 deletions(-)
diff --git a/arch/powerpc/sysdev/dart_iommu.c b/arch/powerpc/sysde
The ppc_md and pci_controller_ops methods are unused now and can be
removed. The dma_nommu implementation is generic to the generic one
except for using max_pfn instead of calling into the memblock API,
and all other dma_map_ops instances implement a method of their own.
Signed-off-by: Christoph
If dart_init failed we didn't have a chance to setup dma or controller
ops yet, so there is no point in resetting them.
Signed-off-by: Christoph Hellwig
---
arch/powerpc/sysdev/dart_iommu.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/arch/powerpc/sysdev/dart_i
This gets rid of a lot of clumsy code and finally allows us to mark
dma_iommu_ops const.
Includes fixes from Michael Ellerman.
Signed-off-by: Christoph Hellwig
---
arch/powerpc/include/asm/dma-mapping.h | 2 +-
arch/powerpc/include/asm/iommu.h | 6 ++
arch/powerpc/kernel/dma-iommu.c
Configure the dma settings at device setup time, and stop playing games
with get_pci_dma_ops. This prepares for using the common dma_configure
code later on.
Includes fixes from Michael Ellerman.
Signed-off-by: Christoph Hellwig
---
arch/powerpc/platforms/cell/iommu.c | 24 +++-
Use the generic iommu bypass code instead of overriding set_dma_mask.
Signed-off-by: Christoph Hellwig
---
arch/powerpc/platforms/pseries/iommu.c | 100 +++--
1 file changed, 27 insertions(+), 73 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/iommu.c
b/arch/powerp
Call dma_get_required_mask_pSeriesLP directly instead of dma_iommu_ops
to simply the code a bit.
Signed-off-by: Christoph Hellwig
---
arch/powerpc/platforms/pseries/iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/pseries/iommu.c
b/arch/powerpc/
Add a new iommu_bypass flag to struct dev_archdata so that the dma_iommu
implementation can handle the direct mapping transparently instead of
switiching ops around. Setting of this flag is controlled by new
pci_controller_ops method.
Signed-off-by: Christoph Hellwig
Tested-by: Christian Zigotzk
vio_dma_mapping_ops currently does a lot of indirect calls through
dma_iommu_ops, which not only make the code harder to follow but are
also expensive in the post-spectre world. Unwind the indirect calls
by calling the ppc_iommu_* or iommu_* APIs directly applicable, or
just use the dma_iommu_* me
The pasemi driver never set a DMA mask, and given that the powerpc
DMA mapping routines never check it this worked ok so far. But the
generic dma-direct code which I plan to switch on for powerpc checks
the DMA mask and fails unsupported mapping requests, so we need to
make sure the proper 64-bit
Hi all,
this series switches the powerpc port to use the generic swiotlb and
noncoherent dma ops, and to use more generic code for the coherent
direct mapping, as well as removing a lot of dead code.
As this series is very large and depends on the dma-mapping tree I've
also published a git tree:
If there is no ZONE_DMA32 we might need GFP_DMA to be able to
allocate memory that satisfies a 32-bit DMA mask.
Reported-by: Christian Zigotzky
Signed-off-by: Christoph Hellwig
Tested-by: Christian Zigotzky
---
kernel/dma/direct.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff -
On Wed, Feb 13, 2019 at 3:38 PM Sam Bobroff wrote:
>
> On Fri, Feb 08, 2019 at 02:08:02PM +1100, Oliver O'Halloran wrote:
> > This patch adds a debugfs interface to force scheduling a recovery event.
> > This can be used to recover a specific PE or schedule a "special" recovery
> > even that check
On Wed, Feb 13, 2019 at 02:38:18PM +1100, Alexey Kardashevskiy wrote:
> We store 2 multilevel tables in iommu_table - one for the hardware and
> one with the corresponding userspace addresses. Before allocating
> the tables, the iommu_table_group_ops::get_table_size() hook returns
> the combined si
On Fri, Feb 08, 2019 at 02:08:02PM +1100, Oliver O'Halloran wrote:
> This patch adds a debugfs interface to force scheduling a recovery event.
> This can be used to recover a specific PE or schedule a "special" recovery
> even that checks for errors at the PHB level.
> To force a recovery of a norm
We store 2 multilevel tables in iommu_table - one for the hardware and
one with the corresponding userspace addresses. Before allocating
the tables, the iommu_table_group_ops::get_table_size() hook returns
the combined size of the two and VFIO SPAPR TCE IOMMU driver adjusts
the locked_vm counter co
From: Christophe Leroy
[ Upstream commit fb0bdec51a4901b7dd088de0a1e365e1b9f5cd21 ]
Commit 8c8c10b90d88 ("powerpc/8xx: fix handling of early NULL pointer
dereference") moved the loading of r6 earlier in the code. As some
functions are called inbetween, r6 needs to be loaded again with the
addres
From: Christophe Leroy
[ Upstream commit fb0bdec51a4901b7dd088de0a1e365e1b9f5cd21 ]
Commit 8c8c10b90d88 ("powerpc/8xx: fix handling of early NULL pointer
dereference") moved the loading of r6 earlier in the code. As some
functions are called inbetween, r6 needs to be loaded again with the
addres
From: Wen Yang
[ Upstream commit 8d68100ab4ad92560a16a68b72e068613ac4d573 ]
Currently there are some issues with the ucc_of_parse_tdm function:
1, a possible null pointer dereference in ucc_of_parse_tdm,
detected by the semantic patch deref_null.cocci,
with the following warning:
drivers/soc/fsl
Hi Michal,
I love your patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v5.0-rc4 next-20190212]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux
Hi Daniel,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on vfio/next]
[also build test ERROR on v5.0-rc4]
[cannot apply to next-20190212]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com
Hi Daniel,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on vfio/next]
[also build test ERROR on v5.0-rc4]
[cannot apply to next-20190212]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com
On 13/02/2019 04:18, Daniel Jordan wrote:
> On Tue, Feb 12, 2019 at 04:50:11PM +, Christopher Lameter wrote:
>> On Tue, 12 Feb 2019, Alexey Kardashevskiy wrote:
>>
>>> Now it is 3 independent accesses (actually 4 but the last one is
>>> diagnostic) with no locking around them. Why do not we
On 13/02/2019 05:56, Alex Williamson wrote:
> On Tue, 12 Feb 2019 17:56:18 +1100
> Alexey Kardashevskiy wrote:
>
>> On 12/02/2019 09:44, Daniel Jordan wrote:
>>> Beginning with bc3e53f682d9 ("mm: distinguish between mlocked and pinned
>>> pages"), locked and pinned pages are accounted separate
On Tue, Feb 12, 2019 at 11:41:10AM -0700, Alex Williamson wrote:
> Daniel Jordan wrote:
> > On Mon, Feb 11, 2019 at 03:56:20PM -0700, Jason Gunthorpe wrote:
> > > I haven't looked at this super closely, but how does this stuff work?
> > >
> > > do_mlock doesn't touch pinned_vm, and this doesn't t
On 13/02/2019 07:52, Alex Williamson wrote:
> On Mon, 11 Feb 2019 18:49:17 +1100
> Alexey Kardashevskiy wrote:
>
>> VFIO TCE IOMMU v2 owns IOMMU tables so when detach a IOMMU group from
>> a container, we need to unset those from a group so we call unset_window()
>> so do we unconditionally. W
Hi Michal,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v5.0-rc4 next-20190212]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits
On 12/02/2019 18:33, Alexey Kardashevskiy wrote:
>
>
> On 12/02/2019 11:20, David Gibson wrote:
>> On Mon, Feb 11, 2019 at 06:48:01PM +1100, Alexey Kardashevskiy wrote:
>>> We store 2 multilevel tables in iommu_table - one for the hardware and
>>> one with the corresponding userspace addresses
We were always calling base_hpte_find() with primary = true,
even when we wanted to check the secondary table...
Fixes: 1515ab932156 powerpc/mm: Dump hash table
Signed-off-by: Rashmica Gupta
---
Thanks Paul for spotting this :)
arch/powerpc/mm/dump_hashpagetable.c | 2 +-
1 file changed, 1 in
On 2/11/19 7:42 AM, Benjamin Herrenschmidt wrote:
> On Mon, 2019-02-11 at 13:38 +1100, David Gibson wrote:
>>
>> 1) All in kernel
>>
>> The offset always maps directly to guest irq number and the kernel
>> somehow binds it either to an IPI or a host irq as necessary.
>> Cédric's original code attem
On Sat, 2019-02-09 at 23:14 +, Darren Stevens wrote:
> The disk activity LED on the Cyrus board is attached to a gpio pin,
> add the required device-tree node for the kernel driver to use.
>
> Signed-off-by: Darren Stevens
>
> ---
>
> diff --git a/arch/powerpc/boot/dts/fsl/cyrus_p5020.dts
>
On 02/12/2019 02:58 PM, Linus Torvalds wrote:
> On Mon, Feb 11, 2019 at 11:31 AM Waiman Long wrote:
>> Modify __down_read_trylock() to make it generate slightly better code
>> (smaller and maybe a tiny bit faster).
> This looks good, but I would ask you to try one slightly different approach.
>
>
On Mon, 11 Feb 2019 18:49:17 +1100
Alexey Kardashevskiy wrote:
> VFIO TCE IOMMU v2 owns IOMMU tables so when detach a IOMMU group from
> a container, we need to unset those from a group so we call unset_window()
> so do we unconditionally. We also unset tables when removing a DMA window
Patch lo
On Mon, Feb 11, 2019 at 7:37 AM Christoph Hellwig wrote:
>
> This API is primarily used through DT entries, but two architectures
> and two drivers call it directly. So instead of selecting the config
> symbol for random architectures pull it in implicitly for the actual
> users. Also rename the
On Mon, Feb 11, 2019 at 7:36 AM Christoph Hellwig wrote:
>
> This function is only used in of_reserved_mem.c, and never overridden
> despite the __weak marker.
>
> Signed-off-by: Christoph Hellwig
> ---
> drivers/of/of_reserved_mem.c| 2 +-
> include/linux/of_reserved_mem.h | 7 ---
> 2
On Mon, Feb 11, 2019 at 7:37 AM Christoph Hellwig wrote:
>
> The OF_RESERVED_MEM can be used if we have either CMA or the generic
> declare coherent code built and we support the early flattened DT.
>
> So don't bother making it a user visible options that is selected
> by most configs that fit th
On Mon, Feb 11, 2019 at 11:31 AM Waiman Long wrote:
>
> Modify __down_read_trylock() to make it generate slightly better code
> (smaller and maybe a tiny bit faster).
This looks good, but I would ask you to try one slightly different approach.
Instead of this:
>long tmp = atomic_long_re
Great! I owe you a night worth of beers at a conference or if
you come anywhere near Innsbruck!
On 12 February 2019 at 8:31PM, Christian Zigotzky wrote:
On 12 February 2019 at 4:25PM, Christoph Hellwig wrote:
On Tue, Feb 12, 2019 at 01:42:56PM +0100, Christian Zigotzky wrote:
On 11 February 2019 at 08:38AM, Christoph Hellwig wrote:
On Sun, Feb 10, 2019 at 01:00:20PM +0100, Christian Zigo
On 12 February 2019 at 4:25PM, Christoph Hellwig wrote:
On Tue, Feb 12, 2019 at 01:42:56PM +0100, Christian Zigotzky wrote:
On 11 February 2019 at 08:38AM, Christoph Hellwig wrote:
On Sun, Feb 10, 2019 at 01:00:20PM +0100, Christian Zigotzky wrote:
I tested the whole series today. The kernels
On Tue, 12 Feb 2019 17:56:18 +1100
Alexey Kardashevskiy wrote:
> On 12/02/2019 09:44, Daniel Jordan wrote:
> > Beginning with bc3e53f682d9 ("mm: distinguish between mlocked and pinned
> > pages"), locked and pinned pages are accounted separately. The SPAPR
> > TCE VFIO IOMMU driver accounts pinn
On Mon, 11 Feb 2019 18:11:53 -0500
Daniel Jordan wrote:
> On Mon, Feb 11, 2019 at 03:56:20PM -0700, Jason Gunthorpe wrote:
> > On Mon, Feb 11, 2019 at 05:44:33PM -0500, Daniel Jordan wrote:
> > > @@ -266,24 +267,15 @@ static int vfio_lock_acct(struct vfio_dma *dma,
> > > long npage, bool async
On 02/12/2019 01:36 PM, Waiman Long wrote:
> On 02/12/2019 08:25 AM, Peter Zijlstra wrote:
>> On Tue, Feb 12, 2019 at 02:24:04PM +0100, Peter Zijlstra wrote:
>>> On Mon, Feb 11, 2019 at 02:31:26PM -0500, Waiman Long wrote:
Modify __down_read_trylock() to make it generate slightly better code
>
On 02/12/2019 08:25 AM, Peter Zijlstra wrote:
> On Tue, Feb 12, 2019 at 02:24:04PM +0100, Peter Zijlstra wrote:
>> On Mon, Feb 11, 2019 at 02:31:26PM -0500, Waiman Long wrote:
>>> Modify __down_read_trylock() to make it generate slightly better code
>>> (smaller and maybe a tiny bit faster).
>>>
>>
On Tue, Feb 12, 2019 at 04:50:11PM +, Christopher Lameter wrote:
> On Tue, 12 Feb 2019, Alexey Kardashevskiy wrote:
>
> > Now it is 3 independent accesses (actually 4 but the last one is
> > diagnostic) with no locking around them. Why do not we need a lock
> > anymore precisely? Thanks,
>
>
On Tue, 12 Feb 2019, Alexey Kardashevskiy wrote:
> Now it is 3 independent accesses (actually 4 but the last one is
> diagnostic) with no locking around them. Why do not we need a lock
> anymore precisely? Thanks,
Updating a regular counter is racy and requires a lock. It was converted
to be an a
On Tue, Feb 12, 2019 at 01:42:56PM +0100, Christian Zigotzky wrote:
> On 11 February 2019 at 08:38AM, Christoph Hellwig wrote:
>> On Sun, Feb 10, 2019 at 01:00:20PM +0100, Christian Zigotzky wrote:
>>> I tested the whole series today. The kernels boot and the P.A. Semi
>>> Ethernet works! :-) Thank
On 2/11/19 11:54 AM, Tom Hromatka wrote:
PowerPC experts,
Paul Moore and I are working on the v2.4 release of libseccomp,
and as part of this work I need to update the syscall table for
each architecture.
I have incorporated the new ppc syscall.tbl into libseccomp, but
I am not familiar with th
This patch adds KASAN support for PPC32.
The KASAN shadow area is located between the vmalloc area and the
fixmap area.
KASAN_SHADOW_OFFSET is calculated in asm/kasan.h and extracted
by Makefile prepare rule via asm-offsets.h
Note that on book3s it will only work on the 603 because the other
one
In preparation of KASAN, move early_init() into a separate
file in order to allow deactivation of KASAN for that function.
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/Makefile | 2 +-
arch/powerpc/kernel/early_32.c | 35 +++
arch/powerpc/kernel/setu
In kernel/cputable.c, explicitly use memcpy() in order
to allow GCC to replace it with __memcpy() when KASAN is
selected.
Since commit 400c47d81ca38 ("powerpc32: memset: only use dcbz once cache is
enabled"), memset() can be used before activation of the cache,
so no need to use memset_io() for ze
This serie adds KASAN support to powerpc/32
Tested on nohash/32 (8xx) and book3s/32 (mpc832x ie 603)
Changes in v5:
- Added KASAN_SHADOW_OFFSET in Makefile, otherwise we fallback to KASAN_MINIMAL
and some stuff like stack instrumentation is not performed
- Moved calls to kasan_early_init() in hea
On Tue, Feb 12, 2019 at 02:24:04PM +0100, Peter Zijlstra wrote:
> On Mon, Feb 11, 2019 at 02:31:26PM -0500, Waiman Long wrote:
> > Modify __down_read_trylock() to make it generate slightly better code
> > (smaller and maybe a tiny bit faster).
> >
> > Before this patch, down_read_trylock:
> >
> >
On Mon, Feb 11, 2019 at 02:31:26PM -0500, Waiman Long wrote:
> Modify __down_read_trylock() to make it generate slightly better code
> (smaller and maybe a tiny bit faster).
>
> Before this patch, down_read_trylock:
>
>0x <+0>: callq 0x5
>0x0005 <+5>:
Le 01/02/2019 à 12:51, Christophe Leroy a écrit :
Le 01/02/2019 à 12:10, Michael Ellerman a écrit :
Christophe Leroy writes:
By delaying the setting of MSR_RI, a 1% improvment is optained on
null_syscall selftest on an mpc8321.
Without this patch:
root@vgoippro:~# ./null_syscall
11
On 11 February 2019 at 08:38AM, Christoph Hellwig wrote:
On Sun, Feb 10, 2019 at 01:00:20PM +0100, Christian Zigotzky wrote:
I tested the whole series today. The kernels boot and the P.A. Semi
Ethernet works! :-) Thanks a lot!
I also tested it in a virtual e5500 QEMU machine today. Unfortunatel
On 2/12/19 2:38 PM, Christophe Leroy wrote:
>
>
> Le 12/02/2019 à 02:08, Daniel Axtens a écrit :
>> Andrey Ryabinin writes:
>>
>>>
>>> Christophe, you can specify KASAN_SHADOW_OFFSET either in Kconfig (e.g.
>>> x86_64) or
>>> in Makefile (e.g. arm64). And make early mapping writable, because co
On 2/12/19 4:08 AM, Daniel Axtens wrote:
> Andrey Ryabinin writes:
>
>> On 2/11/19 3:25 PM, Andrey Konovalov wrote:
>>> On Sat, Feb 9, 2019 at 12:55 PM christophe leroy
>>> wrote:
Hi Andrey,
Le 08/02/2019 à 18:40, Andrey Konovalov a écrit :
> On Fri, Feb 8, 2019 at 6:1
Le 12/02/2019 à 02:08, Daniel Axtens a écrit :
Andrey Ryabinin writes:
On 2/11/19 3:25 PM, Andrey Konovalov wrote:
On Sat, Feb 9, 2019 at 12:55 PM christophe leroy
wrote:
Hi Andrey,
Le 08/02/2019 à 18:40, Andrey Konovalov a écrit :
On Fri, Feb 8, 2019 at 6:17 PM Christophe Leroy wrot
On Tue, Feb 12, 2019 at 10:53:41AM +0100, Michal Hocko wrote:
> Hi,
> this has been posted as an RFC previously [1]. There didn't seem to be
> any objections so I am reposting this for inclusion. I have added a
> debugging patch which prints the zonelist setup for each numa node
> for an easier deb
From: Michal Hocko
We have seen several bugs where zonelists have not been initialized
properly and it is not really straightforward to track those bugs down.
One way to help a bit at least is to dump zonelists of each node when
they are (re)initialized.
Signed-off-by: Michal Hocko
---
mm/page
From: Michal Hocko
Pingfan Liu has reported the following splat
[5.772742] BUG: unable to handle kernel paging request at 2088
[5.773618] PGD 0 P4D 0
[5.773618] Oops: [#1] SMP NOPTI
[5.773618] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.20.0-rc1+ #3
[5.773618]
Hi,
this has been posted as an RFC previously [1]. There didn't seem to be
any objections so I am reposting this for inclusion. I have added a
debugging patch which prints the zonelist setup for each numa node
for an easier debugging of a broken zonelist setup.
[1] http://lkml.kernel.org/r/2019011
On Mon, Feb 11, 2019 at 05:36:53PM +0100, Jann Horn wrote:
> The manpage is missing information about the compatibility hack for
> 5-level paging that went in in 4.14, around commit ee00f4a32a76 ("x86/mm:
> Allow userspace have mappings above 47-bit"). Add some information about
> that.
>
> While
84 matches
Mail list logo
