[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20220916153516.3253582-1-alexlzhu@fb.com>
Date: Fri, 16 Sep 2022 08:35:16 -0700
From: <alexlzhu@...com>
To: <linux-doc@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
<Kernel-team@...com>
CC: Alexander Zhu <alexlzhu@...com>
Subject: [PATCH v2] docs/mm: Improve grammar on mmu_notifier documentation.
From: Alexander Zhu <alexlzhu@...com>
Improve grammar on mmu_notifier documentation.
Signed-off-by: Alexander Zhu <alexlzhu@...com>
---
Changes in v2:
-add blank line back in to avoid kernel test robot complaining
Documentation/mm/mmu_notifier.rst | 25 +++++++++++++------------
1 file changed, 13 insertions(+), 12 deletions(-)
diff --git a/Documentation/mm/mmu_notifier.rst b/Documentation/mm/mmu_notifier.rst
index df5d7777fc6b..751b6eaf456e 100644
--- a/Documentation/mm/mmu_notifier.rst
+++ b/Documentation/mm/mmu_notifier.rst
@@ -7,10 +7,11 @@ When clearing a pte/pmd we are given a choice to notify the event through
(notify version of \*_clear_flush call mmu_notifier_invalidate_range) under
the page table lock. But that notification is not necessary in all cases.
-For secondary TLB (non CPU TLB) like IOMMU TLB or device TLB (when device use
-thing like ATS/PASID to get the IOMMU to walk the CPU page table to access a
-process virtual address space). There is only 2 cases when you need to notify
-those secondary TLB while holding page table lock when clearing a pte/pmd:
+For secondary TLB (non CPU TLB) like IOMMU TLB or device TLB (when the device
+uses something like ATS/PASID to get the IOMMU to walk the CPU page table to
+access a process virtual address space). There are only 2 cases when you need
+to notify the secondary TLB while holding the page table lock when clearing
+a pte/pmd:
A) page backing address is free before mmu_notifier_invalidate_range_end()
B) a page table entry is updated to point to a new page (COW, write fault
@@ -27,13 +28,13 @@ happen:
- set page table entry to point to new page
If clearing the page table entry is not followed by a notify before setting
-the new pte/pmd value then you can break memory model like C11 or C++11 for
-the device.
+the new pte/pmd value then you can break the memory model like C11 or C++11
+for the device.
Consider the following scenario (device use a feature similar to ATS/PASID):
-Two address addrA and addrB such that \|addrA - addrB\| >= PAGE_SIZE we assume
-they are write protected for COW (other case of B apply too).
+Two addresses addrA and addrB such that \|addrA - addrB\| >= PAGE_SIZE we assume
+they are write protected for COW (other case of B applies as well).
::
@@ -87,13 +88,13 @@ they are write protected for COW (other case of B apply too).
DEV-thread-0 {read addrA from old page}
DEV-thread-2 {read addrB from new page}
-So here because at time N+2 the clear page table entry was not pair with a
-notification to invalidate the secondary TLB, the device see the new value for
-addrB before seeing the new value for addrA. This break total memory ordering
+Here because at time N+2 the clear page table entry was not paired with a
+notification to invalidate the secondary TLB, the device sees the new value for
+addrB before seeing the new value for addrA. This breaks total memory ordering
for the device.
When changing a pte to write protect or to point to a new write protected page
with same content (KSM) it is fine to delay the mmu_notifier_invalidate_range
call to mmu_notifier_invalidate_range_end() outside the page table lock. This
is true even if the thread doing the page table update is preempted right after
-releasing page table lock but before call mmu_notifier_invalidate_range_end().
+releasing the page table lock but before calling mmu_notifier_invalidate_range_end().
--
2.30.2
Powered by blists - more mailing lists