linux-next.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* linux-next: manual merge of the akpm-current tree with the hmm tree
@ 2019-07-04 10:01 Stephen Rothwell
  2019-07-04 12:42 ` Jason Gunthorpe
  0 siblings, 1 reply; 17+ messages in thread
From: Stephen Rothwell @ 2019-07-04 10:01 UTC (permalink / raw)
  To: Andrew Morton, Jason Gunthorpe
  Cc: Linux Next Mailing List, Linux Kernel Mailing List,
	Christoph Hellwig, Pavel Tatashin

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

Hi all,

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

  drivers/dax/dax-private.h

between commit:

  ea31d5859f58 ("device-dax: use the dev_pagemap internal refcount")

from the hmm tree and commit:

  420a0854e8f2 ("device-dax: "Hotremove" persistent memory that is used like normal RAM")

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 drivers/dax/dax-private.h
index c915889d1769,9ee659ed5566..000000000000
--- a/drivers/dax/dax-private.h
+++ b/drivers/dax/dax-private.h
@@@ -43,6 -43,9 +43,7 @@@ struct dax_region 
   * @target_node: effective numa node if dev_dax memory range is onlined
   * @dev - device core
   * @pgmap - pgmap for memmap setup / lifetime (driver owned)
 - * @ref: pgmap reference count (driver owned)
 - * @cmp: @ref final put completion (driver owned)
+  * @dax_mem_res: physical address range of hotadded DAX memory
   */
  struct dev_dax {
  	struct dax_region *region;
@@@ -50,6 -53,9 +51,7 @@@
  	int target_node;
  	struct device dev;
  	struct dev_pagemap pgmap;
 -	struct percpu_ref ref;
 -	struct completion cmp;
+ 	struct resource *dax_kmem_res;
  };
  
  static inline struct dev_dax *to_dev_dax(struct device *dev)

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

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the hmm tree
  2019-07-04 10:01 linux-next: manual merge of the akpm-current tree with the hmm tree Stephen Rothwell
@ 2019-07-04 12:42 ` Jason Gunthorpe
  0 siblings, 0 replies; 17+ messages in thread
From: Jason Gunthorpe @ 2019-07-04 12:42 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Linux Next Mailing List,
	Linux Kernel Mailing List, Christoph Hellwig, Pavel Tatashin

On Thu, Jul 04, 2019 at 08:01:39PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the akpm-current tree got a conflict in:
> 
>   drivers/dax/dax-private.h
> 
> between commit:
> 
>   ea31d5859f58 ("device-dax: use the dev_pagemap internal refcount")
> 
> from the hmm tree and commit:
> 
>   420a0854e8f2 ("device-dax: "Hotremove" persistent memory that is used like normal RAM")
> 
> 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 drivers/dax/dax-private.h
> index c915889d1769,9ee659ed5566..000000000000
> --- a/drivers/dax/dax-private.h
> +++ b/drivers/dax/dax-private.h
> @@@ -43,6 -43,9 +43,7 @@@ struct dax_region 
>    * @target_node: effective numa node if dev_dax memory range is onlined
>    * @dev - device core
>    * @pgmap - pgmap for memmap setup / lifetime (driver owned)
>  - * @ref: pgmap reference count (driver owned)
>  - * @cmp: @ref final put completion (driver owned)
> +  * @dax_mem_res: physical address range of hotadded DAX memory
>    */
>   struct dev_dax {
>   	struct dax_region *region;
> @@@ -50,6 -53,9 +51,7 @@@
>   	int target_node;
>   	struct device dev;
>   	struct dev_pagemap pgmap;
>  -	struct percpu_ref ref;
>  -	struct completion cmp;
> + 	struct resource *dax_kmem_res;
>   };
>   
>   static inline struct dev_dax *to_dev_dax(struct device *dev)

Looks OK to me, thanks

Jason

^ permalink raw reply	[flat|nested] 17+ messages in thread

* linux-next: manual merge of the akpm-current tree with the hmm tree
@ 2020-05-08 10:22 Stephen Rothwell
  0 siblings, 0 replies; 17+ messages in thread
From: Stephen Rothwell @ 2020-05-08 10:22 UTC (permalink / raw)
  To: Andrew Morton, Jason Gunthorpe
  Cc: Linux Next Mailing List, Linux Kernel Mailing List,
	Ralph Campbell, Sandipan Das

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

Hi all,

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

  tools/testing/selftests/vm/Makefile

between commit:

  b0d449922eb8 ("mm/hmm/test: add selftests for HMM")

from the hmm tree and commit:

  3a07caa68f66 ("selftests: vm: pkeys: fix multilib builds for x86")

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 tools/testing/selftests/vm/Makefile
index c6eb5305a0f6,d7eae41be628..000000000000
--- a/tools/testing/selftests/vm/Makefile
+++ b/tools/testing/selftests/vm/Makefile
@@@ -34,8 -58,55 +59,57 @@@ TEST_FILES := test_vmalloc.s
  KSFT_KHDR_INSTALL := 1
  include ../lib.mk
  
+ ifeq ($(ARCH),x86_64)
+ BINARIES_32 := $(patsubst %,$(OUTPUT)/%,$(BINARIES_32))
+ BINARIES_64 := $(patsubst %,$(OUTPUT)/%,$(BINARIES_64))
+ 
+ define gen-target-rule-32
+ $(1) $(1)_32: $(OUTPUT)/$(1)_32
+ .PHONY: $(1) $(1)_32
+ endef
+ 
+ define gen-target-rule-64
+ $(1) $(1)_64: $(OUTPUT)/$(1)_64
+ .PHONY: $(1) $(1)_64
+ endef
+ 
+ ifeq ($(CAN_BUILD_I386),1)
+ $(BINARIES_32): CFLAGS += -m32
+ $(BINARIES_32): LDLIBS += -lrt -ldl -lm
+ $(BINARIES_32): %_32: %.c
+ 	$(CC) $(CFLAGS) $(EXTRA_CFLAGS) $(notdir $^) $(LDLIBS) -o $@
+ $(foreach t,$(TARGETS),$(eval $(call gen-target-rule-32,$(t))))
+ endif
+ 
+ ifeq ($(CAN_BUILD_X86_64),1)
+ $(BINARIES_64): CFLAGS += -m64
+ $(BINARIES_64): LDLIBS += -lrt -ldl
+ $(BINARIES_64): %_64: %.c
+ 	$(CC) $(CFLAGS) $(EXTRA_CFLAGS) $(notdir $^) $(LDLIBS) -o $@
+ $(foreach t,$(TARGETS),$(eval $(call gen-target-rule-64,$(t))))
+ endif
+ 
+ # x86_64 users should be encouraged to install 32-bit libraries
+ ifeq ($(CAN_BUILD_I386)$(CAN_BUILD_X86_64),01)
+ all: warn_32bit_failure
+ 
+ warn_32bit_failure:
+ 	@echo "Warning: you seem to have a broken 32-bit build" 2>&1;		\
+ 	echo  "environment. This will reduce test coverage of 64-bit" 2>&1;	\
+ 	echo  "kernels. If you are using a Debian-like distribution," 2>&1;	\
+ 	echo  "try:"; 2>&1;							\
+ 	echo  "";								\
+ 	echo  "  apt-get install gcc-multilib libc6-i386 libc6-dev-i386";	\
+ 	echo  "";								\
+ 	echo  "If you are using a Fedora-like distribution, try:";		\
+ 	echo  "";								\
+ 	echo  "  yum install glibc-devel.*i686";				\
+ 	exit 0;
+ endif
+ endif
+ 
 +$(OUTPUT)/hmm-tests: LDLIBS += -lhugetlbfs -lpthread
 +
  $(OUTPUT)/userfaultfd: LDLIBS += -lpthread
  
  $(OUTPUT)/mlock-random-test: LDLIBS += -lcap

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

