Files
linux/include/linux
Stanislav Kinsburskii 1211708312 mm/hmm: add hmm_range_fault_unlocked_timeout() for mmap lock-drop support
hmm_range_fault() requires the caller to hold the mmap read lock for the
duration of the call.  This is incompatible with mappings whose fault
handler may release the mmap lock, notably userfaultfd-managed regions,
where handle_mm_fault() can return VM_FAULT_RETRY or VM_FAULT_COMPLETED
after dropping the lock.  Drivers that need to populate device page tables
for such mappings have no way to do so today.

Add hmm_range_fault_unlocked_timeout() for callers that do not need to
hold mmap_lock across any work outside the HMM fault itself.  The helper
takes mmap_read_lock_killable() internally, calls the common HMM fault
implementation, and releases the lock before returning if it is still
held.  The timeout is specified in jiffies; passing 0 retries
indefinitely, while a non-zero timeout makes the helper return -EBUSY when
the retry budget expires.  The retry deadline is set before refreshing the
notifier sequence and acquiring mmap_lock, so contended mmap_lock
acquisition is included in the retry budget.  After acquiring mmap_lock,
the helper also rejects unstable address spaces before walking page
tables.

When handle_mm_fault() drops mmap_lock, or when the range is invalidated,
hmm_range_fault_unlocked_timeout() refreshes range->notifier_seq and
retries the walk internally.  If the lock was dropped, the retry deadline
is also restarted because a lock-dropping fault handler made progress. 
Ordinary -EBUSY retries keep the existing deadline, preserving the
caller's timeout policy for repeated mmu-notifier invalidations.

The caller only needs to perform the usual post-success
mmu_interval_read_retry() check while holding its update lock before
consuming the pfns.  If mmap_lock acquisition is interrupted or a fatal
signal is pending during retry handling, -EINTR is returned instead.

The common implementation conditionally sets FAULT_FLAG_ALLOW_RETRY and
FAULT_FLAG_KILLABLE only for hmm_range_fault_unlocked_timeout().  The
existing hmm_range_fault() path still passes no locked state, does not
allow handle_mm_fault() to drop mmap_lock, and remains a thin wrapper
preserving the existing API contract for current callers.

The previous refactor that moved page fault handling out of the page-table
walk callbacks is what makes this change small.  Faults now run after
walk_page_range() has unwound, with only mmap_lock held, so dropping it
does not interact with the walker's pte spinlock or hugetlb_vma_lock. 
Hugetlb regions therefore participate in the unlocked path uniformly with
PTE- and PMD-level mappings; no special case is required.

Documentation/mm/hmm.rst is updated with a description of the new API and
the recommended caller pattern.

Link: https://lore.kernel.org/20260723-hmm-v10-v11-2-c55b003a4b61@gmail.com
Signed-off-by: Stanislav Kinsburskii <skinsburskii@gmail.com>
Cc: Danilo Krummrich <dakr@kernel.org>
Cc: Dave Airlie <airlied@gmail.com>
Cc: David Hildenbrand <david@kernel.org>
Cc: Dexuan Cui <decui@microsoft.com>
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Cc: Jason Gunthorpe <jgg@nvidia.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: K. Y. Srinivasan <kys@microsoft.com>
Cc: Leon Romanovsky <leon@kernel.org>
Cc: Liam R. Howlett <liam@infradead.org>
Cc: Lizhi Hou <lizhi.hou@amd.com>
Cc: Long Li <longli@microsoft.com>
Cc: Lorenzo Stoakes <ljs@kernel.org>
Cc: Lyude <lyude@redhat.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Oded Gabbay <ogabbay@kernel.org>
Cc: Shuah Khan <shuah@kernel.org>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: Thomas Zimemrmann <tzimmermann@suse.de>
Cc: Vlastimil Babka <vbabka@kernel.org>
Cc: Wei Liu <wei.liu@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-08-04 19:18:54 -07:00
..
2026-07-23 10:24:12 -07:00
2026-04-02 15:52:49 +02:00
2026-03-18 15:11:40 +05:30
2026-05-21 13:04:42 +02:00
2026-03-19 23:55:27 +01:00
2026-06-17 11:32:14 +01:00
2026-05-28 21:24:54 -07:00
2026-01-20 19:44:19 -08:00
2026-06-16 08:53:53 -07:00
2026-08-04 19:18:48 -07:00
2026-04-03 16:53:50 -04:00
2026-06-07 10:03:01 -07:00
2026-03-02 17:08:05 -05:00
2026-05-28 17:45:46 -07:00
2026-06-05 00:34:55 -04:00
2026-05-18 11:16:29 +02:00
2026-05-19 17:26:07 +02:00
2025-12-13 20:04:32 +12:00
2026-05-28 11:36:59 -04:00
2026-04-07 17:38:07 +02:00
2025-12-23 11:23:10 -08:00
2026-02-27 16:40:16 +01:00
2026-06-05 17:46:17 -07:00
2026-01-12 16:52:09 +01:00
2026-05-28 21:24:43 -07:00
2026-02-06 07:29:14 -07:00
2026-07-01 15:26:47 +02:00
2026-06-10 10:42:55 -04:00
2026-04-05 13:53:28 -07:00
2026-01-05 16:43:31 +01:00
2026-01-11 06:09:11 -10:00
2026-04-01 10:19:41 +02:00
2026-04-03 16:53:50 -04:00
2026-04-03 16:53:50 -04:00
2026-03-18 09:59:57 +00:00
2026-04-05 13:53:00 -07:00
2025-12-29 11:53:38 +01:00
2026-01-26 20:02:27 -08:00
2026-03-08 11:06:53 +01:00
2026-06-26 22:18:34 -04:00
2026-03-27 07:35:05 -07:00
2026-01-30 11:34:34 +00:00
2026-07-28 21:11:47 -07:00
2026-04-05 13:53:10 -07:00
2026-02-10 11:39:31 +01:00
2026-01-11 06:09:11 -10:00
2026-04-20 11:35:17 -07:00
2026-05-26 11:02:01 +02:00
2026-02-27 16:40:16 +01:00
2026-01-11 06:09:11 -10:00
2026-03-08 11:06:53 +01:00
2026-03-31 07:04:00 -06:00
2026-03-25 20:11:29 +01:00
2026-03-13 08:22:54 +01:00
2026-05-11 16:59:43 +02:00
2026-03-12 15:05:34 +01:00
2026-03-30 16:43:24 -06:00
2026-01-30 18:26:59 -08:00
2026-06-06 15:22:44 +02:00