On Thu, May 21, 2026 at 04:33:09PM -0700, Andrew Morton wrote: > On Wed, 20 May 2026 07:09:19 -0700 Stanislav Kinsburskii > <[email protected]> wrote: > > > This series extends the HMM framework to support userfaultfd-backed memory > > by allowing the mmap read lock to be dropped during hmm_range_fault(). > > > > Some page fault handlers — most notably userfaultfd — require the mmap lock > > to be released so that userspace can resolve the fault. The current HMM > > interface never sets FAULT_FLAG_ALLOW_RETRY, making it impossible to fault > > in pages from userfaultfd-registered regions. > > > > This series follows the established int *locked pattern from > > get_user_pages_remote() in mm/gup.c. A new entry point, > > hmm_range_fault_unlockable(), accepts an int *locked parameter. When the > > mmap lock is dropped during fault resolution (VM_FAULT_RETRY or > > VM_FAULT_COMPLETED), the function returns 0 with *locked = 0, signalling > > the caller to restart its walk. The existing hmm_range_fault() is > > refactored into a thin wrapper that passes NULL, preserving current > > behavior for all existing callers. > > > > Faulting hugetlb pages on the unlockable path is not supported because > > walk_hugetlb_range() unconditionally holds and releases > > hugetlb_vma_lock_read across the callback; if the mmap lock is dropped > > inside the callback, the VMA may be freed before the walk framework's > > unlock. Hugetlb pages already present in page tables are handled normally. > > Possible approaches to lift this limitation are documented in > > Documentation/mm/hmm.rst. > > Thanks. AI review identified one possible issue, possibly a duplicate > from the v2 series? > > > https://sashiko.dev/#/patchset/177928604779.589431.14703161356676674288.stgit@skinsburskii > > I'll take no action at this stage, shall await reviewer input. Please > poke me in a week or so if nothing has happened. >
Hi Andrew, A gentle reminder as requested: do you think this change could be taken into the mm tree? It's beneficial not only for the MSHV driver, but can be used for post-copy live migration of GPU states in future. Thanks, Stanislav > Which is quite possible - things seem rather hectic at this time and > we're almost at -rc5!
