From: "David Hildenbrand (Arm)" <david@kernel.org>
To: Stanislav Kinsburskii <skinsburskii@gmail.com>,
airlied@gmail.com, akhilesh@ee.iitb.ac.in,
akpm@linux-foundation.org, corbet@lwn.net, dakr@kernel.org,
decui@microsoft.com, haiyangz@microsoft.com, jgg@ziepe.ca,
kees@kernel.org, kys@microsoft.com, leon@kernel.org,
liam@infradead.org, lizhi.hou@amd.com, ljs@kernel.org,
longli@microsoft.com, lyude@redhat.com,
maarten.lankhorst@linux.intel.com, mamin506@gmail.com,
mhocko@suse.com, mripard@kernel.org,
nouveau@lists.freedesktop.org, ogabbay@kernel.org,
oleg@redhat.com, rppt@kernel.org, shuah@kernel.org,
simona@ffwll.ch, skhan@linuxfoundation.org, surenb@google.com,
tzimmermann@suse.de, vbabka@kernel.org, wei.liu@kernel.org
Cc: dri-devel@lists.freedesktop.org, intel-xe@lists.freedesktop.org,
linux-mm@kvack.org, linux-doc@vger.kernel.org,
linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-kselftest@vger.kernel.org, linux-rdma@vger.kernel.org
Subject: Re: [PATCH v9 2/8] mm/hmm: add hmm_range_fault_unlocked_timeout() for mmap lock-drop support
Date: Tue, 21 Jul 2026 17:42:53 +0200 [thread overview]
Message-ID: <3ed2043b-88e7-4a86-9efb-fe788191e8e8@kernel.org> (raw)
In-Reply-To: <178413936536.1155966.8918127042760531802.stgit@skinsburskii>
On 7/15/26 20:16, Stanislav Kinsburskii wrote:
> 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 timeout does not / cannot affect how long we might be stuck without the mmap
lock in e.g., the userfaultfd handler. And also not how long it would take to
actually grab the mmap lock.
That's expected with the timeout, right?
[...]
Nothing else jumped at me.
--
Cheers,
David
next prev parent reply other threads:[~2026-07-21 15:43 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-15 18:15 [PATCH v9 0/8] mm/hmm: Add mmap lock-drop support for userfaultfd-backed mappings Stanislav Kinsburskii
2026-07-15 18:15 ` [PATCH v9 1/8] mm/hmm: move page fault handling out of walk callbacks Stanislav Kinsburskii
2026-07-21 15:19 ` David Hildenbrand (Arm)
2026-07-15 18:16 ` [PATCH v9 2/8] mm/hmm: add hmm_range_fault_unlocked_timeout() for mmap lock-drop support Stanislav Kinsburskii
2026-07-21 15:42 ` David Hildenbrand (Arm) [this message]
2026-07-21 16:49 ` Stanislav Kinsburskii
2026-07-15 18:16 ` [PATCH v9 3/8] selftests/mm: add HMM test for mmap lock-dropping faults Stanislav Kinsburskii
2026-07-15 18:16 ` [PATCH v9 4/8] mshv: Use hmm_range_fault_unlocked_timeout() for region faults Stanislav Kinsburskii
2026-07-15 18:16 ` [PATCH v9 5/8] drm/nouveau: Use hmm_range_fault_unlocked_timeout() for SVM faults Stanislav Kinsburskii
2026-07-15 18:16 ` [PATCH v9 6/8] RDMA/umem: Use hmm_range_fault_unlocked_timeout() for ODP faults Stanislav Kinsburskii
2026-07-15 18:16 ` [PATCH v9 7/8] accel/amdxdna: Use hmm_range_fault_unlocked_timeout() for range population Stanislav Kinsburskii
2026-07-15 18:16 ` [PATCH v9 8/8] drm/gpusvm: Use hmm_range_fault_unlocked_timeout() for range faults Stanislav Kinsburskii
2026-07-21 0:49 ` Matthew Brost
2026-07-15 21:17 ` [PATCH v9 0/8] mm/hmm: Add mmap lock-drop support for userfaultfd-backed mappings Andrew Morton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3ed2043b-88e7-4a86-9efb-fe788191e8e8@kernel.org \
--to=david@kernel.org \
--cc=airlied@gmail.com \
--cc=akhilesh@ee.iitb.ac.in \
--cc=akpm@linux-foundation.org \
--cc=corbet@lwn.net \
--cc=dakr@kernel.org \
--cc=decui@microsoft.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=haiyangz@microsoft.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=jgg@ziepe.ca \
--cc=kees@kernel.org \
--cc=kys@microsoft.com \
--cc=leon@kernel.org \
--cc=liam@infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-hyperv@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-rdma@vger.kernel.org \
--cc=lizhi.hou@amd.com \
--cc=ljs@kernel.org \
--cc=longli@microsoft.com \
--cc=lyude@redhat.com \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mamin506@gmail.com \
--cc=mhocko@suse.com \
--cc=mripard@kernel.org \
--cc=nouveau@lists.freedesktop.org \
--cc=ogabbay@kernel.org \
--cc=oleg@redhat.com \
--cc=rppt@kernel.org \
--cc=shuah@kernel.org \
--cc=simona@ffwll.ch \
--cc=skhan@linuxfoundation.org \
--cc=skinsburskii@gmail.com \
--cc=surenb@google.com \
--cc=tzimmermann@suse.de \
--cc=vbabka@kernel.org \
--cc=wei.liu@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox