On Thu, Jul 23, 2026 at 02:22:42PM -0700, Andrew Morton wrote:
> On Thu, 23 Jul 2026 10:36:32 -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().
> >
>
> Thanks, I've updated mm.git to this version.
>
> AI review suggests there may be some problems. Sorry, I don't recall if
> these were considered in previous versions of the patchset:
>
>
> https://sashiko.dev/#/patchset/[email protected]
>
These look like new findings, perhaps from a newer model or review prompt.
I do not think they apply here.
The unlockable path sets FAULT_FLAG_ALLOW_RETRY only when HMM provides a
non-NULL lock state pointer. The legacy hmm_range_fault() path passes NULL
and therefore does not opt in to lock-dropping faults. Fault handlers are not
supposed to return VM_FAULT_RETRY/VM_FAULT_COMPLETED with the mmap lock
dropped unless FAULT_FLAG_ALLOW_RETRY allows that, so the NULL locked state is
not expected to be dereferenced on the legacy path.
For the FAULT_FLAG_TRIED concern, HMM is not trying to emulate GUP's exact
single-address retry loop. If a fault drops mmap_lock, HMM has to restart the
range walk because the VMA/page table state may have changed. Resetting the
timeout on that path is intentional: a lock-dropping fault made progress, and
the timeout is meant to bound mmu-notifier retry churn rather than the time
spent servicing faults.
Also, the newly converted HMM users are not using this path for ordinary
file-backed page-cache population, and process-context callers can still be
interrupted by fatal signals. All the existent kernel thread callers are
capped by a timeout.
So I do not think this requires a code change.
Thanks,
Stanislav
> >
> > Changes in v11:
> > - Reject unstable address spaces in hmm_range_fault_unlocked_timeout()
> > after taking mmap_lock and before walking page tables.
> > - Compute the remaining HMM timeout budget before the time_after_eq()
> > check in drm_gpusvm_get_pages() to make sure it can't result in zero
> > and lead to infinite HMM range faulting loop.
>
> Here's how v11 altered mm.git:
>
>
> drivers/gpu/drm/drm_gpusvm.c | 4 ++--
> mm/hmm.c | 6 ++++++
> 2 files changed, 8 insertions(+), 2 deletions(-)
>
> --- a/drivers/gpu/drm/drm_gpusvm.c~b
> +++ a/drivers/gpu/drm/drm_gpusvm.c
> @@ -1422,11 +1422,11 @@ int drm_gpusvm_get_pages(struct drm_gpus
> struct dma_iova_state *state = &svm_pages->state;
>
> retry:
> + remaining = timeout - jiffies;
> +
> if (time_after_eq(jiffies, timeout))
> return -EBUSY;
>
> - remaining = timeout - jiffies;
> -
> hmm_range.notifier_seq = mmu_interval_read_begin(notifier);
> if (drm_gpusvm_pages_valid_unlocked(gpusvm, svm_pages))
> goto set_seqno;
> --- a/mm/hmm.c~b
> +++ a/mm/hmm.c
> @@ -17,6 +17,7 @@
> #include <linux/slab.h>
> #include <linux/sched.h>
> #include <linux/mmzone.h>
> +#include <linux/oom.h>
> #include <linux/pagemap.h>
> #include <linux/leafops.h>
> #include <linux/hugetlb.h>
> @@ -806,6 +807,11 @@ int hmm_range_fault_unlocked_timeout(str
> if (ret)
> return ret;
>
> + if (check_stable_address_space(mm)) {
> + mmap_read_unlock(mm);
> + return -EFAULT;
> + }
> +
> if (timeout && time_after(jiffies, deadline)) {
> mmap_read_unlock(mm);
> return -EBUSY;
> _
>
