linux-next: manual merge of the akpm-current tree with the dma-mapping tree

linux-next: manual merge of the akpm-current tree with the dma-mapping tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1274 bytes --]

Hi all,

Today's linux-next merge of the akpm-current tree got a conflict in:

  kernel/dma/remap.c

between commit:

  4b4b077cbd0a ("dma-remap: Avoid de-referencing NULL atomic_pool")

from the dma-mapping tree and commit:

  14de8ba3fa2e ("lib/genalloc.c: rename addr_in_gen_pool to gen_pool_has_addr")

from the akpm-current tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc kernel/dma/remap.c
index 0207e3764d52,2b750f13bc8f..000000000000
--- a/kernel/dma/remap.c
+++ b/kernel/dma/remap.c
@@@ -158,10 -158,7 +158,10 @@@ out
  
  bool dma_in_atomic_pool(void *start, size_t size)
  {
 +	if (unlikely(!atomic_pool))
 +		return false;
 +
- 	return addr_in_gen_pool(atomic_pool, (unsigned long)start, size);
+ 	return gen_pool_has_addr(atomic_pool, (unsigned long)start, size);
  }
  
  void *dma_alloc_from_pool(size_t size, struct page **ret_page, gfp_t flags)

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the akpm-current tree with the dma-mapping tree

[Christoph Hellwig]

On Mon, Jun 17, 2019 at 06:14:39PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the akpm-current tree got a conflict in:
> 
>   kernel/dma/remap.c
> 
> between commit:
> 
>   4b4b077cbd0a ("dma-remap: Avoid de-referencing NULL atomic_pool")
> 
> from the dma-mapping tree and commit:
> 
>   14de8ba3fa2e ("lib/genalloc.c: rename addr_in_gen_pool to gen_pool_has_addr")

I really wish we could drop this pointless rename, and also the export
until we have actual users.

Re: linux-next: manual merge of the akpm-current tree with the dma-mapping tree

[Christoph Hellwig]

On Wed, Sep 16, 2020 at 04:22:03AM +0000, Song Bao Hua (Barry Song) wrote:
> >   c999bd436fe9 ("mm/cma: make number of CMA areas dynamic, remove
> > CONFIG_CMA_AREAS")
> > 
> > from the akpm-current tree.
> 
> I guess this is because Mike's patch was written on top of dma-mapping's next branch.

It wasn't.

> Will it be better to go through Christoph's tree?

I don't think this merge is much of a problem, we'll just need to tell
Linus about it.

RE: linux-next: manual merge of the akpm-current tree with the dma-mapping tree

[Song Bao Hua (Barry Song)]

> -----Original Message-----
> From: Stephen Rothwell [mailto:sfr@canb.auug.org.au]
> Sent: Wednesday, September 16, 2020 4:12 PM
> To: Andrew Morton <akpm@linux-foundation.org>; Christoph Hellwig
> <hch@lst.de>
> Cc: Mike Kravetz <mike.kravetz@oracle.com>; Song Bao Hua (Barry Song)
> <song.bao.hua@hisilicon.com>; Linux Next Mailing List
> <linux-next@vger.kernel.org>; Linux Kernel Mailing List
> <linux-kernel@vger.kernel.org>
> Subject: linux-next: manual merge of the akpm-current tree with the
> dma-mapping tree
> 
> Hi all,
> 
> Today's linux-next merge of the akpm-current tree got a conflict in:
> 
>   mm/Kconfig
> 
> between commit:
> 
>   b7176c261cdb ("dma-contiguous: provide the ability to reserve per-numa
> CMA")
> 
> from the dma-mapping tree and commit:
> 
>   c999bd436fe9 ("mm/cma: make number of CMA areas dynamic, remove
> CONFIG_CMA_AREAS")
> 
> from the akpm-current tree.

I guess this is because Mike's patch was written on top of dma-mapping's next branch.
Will it be better to go through Christoph's tree?
> 
> I fixed it up (I just used the latter version) and can carry the fix as
> necessary. This is now fixed as far as linux-next is concerned, but any
> non trivial conflicts should be mentioned to your upstream maintainer
> when your tree is submitted for merging.  You may also want to consider
> cooperating with the maintainer of the conflicting tree to minimise any
> particularly complex conflicts.
> 
> --
> Cheers,
> Stephen Rothwell

Thanks
Barry

linux-next: manual merge of the akpm-current tree with the dma-mapping tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 790 bytes --]

Hi all,

Today's linux-next merge of the akpm-current tree got a conflict in:

  mm/Kconfig

between commit:

  b7176c261cdb ("dma-contiguous: provide the ability to reserve per-numa CMA")

from the dma-mapping tree and commit:

  c999bd436fe9 ("mm/cma: make number of CMA areas dynamic, remove CONFIG_CMA_AREAS")

from the akpm-current tree.

I fixed it up (I just used the latter version) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the akpm-current tree with the dma-mapping tree

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 531 bytes --]

Hi all,

Today's linux-next merge of the akpm-current tree got a conflict in:

  arch/arm/include/asm/xen/page-coherent.h

between commits:

  bef4d2037d2143a ("xen/arm: consolidate page-coherent.h")
  60d8cd572f655aa ("arm64/xen: fix xen-swiotlb cache flushing")

from the dma-mapping tree and commit:

  46d5fa030cd9225 ("mm: introduce compound_nr()")

from the akpm-current tree.  The former appear to make the latter
redundant so I resolved by dropping the relevant portions of the
commit from the akpm tree.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the akpm-current tree with the dma-mapping tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1265 bytes --]

