mmu notifier provide context informations

From: Jérôme Glisse <[email protected]>

Simple helpers to test if range invalidation is blockable. Latter patches use cocinnelle to convert all direct dereference of range-> blockable to use this function instead so that we can convert the blockable field to an unsigned for more flags.

Signed-off-by Jérôme Glisse <[email protected]>

Cc Christian König <[email protected]>

Cc Joonas Lahtinen <[email protected]>

Cc Jani Nikula <[email protected]>

Cc Rodrigo Vivi <[email protected]>

Cc Jan Kara <[email protected]>

Cc Andrea Arcangeli <[email protected]>

Cc Peter Xu <[email protected]>

Cc Felix Kuehling <[email protected]>

Cc Jason Gunthorpe <[email protected]>

Cc Andrew Morton <[email protected]>

Cc Ross Zwisler <[email protected]>

Cc Dan Williams <[email protected]>

Cc Paolo Bonzini <[email protected]>

Cc Radim Krčmář <[email protected]>

Cc Michal Hocko <[email protected]>

Cc Christian Koenig <[email protected]>

Cc Ralph Campbell <[email protected]>

Cc John Hubbard <[email protected]>

Cc [email protected]

Cc [email protected]

Cc [email protected]

Cc [email protected]

Cc Arnd Bergmann <[email protected]>

---
  include/linux/mmu_notifier.h | 11 +++++++++++
  1 file changed, 11 insertions(+)

include/linux/mmu_notifier.h +6 -0

