mmu notifier cover letter

Signed-off-by: Jérôme Glisse <jglisse@redhat.com>

4 files changed, 271 insertions, 0 deletions

diff --git a/blockable.spatch b/blockable.spatch
new file mode 100644
index 000000000000..7128dffb2303
--- /dev/null
+++ b/blockable.spatch
@@ -0,0 +1,9 @@
+@@
+identifier I1, FN;
+@@
+FN(..., struct mmu_notifier_range *I1, ...) {
+<...
+-I1->blockable
++mmu_notifier_range_blockable(I1)
+...>
+}
diff --git a/cover-letter b/cover-letter
new file mode 100644
index 000000000000..37b8d9ed7af4
--- /dev/null
+++ b/cover-letter
@@ -0,0 +1,88 @@
+Changes since v5:
+    - drop KVM bits waiting for KVM people to express interest if they
+      do not then i will post patchset to remove change_pte_notify as
+      without the changes in v5 change_pte_notify is just useless (it
+      it is useless today upstream it is just wasting cpu cycles)
+
+Updated cover letter:
+
+
+Here i am not posting users of this, they already have been posted to
+appropriate mailing list [6] and will be merge through the appropriate
+tree once this patchset is upstream.
+
+Note that this serie does not change any behavior for any existing
+code. It just pass down more information to mmu notifier listener.
+
+The rational for this patchset:
+
+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:
+
+    - 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). Without this serie, driver are force to assume that
+every notification is an munmap which triggers useless trashing within
+drivers that associate structure with range of virtual address. Each
+driver is force to free up its tracking structure and then restore it
+on next device page fault. With this serie we can also optimize device
+page table update [6].
+
+More over this can also be use to optimize out some page table updates
+like for KVM where we can update the secondary MMU directly from the
+callback instead of clearing it.
+
+ACKS AMD/RADEON https://lkml.org/lkml/2019/2/1/395
+ACKS RDMA https://lkml.org/lkml/2018/12/6/1473
+
+Cheers,
+Jérôme
+
+[1] v1 https://lkml.org/lkml/2018/3/23/1049
+[2] v2 https://lkml.org/lkml/2018/12/5/10
+[3] v3 https://lkml.org/lkml/2018/12/13/620
+[4] v4 https://lkml.org/lkml/2019/1/23/838
+[5] v5 https://lkml.org/lkml/2019/2/19/752
+[6] patches to use this:
+    https://lkml.org/lkml/2019/1/23/833
+    https://lkml.org/lkml/2019/1/23/834
+    https://lkml.org/lkml/2019/1/23/832
+    https://lkml.org/lkml/2019/1/23/831
+
+Cc: Andrew Morton <akpm@linux-foundation.org>
+Cc: linux-mm@kvack.org
+Cc: Christian König <christian.koenig@amd.com>
+Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
+Cc: Jani Nikula <jani.nikula@linux.intel.com>
+Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
+Cc: Jan Kara <jack@suse.cz>
+Cc: Andrea Arcangeli <aarcange@redhat.com>
+Cc: Peter Xu <peterx@redhat.com>
+Cc: Felix Kuehling <Felix.Kuehling@amd.com>
+Cc: Jason Gunthorpe <jgg@mellanox.com>
+Cc: Ross Zwisler <zwisler@kernel.org>
+Cc: Dan Williams <dan.j.williams@intel.com>
+Cc: Paolo Bonzini <pbonzini@redhat.com>
+Cc: Alex Deucher <alexander.deucher@amd.com>
+Cc: Radim Krčmář <rkrcmar@redhat.com>
+Cc: Michal Hocko <mhocko@kernel.org>
+Cc: Christian Koenig <christian.koenig@amd.com>
+Cc: Ralph Campbell <rcampbell@nvidia.com>
+Cc: John Hubbard <jhubbard@nvidia.com>
+Cc: kvm@vger.kernel.org
+Cc: dri-devel@lists.freedesktop.org
+Cc: linux-rdma@vger.kernel.org
+Cc: Arnd Bergmann <arnd@arndb.de>
diff --git a/mmu-notifier.commit b/mmu-notifier.commit
new file mode 100644
index 000000000000..3eda15593fc2
--- /dev/null
+++ b/mmu-notifier.commit
@@ -0,0 +1,117 @@
+mm/mmu_notifier: contextual information for event triggering invalidation v2
+
+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,
++enum mmu_notifier_event event,
++unsigned flags,
++struct vm_area_struct *vma,
+struct mm_struct *I2, unsigned long I3, unsigned long I4) { ... }
+
+@@
+@@
+-#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 <jglisse@redhat.com>
+To: Andrew Morton <akpm@linux-foundation.org>
+To: linux-mm@kvack.org
+Cc: Christian König <christian.koenig@amd.com>
+Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
+Cc: Jani Nikula <jani.nikula@linux.intel.com>
+Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
+Cc: Jan Kara <jack@suse.cz>
+Cc: Andrea Arcangeli <aarcange@redhat.com>
+Cc: Peter Xu <peterx@redhat.com>
+Cc: Felix Kuehling <Felix.Kuehling@amd.com>
+Cc: Jason Gunthorpe <jgg@mellanox.com>
+Cc: Ross Zwisler <zwisler@kernel.org>
+Cc: Dan Williams <dan.j.williams@intel.com>
+Cc: Paolo Bonzini <pbonzini@redhat.com>
+Cc: Radim Krčmář <rkrcmar@redhat.com>
+Cc: Michal Hocko <mhocko@kernel.org>
+Cc: Christian Koenig <christian.koenig@amd.com>
+Cc: Ralph Campbell <rcampbell@nvidia.com>
+Cc: John Hubbard <jhubbard@nvidia.com>
+Cc: kvm@vger.kernel.org
+Cc: dri-devel@lists.freedesktop.org
+Cc: linux-rdma@vger.kernel.org
+Cc: Arnd Bergmann <arnd@arndb.de>
diff --git a/mmu-notifier.spatch b/mmu-notifier.spatch
new file mode 100644
index 000000000000..3bf594f89c5b
--- /dev/null
+++ b/mmu-notifier.spatch
@@ -0,0 +1,57 @@
+@@
+identifier I1, I2, I3, I4;
+@@
+static inline void mmu_notifier_range_init(struct mmu_notifier_range *I1,
++enum mmu_notifier_event event,
++unsigned flags,
++struct vm_area_struct *vma,
+struct mm_struct *I2, unsigned long I3, unsigned long I4) { ... }
+
+@@
+@@
+-#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)
+...> }