Hi all,

Today's linux-next merge of the akpm-current tree got a conflict in:

  arch/arm/Kconfig

between commit:

  936376f88ff1 ("arm: select the dma-noncoherent symbols for all swiotlb builds")

from the dma-mapping tree and commit:

  83286f0dcb91 ("arm: use generic mmap top-down layout and brk randomization")

from the akpm-current tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/arm/Kconfig
index dcf46f0e45c2,81b08b027e4e..000000000000
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@@ -7,9 -7,6 +7,8 @@@ config AR
  	select ARCH_HAS_BINFMT_FLAT
  	select ARCH_HAS_DEBUG_VIRTUAL if MMU
  	select ARCH_HAS_DEVMEM_IS_ALLOWED
 +	select ARCH_HAS_DMA_COHERENT_TO_PFN if SWIOTLB
 +	select ARCH_HAS_DMA_MMAP_PGPROT if SWIOTLB
- 	select ARCH_HAS_ELF_RANDOMIZE
  	select ARCH_HAS_FORTIFY_SOURCE
  	select ARCH_HAS_KEEPINITRD
  	select ARCH_HAS_KCOV

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the akpm-current tree with the dma-mapping tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 3129 bytes --]

Hi all,

Today's linux-next merge of the akpm-current tree got a conflict in:

  include/linux/genalloc.h

between commit:

  3334e1dc5d71 ("lib/genalloc: add gen_pool_dma_zalloc() for zeroed DMA allocations")

from the dma-mapping tree and commit:

  1c6b703cba18 ("lib/genalloc: introduce chunk owners")

from the akpm-current tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc include/linux/genalloc.h
index 6c62eeca754f,b0ab64879ccb..000000000000
--- a/include/linux/genalloc.h
+++ b/include/linux/genalloc.h
@@@ -116,13 -124,47 +124,48 @@@ static inline int gen_pool_add(struct g
  	return gen_pool_add_virt(pool, addr, -1, size, nid);
  }
  extern void gen_pool_destroy(struct gen_pool *);