index 4050ec1c3b45..e630def131ce 100644
@@ -226,6 +226,12 @@ extern void __mmu_notifier_invalidate_range_end(struct mmu_notifier_range *r,
  extern void __mmu_notifier_invalidate_range(struct mm_struct *mm,
  				  unsigned long start, unsigned long end);
 
+static inline bool
+mmu_notifier_range_blockable(const struct mmu_notifier_range *range)
+{
+	return range->blockable;
+}
+
  static inline void mmu_notifier_release(struct mm_struct *mm)
  {
  	if (mm_has_notifiers(mm))

@@ -455,6 +461,11 @@ static inline void _mmu_notifier_range_init(struct mmu_notifier_range *range,
  #define mmu_notifier_range_init(range, mm, start, end) \

From: Jérôme Glisse <[email protected]>

Use the mmu_notifier_range_blockable() helper function instead of directly dereferencing the range->blockable field. This is done to make it easier to change the mmu_notifier range field.

This patch is the outcome of the following coccinelle patch:

%<------------------------------------------------------------------- @@
identifier I1, FN;
@@
FN(..., struct mmu_notifier_range *I1, ...) {
<...

(quoted diff) +1 -1

-I1->blockable
+mmu_notifier_range_blockable(I1)

...>
} ------------------------------------------------------------------->%

spatch --in-place --sp-file blockable.spatch --dir .

Signed-off-by Jérôme Glisse <[email protected]>

Cc Christian König <[email protected]>

Cc Joonas Lahtinen <[email protected]>

Cc Jani Nikula <[email protected]>

Cc Rodrigo Vivi <[email protected]>

Cc Jan Kara <[email protected]>

Cc Andrea Arcangeli <[email protected]>

Cc Peter Xu <[email protected]>

Cc Felix Kuehling <[email protected]>

Cc Jason Gunthorpe <[email protected]>

Cc Ross Zwisler <[email protected]>

Cc Dan Williams <[email protected]>

Cc Paolo Bonzini <[email protected]>

Cc Radim Krčmář <[email protected]>

Cc Michal Hocko <[email protected]>

Cc Christian Koenig <[email protected]>

Cc Ralph Campbell <[email protected]>

Cc John Hubbard <[email protected]>

Cc [email protected]

Cc [email protected]

Cc [email protected]

Cc Arnd Bergmann <[email protected]>

---
  drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c  | 8 ++++----
  drivers/gpu/drm/i915/i915_gem_userptr.c | 2 +-
  drivers/gpu/drm/radeon/radeon_mn.c      | 4 ++--
  drivers/infiniband/core/umem_odp.c      | 5 +++--
  drivers/xen/gntdev.c                    | 6 +++---
  mm/hmm.c                                | 6 +++---
  mm/mmu_notifier.c                       | 2 +-
  virt/kvm/kvm_main.c                     | 3 ++-
  8 files changed, 19 insertions(+), 17 deletions(-)

drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c +4 -4

index 3e6823fdd939..58ed401c5996 100644
@@ -256,14 +256,14 @@ static int amdgpu_mn_invalidate_range_start_gfx(struct mmu_notifier *mn,
  	/* TODO we should be able to split locking for interval tree and
  	 * amdgpu_mn_invalidate_node
  	 */
-	if (amdgpu_mn_read_lock(amn, range->blockable))
+	if (amdgpu_mn_read_lock(amn, mmu_notifier_range_blockable(range)))
  		return -EAGAIN;
 
  	it = interval_tree_iter_first(&amn->objects, range->start, end);
  	while (it) {
  		struct amdgpu_mn_node *node;
 
-		if (!range->blockable) {
+		if (!mmu_notifier_range_blockable(range)) {
  			amdgpu_mn_read_unlock(amn);
  			return -EAGAIN;
  		}

@@ -299,7 +299,7 @@ static int amdgpu_mn_invalidate_range_start_hsa(struct mmu_notifier *mn,
  	/* notification is exclusive, but interval is inclusive */
  	end = range->end - 1;
 
-	if (amdgpu_mn_read_lock(amn, range->blockable))
+	if (amdgpu_mn_read_lock(amn, mmu_notifier_range_blockable(range)))
  		return -EAGAIN;
 
  	it = interval_tree_iter_first(&amn->objects, range->start, end);

@@ -307,7 +307,7 @@ static int amdgpu_mn_invalidate_range_start_hsa(struct mmu_notifier *mn,
  		struct amdgpu_mn_node *node;
  		struct amdgpu_bo *bo;
 
-		if (!range->blockable) {
+		if (!mmu_notifier_range_blockable(range)) {
  			amdgpu_mn_read_unlock(amn);
  			return -EAGAIN;
  		}

drivers/gpu/drm/i915/i915_gem_userptr.c +1 -1

index 1d3f9a31ad61..777b3f8727e7 100644
@@ -122,7 +122,7 @@ userptr_mn_invalidate_range_start(struct mmu_notifier *_mn,
  	while (it) {
  		struct drm_i915_gem_object *obj;
 
-		if (!range->blockable) {
+		if (!mmu_notifier_range_blockable(range)) {
  			ret = -EAGAIN;
  			break;
  		}

drivers/gpu/drm/radeon/radeon_mn.c +2 -2

index b3019505065a..c9bd1278f573 100644
@@ -133,7 +133,7 @@ static int radeon_mn_invalidate_range_start(struct mmu_notifier *mn,
  	/* TODO we should be able to split locking for interval tree and
  	 * the tear down.
  	 */
-	if (range->blockable)
+	if (mmu_notifier_range_blockable(range))
  		mutex_lock(&rmn->lock);
  	else if (!mutex_trylock(&rmn->lock))
  		return -EAGAIN;

@@ -144,7 +144,7 @@ static int radeon_mn_invalidate_range_start(struct mmu_notifier *mn,
  		struct radeon_bo *bo;
  		long r;
 
-		if (!range->blockable) {
+		if (!mmu_notifier_range_blockable(range)) {
  			ret = -EAGAIN;
  			goto out_unlock;
  		}

drivers/infiniband/core/umem_odp.c +3 -2

index 012044f16d1c..3a3f1538d295 100644
@@ -151,7 +151,7 @@ static int ib_umem_notifier_invalidate_range_start(struct mmu_notifier *mn,
  	struct ib_ucontext_per_mm *per_mm =
  		container_of(mn, struct ib_ucontext_per_mm, mn);
 
-	if (range->blockable)
+	if (mmu_notifier_range_blockable(range))
  		down_read(&per_mm->umem_rwsem);
  	else if (!down_read_trylock(&per_mm->umem_rwsem))
  		return -EAGAIN;

@@ -169,7 +169,8 @@ static int ib_umem_notifier_invalidate_range_start(struct mmu_notifier *mn,
  	return rbt_ib_umem_for_each_in_range(&per_mm->umem_tree, range->start,
  					     range->end,
  					     invalidate_range_start_trampoline,
-					     range->blockable, NULL);
+					     mmu_notifier_range_blockable(range),
+					     NULL);
  }
 
  static int invalidate_range_end_trampoline(struct ib_umem_odp *item, u64 start,

drivers/xen/gntdev.c +3 -3

index 5efc5eee9544..9da8f7192f46 100644
@@ -526,20 +526,20 @@ static int mn_invl_range_start(struct mmu_notifier *mn,
  	struct gntdev_grant_map *map;
  	int ret = 0;
 
-	if (range->blockable)
+	if (mmu_notifier_range_blockable(range))
  		mutex_lock(&priv->lock);
  	else if (!mutex_trylock(&priv->lock))
  		return -EAGAIN;
 
  	list_for_each_entry(map, &priv->maps, next) {
  		ret = unmap_if_in_range(map, range->start, range->end,
-					range->blockable);
+					mmu_notifier_range_blockable(range));
  		if (ret)
  			goto out_unlock;
  	}
  	list_for_each_entry(map, &priv->freeable_maps, next) {
  		ret = unmap_if_in_range(map, range->start, range->end,
-					range->blockable);
+					mmu_notifier_range_blockable(range));
  		if (ret)
  			goto out_unlock;
  	}

mm/hmm.c +3 -3

index 3c9781037918..a03b5083d880 100644
@@ -205,9 +205,9 @@ static int hmm_invalidate_range_start(struct mmu_notifier *mn,
  	update.start = nrange->start;
  	update.end = nrange->end;
  	update.event = HMM_UPDATE_INVALIDATE;
-	update.blockable = nrange->blockable;
+	update.blockable = mmu_notifier_range_blockable(nrange);
 
-	if (nrange->blockable)
+	if (mmu_notifier_range_blockable(nrange))
  		mutex_lock(&hmm->lock);
  	else if (!mutex_trylock(&hmm->lock)) {
  		ret = -EAGAIN;

@@ -222,7 +222,7 @@ static int hmm_invalidate_range_start(struct mmu_notifier *mn,
  	}
  	mutex_unlock(&hmm->lock);
 
-	if (nrange->blockable)
+	if (mmu_notifier_range_blockable(nrange))
  		down_read(&hmm->mirrors_sem);
  	else if (!down_read_trylock(&hmm->mirrors_sem)) {
  		ret = -EAGAIN;

mm/mmu_notifier.c +1 -1

index 9c884abc7850..abd88c466eb2 100644
@@ -180,7 +180,7 @@ int __mmu_notifier_invalidate_range_start(struct mmu_notifier_range *range)
  			if (_ret) {
  				pr_info("%pS callback failed with %d in %sblockable context.\n",
  					mn->ops->invalidate_range_start, _ret,
-					!range->blockable ? "non-" : "");
+					!mmu_notifier_range_blockable(range) ? "non-" : "");
  				ret = _ret;
  			}
  		}

virt/kvm/kvm_main.c +0 -0

index 38df17b7760e..629760c0fb95 100644

From: Jérôme Glisse <[email protected]>

Use an unsigned field for flags other than blockable and convert the blockable field to be one of those flags.

Signed-off-by Jérôme Glisse <[email protected]>

Cc Christian König <[email protected]>

Cc Joonas Lahtinen <[email protected]>

Cc Jani Nikula <[email protected]>

Cc Rodrigo Vivi <[email protected]>

Cc Jan Kara <[email protected]>

Cc Andrea Arcangeli <[email protected]>

Cc Peter Xu <[email protected]>

Cc Felix Kuehling <[email protected]>

Cc Jason Gunthorpe <[email protected]>

Cc Andrew Morton <[email protected]>

Cc Ross Zwisler <[email protected]>

Cc Dan Williams <[email protected]>

Cc Paolo Bonzini <[email protected]>

Cc Radim Krčmář <[email protected]>

Cc Michal Hocko <[email protected]>

Cc Christian Koenig <[email protected]>

Cc Ralph Campbell <[email protected]>

Cc John Hubbard <[email protected]>

Cc [email protected]

Cc [email protected]

Cc [email protected]

Cc Arnd Bergmann <[email protected]>

---
  include/linux/mmu_notifier.h | 11 +++++++----
  1 file changed, 7 insertions(+), 4 deletions(-)

include/linux/mmu_notifier.h +6 -4

index e630def131ce..c8672c366f67 100644
@@ -25,11 +25,13 @@ struct mmu_notifier_mm {
  	spinlock_t lock;
  };
 
+#define MMU_NOTIFIER_RANGE_BLOCKABLE (1 << 0)
+
  struct mmu_notifier_range {
  	struct mm_struct *mm;
  	unsigned long start;
  	unsigned long end;
-	bool blockable;
+	unsigned flags;
  };
 
  struct mmu_notifier_ops {

@@ -229,7 +231,7 @@ extern void __mmu_notifier_invalidate_range(struct mm_struct *mm,
  static inline bool
  mmu_notifier_range_blockable(const struct mmu_notifier_range *range)
  {
-	return range->blockable;
+	return (range->flags & MMU_NOTIFIER_RANGE_BLOCKABLE);
  }
 
  static inline void mmu_notifier_release(struct mm_struct *mm)

@@ -275,7 +277,7 @@ static inline void
  mmu_notifier_invalidate_range_start(struct mmu_notifier_range *range)
  {
  	if (mm_has_notifiers(range->mm)) {
-		range->blockable = true;
+		range->flags |= MMU_NOTIFIER_RANGE_BLOCKABLE;
  		__mmu_notifier_invalidate_range_start(range);
  	}
  }

@@ -284,7 +286,7 @@ static inline int
  mmu_notifier_invalidate_range_start_nonblock(struct mmu_notifier_range *range)
  {
  	if (mm_has_notifiers(range->mm)) {
-		range->blockable = false;
+		range->flags &= ~MMU_NOTIFIER_RANGE_BLOCKABLE;
  		return __mmu_notifier_invalidate_range_start(range);
  	}
  	return 0;

From: Jérôme Glisse <[email protected]>

CPU page table update can happens for many reasons, not only as a result

of a syscall (munmap(), mprotect(), mremap(), madvise(), ...) but also as a result of kernel activities (memory compression, reclaim, migration, ...).

This patch introduce a set of enums that can be associated with each of

the events triggering a mmu notifier. Latter patches take advantages of those enum values.

- UNMAP: munmap() or mremap()
- CLEAR: page table is cleared (migration, compaction, reclaim, ...)
- PROTECTION_VMA: change in access protections for the range
- PROTECTION_PAGE: change in access protections for page in the range
- SOFT_DIRTY: soft dirtyness tracking

Being able to identify munmap() and mremap() from other reasons why the page table is cleared is important to allow user of mmu notifier to update their own internal tracking structure accordingly (on munmap or mremap it is not longer needed to track range of virtual address as it becomes invalid).

Signed-off-by Jérôme Glisse <[email protected]>

Cc Christian König <[email protected]>

Cc Joonas Lahtinen <[email protected]>

Cc Jani Nikula <[email protected]>

Cc Rodrigo Vivi <[email protected]>

Cc Jan Kara <[email protected]>

Cc Andrea Arcangeli <[email protected]>

Cc Peter Xu <[email protected]>

Cc Felix Kuehling <[email protected]>

Cc Jason Gunthorpe <[email protected]>

Cc Ross Zwisler <[email protected]>

Cc Dan Williams <[email protected]>

Cc Paolo Bonzini <[email protected]>

Cc Radim Krčmář <[email protected]>

Cc Michal Hocko <[email protected]>

Cc Christian Koenig <[email protected]>

Cc Ralph Campbell <[email protected]>

Cc John Hubbard <[email protected]>

Cc [email protected]

Cc [email protected]

Cc [email protected]

Cc Arnd Bergmann <[email protected]>

---
  include/linux/mmu_notifier.h | 30 ++++++++++++++++++++++++++++++
  1 file changed, 30 insertions(+)

include/linux/mmu_notifier.h +0 -0

index c8672c366f67..2386e71ac1b8 100644

include/linux/mmu_notifier.h +26 -0

+ *
+ * @MMU_NOTIFY_CLEAR: clear page table entry (many reasons for this like
+ * madvise() or replacing a page by another one, ...).
+ *
+ * @MMU_NOTIFY_PROTECTION_VMA: update is due to protection change for the range
+ * ie using the vma access permission (vm_page_prot) to update the whole range
+ * is enough no need to inspect changes to the CPU page table (mprotect()
+ * syscall)
+ *
+ * @MMU_NOTIFY_PROTECTION_PAGE: update is due to change in read/write flag for
+ * pages in the range so to mirror those changes the user must inspect the CPU
+ * page table (from the end callback).
+ *
+ * @MMU_NOTIFY_SOFT_DIRTY: soft dirty accounting (still same page and same
+ * access flags). User should soft dirty the page in the end callback to make
+ * sure that anyone relying on soft dirtyness catch pages that might be written
+ * through non CPU mappings.
+ */
+enum mmu_notifier_event {
+	MMU_NOTIFY_UNMAP = 0,
+	MMU_NOTIFY_CLEAR,
+	MMU_NOTIFY_PROTECTION_VMA,
+	MMU_NOTIFY_PROTECTION_PAGE,
+	MMU_NOTIFY_SOFT_DIRTY,
+};
+
  #ifdef CONFIG_MMU_NOTIFIER
 
  /*

From: Jérôme Glisse <[email protected]>

CPU page table update can happens for many reasons, not only as a result of a syscall (munmap(), mprotect(), mremap(), madvise(), ...) but also as a result of kernel activities (memory compression, reclaim, migration, ...).

Users of mmu notifier API track changes to the CPU page table and take specific action for them. While current API only provide range of virtual address affected by the change, not why the changes is happening.

This patchset do the initial mechanical convertion of all the places that calls mmu_notifier_range_init to also provide the default MMU_NOTIFY_UNMAP event as well as the vma if it is know (most invalidation happens against a given vma). Passing down the vma allows the users of mmu notifier to inspect the new vma page protection.

The MMU_NOTIFY_UNMAP is always the safe default as users of mmu notifier should assume that every for the range is going away when that event happens. A latter patch do convert mm call path to use a more appropriate events for each call.

Changes since v1:
- add the flags parameter to init range flags

This is done as 2 patches so that no call site is forgotten especialy as it uses this following coccinelle patch:

%<---------------------------------------------------------------------- @@
identifier I1, I2, I3, I4;
@@
static inline void mmu_notifier_range_init(struct mmu_notifier_range *I1,

include/linux/mmu_notifier.h +3 -0

+enum mmu_notifier_event event,
+unsigned flags,
+struct vm_area_struct *vma,

struct mm_struct *I2, unsigned long I3, unsigned long I4) { ... }

@@
@@

(quoted diff) +1 -1

-#define mmu_notifier_range_init(range, mm, start, end)
+#define mmu_notifier_range_init(range, event, flags, vma, mm, start, end)

@@
expression E1, E3, E4;
identifier I1;
@@
<...
mmu_notifier_range_init(E1,
+MMU_NOTIFY_UNMAP, 0, I1,
I1->vm_mm, E3, E4)
...>

@@
expression E1, E2, E3, E4;
identifier FN, VMA;
@@
FN(..., struct vm_area_struct *VMA, ...) {
<...
mmu_notifier_range_init(E1,
+MMU_NOTIFY_UNMAP, 0, VMA,
E2, E3, E4)
...> }

@@
expression E1, E2, E3, E4;
identifier FN, VMA;
@@
FN(...) {
struct vm_area_struct *VMA;
<...
mmu_notifier_range_init(E1,
+MMU_NOTIFY_UNMAP, 0, VMA,
E2, E3, E4)
...> }

@@
expression E1, E2, E3, E4;
identifier FN;
@@
FN(...) {
<...
mmu_notifier_range_init(E1,
+MMU_NOTIFY_UNMAP, 0, NULL,
E2, E3, E4)
...> } ---------------------------------------------------------------------->%

Applied with:
spatch --all-includes --sp-file mmu-notifier.spatch fs/proc/task_mmu.c --in-place spatch --sp-file mmu-notifier.spatch --dir kernel/events/ --in-place spatch --sp-file mmu-notifier.spatch --dir mm --in-place

Signed-off-by Jérôme Glisse <[email protected]>

Cc Christian König <[email protected]>

Cc Joonas Lahtinen <[email protected]>

Cc Jani Nikula <[email protected]>

Cc Rodrigo Vivi <[email protected]>

Cc Jan Kara <[email protected]>

Cc Andrea Arcangeli <[email protected]>

Cc Peter Xu <[email protected]>

Cc Felix Kuehling <[email protected]>

Cc Jason Gunthorpe <[email protected]>

Cc Ross Zwisler <[email protected]>

Cc Dan Williams <[email protected]>

Cc Paolo Bonzini <[email protected]>

Cc Radim Krčmář <[email protected]>

Cc Michal Hocko <[email protected]>

Cc Christian Koenig <[email protected]>

Cc Ralph Campbell <[email protected]>

Cc John Hubbard <[email protected]>

Cc [email protected]

Cc [email protected]

Cc [email protected]

Cc Arnd Bergmann <[email protected]>

---

From: Jérôme Glisse <[email protected]>

This update each existing invalidation to use the correct mmu notifier event that represent what is happening to the CPU page table. See the patch which introduced the events to see the rational behind this.

Signed-off-by Jérôme Glisse <[email protected]>

Cc Christian König <[email protected]>

Cc Joonas Lahtinen <[email protected]>

Cc Jani Nikula <[email protected]>

Cc Rodrigo Vivi <[email protected]>

Cc Jan Kara <[email protected]>

Cc Andrea Arcangeli <[email protected]>

Cc Peter Xu <[email protected]>

Cc Felix Kuehling <[email protected]>

Cc Jason Gunthorpe <[email protected]>

Cc Ross Zwisler <[email protected]>

Cc Dan Williams <[email protected]>

Cc Paolo Bonzini <[email protected]>

Cc Radim Krčmář <[email protected]>

Cc Michal Hocko <[email protected]>

Cc Christian Koenig <[email protected]>

Cc Ralph Campbell <[email protected]>

Cc John Hubbard <[email protected]>

Cc [email protected]

Cc [email protected]

Cc [email protected]

Cc Arnd Bergmann <[email protected]>

---
  fs/proc/task_mmu.c      |  4 ++--
  kernel/events/uprobes.c |  2 +-
  mm/huge_memory.c        | 14 ++++++--------
  mm/hugetlb.c            |  8 ++++----
  mm/khugepaged.c         |  2 +-
  mm/ksm.c                |  4 ++--
  mm/madvise.c            |  2 +-
  mm/memory.c             | 14 +++++++-------
  mm/migrate.c            |  4 ++--
  mm/mprotect.c           |  5 +++--
  mm/rmap.c               |  6 +++---
  11 files changed, 32 insertions(+), 33 deletions(-)

fs/proc/task_mmu.c +2 -2

index fcbd0e574917..3b93ce496dd4 100644
@@ -1151,8 +1151,8 @@ static ssize_t clear_refs_write(struct file *file, const char __user *buf,
  				break;
  			}
 
-			mmu_notifier_range_init(&range, MMU_NOTIFY_UNMAP, 0,
-						NULL, mm, 0, -1UL);
+			mmu_notifier_range_init(&range, MMU_NOTIFY_SOFT_DIRTY,
+						0, NULL, mm, 0, -1UL);
  			mmu_notifier_invalidate_range_start(&range);
  		}
  		walk_page_range(0, mm->highest_vm_end, &clear_refs_walk);

kernel/events/uprobes.c +1 -1

index 46f546bdba00..8e8342080013 100644
@@ -161,7 +161,7 @@ static int __replace_page(struct vm_area_struct *vma, unsigned long addr,
  	struct mmu_notifier_range range;
  	struct mem_cgroup *memcg;
 
-	mmu_notifier_range_init(&range, MMU_NOTIFY_UNMAP, 0, vma, mm, addr,
+	mmu_notifier_range_init(&range, MMU_NOTIFY_CLEAR, 0, vma, mm, addr,
  				addr + PAGE_SIZE);
 
  	VM_BUG_ON_PAGE(PageTransHuge(old_page), old_page);

mm/huge_memory.c +6 -8

index c9d638f1b34e..1da6ca0f0f6d 100644
@@ -1184,9 +1184,8 @@ static vm_fault_t do_huge_pmd_wp_page_fallback(struct vm_fault *vmf,
  		cond_resched();
  	}
 
-	mmu_notifier_range_init(&range, MMU_NOTIFY_UNMAP, 0, vma, vma->vm_mm,
-				haddr,
-				haddr + HPAGE_PMD_SIZE);
+	mmu_notifier_range_init(&range, MMU_NOTIFY_CLEAR, 0, vma, vma->vm_mm,
+				haddr, haddr + HPAGE_PMD_SIZE);
  	mmu_notifier_invalidate_range_start(&range);
 
  	vmf->ptl = pmd_lock(vma->vm_mm, vmf->pmd);

@@ -1349,9 +1348,8 @@ vm_fault_t do_huge_pmd_wp_page(struct vm_fault *vmf, pmd_t orig_pmd)
  				    vma, HPAGE_PMD_NR);
  	__SetPageUptodate(new_page);
 
-	mmu_notifier_range_init(&range, MMU_NOTIFY_UNMAP, 0, vma, vma->vm_mm,
-				haddr,
-				haddr + HPAGE_PMD_SIZE);
+	mmu_notifier_range_init(&range, MMU_NOTIFY_CLEAR, 0, vma, vma->vm_mm,
+				haddr, haddr + HPAGE_PMD_SIZE);
  	mmu_notifier_invalidate_range_start(&range);
 
  	spin_lock(vmf->ptl);

@@ -2028,7 +2026,7 @@ void __split_huge_pud(struct vm_area_struct *vma, pud_t *pud,
  	spinlock_t *ptl;
  	struct mmu_notifier_range range;
 
-	mmu_notifier_range_init(&range, MMU_NOTIFY_UNMAP, 0, vma, vma->vm_mm,
+	mmu_notifier_range_init(&range, MMU_NOTIFY_CLEAR, 0, vma, vma->vm_mm,
  				address & HPAGE_PUD_MASK,
  				(address & HPAGE_PUD_MASK) + HPAGE_PUD_SIZE);
  	mmu_notifier_invalidate_range_start(&range);

@@ -2247,7 +2245,7 @@ void __split_huge_pmd(struct vm_area_struct *vma, pmd_t *pmd,
  	spinlock_t *ptl;
  	struct mmu_notifier_range range;
 
-	mmu_notifier_range_init(&range, MMU_NOTIFY_UNMAP, 0, vma, vma->vm_mm,
+	mmu_notifier_range_init(&range, MMU_NOTIFY_CLEAR, 0, vma, vma->vm_mm,
  				address & HPAGE_PMD_MASK,
  				(address & HPAGE_PMD_MASK) + HPAGE_PMD_SIZE);
  	mmu_notifier_invalidate_range_start(&range);

mm/hugetlb.c +4 -4

index d9e5c5a4c004..a58115c6b0a3 100644
@@ -3250,7 +3250,7 @@ int copy_hugetlb_page_range(struct mm_struct *dst, struct mm_struct *src,
  	cow = (vma->vm_flags & (VM_SHARED | VM_MAYWRITE)) == VM_MAYWRITE;
 
  	if (cow) {
-		mmu_notifier_range_init(&range, MMU_NOTIFY_UNMAP, 0, vma, src,
+		mmu_notifier_range_init(&range, MMU_NOTIFY_CLEAR, 0, vma, src,
  					vma->vm_start,
  					vma->vm_end);
  		mmu_notifier_invalidate_range_start(&range);

@@ -3631,7 +3631,7 @@ static vm_fault_t hugetlb_cow(struct mm_struct *mm, struct vm_area_struct *vma,
  			    pages_per_huge_page(h));
  	__SetPageUptodate(new_page);
 
-	mmu_notifier_range_init(&range, MMU_NOTIFY_UNMAP, 0, vma, mm, haddr,
+	mmu_notifier_range_init(&range, MMU_NOTIFY_CLEAR, 0, vma, mm, haddr,
  				haddr + huge_page_size(h));
  	mmu_notifier_invalidate_range_start(&range);
 

@@ -4357,8 +4357,8 @@ unsigned long hugetlb_change_protection(struct vm_area_struct *vma,
  	 * start/end.  Set range.start/range.end to cover the maximum possible
  	 * range if PMD sharing is possible.
  	 */
-	mmu_notifier_range_init(&range, MMU_NOTIFY_UNMAP, 0, vma, mm, start,
-				end);
+	mmu_notifier_range_init(&range, MMU_NOTIFY_PROTECTION_VMA,
+				0, vma, mm, start, end);
  	adjust_range_if_pmd_sharing_possible(vma, &range.start, &range.end);
 
  	BUG_ON(address >= end);

mm/khugepaged.c +0 -0

index e7944f5e6258..579699d2b347 100644

mm/khugepaged.c +0 -0

  				address, address + HPAGE_PMD_SIZE);
  	mmu_notifier_invalidate_range_start(&range);
  	pmd_ptl = pmd_lock(mm, pmd); /* probably unnecessary */

mm/ksm.c +2 -2

index 2ea25fc0befb..b782fadade8f 100644
@@ -1066,7 +1066,7 @@ static int write_protect_page(struct vm_area_struct *vma, struct page *page,
 
  	BUG_ON(PageTransCompound(page));
 
-	mmu_notifier_range_init(&range, MMU_NOTIFY_UNMAP, 0, vma, mm,
+	mmu_notifier_range_init(&range, MMU_NOTIFY_CLEAR, 0, vma, mm,
  				pvmw.address,
  				pvmw.address + PAGE_SIZE);
  	mmu_notifier_invalidate_range_start(&range);

@@ -1155,7 +1155,7 @@ static int replace_page(struct vm_area_struct *vma, struct page *page,
  	if (!pmd)
  		goto out;
 
-	mmu_notifier_range_init(&range, MMU_NOTIFY_UNMAP, 0, vma, mm, addr,
+	mmu_notifier_range_init(&range, MMU_NOTIFY_CLEAR, 0, vma, mm, addr,
  				addr + PAGE_SIZE);
  	mmu_notifier_invalidate_range_start(&range);
 

mm/madvise.c +1 -1

index c617f53a9c09..a692d2a893b5 100644
@@ -472,7 +472,7 @@ static int madvise_free_single_vma(struct vm_area_struct *vma,
  	range.end = min(vma->vm_end, end_addr);
  	if (range.end <= vma->vm_start)
  		return -EINVAL;
-	mmu_notifier_range_init(&range, MMU_NOTIFY_UNMAP, 0, vma, mm,
+	mmu_notifier_range_init(&range, MMU_NOTIFY_CLEAR, 0, vma, mm,
  				range.start, range.end);
 
  	lru_add_drain();

mm/memory.c +7 -7

index 4565f636cca3..45dbc174a88c 100644
@@ -1010,8 +1010,8 @@ int copy_page_range(struct mm_struct *dst_mm, struct mm_struct *src_mm,
  	is_cow = is_cow_mapping(vma->vm_flags);
 
  	if (is_cow) {
-		mmu_notifier_range_init(&range, MMU_NOTIFY_UNMAP, 0, vma,
-					src_mm, addr, end);
+		mmu_notifier_range_init(&range, MMU_NOTIFY_PROTECTION_PAGE,
+					0, vma, src_mm, addr, end);
  		mmu_notifier_invalidate_range_start(&range);
  	}
 

@@ -1358,7 +1358,7 @@ void zap_page_range(struct vm_area_struct *vma, unsigned long start,
  	struct mmu_gather tlb;
 
  	lru_add_drain();
-	mmu_notifier_range_init(&range, MMU_NOTIFY_UNMAP, 0, vma, vma->vm_mm,
+	mmu_notifier_range_init(&range, MMU_NOTIFY_CLEAR, 0, vma, vma->vm_mm,
  				start, start + size);
  	tlb_gather_mmu(&tlb, vma->vm_mm, start, range.end);
  	update_hiwater_rss(vma->vm_mm);

@@ -1385,7 +1385,7 @@ static void zap_page_range_single(struct vm_area_struct *vma, unsigned long addr
  	struct mmu_gather tlb;
 
  	lru_add_drain();
-	mmu_notifier_range_init(&range, MMU_NOTIFY_UNMAP, 0, vma, vma->vm_mm,
+	mmu_notifier_range_init(&range, MMU_NOTIFY_CLEAR, 0, vma, vma->vm_mm,
  				address, address + size);
  	tlb_gather_mmu(&tlb, vma->vm_mm, address, range.end);
  	update_hiwater_rss(vma->vm_mm);

@@ -2282,7 +2282,7 @@ static vm_fault_t wp_page_copy(struct vm_fault *vmf)
 
  	__SetPageUptodate(new_page);
 
-	mmu_notifier_range_init(&range, MMU_NOTIFY_UNMAP, 0, vma, mm,
+	mmu_notifier_range_init(&range, MMU_NOTIFY_CLEAR, 0, vma, mm,
  				vmf->address & PAGE_MASK,
  				(vmf->address & PAGE_MASK) + PAGE_SIZE);
  	mmu_notifier_invalidate_range_start(&range);

@@ -4105,7 +4105,7 @@ static int __follow_pte_pmd(struct mm_struct *mm, unsigned long address,
  			goto out;
 
  		if (range) {
-			mmu_notifier_range_init(range, MMU_NOTIFY_UNMAP, 0,
+			mmu_notifier_range_init(range, MMU_NOTIFY_CLEAR, 0,
  						NULL, mm, address & PMD_MASK,
  						(address & PMD_MASK) + PMD_SIZE);
  			mmu_notifier_invalidate_range_start(range);

@@ -4124,7 +4124,7 @@ static int __follow_pte_pmd(struct mm_struct *mm, unsigned long address,
  		goto out;
 
  	if (range) {
-		mmu_notifier_range_init(range, MMU_NOTIFY_UNMAP, 0, NULL, mm,
+		mmu_notifier_range_init(range, MMU_NOTIFY_CLEAR, 0, NULL, mm,
  					address & PAGE_MASK,
  					(address & PAGE_MASK) + PAGE_SIZE);
  		mmu_notifier_invalidate_range_start(range);

mm/migrate.c +0 -0

index 81eb307b2b5b..8e6d00541b3c 100644

mm/migrate.c +0 -0

  							migrate->vma->vm_mm,
  							addr, migrate->end);

mm/mprotect.c +0 -0

index b10984052ae9..65242f1e4457 100644
@@ -185,8 +185,9 @@ static inline unsigned long change_pmd_range(struct vm_area_struct *vma,
 

mm/rmap.c +2 -2

index c6535a6ec850..627b38ad5052 100644
@@ -896,8 +896,8 @@ static bool page_mkclean_one(struct page *page, struct vm_area_struct *vma,
  	 * We have to assume the worse case ie pmd for invalidation. Note that
  	 * the page can not be free from this function.
  	 */
-	mmu_notifier_range_init(&range, MMU_NOTIFY_UNMAP, 0, vma, vma->vm_mm,
-				address,
+	mmu_notifier_range_init(&range, MMU_NOTIFY_PROTECTION_PAGE,
+				0, vma, vma->vm_mm, address,
  				min(vma->vm_end, address +
  				    (PAGE_SIZE << compound_order(page))));
  	mmu_notifier_invalidate_range_start(&range);

From: Jérôme Glisse <[email protected]>

CPU page table update can happens for many reasons, not only as a result of a syscall (munmap(), mprotect(), mremap(), madvise(), ...) but also as a result of kernel activities (memory compression, reclaim, migration, ...).

Users of mmu notifier API track changes to the CPU page table and take specific action for them. While current API only provide range of virtual address affected by the change, not why the changes is happening

This patch is just passing down the new informations by adding it to the mmu_notifier_range structure.

Changes since v1:
- Initialize flags field from mmu_notifier_range_init() arguments

Signed-off-by Jérôme Glisse <[email protected]>

Cc Christian König <[email protected]>

Cc Joonas Lahtinen <[email protected]>

Cc Jani Nikula <[email protected]>

Cc Rodrigo Vivi <[email protected]>

Cc Jan Kara <[email protected]>

Cc Andrea Arcangeli <[email protected]>

Cc Peter Xu <[email protected]>

Cc Felix Kuehling <[email protected]>

Cc Jason Gunthorpe <[email protected]>

Cc Ross Zwisler <[email protected]>

Cc Dan Williams <[email protected]>

Cc Paolo Bonzini <[email protected]>

Cc Radim Krčmář <[email protected]>

Cc Michal Hocko <[email protected]>

Cc Christian Koenig <[email protected]>

Cc Ralph Campbell <[email protected]>

Cc John Hubbard <[email protected]>

Cc [email protected]

Cc [email protected]

Cc [email protected]

Cc Arnd Bergmann <[email protected]>

---
  include/linux/mmu_notifier.h | 6 +++++-
  1 file changed, 5 insertions(+), 1 deletion(-)

include/linux/mmu_notifier.h +2 -0

index 62f94cd85455..0379956fff23 100644
@@ -58,10 +58,12 @@ struct mmu_notifier_mm {
  #define MMU_NOTIFIER_RANGE_BLOCKABLE (1 << 0)
 
  struct mmu_notifier_range {
+	struct vm_area_struct *vma;
  	struct mm_struct *mm;
  	unsigned long start;
  	unsigned long end;
  	unsigned flags;
+	enum mmu_notifier_event event;
  };
 
  struct mmu_notifier_ops {

@@ -363,10 +365,12 @@ static inline void mmu_notifier_range_init(struct mmu_notifier_range *range,
  					   unsigned long start,
  					   unsigned long end)
  {

From: Jérôme Glisse <[email protected]>

Helper to test if a range is updated to read only (it is still valid to read from the range). This is useful for device driver or anyone who wish to optimize out update when they know that they already have the range map read only.

Signed-off-by Jérôme Glisse <[email protected]>

Cc Christian König <[email protected]>

Cc Joonas Lahtinen <[email protected]>

Cc Jani Nikula <[email protected]>

Cc Rodrigo Vivi <[email protected]>

Cc Jan Kara <[email protected]>

Cc Andrea Arcangeli <[email protected]>

Cc Peter Xu <[email protected]>

Cc Felix Kuehling <[email protected]>

Cc Jason Gunthorpe <[email protected]>

Cc Ross Zwisler <[email protected]>

Cc Dan Williams <[email protected]>

Cc Paolo Bonzini <[email protected]>

Cc Radim Krčmář <[email protected]>

Cc Michal Hocko <[email protected]>

Cc Christian Koenig <[email protected]>

Cc Ralph Campbell <[email protected]>

Cc John Hubbard <[email protected]>

Cc [email protected]

Cc [email protected]

Cc [email protected]

Cc Arnd Bergmann <[email protected]>

---
  include/linux/mmu_notifier.h |  4 ++++
  mm/mmu_notifier.c            | 10 ++++++++++
  2 files changed, 14 insertions(+)

include/linux/mmu_notifier.h +4 -0

index 0379956fff23..b6c004bd9f6a 100644
@@ -259,6 +259,8 @@ extern void __mmu_notifier_invalidate_range_end(struct mmu_notifier_range *r,
  				  bool only_end);
  extern void __mmu_notifier_invalidate_range(struct mm_struct *mm,
  				  unsigned long start, unsigned long end);
+extern bool
+mmu_notifier_range_update_to_read_only(const struct mmu_notifier_range *range);
 
  static inline bool
  mmu_notifier_range_blockable(const struct mmu_notifier_range *range)

@@ -568,6 +570,8 @@ static inline void mmu_notifier_mm_destroy(struct mm_struct *mm)
  {
  }
 
+#define mmu_notifier_range_update_to_read_only(r) false
+
  #define ptep_clear_flush_young_notify ptep_clear_flush_young
  #define pmdp_clear_flush_young_notify pmdp_clear_flush_young
  #define ptep_clear_young_notify ptep_test_and_clear_young

mm/mmu_notifier.c +0 -0

index abd88c466eb2..ee36068077b6 100644
@@ -395,3 +395,13 @@ void mmu_notifier_unregister_no_release(struct mmu_notifier *mn,
  	mmdrop(mm);
  }
  EXPORT_SYMBOL_GPL(mmu_notifier_unregister_no_release);

From: Jérôme Glisse <[email protected]>

When notifying change for a range use MMU_NOTIFIER_USE_CHANGE_PTE flag for page table update that use set_pte_at_notify() and where the we are going either from read and write to read only with same pfn or read only to read and write with new pfn.

Note that set_pte_at_notify() itself should only be use in rare cases ie we do not want to use it when we are updating a significant range of virtual addresses and thus a significant number of pte. Instead for those cases the event provided to mmu notifer invalidate_range_start() callback should be use for optimization.

Changes since v1:
- Use the new unsigned flags field in struct mmu_notifier_range
- Use the new flags parameter to mmu_notifier_range_init()
- Explicitly list all the patterns where we can use change_pte()

Signed-off-by Jérôme Glisse <[email protected]>

Cc Christian König <[email protected]>

Cc Joonas Lahtinen <[email protected]>

Cc Jani Nikula <[email protected]>

Cc Rodrigo Vivi <[email protected]>

Cc Jan Kara <[email protected]>

Cc Andrea Arcangeli <[email protected]>

Cc Peter Xu <[email protected]>

Cc Felix Kuehling <[email protected]>

Cc Jason Gunthorpe <[email protected]>

Cc Ross Zwisler <[email protected]>

Cc Dan Williams <[email protected]>

Cc Paolo Bonzini <[email protected]>

Cc Radim Krčmář <[email protected]>

Cc Michal Hocko <[email protected]>

Cc Christian Koenig <[email protected]>

Cc Ralph Campbell <[email protected]>

Cc John Hubbard <[email protected]>

Cc [email protected]

Cc [email protected]

Cc [email protected]

Cc Arnd Bergmann <[email protected]>

---
  include/linux/mmu_notifier.h | 34 ++++++++++++++++++++++++++++++++--
  mm/ksm.c                     | 11 ++++++-----
  mm/memory.c                  |  5 +++--
  3 files changed, 41 insertions(+), 9 deletions(-)

include/linux/mmu_notifier.h +32 -2

index b6c004bd9f6a..0230a4b06b46 100644
@@ -40,6 +40,26 @@ enum mmu_notifier_event {
  	MMU_NOTIFY_SOFT_DIRTY,
  };
 
+/*
+ * @MMU_NOTIFIER_RANGE_BLOCKABLE: can the mmu notifier range_start/range_end
+ * callback block or not ? If set then the callback can block.
+ *
+ * @MMU_NOTIFIER_USE_CHANGE_PTE: only set when the page table it updated with
+ * the set_pte_at_notify() the valid patterns for this are:
+ *      - pte read and write to read only same pfn
+ *      - pte read only to read and write (pfn can change or stay the same)
+ *      - pte read only to read only with different pfn
+ * It is illegal to set in any other circumstances.
+ *
+ * Note that set_pte_at_notify() should not be use outside of the above cases.
+ * When updating a range in batch (like write protecting a range) it is better
+ * to rely on invalidate_range_start() and struct mmu_notifier_range to infer
+ * the kind of update that is happening (as an example you can look at the
+ * mmu_notifier_range_update_to_read_only() function).
+ */
+#define MMU_NOTIFIER_RANGE_BLOCKABLE (1 << 0)
+#define MMU_NOTIFIER_USE_CHANGE_PTE (1 << 1)
+
  #ifdef CONFIG_MMU_NOTIFIER
 
  /*

@@ -55,8 +75,6 @@ struct mmu_notifier_mm {
  	spinlock_t lock;
  };
 
-#define MMU_NOTIFIER_RANGE_BLOCKABLE (1 << 0)
-
  struct mmu_notifier_range {
  	struct vm_area_struct *vma;
  	struct mm_struct *mm;

@@ -268,6 +286,12 @@ mmu_notifier_range_blockable(const struct mmu_notifier_range *range)
  	return (range->flags & MMU_NOTIFIER_RANGE_BLOCKABLE);
  }
 
+static inline bool
+mmu_notifier_range_use_change_pte(const struct mmu_notifier_range *range)
+{
+	return (range->flags & MMU_NOTIFIER_USE_CHANGE_PTE);
+}
+
  static inline void mmu_notifier_release(struct mm_struct *mm)
  {
  	if (mm_has_notifiers(mm))

@@ -509,6 +533,12 @@ mmu_notifier_range_blockable(const struct mmu_notifier_range *range)
  	return true;
  }
 
+static inline bool
+mmu_notifier_range_use_change_pte(const struct mmu_notifier_range *range)
+{
+	return false;
+}
+
  static inline int mm_has_notifiers(struct mm_struct *mm)
  {
  	return 0;

mm/ksm.c +6 -5

index b782fadade8f..41e51882f999 100644
@@ -1066,9 +1066,9 @@ static int write_protect_page(struct vm_area_struct *vma, struct page *page,
 
  	BUG_ON(PageTransCompound(page));
 
-	mmu_notifier_range_init(&range, MMU_NOTIFY_CLEAR, 0, vma, mm,
-				pvmw.address,
-				pvmw.address + PAGE_SIZE);
+	mmu_notifier_range_init(&range, MMU_NOTIFY_CLEAR,
+				MMU_NOTIFIER_USE_CHANGE_PTE, vma, mm,
+				pvmw.address, pvmw.address + PAGE_SIZE);
  	mmu_notifier_invalidate_range_start(&range);
 
  	if (!page_vma_mapped_walk(&pvmw))

@@ -1155,8 +1155,9 @@ static int replace_page(struct vm_area_struct *vma, struct page *page,
  	if (!pmd)
  		goto out;
 
-	mmu_notifier_range_init(&range, MMU_NOTIFY_CLEAR, 0, vma, mm, addr,
-				addr + PAGE_SIZE);
+	mmu_notifier_range_init(&range, MMU_NOTIFY_CLEAR,
+				MMU_NOTIFIER_USE_CHANGE_PTE,
+				vma, mm, addr, addr + PAGE_SIZE);
  	mmu_notifier_invalidate_range_start(&range);
 
  	ptep = pte_offset_map_lock(mm, pmd, addr, &ptl);

mm/memory.c +0 -0

index 45dbc174a88c..cb71d3ff1b97 100644
@@ -2282,8 +2282,9 @@ static vm_fault_t wp_page_copy(struct vm_fault *vmf)
 

From: Jérôme Glisse <[email protected]>

Since last version [4] i added the extra bits needed for the change_pte optimization (which is a KSM thing). Here i am not posting users of this, they will be posted to the appropriate sub-systems (KVM, GPU, RDMA, ...) once this serie get upstream. If you want to look at users of this see [5] [6]. If this gets in 5.1 then i will be submitting those users for 5.2 (including KVM if KVM folks feel comfortable with it).

Quoted 10 lines · On Tue, Feb 19, 2019 at 12:04 PM <[email protected]> wrote:

From: Jérôme Glisse <[email protected]>

Since last version [4] i added the extra bits needed for the change_pte optimization (which is a KSM thing). Here i am not posting users of this, they will be posted to the appropriate sub-systems (KVM, GPU, RDMA, ...) once this serie get upstream. If you want to look at users of this see [5] [6]. If this gets in 5.1 then i will be submitting those users for 5.2 (including KVM if KVM folks feel comfortable with it).

The users look small and straightforward. Why not await acks and reviewed-by's for the users like a typical upstream submission and merge them together? Is all of the functionality of this infrastructure consumed by the proposed users? Last time I checked it was only a subset.

Quoted 12 lines · Dan Williams

Quoted 10 lines · On Tue, Feb 19, 2019 at 12:04 PM <[email protected]> wrote:

From: Jérôme Glisse <[email protected]>

Since last version [4] i added the extra bits needed for the change_pte optimization (which is a KSM thing). Here i am not posting users of this, they will be posted to the appropriate sub-systems (KVM, GPU, RDMA, ...) once this serie get upstream. If you want to look at users of this see [5] [6]. If this gets in 5.1 then i will be submitting those users for 5.2 (including KVM if KVM folks feel comfortable with it).

Quoted 5 lines

The users look small and straightforward. Why not await acks and reviewed-by's for the users like a typical upstream submission and merge them together? Is all of the functionality of this infrastructure consumed by the proposed users? Last time I checked it was only a subset.

Yes pretty much all is use, the unuse case is SOFT_DIRTY and CLEAR vs UNMAP. Both of which i intend to use. The RDMA folks already ack the patches IIRC, so did radeon and amdgpu. I believe the i915 folks were ok with it too. I do not want to merge things through Andrew for all of this we discussed that in the past, merge mm bits through Andrew in one release and bits that use things in the next release.

Quoted 19 lines · Jerome Glisse

Quoted 12 lines · Dan Williams

Quoted 10 lines · On Tue, Feb 19, 2019 at 12:04 PM <[email protected]> wrote:

From: Jérôme Glisse <[email protected]>

Since last version [4] i added the extra bits needed for the change_pte optimization (which is a KSM thing). Here i am not posting users of this, they will be posted to the appropriate sub-systems (KVM, GPU, RDMA, ...) once this serie get upstream. If you want to look at users of this see [5] [6]. If this gets in 5.1 then i will be submitting those users for 5.2 (including KVM if KVM folks feel comfortable with it).

Quoted 5 lines

The users look small and straightforward. Why not await acks and reviewed-by's for the users like a typical upstream submission and merge them together? Is all of the functionality of this infrastructure consumed by the proposed users? Last time I checked it was only a subset.

Quoted 6 lines

Yes pretty much all is use, the unuse case is SOFT_DIRTY and CLEAR vs UNMAP. Both of which i intend to use. The RDMA folks already ack the patches IIRC, so did radeon and amdgpu. I believe the i915 folks were ok with it too. I do not want to merge things through Andrew for all of this we discussed that in the past, merge mm bits through Andrew in one release and bits that use things in the next release.

It is usually cleaner for everyone to split patches like this, for instance I always prefer to merge RDMA patches via RDMA when possible. Less conflicts.

The other somewhat reasonable option is to get acks and send your own complete PR to Linus next week? That works OK for tree-wide changes.

Quoted 12 lines · Dan Williams

Quoted 10 lines · On Tue, Feb 19, 2019 at 12:04 PM <[email protected]> wrote:

From: Jérôme Glisse <[email protected]>

Since last version [4] i added the extra bits needed for the change_pte optimization (which is a KSM thing). Here i am not posting users of this, they will be posted to the appropriate sub-systems (KVM, GPU, RDMA, ...) once this serie get upstream. If you want to look at users of this see [5] [6]. If this gets in 5.1 then i will be submitting those users for 5.2 (including KVM if KVM folks feel comfortable with it).

Quoted 5 lines

The users look small and straightforward. Why not await acks and reviewed-by's for the users like a typical upstream submission and merge them together? Is all of the functionality of this infrastructure consumed by the proposed users? Last time I checked it was only a subset.

Yes pretty much all is use, the unuse case is SOFT_DIRTY and CLEAR vs UNMAP. Both of which i intend to use. The RDMA folks already ack the patches IIRC, so did radeon and amdgpu. I believe the i915 folks were ok with it too. I do not want to merge things through Andrew for all of this we discussed that in the past, merge mm bits through Andrew in one release and bits that use things in the next release.

Quoted 20 lines · Jerome Glisse

Quoted 12 lines · Dan Williams

Quoted 10 lines · On Tue, Feb 19, 2019 at 12:04 PM <[email protected]> wrote:

From: Jérôme Glisse <[email protected]>

Since last version [4] i added the extra bits needed for the change_pte optimization (which is a KSM thing). Here i am not posting users of this, they will be posted to the appropriate sub-systems (KVM, GPU, RDMA, ...) once this serie get upstream. If you want to look at users of this see [5] [6]. If this gets in 5.1 then i will be submitting those users for 5.2 (including KVM if KVM folks feel comfortable with it).

Quoted 5 lines

The users look small and straightforward. Why not await acks and reviewed-by's for the users like a typical upstream submission and merge them together? Is all of the functionality of this infrastructure consumed by the proposed users? Last time I checked it was only a subset.

Quoted 6 lines

Yes pretty much all is use, the unuse case is SOFT_DIRTY and CLEAR vs UNMAP. Both of which i intend to use. The RDMA folks already ack the patches IIRC, so did radeon and amdgpu. I believe the i915 folks were ok with it too. I do not want to merge things through Andrew for all of this we discussed that in the past, merge mm bits through Andrew in one release and bits that use things in the next release.

Ok, I was trying to find the links to the acks on the mailing list, those references would address my concerns. I see no reason to rush SOFT_DIRTY and CLEAR ahead of the upstream user.

Quoted 28 lines · Dan Williams

Quoted 20 lines · Jerome Glisse

Quoted 12 lines · Dan Williams

Quoted 10 lines · On Tue, Feb 19, 2019 at 12:04 PM <[email protected]> wrote:

From: Jérôme Glisse <[email protected]>

Since last version [4] i added the extra bits needed for the change_pte optimization (which is a KSM thing). Here i am not posting users of this, they will be posted to the appropriate sub-systems (KVM, GPU, RDMA, ...) once this serie get upstream. If you want to look at users of this see [5] [6]. If this gets in 5.1 then i will be submitting those users for 5.2 (including KVM if KVM folks feel comfortable with it).

Quoted 5 lines

The users look small and straightforward. Why not await acks and reviewed-by's for the users like a typical upstream submission and merge them together? Is all of the functionality of this infrastructure consumed by the proposed users? Last time I checked it was only a subset.

Quoted 6 lines

Yes pretty much all is use, the unuse case is SOFT_DIRTY and CLEAR vs UNMAP. Both of which i intend to use. The RDMA folks already ack the patches IIRC, so did radeon and amdgpu. I believe the i915 folks were ok with it too. I do not want to merge things through Andrew for all of this we discussed that in the past, merge mm bits through Andrew in one release and bits that use things in the next release.

Quoted 3 lines

Ok, I was trying to find the links to the acks on the mailing list, those references would address my concerns. I see no reason to rush SOFT_DIRTY and CLEAR ahead of the upstream user.

I intend to post user for those in next couple weeks for 5.2 HMM bits. So user for this (CLEAR/UNMAP/SOFTDIRTY) will definitly materialize in time for 5.2.

ACKS AMD/RADEON https://lkml.org/lkml/2019/2/1/395
ACKS RDMA https://lkml.org/lkml/2018/12/6/1473

For KVM Andrea Arcangeli seems to like the whole idea to restore the change_pte optimization but i have not got ACK from Radim or Paolo, however given the small performance improvement figure i get with it i do not see while they would not ACK.

Quoted 34 lines · Jerome Glisse

Quoted 28 lines · Dan Williams

Quoted 20 lines · Jerome Glisse

Quoted 12 lines · Dan Williams

Quoted 10 lines · On Tue, Feb 19, 2019 at 12:04 PM <[email protected]> wrote:

From: Jérôme Glisse <[email protected]>

Since last version [4] i added the extra bits needed for the change_pte optimization (which is a KSM thing). Here i am not posting users of this, they will be posted to the appropriate sub-systems (KVM, GPU, RDMA, ...) once this serie get upstream. If you want to look at users of this see [5] [6]. If this gets in 5.1 then i will be submitting those users for 5.2 (including KVM if KVM folks feel comfortable with it).

Quoted 5 lines

The users look small and straightforward. Why not await acks and reviewed-by's for the users like a typical upstream submission and merge them together? Is all of the functionality of this infrastructure consumed by the proposed users? Last time I checked it was only a subset.

Quoted 6 lines

Yes pretty much all is use, the unuse case is SOFT_DIRTY and CLEAR vs UNMAP. Both of which i intend to use. The RDMA folks already ack the patches IIRC, so did radeon and amdgpu. I believe the i915 folks were ok with it too. I do not want to merge things through Andrew for all of this we discussed that in the past, merge mm bits through Andrew in one release and bits that use things in the next release.

Quoted 3 lines

Ok, I was trying to find the links to the acks on the mailing list, those references would address my concerns. I see no reason to rush SOFT_DIRTY and CLEAR ahead of the upstream user.

Quoted 6 lines

I intend to post user for those in next couple weeks for 5.2 HMM bits. So user for this (CLEAR/UNMAP/SOFTDIRTY) will definitly materialize in time for 5.2.

ACKS AMD/RADEON https://lkml.org/lkml/2019/2/1/395
ACKS RDMA https://lkml.org/lkml/2018/12/6/1473

Nice, thanks!

Quoted 4 lines

For KVM Andrea Arcangeli seems to like the whole idea to restore the change_pte optimization but i have not got ACK from Radim or Paolo, however given the small performance improvement figure i get with it i do not see while they would not ACK.

Sure, but no need to push ahead without that confirmation, right? At least for the piece that KVM cares about, maybe that's already covered in the infrastructure RDMA and RADEON are using?