^ permalink raw reply	[flat|nested] 17+ messages in thread

* linux-next: manual merge of the akpm-current tree with the hmm tree
@ 2019-08-22  8:14 Stephen Rothwell
  0 siblings, 0 replies; 17+ messages in thread
From: Stephen Rothwell @ 2019-08-22  8:14 UTC (permalink / raw)
  To: Andrew Morton, Jason Gunthorpe
  Cc: Linux Next Mailing List, Linux Kernel Mailing List,
	Christoph Hellwig, Toshiki Fukasawa

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

Hi all,

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

  include/linux/memremap.h

between commit:

  6869b7b20659 ("memremap: provide a not device managed memremap_pages")

from the hmm tree and commit:

  1ed60e3c73e6 ("/proc/kpageflags: do not use uninitialized struct pages")

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/memremap.h
index bef51e35d8d2,2cfc3c289d01..000000000000
--- a/include/linux/memremap.h
+++ b/include/linux/memremap.h
@@@ -122,8 -124,7 +122,9 @@@ static inline struct vmem_altmap *pgmap
  }
  
  #ifdef CONFIG_ZONE_DEVICE
+ bool pfn_zone_device_reserved(unsigned long pfn);
 +void *memremap_pages(struct dev_pagemap *pgmap, int nid);
 +void memunmap_pages(struct dev_pagemap *pgmap);
  void *devm_memremap_pages(struct device *dev, struct dev_pagemap *pgmap);
  void devm_memunmap_pages(struct device *dev, struct dev_pagemap *pgmap);
  struct dev_pagemap *get_dev_pagemap(unsigned long pfn,

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

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the hmm tree
  2019-07-07  5:04             ` Andrew Morton
@ 2019-07-16  4:25               ` Dan Williams
  0 siblings, 0 replies; 17+ messages in thread
From: Dan Williams @ 2019-07-16  4:25 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Jason Gunthorpe, Stephen Rothwell, Linux Next Mailing List,
	Linux Kernel Mailing List, Christoph Hellwig

On Sat, Jul 6, 2019 at 10:04 PM Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Fri, 5 Jul 2019 12:08:15 +0000 Jason Gunthorpe <jgg@mellanox.com> wrote:
>
> > On Thu, Jul 04, 2019 at 04:29:55PM -0700, Dan Williams wrote:
> > > Guys, Andrew has kicked the subsection patches out of -mm because of
> > > the merge conflicts. Can we hold off on the hmm cleanups for this
> > > cycle?
> >
> > I agree with you we should prioritize your subsection patches over
> > CH's cleanup if we cannot have both.
> >
> > As I said, I'll drop CH's at Andrews request, but I do not want to
> > make any changes without being aligned with him.
>
> OK, I had a shot at repairing the damage on top of current linux-next.
> The great majority of the issues were in
> mm-devm_memremap_pages-enable-sub-section-remap.patch.
>
> Below are the rejects which I saw and below that is my attempt to
> resolve it all.  Dan, please go through this with a toothcomb.  I've
> just done an mmotm release with all this in it so please do whatever's
> needed to verify that it's all working correctly.

Apologies for the delay, I was offline last week for a move. This
looks good to me and even caught some "X >> PAGE_SHIFT" to
"PHYS_PFN(X)" conversions that I missed. It also passes my testing.
Thank you accommodating a rebase.

Now to take a look at Oscar's fixes.

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the hmm tree
  2019-07-05 12:08           ` Jason Gunthorpe
@ 2019-07-07  5:04             ` Andrew Morton
  2019-07-16  4:25               ` Dan Williams
  0 siblings, 1 reply; 17+ messages in thread
From: Andrew Morton @ 2019-07-07  5:04 UTC (permalink / raw)
  To: Jason Gunthorpe
  Cc: Dan Williams, Stephen Rothwell, Linux Next Mailing List,
	Linux Kernel Mailing List, Christoph Hellwig

On Fri, 5 Jul 2019 12:08:15 +0000 Jason Gunthorpe <jgg@mellanox.com> wrote:

> On Thu, Jul 04, 2019 at 04:29:55PM -0700, Dan Williams wrote:
> > Guys, Andrew has kicked the subsection patches out of -mm because of
> > the merge conflicts. Can we hold off on the hmm cleanups for this
> > cycle?
> 
> I agree with you we should prioritize your subsection patches over
> CH's cleanup if we cannot have both.
> 
> As I said, I'll drop CH's at Andrews request, but I do not want to
> make any changes without being aligned with him.

OK, I had a shot at repairing the damage on top of current linux-next. 
The great majority of the issues were in
mm-devm_memremap_pages-enable-sub-section-remap.patch.

Below are the rejects which I saw and below that is my attempt to
resolve it all.  Dan, please go through this with a toothcomb.  I've
just done an mmotm release with all this in it so please do whatever's
needed to verify that it's all working correctly.


--- kernel/memremap.c~mm-devm_memremap_pages-enable-sub-section-remap
+++ kernel/memremap.c
@@ -58,7 +58,7 @@ static unsigned long pfn_first(struct de
 	struct vmem_altmap *altmap = &pgmap->altmap;
 	unsigned long pfn;
 
-	pfn = res->start >> PAGE_SHIFT;
+	pfn = PHYS_PFN(res->start);
 	if (pgmap->altmap_valid)
 		pfn += vmem_altmap_offset(altmap);
 	return pfn;
@@ -95,25 +94,21 @@ static void devm_memremap_pages_release(
 	pgmap->cleanup(pgmap->ref);
 
 	/* pages are dead and unused, undo the arch mapping */
-	align_start = res->start & ~(PA_SECTION_SIZE - 1);
-	align_size = ALIGN(res->start + resource_size(res), PA_SECTION_SIZE)
-		- align_start;
-
-	nid = page_to_nid(pfn_to_page(align_start >> PAGE_SHIFT));
+	nid = page_to_nid(pfn_to_page(PHYS_PFN(res->start)));
 
 	mem_hotplug_begin();
 	if (pgmap->type == MEMORY_DEVICE_PRIVATE) {
-		pfn = align_start >> PAGE_SHIFT;
+		pfn = PHYS_PFN(res->start);
 		__remove_pages(page_zone(pfn_to_page(pfn)), pfn,
-				align_size >> PAGE_SHIFT, NULL);
+				PHYS_PFN(resource_size(res)), NULL);
 	} else {
-		arch_remove_memory(nid, align_start, align_size,
+		arch_remove_memory(nid, res->start, resource_size(res),
 				pgmap->altmap_valid ? &pgmap->altmap : NULL);
-		kasan_remove_zero_shadow(__va(align_start), align_size);
+		kasan_remove_zero_shadow(__va(res->start), resource_size(res));
 	}
 	mem_hotplug_done();
 
-	untrack_pfn(NULL, PHYS_PFN(align_start), align_size);
+	untrack_pfn(NULL, PHYS_PFN(res->start), resource_size(res));
 	pgmap_array_delete(res);
 	dev_WARN_ONCE(dev, pgmap->altmap.alloc,
 		      "%s: failed to free all reserved pages\n", __func__);
@@ -140,16 +135,13 @@ static void devm_memremap_pages_release(
  */
 void *devm_memremap_pages(struct device *dev, struct dev_pagemap *pgmap)
 {
-	resource_size_t align_start, align_size, align_end;
-	struct vmem_altmap *altmap = pgmap->altmap_valid ?
-			&pgmap->altmap : NULL;
 	struct resource *res = &pgmap->res;
 	struct dev_pagemap *conflict_pgmap;
 	struct mhp_restrictions restrictions = {
 		/*
 		 * We do not want any optional features only our own memmap
 		*/
-		.altmap = altmap,
+		.altmap = pgmap->altmap_valid ? &pgmap->altmap : NULL,
 	};
 	pgprot_t pgprot = PAGE_KERNEL;
 	int error, nid, is_ram;
@@ -159,12 +151,7 @@ void *devm_memremap_pages(struct device
 		return ERR_PTR(-EINVAL);
 	}
 
-	align_start = res->start & ~(PA_SECTION_SIZE - 1);
-	align_size = ALIGN(res->start + resource_size(res), PA_SECTION_SIZE)
-		- align_start;
-	align_end = align_start + align_size - 1;
-
-	conflict_pgmap = get_dev_pagemap(PHYS_PFN(align_start), NULL);
+	conflict_pgmap = get_dev_pagemap(PHYS_PFN(res->start), NULL);
 	if (conflict_pgmap) {
 		dev_WARN(dev, "Conflicting mapping in same section\n");
 		put_dev_pagemap(conflict_pgmap);
@@ -220,25 +207,25 @@ void *devm_memremap_pages(struct device
 	 * arch_add_memory().
 	 */
 	if (pgmap->type == MEMORY_DEVICE_PRIVATE) {
-		error = add_pages(nid, align_start >> PAGE_SHIFT,
-				align_size >> PAGE_SHIFT, &restrictions);
+		error = add_pages(nid, PHYS_PFN(res->start),
+				PHYS_PFN(resource_size(res)), &restrictions);
 	} else {
-		error = kasan_add_zero_shadow(__va(align_start), align_size);
+		error = kasan_add_zero_shadow(__va(res->start), resource_size(res));
 		if (error) {
 			mem_hotplug_done();
 			goto err_kasan;
 		}
 
-		error = arch_add_memory(nid, align_start, align_size,
-					&restrictions);
+		error = arch_add_memory(nid, res->start, resource_size(res),
+				&restrictions);
 	}
 
 	if (!error) {
 		struct zone *zone;
 
 		zone = &NODE_DATA(nid)->node_zones[ZONE_DEVICE];
-		move_pfn_range_to_zone(zone, align_start >> PAGE_SHIFT,
-				align_size >> PAGE_SHIFT, altmap);
+		move_pfn_range_to_zone(zone, PHYS_PFN(res->start),
+				PHYS_PFN(resource_size(res)), restrictions.altmap);
 	}
 
 	mem_hotplug_done();






From: Dan Williams <dan.j.williams@intel.com>
Subject: mm/devm_memremap_pages: enable sub-section remap

Teach devm_memremap_pages() about the new sub-section capabilities of
arch_{add,remove}_memory().  Effectively, just replace all usage of
align_start, align_end, and align_size with res->start, res->end, and
resource_size(res).  The existing sanity check will still make sure that
the two separate remap attempts do not collide within a sub-section (2MB
on x86).

Link: http://lkml.kernel.org/r/156092355542.979959.10060071713397030576.stgit@dwillia2-desk3.amr.corp.intel.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Tested-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>	[ppc64]
Cc: Michal Hocko <mhocko@suse.com>
Cc: Toshi Kani <toshi.kani@hpe.com>
Cc: Jérôme Glisse <jglisse@redhat.com>
Cc: Logan Gunthorpe <logang@deltatee.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Pavel Tatashin <pasha.tatashin@soleen.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Jane Chu <jane.chu@oracle.com>
Cc: Jeff Moyer <jmoyer@redhat.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Mike Rapoport <rppt@linux.ibm.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Wei Yang <richardw.yang@linux.intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 kernel/memremap.c |   57 +++++++++++++++++---------------------------
 1 file changed, 23 insertions(+), 34 deletions(-)

--- a/kernel/memremap.c~mm-devm_memremap_pages-enable-sub-section-remap
+++ a/kernel/memremap.c
@@ -54,7 +54,7 @@ static void pgmap_array_delete(struct re
 
 static unsigned long pfn_first(struct dev_pagemap *pgmap)
 {
-	return (pgmap->res.start >> PAGE_SHIFT) +
+	return PHYS_PFN(pgmap->res.start) +
 		vmem_altmap_offset(pgmap_altmap(pgmap));
 }
 
@@ -98,7 +98,6 @@ static void devm_memremap_pages_release(
 	struct dev_pagemap *pgmap = data;
 	struct device *dev = pgmap->dev;
 	struct resource *res = &pgmap->res;
-	resource_size_t align_start, align_size;
 	unsigned long pfn;
 	int nid;
 
@@ -108,25 +107,21 @@ static void devm_memremap_pages_release(
 	dev_pagemap_cleanup(pgmap);
 
 	/* pages are dead and unused, undo the arch mapping */
-	align_start = res->start & ~(SECTION_SIZE - 1);
-	align_size = ALIGN(res->start + resource_size(res), SECTION_SIZE)
-		- align_start;
-
-	nid = page_to_nid(pfn_to_page(align_start >> PAGE_SHIFT));
+	nid = page_to_nid(pfn_to_page(PHYS_PFN(res->start)));
 
 	mem_hotplug_begin();
 	if (pgmap->type == MEMORY_DEVICE_PRIVATE) {
-		pfn = align_start >> PAGE_SHIFT;
+		pfn = PHYS_PFN(res->start);
 		__remove_pages(page_zone(pfn_to_page(pfn)), pfn,
-				align_size >> PAGE_SHIFT, NULL);
+				 PHYS_PFN(resource_size(res)), NULL);
 	} else {
-		arch_remove_memory(nid, align_start, align_size,
+		arch_remove_memory(nid, res->start, resource_size(res),
 				pgmap_altmap(pgmap));
-		kasan_remove_zero_shadow(__va(align_start), align_size);
+		kasan_remove_zero_shadow(__va(res->start), resource_size(res));
 	}
 	mem_hotplug_done();
 
-	untrack_pfn(NULL, PHYS_PFN(align_start), align_size);
+	untrack_pfn(NULL, PHYS_PFN(res->start), resource_size(res));
 	pgmap_array_delete(res);
 	dev_WARN_ONCE(dev, pgmap->altmap.alloc,
 		      "%s: failed to free all reserved pages\n", __func__);
@@ -162,13 +157,12 @@ static void dev_pagemap_percpu_release(s
  */
 void *devm_memremap_pages(struct device *dev, struct dev_pagemap *pgmap)
 {
-	resource_size_t align_start, align_size, align_end;
 	struct resource *res = &pgmap->res;
 	struct dev_pagemap *conflict_pgmap;
 	struct mhp_restrictions restrictions = {
 		/*
 		 * We do not want any optional features only our own memmap
-		*/
+		 */
 		.altmap = pgmap_altmap(pgmap),
 	};
 	pgprot_t pgprot = PAGE_KERNEL;
@@ -225,12 +219,7 @@ void *devm_memremap_pages(struct device
 			return ERR_PTR(error);
 	}
 
-	align_start = res->start & ~(SECTION_SIZE - 1);
-	align_size = ALIGN(res->start + resource_size(res), SECTION_SIZE)
-		- align_start;
-	align_end = align_start + align_size - 1;
-
-	conflict_pgmap = get_dev_pagemap(PHYS_PFN(align_start), NULL);
+	conflict_pgmap = get_dev_pagemap(PHYS_PFN(res->start), NULL);
 	if (conflict_pgmap) {
 		dev_WARN(dev, "Conflicting mapping in same section\n");
 		put_dev_pagemap(conflict_pgmap);
@@ -238,7 +227,7 @@ void *devm_memremap_pages(struct device
 		goto err_array;
 	}
 
-	conflict_pgmap = get_dev_pagemap(PHYS_PFN(align_end), NULL);
+	conflict_pgmap = get_dev_pagemap(PHYS_PFN(res->end), NULL);
 	if (conflict_pgmap) {
 		dev_WARN(dev, "Conflicting mapping in same section\n");
 		put_dev_pagemap(conflict_pgmap);
@@ -246,7 +235,7 @@ void *devm_memremap_pages(struct device
 		goto err_array;
 	}
 
-	is_ram = region_intersects(align_start, align_size,
+	is_ram = region_intersects(res->start, resource_size(res),
 		IORESOURCE_SYSTEM_RAM, IORES_DESC_NONE);
 
 	if (is_ram != REGION_DISJOINT) {
@@ -267,8 +256,8 @@ void *devm_memremap_pages(struct device
 	if (nid < 0)
 		nid = numa_mem_id();
 
-	error = track_pfn_remap(NULL, &pgprot, PHYS_PFN(align_start), 0,
-			align_size);
+	error = track_pfn_remap(NULL, &pgprot, PHYS_PFN(res->start), 0,
+			resource_size(res));
 	if (error)
 		goto err_pfn_remap;
 
@@ -286,16 +275,16 @@ void *devm_memremap_pages(struct device
 	 * arch_add_memory().
 	 */
 	if (pgmap->type == MEMORY_DEVICE_PRIVATE) {
-		error = add_pages(nid, align_start >> PAGE_SHIFT,
-				align_size >> PAGE_SHIFT, &restrictions);
+		error = add_pages(nid, PHYS_PFN(res->start),
+				PHYS_PFN(resource_size(res)), &restrictions);
 	} else {
-		error = kasan_add_zero_shadow(__va(align_start), align_size);
+		error = kasan_add_zero_shadow(__va(res->start), resource_size(res));
 		if (error) {
 			mem_hotplug_done();
 			goto err_kasan;
 		}
 
-		error = arch_add_memory(nid, align_start, align_size,
+		error = arch_add_memory(nid, res->start, resource_size(res),
 					&restrictions);
 	}
 
@@ -303,8 +292,8 @@ void *devm_memremap_pages(struct device
 		struct zone *zone;
 
 		zone = &NODE_DATA(nid)->node_zones[ZONE_DEVICE];
-		move_pfn_range_to_zone(zone, align_start >> PAGE_SHIFT,
-				align_size >> PAGE_SHIFT, pgmap_altmap(pgmap));
+		move_pfn_range_to_zone(zone, PHYS_PFN(res->start),
+				PHYS_PFN(resource_size(res)), restrictions.altmap);
 	}
 
 	mem_hotplug_done();
@@ -316,8 +305,8 @@ void *devm_memremap_pages(struct device
 	 * to allow us to do the work while not holding the hotplug lock.
 	 */
 	memmap_init_zone_device(&NODE_DATA(nid)->node_zones[ZONE_DEVICE],
-				align_start >> PAGE_SHIFT,
-				align_size >> PAGE_SHIFT, pgmap);
+				PHYS_PFN(res->start),
+				PHYS_PFN(resource_size(res)), pgmap);
 	percpu_ref_get_many(pgmap->ref, pfn_end(pgmap) - pfn_first(pgmap));
 
 	error = devm_add_action_or_reset(dev, devm_memremap_pages_release,
@@ -328,9 +317,9 @@ void *devm_memremap_pages(struct device
 	return __va(res->start);
 
  err_add_memory:
-	kasan_remove_zero_shadow(__va(align_start), align_size);
+	kasan_remove_zero_shadow(__va(res->start), resource_size(res));
  err_kasan:
-	untrack_pfn(NULL, PHYS_PFN(align_start), align_size);
+	untrack_pfn(NULL, PHYS_PFN(res->start), resource_size(res));
  err_pfn_remap:
 	pgmap_array_delete(res);
  err_array:
_


^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the hmm tree
  2019-07-04 23:29         ` Dan Williams
@ 2019-07-05 12:08           ` Jason Gunthorpe
  2019-07-07  5:04             ` Andrew Morton
  0 siblings, 1 reply; 17+ messages in thread
From: Jason Gunthorpe @ 2019-07-05 12:08 UTC (permalink / raw)
  To: Dan Williams
  Cc: Stephen Rothwell, Andrew Morton, Linux Next Mailing List,
	Linux Kernel Mailing List, Christoph Hellwig

On Thu, Jul 04, 2019 at 04:29:55PM -0700, Dan Williams wrote:
> Guys, Andrew has kicked the subsection patches out of -mm because of
> the merge conflicts. Can we hold off on the hmm cleanups for this
> cycle?

I agree with you we should prioritize your subsection patches over
CH's cleanup if we cannot have both.

As I said, I'll drop CH's at Andrews request, but I do not want to
make any changes without being aligned with him.

Jason

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the hmm tree
  2019-07-04 21:08       ` Stephen Rothwell
@ 2019-07-04 23:29         ` Dan Williams
  2019-07-05 12:08           ` Jason Gunthorpe
  0 siblings, 1 reply; 17+ messages in thread
From: Dan Williams @ 2019-07-04 23:29 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Jason Gunthorpe, Andrew Morton, Linux Next Mailing List,
	Linux Kernel Mailing List, Christoph Hellwig

Guys, Andrew has kicked the subsection patches out of -mm because of
the merge conflicts. Can we hold off on the hmm cleanups for this
cycle?

On Thu, Jul 4, 2019 at 2:08 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi Jason,
>
> On Thu, 4 Jul 2019 13:28:41 +0000 Jason Gunthorpe <jgg@mellanox.com> wrote:
> >
> > BTW, do you use a script to get these conflicting patch commit ID
> > automatically? It is so helpful to have them.
>
> No, I just use gitk and a bit of searching.  Though often there are not
> many possible commits to search.
>
> --
> Cheers,
> Stephen Rothwell

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the hmm tree
  2019-07-04 13:28     ` Jason Gunthorpe
@ 2019-07-04 21:08       ` Stephen Rothwell
  2019-07-04 23:29         ` Dan Williams
  0 siblings, 1 reply; 17+ messages in thread
From: Stephen Rothwell @ 2019-07-04 21:08 UTC (permalink / raw)
  To: Jason Gunthorpe
  Cc: Andrew Morton, Linux Next Mailing List,
	Linux Kernel Mailing List, Christoph Hellwig, Dan Williams

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

Hi Jason,

On Thu, 4 Jul 2019 13:28:41 +0000 Jason Gunthorpe <jgg@mellanox.com> wrote:
>
> BTW, do you use a script to get these conflicting patch commit ID
> automatically? It is so helpful to have them.

No, I just use gitk and a bit of searching.  Though often there are not
many possible commits to search.

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the hmm tree
  2019-07-04 13:01   ` Stephen Rothwell
@ 2019-07-04 13:28     ` Jason Gunthorpe
  2019-07-04 21:08       ` Stephen Rothwell
  0 siblings, 1 reply; 17+ messages in thread
From: Jason Gunthorpe @ 2019-07-04 13:28 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Linux Next Mailing List,
	Linux Kernel Mailing List, Christoph Hellwig, Dan Williams

On Thu, Jul 04, 2019 at 11:01:33PM +1000, Stephen Rothwell wrote:
> Hi Jason,
> 
> On Thu, 4 Jul 2019 12:55:43 +0000 Jason Gunthorpe <jgg@mellanox.com> wrote:
> >
> > On Thu, Jul 04, 2019 at 08:55:36PM +1000, Stephen Rothwell wrote:
> > > 
> > > Today's linux-next merge of the akpm-current tree got a conflict in:
> > > 
> > >   mm/memory_hotplug.c
> > > 
> > > between commit:
> > > 
> > >   514caf23a70f ("memremap: replace the altmap_valid field with a PGMAP_ALTMAP_VALID flag")
> > > 
> > > from the hmm tree and commit:
> > > 
> > >   db30f881e2d7 ("mm/hotplug: kill is_dev_zone() usage in __remove_pages()")  
> > 
> > There must be another commit involved for the 'unsigned long nr,
> > start_sec, end_sec;' lines..
> 
> Yeah, there was, but that didn't actually create a conflict.  That hunk
> is only there because I removed the initialisation of map_offset.

BTW, do you use a script to get these conflicting patch commit ID
automatically? It is so helpful to have them.

Jason

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the hmm tree
  2019-07-04 12:55 ` Jason Gunthorpe
@ 2019-07-04 13:01   ` Stephen Rothwell
  2019-07-04 13:28     ` Jason Gunthorpe
  0 siblings, 1 reply; 17+ messages in thread
From: Stephen Rothwell @ 2019-07-04 13:01 UTC (permalink / raw)
  To: Jason Gunthorpe
  Cc: Andrew Morton, Linux Next Mailing List,
	Linux Kernel Mailing List, Christoph Hellwig, Dan Williams

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

Hi Jason,

On Thu, 4 Jul 2019 12:55:43 +0000 Jason Gunthorpe <jgg@mellanox.com> wrote:
>
> On Thu, Jul 04, 2019 at 08:55:36PM +1000, Stephen Rothwell wrote:
> > 
> > Today's linux-next merge of the akpm-current tree got a conflict in:
> > 
> >   mm/memory_hotplug.c
> > 
> > between commit:
> > 
> >   514caf23a70f ("memremap: replace the altmap_valid field with a PGMAP_ALTMAP_VALID flag")
> > 
> > from the hmm tree and commit:
> > 
> >   db30f881e2d7 ("mm/hotplug: kill is_dev_zone() usage in __remove_pages()")  
> 
> There must be another commit involved for the 'unsigned long nr,
> start_sec, end_sec;' lines..

Yeah, there was, but that didn't actually create a conflict.  That hunk
is only there because I removed the initialisation of map_offset.

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the hmm tree
  2019-07-04 10:55 Stephen Rothwell
@ 2019-07-04 12:55 ` Jason Gunthorpe
  2019-07-04 13:01   ` Stephen Rothwell
  0 siblings, 1 reply; 17+ messages in thread
From: Jason Gunthorpe @ 2019-07-04 12:55 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Linux Next Mailing List,
	Linux Kernel Mailing List, Christoph Hellwig, Dan Williams

On Thu, Jul 04, 2019 at 08:55:36PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the akpm-current tree got a conflict in:
> 
>   mm/memory_hotplug.c
> 
> between commit:
> 
>   514caf23a70f ("memremap: replace the altmap_valid field with a PGMAP_ALTMAP_VALID flag")
> 
> from the hmm tree and commit:
> 
>   db30f881e2d7 ("mm/hotplug: kill is_dev_zone() usage in __remove_pages()")

There must be another commit involved for the 'unsigned long nr,
start_sec, end_sec;' lines..
 
> from the akpm-current tree.
> 
> I fixed it up (I think - 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 mm/memory_hotplug.c
> index 6166ba5a15f3,dfab21dc33dc..000000000000
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@@ -549,16 -537,14 +537,13 @@@ static void __remove_section(struct zon
>    * sure that pages are marked reserved and zones are adjust properly by
>    * calling offline_pages().
>    */
> - void __remove_pages(struct zone *zone, unsigned long phys_start_pfn,
> + void __remove_pages(struct zone *zone, unsigned long pfn,
>   		    unsigned long nr_pages, struct vmem_altmap *altmap)
>   {
> - 	unsigned long i;
> --	unsigned long map_offset = 0;
> - 	int sections_to_remove;
> ++	unsigned long map_offset;
> + 	unsigned long nr, start_sec, end_sec;
>   
> - 	/* In the ZONE_DEVICE case device driver owns the memory region */
> - 	if (is_dev_zone(zone))
>  -	if (altmap)
> --		map_offset = vmem_altmap_offset(altmap);
> ++	map_offset = vmem_altmap_offset(altmap);
>   
>   	clear_zone_contiguous(zone);
>   

This looks OK to me. After the trees are merged vmem_altmap_offset()
returns 0 if !altmap, so the code is equivalent.

Jason

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the hmm tree
  2019-07-04 10:09 Stephen Rothwell
@ 2019-07-04 12:44 ` Jason Gunthorpe
  0 siblings, 0 replies; 17+ messages in thread
From: Jason Gunthorpe @ 2019-07-04 12:44 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Linux Next Mailing List,
	Linux Kernel Mailing List, Robin Murphy, Christoph Hellwig

On Thu, Jul 04, 2019 at 08:09:56PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the akpm-current tree got a conflict in:
> 
>   include/linux/mm.h
> 
> between commit:
> 
>   25b2995a35b6 ("mm: remove MEMORY_DEVICE_PUBLIC support")
> 
> from the hmm tree and commit:
> 
>   0a470a2d114a ("mm: clean up is_device_*_page() definitions")
> 
> 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/mm.h
> index d405a7cff62a,12980954daf9..000000000000
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@@ -950,27 -953,15 +950,7 @@@ static inline bool put_devmap_managed_p
>   	}
>   	return false;
>   }
> - 
> - static inline bool is_device_private_page(const struct page *page)
> - {
> - 	return is_zone_device_page(page) &&
> - 		page->pgmap->type == MEMORY_DEVICE_PRIVATE;
> - }
> - 
> - #ifdef CONFIG_PCI_P2PDMA
> - static inline bool is_pci_p2pdma_page(const struct page *page)
> - {
> - 	return is_zone_device_page(page) &&
> - 		page->pgmap->type == MEMORY_DEVICE_PCI_P2PDMA;
> - }
> - #else /* CONFIG_PCI_P2PDMA */
> - static inline bool is_pci_p2pdma_page(const struct page *page)
> - {
> - 	return false;
> - }
> - #endif /* CONFIG_PCI_P2PDMA */
> - 
>   #else /* CONFIG_DEV_PAGEMAP_OPS */
>  -static inline void dev_pagemap_get_ops(void)
>  -{
>  -}
>  -
>  -static inline void dev_pagemap_put_ops(void)
>  -{
>  -}
>  -
>   static inline bool put_devmap_managed_page(struct page *page)
>   {
>   	return false;
> @@@ -978,14 -970,27 +959,19 @@@
>   
>   static inline bool is_device_private_page(const struct page *page)
>   {
> - 	return false;
> + 	return IS_ENABLED(CONFIG_DEV_PAGEMAP_OPS) &&
> + 		IS_ENABLED(CONFIG_DEVICE_PRIVATE) &&
> + 		is_zone_device_page(page) &&
> + 		page->pgmap->type == MEMORY_DEVICE_PRIVATE;
>   }
>   
>  -static inline bool is_device_public_page(const struct page *page)
>  -{
>  -	return IS_ENABLED(CONFIG_DEV_PAGEMAP_OPS) &&
>  -		IS_ENABLED(CONFIG_DEVICE_PUBLIC) &&
>  -		is_zone_device_page(page) &&
>  -		page->pgmap->type == MEMORY_DEVICE_PUBLIC;
>  -}
>  -
>   static inline bool is_pci_p2pdma_page(const struct page *page)
>   {
> - 	return false;
> + 	return IS_ENABLED(CONFIG_DEV_PAGEMAP_OPS) &&
> + 		IS_ENABLED(CONFIG_PCI_P2PDMA) &&
> + 		is_zone_device_page(page) &&
> + 		page->pgmap->type == MEMORY_DEVICE_PCI_P2PDMA;
>   }
> - #endif /* CONFIG_DEV_PAGEMAP_OPS */
>   
>   /* 127: arbitrary random number, small enough to assemble well */
>   #define page_ref_zero_or_close_to_overflow(page) \

Yep, this new version is much nicer

Jason


^ permalink raw reply	[flat|nested] 17+ messages in thread

* linux-next: manual merge of the akpm-current tree with the hmm tree
@ 2019-07-04 10:55 Stephen Rothwell
  2019-07-04 12:55 ` Jason Gunthorpe
  0 siblings, 1 reply; 17+ messages in thread
From: Stephen Rothwell @ 2019-07-04 10:55 UTC (permalink / raw)
  To: Andrew Morton, Jason Gunthorpe
  Cc: Linux Next Mailing List, Linux Kernel Mailing List,
	Christoph Hellwig, Dan Williams

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

Hi all,

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

  mm/memory_hotplug.c

between commit:

  514caf23a70f ("memremap: replace the altmap_valid field with a PGMAP_ALTMAP_VALID flag")

from the hmm tree and commit:

  db30f881e2d7 ("mm/hotplug: kill is_dev_zone() usage in __remove_pages()")

from the akpm-current tree.

I fixed it up (I think - 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 mm/memory_hotplug.c
index 6166ba5a15f3,dfab21dc33dc..000000000000
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@@ -549,16 -537,14 +537,13 @@@ static void __remove_section(struct zon
   * sure that pages are marked reserved and zones are adjust properly by
   * calling offline_pages().
   */
- void __remove_pages(struct zone *zone, unsigned long phys_start_pfn,
+ void __remove_pages(struct zone *zone, unsigned long pfn,
  		    unsigned long nr_pages, struct vmem_altmap *altmap)
  {
- 	unsigned long i;
--	unsigned long map_offset = 0;
- 	int sections_to_remove;
++	unsigned long map_offset;
+ 	unsigned long nr, start_sec, end_sec;
  
- 	/* In the ZONE_DEVICE case device driver owns the memory region */
- 	if (is_dev_zone(zone))
 -	if (altmap)
--		map_offset = vmem_altmap_offset(altmap);
++	map_offset = vmem_altmap_offset(altmap);
  
  	clear_zone_contiguous(zone);
  

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

^ permalink raw reply	[flat|nested] 17+ messages in thread

* linux-next: manual merge of the akpm-current tree with the hmm tree
@ 2019-07-04 10:44 Stephen Rothwell
  0 siblings, 0 replies; 17+ messages in thread
From: Stephen Rothwell @ 2019-07-04 10:44 UTC (permalink / raw)
  To: Andrew Morton, Jason Gunthorpe
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Robin Murphy,
	Christoph Hellwig

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

Hi all,

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

  mm/hmm.c

between commits:

  0092908d16c6 ("mm: factor out a devm_request_free_mem_region helper")
  43535b0aefab ("mm: remove the HMM config option")

from the hmm tree and commit:

  4c24b795d8c4 ("mm/memremap: rename and consolidate SECTION_SIZE")

from the akpm-current tree.

I fixed it up (the latter is just part of the first hmm tree commit) 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 --]

^ permalink raw reply	[flat|nested] 17+ messages in thread

* linux-next: manual merge of the akpm-current tree with the hmm tree
@ 2019-07-04 10:36 Stephen Rothwell
  0 siblings, 0 replies; 17+ messages in thread
From: Stephen Rothwell @ 2019-07-04 10:36 UTC (permalink / raw)
  To: Andrew Morton, Jason Gunthorpe
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Dan Williams,
	Christoph Hellwig

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

Hi all,

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

  kernel/memremap.c

between commit:

  514caf23a70f ("memremap: replace the altmap_valid field with a PGMAP_ALTMAP_VALID flag")

from the hmm tree and commit:

  a10a0f39cae6 ("mm/devm_memremap_pages: enable sub-section remap")

from the akpm-current tree.

I fixed it up (I think - 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/memremap.c
index bea6f887adad,a0e5f6b91b04..000000000000
--- a/kernel/memremap.c
+++ b/kernel/memremap.c
@@@ -11,39 -11,39 +11,37 @@@
  #include <linux/types.h>
  #include <linux/wait_bit.h>
  #include <linux/xarray.h>
 -#include <linux/hmm.h>
  
  static DEFINE_XARRAY(pgmap_array);
- #define SECTION_MASK ~((1UL << PA_SECTION_SHIFT) - 1)
- #define SECTION_SIZE (1UL << PA_SECTION_SHIFT)
  
 -#if IS_ENABLED(CONFIG_DEVICE_PRIVATE)
 -vm_fault_t device_private_entry_fault(struct vm_area_struct *vma,
 -		       unsigned long addr,
 -		       swp_entry_t entry,
 -		       unsigned int flags,
 -		       pmd_t *pmdp)
 +#ifdef CONFIG_DEV_PAGEMAP_OPS
 +DEFINE_STATIC_KEY_FALSE(devmap_managed_key);
 +EXPORT_SYMBOL(devmap_managed_key);
 +static atomic_t devmap_managed_enable;
 +
 +static void devmap_managed_enable_put(void *data)
  {
 -	struct page *page = device_private_entry_to_page(entry);
 -	struct hmm_devmem *devmem;
 +	if (atomic_dec_and_test(&devmap_managed_enable))
 +		static_branch_disable(&devmap_managed_key);
 +}
  
 -	devmem = container_of(page->pgmap, typeof(*devmem), pagemap);
 +static int devmap_managed_enable_get(struct device *dev, struct dev_pagemap *pgmap)
 +{
 +	if (!pgmap->ops || !pgmap->ops->page_free) {
 +		WARN(1, "Missing page_free method\n");
 +		return -EINVAL;
 +	}
  
 -	/*
 -	 * The page_fault() callback must migrate page back to system memory
 -	 * so that CPU can access it. This might fail for various reasons
 -	 * (device issue, device was unsafely unplugged, ...). When such
 -	 * error conditions happen, the callback must return VM_FAULT_SIGBUS.
 -	 *
 -	 * Note that because memory cgroup charges are accounted to the device
 -	 * memory, this should never fail because of memory restrictions (but
 -	 * allocation of regular system page might still fail because we are
 -	 * out of memory).
 -	 *
 -	 * There is a more in-depth description of what that callback can and
 -	 * cannot do, in include/linux/memremap.h
 -	 */
 -	return devmem->page_fault(vma, addr, page, flags, pmdp);
 +	if (atomic_inc_return(&devmap_managed_enable) == 1)
 +		static_branch_enable(&devmap_managed_key);
 +	return devm_add_action_or_reset(dev, devmap_managed_enable_put, NULL);
  }
 -#endif /* CONFIG_DEVICE_PRIVATE */
 +#else
 +static int devmap_managed_enable_get(struct device *dev, struct dev_pagemap *pgmap)
 +{
 +	return -EINVAL;
 +}
 +#endif /* CONFIG_DEV_PAGEMAP_OPS */
  
  static void pgmap_array_delete(struct resource *res)
  {
@@@ -54,8 -54,14 +52,8 @@@
  
  static unsigned long pfn_first(struct dev_pagemap *pgmap)
  {
- 	return (pgmap->res.start >> PAGE_SHIFT) +
 -	const struct resource *res = &pgmap->res;
 -	struct vmem_altmap *altmap = &pgmap->altmap;
 -	unsigned long pfn;
 -
 -	pfn = PHYS_PFN(res->start);
 -	if (pgmap->altmap_valid)
 -		pfn += vmem_altmap_offset(altmap);
 -	return pfn;
++	return (PHYS_PFN(pgmap->res.start)) +
 +		vmem_altmap_offset(pgmap_altmap(pgmap));
  }
  
  static unsigned long pfn_end(struct dev_pagemap *pgmap)
@@@ -101,28 -89,23 +99,23 @@@ static void devm_memremap_pages_release
  	unsigned long pfn;
  	int nid;
  
 -	pgmap->kill(pgmap->ref);
 +	dev_pagemap_kill(pgmap);
  	for_each_device_pfn(pfn, pgmap)
  		put_page(pfn_to_page(pfn));
 -	pgmap->cleanup(pgmap->ref);
 +	dev_pagemap_cleanup(pgmap);
  
  	/* pages are dead and unused, undo the arch mapping */
- 	align_start = res->start & ~(SECTION_SIZE - 1);
- 	align_size = ALIGN(res->start + resource_size(res), SECTION_SIZE)
- 		- align_start;
- 
- 	nid = page_to_nid(pfn_to_page(align_start >> PAGE_SHIFT));
+ 	nid = page_to_nid(pfn_to_page(PHYS_PFN(res->start)));
  
  	mem_hotplug_begin();
  	if (pgmap->type == MEMORY_DEVICE_PRIVATE) {
- 		pfn = align_start >> PAGE_SHIFT;
+ 		pfn = PHYS_PFN(res->start);
  		__remove_pages(page_zone(pfn_to_page(pfn)), pfn,
- 				align_size >> PAGE_SHIFT, NULL);
+ 				PHYS_PFN(resource_size(res)), NULL);
  	} else {
- 		arch_remove_memory(nid, align_start, align_size,
+ 		arch_remove_memory(nid, res->start, resource_size(res),
 -				pgmap->altmap_valid ? &pgmap->altmap : NULL);
 +				pgmap_altmap(pgmap));
- 		kasan_remove_zero_shadow(__va(align_start), align_size);
+ 		kasan_remove_zero_shadow(__va(res->start), resource_size(res));
  	}
  	mem_hotplug_done();
  
@@@ -173,64 -146,13 +165,59 @@@ void *devm_memremap_pages(struct devic
  	};
  	pgprot_t pgprot = PAGE_KERNEL;
  	int error, nid, is_ram;
 +	bool need_devmap_managed = true;
 +
 +	switch (pgmap->type) {
 +	case MEMORY_DEVICE_PRIVATE:
 +		if (!IS_ENABLED(CONFIG_DEVICE_PRIVATE)) {
 +			WARN(1, "Device private memory not supported\n");
 +			return ERR_PTR(-EINVAL);
 +		}
 +		if (!pgmap->ops || !pgmap->ops->migrate_to_ram) {
 +			WARN(1, "Missing migrate_to_ram method\n");
 +			return ERR_PTR(-EINVAL);
 +		}
 +		break;
 +	case MEMORY_DEVICE_FS_DAX:
 +		if (!IS_ENABLED(CONFIG_ZONE_DEVICE) ||
 +		    IS_ENABLED(CONFIG_FS_DAX_LIMITED)) {
 +			WARN(1, "File system DAX not supported\n");
 +			return ERR_PTR(-EINVAL);
 +		}
 +		break;
 +	case MEMORY_DEVICE_DEVDAX:
 +	case MEMORY_DEVICE_PCI_P2PDMA:
 +		need_devmap_managed = false;
 +		break;
 +	default:
 +		WARN(1, "Invalid pgmap type %d\n", pgmap->type);
 +		break;
 +	}
 +
 +	if (!pgmap->ref) {
 +		if (pgmap->ops && (pgmap->ops->kill || pgmap->ops->cleanup))
 +			return ERR_PTR(-EINVAL);
 +
 +		init_completion(&pgmap->done);
 +		error = percpu_ref_init(&pgmap->internal_ref,
 +				dev_pagemap_percpu_release, 0, GFP_KERNEL);
 +		if (error)
 +			return ERR_PTR(error);
 +		pgmap->ref = &pgmap->internal_ref;
 +	} else {
 +		if (!pgmap->ops || !pgmap->ops->kill || !pgmap->ops->cleanup) {
 +			WARN(1, "Missing reference count teardown definition\n");
 +			return ERR_PTR(-EINVAL);
 +		}
 +	}
  
 -	if (!pgmap->ref || !pgmap->kill || !pgmap->cleanup) {
 -		WARN(1, "Missing reference count teardown definition\n");
 -		return ERR_PTR(-EINVAL);
 +	if (need_devmap_managed) {
 +		error = devmap_managed_enable_get(dev, pgmap);
 +		if (error)
 +			return ERR_PTR(error);
  	}
  
- 	align_start = res->start & ~(SECTION_SIZE - 1);
- 	align_size = ALIGN(res->start + resource_size(res), SECTION_SIZE)
- 		- align_start;
- 	align_end = align_start + align_size - 1;
- 
- 	conflict_pgmap = get_dev_pagemap(PHYS_PFN(align_start), NULL);
+ 	conflict_pgmap = get_dev_pagemap(PHYS_PFN(res->start), NULL);
  	if (conflict_pgmap) {
  		dev_WARN(dev, "Conflicting mapping in same section\n");
  		put_dev_pagemap(conflict_pgmap);

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

^ permalink raw reply	[flat|nested] 17+ messages in thread

* linux-next: manual merge of the akpm-current tree with the hmm tree
@ 2019-07-04 10:09 Stephen Rothwell
  2019-07-04 12:44 ` Jason Gunthorpe
  0 siblings, 1 reply; 17+ messages in thread
From: Stephen Rothwell @ 2019-07-04 10:09 UTC (permalink / raw)
  To: Andrew Morton, Jason Gunthorpe
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Robin Murphy,
	Christoph Hellwig

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

Hi all,

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

  include/linux/mm.h

between commit:

  25b2995a35b6 ("mm: remove MEMORY_DEVICE_PUBLIC support")

from the hmm tree and commit:

  0a470a2d114a ("mm: clean up is_device_*_page() definitions")

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/mm.h
index d405a7cff62a,12980954daf9..000000000000
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@@ -950,27 -953,15 +950,7 @@@ static inline bool put_devmap_managed_p
  	}
  	return false;
  }
- 
- static inline bool is_device_private_page(const struct page *page)
- {
- 	return is_zone_device_page(page) &&
- 		page->pgmap->type == MEMORY_DEVICE_PRIVATE;
- }
- 
- #ifdef CONFIG_PCI_P2PDMA
- static inline bool is_pci_p2pdma_page(const struct page *page)
- {
- 	return is_zone_device_page(page) &&
- 		page->pgmap->type == MEMORY_DEVICE_PCI_P2PDMA;
- }
- #else /* CONFIG_PCI_P2PDMA */
- static inline bool is_pci_p2pdma_page(const struct page *page)
- {
- 	return false;
- }
- #endif /* CONFIG_PCI_P2PDMA */
- 
  #else /* CONFIG_DEV_PAGEMAP_OPS */
 -static inline void dev_pagemap_get_ops(void)
 -{
 -}
 -
 -static inline void dev_pagemap_put_ops(void)
 -{
 -}
 -
  static inline bool put_devmap_managed_page(struct page *page)
  {
  	return false;
@@@ -978,14 -970,27 +959,19 @@@
  
  static inline bool is_device_private_page(const struct page *page)
  {
- 	return false;
+ 	return IS_ENABLED(CONFIG_DEV_PAGEMAP_OPS) &&
+ 		IS_ENABLED(CONFIG_DEVICE_PRIVATE) &&
+ 		is_zone_device_page(page) &&
+ 		page->pgmap->type == MEMORY_DEVICE_PRIVATE;
  }
  
 -static inline bool is_device_public_page(const struct page *page)
 -{
 -	return IS_ENABLED(CONFIG_DEV_PAGEMAP_OPS) &&
 -		IS_ENABLED(CONFIG_DEVICE_PUBLIC) &&
 -		is_zone_device_page(page) &&
 -		page->pgmap->type == MEMORY_DEVICE_PUBLIC;
 -}
 -
  static inline bool is_pci_p2pdma_page(const struct page *page)
  {
- 	return false;
+ 	return IS_ENABLED(CONFIG_DEV_PAGEMAP_OPS) &&
+ 		IS_ENABLED(CONFIG_PCI_P2PDMA) &&
+ 		is_zone_device_page(page) &&
+ 		page->pgmap->type == MEMORY_DEVICE_PCI_P2PDMA;
  }
- #endif /* CONFIG_DEV_PAGEMAP_OPS */
  
  /* 127: arbitrary random number, small enough to assemble well */
  #define page_ref_zero_or_close_to_overflow(page) \

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

^ permalink raw reply	[flat|nested] 17+ messages in thread

end of thread, other threads:[~2020-05-08 10:22 UTC | newest]

Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-07-04 10:01 linux-next: manual merge of the akpm-current tree with the hmm tree Stephen Rothwell
2019-07-04 12:42 ` Jason Gunthorpe
2019-07-04 10:09 Stephen Rothwell
2019-07-04 12:44 ` Jason Gunthorpe
2019-07-04 10:36 Stephen Rothwell
2019-07-04 10:44 Stephen Rothwell
2019-07-04 10:55 Stephen Rothwell
2019-07-04 12:55 ` Jason Gunthorpe
2019-07-04 13:01   ` Stephen Rothwell
2019-07-04 13:28     ` Jason Gunthorpe
2019-07-04 21:08       ` Stephen Rothwell
2019-07-04 23:29         ` Dan Williams
2019-07-05 12:08           ` Jason Gunthorpe
2019-07-07  5:04             ` Andrew Morton
2019-07-16  4:25               ` Dan Williams
2019-08-22  8:14 Stephen Rothwell
2020-05-08 10:22 Stephen Rothwell

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).