- extern unsigned long gen_pool_alloc(struct gen_pool *, size_t);
- extern unsigned long gen_pool_alloc_algo(struct gen_pool *, size_t,
- 		genpool_algo_t algo, void *data);
+ unsigned long gen_pool_alloc_algo_owner(struct gen_pool *pool, size_t size,
+ 		genpool_algo_t algo, void *data, void **owner);
+ 
+ static inline unsigned long gen_pool_alloc_owner(struct gen_pool *pool,
+ 		size_t size, void **owner)
+ {
+ 	return gen_pool_alloc_algo_owner(pool, size, pool->algo, pool->data,
+ 			owner);
+ }
+ 
+ static inline unsigned long gen_pool_alloc_algo(struct gen_pool *pool,
+ 		size_t size, genpool_algo_t algo, void *data)
+ {
+ 	return gen_pool_alloc_algo_owner(pool, size, algo, data, NULL);
+ }
+ 
+ /**
+  * gen_pool_alloc - allocate special memory from the pool
+  * @pool: pool to allocate from
+  * @size: number of bytes to allocate from the pool
+  *
+  * Allocate the requested number of bytes from the specified pool.
+  * Uses the pool allocation function (with first-fit algorithm by default).
+  * Can not be used in NMI handler on architectures without
+  * NMI-safe cmpxchg implementation.
+  */
+ static inline unsigned long gen_pool_alloc(struct gen_pool *pool, size_t size)
+ {
+ 	return gen_pool_alloc_algo(pool, size, pool->algo, pool->data);
+ }
+ 
  extern void *gen_pool_dma_alloc(struct gen_pool *pool, size_t size,
  		dma_addr_t *dma);
 +void *gen_pool_dma_zalloc(struct gen_pool *pool, size_t size, dma_addr_t *dma);
- extern void gen_pool_free(struct gen_pool *, unsigned long, size_t);
+ extern void gen_pool_free_owner(struct gen_pool *pool, unsigned long addr,
+ 		size_t size, void **owner);
+ static inline void gen_pool_free(struct gen_pool *pool, unsigned long addr,
+                 size_t size)
+ {
+ 	gen_pool_free_owner(pool, addr, size, NULL);
+ }
+ 
  extern void gen_pool_for_each_chunk(struct gen_pool *,
  	void (*)(struct gen_pool *, struct gen_pool_chunk *, void *), void *);
  extern size_t gen_pool_avail(struct gen_pool *);

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the akpm-current tree with the dma-mapping tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1273 bytes --]

Hi all,

Today's linux-next merge of the akpm-current tree got a conflict in:

  arch/hexagon/Kconfig

between commit:

  e0a9317d9004 ("hexagon: use generic dma_noncoherent_ops")

from the dma-mapping tree and commit:

  365c1f4922a4 ("hexagon: switch to NO_BOOTMEM")

from the akpm-current tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/hexagon/Kconfig
index 6cee842a9b44,f7934998913a..000000000000
--- a/arch/hexagon/Kconfig
+++ b/arch/hexagon/Kconfig
@@@ -30,7 -29,9 +30,10 @@@ config HEXAGO
  	select GENERIC_CLOCKEVENTS_BROADCAST
  	select MODULES_USE_ELF_RELA
  	select GENERIC_CPU_DEVICES
 +	select DMA_NONCOHERENT_OPS
+ 	select HAVE_MEMBLOCK
+ 	select ARCH_DISCARD_MEMBLOCK
+ 	select NO_BOOTMEM
  	---help---
  	  Qualcomm Hexagon is a processor architecture designed for high
  	  performance and low power across a wide variety of applications.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the akpm-current tree with the dma-mapping tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1353 bytes --]

Hi Andrew,

Today's linux-next merge of the akpm-current tree got a conflict in:

  arch/sh/Kconfig

between commits:

  86596f0a2833 ("scatterlist: move the NEED_SG_DMA_LENGTH config symbol to lib/Kconfig")
  f616ab59c294 ("dma-mapping: move the NEED_DMA_MAP_STATE config symbol to lib/Kconfig")

from the dma-mapping tree and commit:

  1099dc900e93 ("mm: introduce ARCH_HAS_PTE_SPECIAL")

