The hmm_range_fault_unlocked_timeout() example checks for a concurrent mmu_interval_notifier invalidation after the HMM fault has succeeded. The sequence number used for that check is stored in range->notifier_seq by hmm_range_fault_unlocked_timeout(), so the retry check should use the same notifier stored in range as well.
Update the example to pass range.notifier to mmu_interval_read_retry(), and spell out that the retry check uses the notifier and sequence number stored in range by the HMM fault helper. This makes the relationship between the HMM walk and the later invalidation check explicit. Signed-off-by: Stanislav Kinsburskii <[email protected]> --- Documentation/mm/hmm.rst | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/Documentation/mm/hmm.rst b/Documentation/mm/hmm.rst index 5c88d2cf0818..fc1b8dc19825 100644 --- a/Documentation/mm/hmm.rst +++ b/Documentation/mm/hmm.rst @@ -206,7 +206,7 @@ The usage pattern is:: goto out_put; take_lock(driver->update); - if (mmu_interval_read_retry(&interval_sub, range.notifier_seq)) { + if (mmu_interval_read_retry(range.notifier, range.notifier_seq)) { release_lock(driver->update); goto again; } @@ -225,7 +225,8 @@ The usage pattern is:: The driver->update lock is the same lock that the driver takes inside its invalidate() callback. That lock must be held before calling mmu_interval_read_retry() to avoid any race with a concurrent CPU page table -update. +update. The retry check must use the same notifier and sequence number stored +in ``range`` by ``hmm_range_fault_unlocked_timeout()``. Holding the mmap lock across HMM faults =======================================