from the akpm-current tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/sh/Kconfig
index 7d521926041e,a6c75b6806d2..000000000000
--- a/arch/sh/Kconfig
+++ b/arch/sh/Kconfig
@@@ -49,9 -50,7 +49,10 @@@ config SUPER
  	select HAVE_ARCH_AUDITSYSCALL
  	select HAVE_FUTEX_CMPXCHG if FUTEX
  	select HAVE_NMI
 +	select NEED_DMA_MAP_STATE
 +	select NEED_SG_DMA_LENGTH
+ 	select ARCH_HAS_PTE_SPECIAL
 +
  	help
  	  The SuperH is a RISC processor targeted for use in embedded systems
  	  and consumer electronics; it was also used in the Sega Dreamcast

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the akpm-current tree with the dma-mapping tree

[Andrew Morton]

On Tue, 28 Oct 2014 07:54:09 +0100 Marek Szyprowski <m.szyprowski@samsung.com> wrote:

> Hello,
> 
> On 2014-10-28 07:29, Andrew Morton wrote:
> > On Tue, 28 Oct 2014 15:24:44 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> >> Today's linux-next merge of the akpm-current tree got a conflict in
> >> mm/cma.c between commit 16195ddd4ebc ("mm: cma: Ensure that
> >> reservations never cross the low/high mem boundary") from the
> >> dma-mapping tree and commit 2a70e5a78672 ("mm/cma: ake kmemleak ignore
> >> CMA regions") from the akpm-current tree.
> > hm, we have multiple trees altering mm/cma.c?
> >
> > I'm a bit surprised that this series was merged, given that Laurent
> > said he would be sending out a v2...
> 
> v2 of Laurent's patches has been posted on 24th October
> (https://lkml.org/lkml/2014/10/24/207 ), but since I didn't notice them 
> to be taken
> I thought that it would make sense to get them via my tree and send them 
> to Linus
> during the 3.18-rc cycle. If this was not appropriate, I will drop my tree.

I think I got it all sorted out.  Thierry's "mm/cma: make kmemleak
ignore CMA regions" needed a bit of rework - please check.


From: Thierry Reding <treding@nvidia.com>
Subject: mm/cma: make kmemleak ignore CMA regions

kmemleak will add allocations as objects to a pool.  The memory allocated
for each object in this pool is periodically searched for pointers to
other allocated objects.  This only works for memory that is mapped into
the kernel's virtual address space, which happens not to be the case for
most CMA regions.  

Furthermore, CMA regions are typically used to store data transferred to
or from a device and therefore don't contain pointers to other objects.

Without this, the kernel crashes on the first execution of the
scan_gray_list() because it tries to access highmem.  Perhaps a more
appropriate fix would be to reject any object that can't map to a kernel
virtual address?

[akpm@linux-foundation.org: add comment]
[akpm@linux-foundation.org: fix comment, per Catalin]
[sfr@canb.auug.org.au: include linux/io.h for phys_to_virt()]
Signed-off-by: Thierry Reding <treding@nvidia.com>
Cc: Michal Nazarewicz <mina86@mina86.com>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 mm/cma.c |    6 ++++++
 1 file changed, 6 insertions(+)

diff -puN mm/cma.c~mm-cma-make-kmemleak-ignore-cma-regions mm/cma.c
--- a/mm/cma.c~mm-cma-make-kmemleak-ignore-cma-regions
+++ a/mm/cma.c
@@ -33,6 +33,7 @@
 #include <linux/log2.h>
 #include <linux/cma.h>
 #include <linux/highmem.h>
+#include <linux/io.h>
 
 struct cma {
 	unsigned long	base_pfn;
@@ -301,6 +302,11 @@ int __init cma_declare_contiguous(phys_a
 			}
 		}
 
+		/*
+		 * kmemleak scans/reads tracked objects for pointers to other
+		 * objects but this address isn't mapped and accessible
+		 */
+		kmemleak_ignore(phys_to_virt(addr));
 		base = addr;
 	}
 
_

Re: linux-next: manual merge of the akpm-current tree with the dma-mapping tree

[Marek Szyprowski]

Hello,

On 2014-10-28 07:29, Andrew Morton wrote:
> On Tue, 28 Oct 2014 15:24:44 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
>> Today's linux-next merge of the akpm-current tree got a conflict in
>> mm/cma.c between commit 16195ddd4ebc ("mm: cma: Ensure that
>> reservations never cross the low/high mem boundary") from the
>> dma-mapping tree and commit 2a70e5a78672 ("mm/cma: ake kmemleak ignore
>> CMA regions") from the akpm-current tree.
> hm, we have multiple trees altering mm/cma.c?
>
> I'm a bit surprised that this series was merged, given that Laurent
> said he would be sending out a v2...

v2 of Laurent's patches has been posted on 24th October
(https://lkml.org/lkml/2014/10/24/207 ), but since I didn't notice them 
to be taken
I thought that it would make sense to get them via my tree and send them 
to Linus
during the 3.18-rc cycle. If this was not appropriate, I will drop my tree.

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

Re: linux-next: manual merge of the akpm-current tree with the dma-mapping tree

[Andrew Morton]

On Tue, 28 Oct 2014 15:24:44 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Today's linux-next merge of the akpm-current tree got a conflict in
> mm/cma.c between commit 16195ddd4ebc ("mm: cma: Ensure that
> reservations never cross the low/high mem boundary") from the
> dma-mapping tree and commit 2a70e5a78672 ("mm/cma: ake kmemleak ignore
> CMA regions") from the akpm-current tree.

hm, we have multiple trees altering mm/cma.c?

I'm a bit surprised that this series was merged, given that Laurent
said he would be sending out a v2...

linux-next: manual merge of the akpm-current tree with the dma-mapping tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2002 bytes --]

Hi Andrew,

Today's linux-next merge of the akpm-current tree got a conflict in
mm/cma.c between commit 16195ddd4ebc ("mm: cma: Ensure that
reservations never cross the low/high mem boundary") from the
dma-mapping tree and commit 2a70e5a78672 ("mm/cma: ake kmemleak ignore
CMA regions") from the akpm-current tree.

I fixed it up (I think - see below) and can carry the fix as necessary
(no action is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc mm/cma.c
index fde706e1284f,471fcfef043b..000000000000
--- a/mm/cma.c
+++ b/mm/cma.c
@@@ -278,30 -274,20 +278,35 @@@ int __init cma_declare_contiguous(phys_
  			goto err;
  		}
  	} else {
 -		phys_addr_t addr = memblock_alloc_range(size, alignment, base,
 -							limit);
 +		phys_addr_t addr = 0;
 +
 +		/*
 +		 * All pages in the reserved area must come from the same zone.
 +		 * If the requested region crosses the low/high memory boundary,
 +		 * try allocating from high memory first and fall back to low
 +		 * memory in case of failure.
 +		 */
 +		if (base < highmem_start && limit > highmem_start) {
 +			addr = memblock_alloc_range(size, alignment,
 +						    highmem_start, limit);
 +			limit = highmem_start;
 +		}
 +
  		if (!addr) {
 -			ret = -ENOMEM;
 -			goto err;
 -		} else {
 -			/*
 -			 * kmemleak scans/reads tracked objects for pointers to
 -			 * other objects but this address isn't mapped and
 -			 * accessible
 -			 */
 -			kmemleak_ignore(phys_to_virt(addr));
 -			base = addr;
 +			addr = memblock_alloc_range(size, alignment, base,
 +						    limit);
 +			if (!addr) {
 +				ret = -ENOMEM;
 +				goto err;
 +			}
  		}
- 
++		/*
++		 * kmemleak scans/reads tracked objects for pointers to
++		 * other objects but this address isn't mapped and
++		 * accessible
++		 */
++		kmemleak_ignore(phys_to_virt(addr));
 +		base = addr;
  	}
  
  	ret = cma_init_reserved_mem(base, size, order_per_bit, res_cma);

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]