Documentation/mm/hmm.rst | 5 +++-- drivers/accel/amdxdna/aie2_ctx.c | 12 ++++-------- drivers/gpu/drm/drm_gpusvm.c | 21 ++++++--------------- drivers/gpu/drm/nouveau/nouveau_svm.c | 14 ++++++++++---- 4 files changed, 23 insertions(+), 29 deletions(-)
This small fixup series applies on top of:
[PATCH v8 0/8] mm/hmm: Add mmap lock-drop support for userfaultfd-backed mappings
The first patch updates the HMM documentation example to make the
mmu_interval_read_retry() state explicit: callers should use the notifier and
notifier_seq stored in the same hmm_range that was passed to
hmm_range_fault_unlocked_timeout().
The remaining patches adjust nouveau, amdxdna, and drm_gpusvm users so the
timeout passed to hmm_range_fault_unlocked_timeout() is treated as a relative
HMM retry budget. These callers no longer keep an absolute deadline around
their outer driver retry loops or pass a computed remaining time into HMM.
This keeps the timeout scoped to HMM's internal mmu-notifier retry handling. If
HMM succeeds and the driver later observes an invalidation through
mmu_interval_read_retry(), the driver retries the operation with a fresh HMM
retry budget.
Changes in v2:
- Kept the nouveau outer absolute timeout around the
mmu_interval_read_retry() loop. hmm_range_fault_unlocked_timeout() only
bounds HMM’s internal retries, while nouveau faults are handled from a GPU
fault worker, so userspace fatal signals cannot break an endless stream of
invalidations there.
- Updated nouveau to use time_after_eq() before calling HMM, so the remaining
timeout passed to hmm_range_fault_unlocked_timeout() is always positive and
never 0, which would mean retry indefinitely.
- Updated the nouveau fixup commit message to explain the worker-thread
timeout issue and the time_after_eq() boundary behavior.
- Fixed the amdxdna fixup commit message. It now describes
aie2_populate_range() correctly instead of carrying stale nouveau prose,
and notes that command submission still keeps its broader timeout while HMM
gets a fresh relative retry budget.
---
Stanislav Kinsburskii (4):
fixup! mm/hmm: add hmm_range_fault_unlocked_timeout() for mmap lock-drop support
fixup! drm/nouveau: use hmm_range_fault_unlocked_timeout() for SVM faults
fixup! accel/amdxdna: use hmm_range_fault_unlocked_timeout() for range population
fixup! drm/gpusvm: use hmm_range_fault_unlocked_timeout() for range faults
Documentation/mm/hmm.rst | 5 +++--
drivers/accel/amdxdna/aie2_ctx.c | 12 ++++--------
drivers/gpu/drm/drm_gpusvm.c | 21 ++++++---------------
drivers/gpu/drm/nouveau/nouveau_svm.c | 14 ++++++++++----
4 files changed, 23 insertions(+), 29 deletions(-)
On 7/15/26 00:21, Stanislav Kinsburskii wrote: > This small fixup series applies on top of: > > [PATCH v8 0/8] mm/hmm: Add mmap lock-drop support for userfaultfd-backed mappings > > The first patch updates the HMM documentation example to make the > mmu_interval_read_retry() state explicit: callers should use the notifier and > notifier_seq stored in the same hmm_range that was passed to > hmm_range_fault_unlocked_timeout(). > > The remaining patches adjust nouveau, amdxdna, and drm_gpusvm users so the > timeout passed to hmm_range_fault_unlocked_timeout() is treated as a relative > HMM retry budget. These callers no longer keep an absolute deadline around > their outer driver retry loops or pass a computed remaining time into HMM. > > This keeps the timeout scoped to HMM's internal mmu-notifier retry handling. If > HMM succeeds and the driver later observes an invalidation through > mmu_interval_read_retry(), the driver retries the operation with a fresh HMM > retry budget. > > Changes in v2: > - Kept the nouveau outer absolute timeout around the > mmu_interval_read_retry() loop. hmm_range_fault_unlocked_timeout() only > bounds HMM’s internal retries, while nouveau faults are handled from a GPU > fault worker, so userspace fatal signals cannot break an endless stream of > invalidations there. > - Updated nouveau to use time_after_eq() before calling HMM, so the remaining > timeout passed to hmm_range_fault_unlocked_timeout() is always positive and > never 0, which would mean retry indefinitely. > - Updated the nouveau fixup commit message to explain the worker-thread > timeout issue and the time_after_eq() boundary behavior. > - Fixed the amdxdna fixup commit message. It now describes > aie2_populate_range() correctly instead of carrying stale nouveau prose, > and notes that command submission still keeps its broader timeout while HMM > gets a fresh relative retry budget. > > > --- > > Stanislav Kinsburskii (4): > fixup! mm/hmm: add hmm_range_fault_unlocked_timeout() for mmap lock-drop support > fixup! drm/nouveau: use hmm_range_fault_unlocked_timeout() for SVM faults > fixup! accel/amdxdna: use hmm_range_fault_unlocked_timeout() for range population > fixup! drm/gpusvm: use hmm_range_fault_unlocked_timeout() for range faults Why a fixup series instead of properly resending the full thing? -- Cheers, David
On Wed, Jul 15, 2026 at 02:41:43PM +0200, David Hildenbrand (Arm) wrote: > On 7/15/26 00:21, Stanislav Kinsburskii wrote: > > This small fixup series applies on top of: > > > > [PATCH v8 0/8] mm/hmm: Add mmap lock-drop support for userfaultfd-backed mappings > > > > The first patch updates the HMM documentation example to make the > > mmu_interval_read_retry() state explicit: callers should use the notifier and > > notifier_seq stored in the same hmm_range that was passed to > > hmm_range_fault_unlocked_timeout(). > > > > The remaining patches adjust nouveau, amdxdna, and drm_gpusvm users so the > > timeout passed to hmm_range_fault_unlocked_timeout() is treated as a relative > > HMM retry budget. These callers no longer keep an absolute deadline around > > their outer driver retry loops or pass a computed remaining time into HMM. > > > > This keeps the timeout scoped to HMM's internal mmu-notifier retry handling. If > > HMM succeeds and the driver later observes an invalidation through > > mmu_interval_read_retry(), the driver retries the operation with a fresh HMM > > retry budget. > > > > Changes in v2: > > - Kept the nouveau outer absolute timeout around the > > mmu_interval_read_retry() loop. hmm_range_fault_unlocked_timeout() only > > bounds HMM’s internal retries, while nouveau faults are handled from a GPU > > fault worker, so userspace fatal signals cannot break an endless stream of > > invalidations there. > > - Updated nouveau to use time_after_eq() before calling HMM, so the remaining > > timeout passed to hmm_range_fault_unlocked_timeout() is always positive and > > never 0, which would mean retry indefinitely. > > - Updated the nouveau fixup commit message to explain the worker-thread > > timeout issue and the time_after_eq() boundary behavior. > > - Fixed the amdxdna fixup commit message. It now describes > > aie2_populate_range() correctly instead of carrying stale nouveau prose, > > and notes that command submission still keeps its broader timeout while HMM > > gets a fresh relative retry budget. > > > > > > --- > > > > Stanislav Kinsburskii (4): > > fixup! mm/hmm: add hmm_range_fault_unlocked_timeout() for mmap lock-drop support > > fixup! drm/nouveau: use hmm_range_fault_unlocked_timeout() for SVM faults > > fixup! accel/amdxdna: use hmm_range_fault_unlocked_timeout() for range population > > fixup! drm/gpusvm: use hmm_range_fault_unlocked_timeout() for range faults > > Why a fixup series instead of properly resending the full thing? > The goal was to get a Sashiko review, and v8 has already been applied to both `mm-new` and `linux-next`. You can find more details here: https://sashiko.dev/#/message/alaWmUEeIBeSkmO0%40skinsburskii Thanks, Stanislav > -- > Cheers, > > David
To avoid confusion: obviously please don't merge this series Andrew. On Wed, Jul 15, 2026 at 07:42:48AM -0700, Stanislav Kinsburskii wrote: > On Wed, Jul 15, 2026 at 02:41:43PM +0200, David Hildenbrand (Arm) wrote: > > On 7/15/26 00:21, Stanislav Kinsburskii wrote: > > > This small fixup series applies on top of: > > > > > > [PATCH v8 0/8] mm/hmm: Add mmap lock-drop support for userfaultfd-backed mappings > > > > > > The first patch updates the HMM documentation example to make the > > > mmu_interval_read_retry() state explicit: callers should use the notifier and > > > notifier_seq stored in the same hmm_range that was passed to > > > hmm_range_fault_unlocked_timeout(). > > > > > > The remaining patches adjust nouveau, amdxdna, and drm_gpusvm users so the > > > timeout passed to hmm_range_fault_unlocked_timeout() is treated as a relative > > > HMM retry budget. These callers no longer keep an absolute deadline around > > > their outer driver retry loops or pass a computed remaining time into HMM. > > > > > > This keeps the timeout scoped to HMM's internal mmu-notifier retry handling. If > > > HMM succeeds and the driver later observes an invalidation through > > > mmu_interval_read_retry(), the driver retries the operation with a fresh HMM > > > retry budget. > > > > > > Changes in v2: > > > - Kept the nouveau outer absolute timeout around the > > > mmu_interval_read_retry() loop. hmm_range_fault_unlocked_timeout() only > > > bounds HMM’s internal retries, while nouveau faults are handled from a GPU > > > fault worker, so userspace fatal signals cannot break an endless stream of > > > invalidations there. > > > - Updated nouveau to use time_after_eq() before calling HMM, so the remaining > > > timeout passed to hmm_range_fault_unlocked_timeout() is always positive and > > > never 0, which would mean retry indefinitely. > > > - Updated the nouveau fixup commit message to explain the worker-thread > > > timeout issue and the time_after_eq() boundary behavior. > > > - Fixed the amdxdna fixup commit message. It now describes > > > aie2_populate_range() correctly instead of carrying stale nouveau prose, > > > and notes that command submission still keeps its broader timeout while HMM > > > gets a fresh relative retry budget. > > > > > > > > > --- > > > > > > Stanislav Kinsburskii (4): > > > fixup! mm/hmm: add hmm_range_fault_unlocked_timeout() for mmap lock-drop support > > > fixup! drm/nouveau: use hmm_range_fault_unlocked_timeout() for SVM faults > > > fixup! accel/amdxdna: use hmm_range_fault_unlocked_timeout() for range population > > > fixup! drm/gpusvm: use hmm_range_fault_unlocked_timeout() for range faults > > > > Why a fixup series instead of properly resending the full thing? > > > > The goal was to get a Sashiko review, and v8 has already been applied to > both `mm-new` and `linux-next`. Please don't do this, this is completely impossible to track for review :) mm review is currently very difficult based on volumes, it'll become impossible to manage if people sound fragments of series. Please just resend the whole thing at this point. > > You can find more details here: > > https://sashiko.dev/#/message/alaWmUEeIBeSkmO0%40skinsburskii > > Thanks, Stanislav > > > -- > > Cheers, > > > > David Thanks, Lorenzo
On Wed, Jul 15, 2026 at 05:02:59PM +0100, Lorenzo Stoakes (ARM) wrote: > To avoid confusion: obviously please don't merge this series Andrew. > > On Wed, Jul 15, 2026 at 07:42:48AM -0700, Stanislav Kinsburskii wrote: > > On Wed, Jul 15, 2026 at 02:41:43PM +0200, David Hildenbrand (Arm) wrote: > > > On 7/15/26 00:21, Stanislav Kinsburskii wrote: > > > > This small fixup series applies on top of: > > > > > > > > [PATCH v8 0/8] mm/hmm: Add mmap lock-drop support for userfaultfd-backed mappings > > > > > > > > The first patch updates the HMM documentation example to make the > > > > mmu_interval_read_retry() state explicit: callers should use the notifier and > > > > notifier_seq stored in the same hmm_range that was passed to > > > > hmm_range_fault_unlocked_timeout(). > > > > > > > > The remaining patches adjust nouveau, amdxdna, and drm_gpusvm users so the > > > > timeout passed to hmm_range_fault_unlocked_timeout() is treated as a relative > > > > HMM retry budget. These callers no longer keep an absolute deadline around > > > > their outer driver retry loops or pass a computed remaining time into HMM. > > > > > > > > This keeps the timeout scoped to HMM's internal mmu-notifier retry handling. If > > > > HMM succeeds and the driver later observes an invalidation through > > > > mmu_interval_read_retry(), the driver retries the operation with a fresh HMM > > > > retry budget. > > > > > > > > Changes in v2: > > > > - Kept the nouveau outer absolute timeout around the > > > > mmu_interval_read_retry() loop. hmm_range_fault_unlocked_timeout() only > > > > bounds HMM’s internal retries, while nouveau faults are handled from a GPU > > > > fault worker, so userspace fatal signals cannot break an endless stream of > > > > invalidations there. > > > > - Updated nouveau to use time_after_eq() before calling HMM, so the remaining > > > > timeout passed to hmm_range_fault_unlocked_timeout() is always positive and > > > > never 0, which would mean retry indefinitely. > > > > - Updated the nouveau fixup commit message to explain the worker-thread > > > > timeout issue and the time_after_eq() boundary behavior. > > > > - Fixed the amdxdna fixup commit message. It now describes > > > > aie2_populate_range() correctly instead of carrying stale nouveau prose, > > > > and notes that command submission still keeps its broader timeout while HMM > > > > gets a fresh relative retry budget. > > > > > > > > > > > > --- > > > > > > > > Stanislav Kinsburskii (4): > > > > fixup! mm/hmm: add hmm_range_fault_unlocked_timeout() for mmap lock-drop support > > > > fixup! drm/nouveau: use hmm_range_fault_unlocked_timeout() for SVM faults > > > > fixup! accel/amdxdna: use hmm_range_fault_unlocked_timeout() for range population > > > > fixup! drm/gpusvm: use hmm_range_fault_unlocked_timeout() for range faults > > > > > > Why a fixup series instead of properly resending the full thing? > > > > > > > The goal was to get a Sashiko review, and v8 has already been applied to > > both `mm-new` and `linux-next`. > > Please don't do this, this is completely impossible to track for review :) > > mm review is currently very difficult based on volumes, it'll become impossible > to manage if people sound fragments of series. > > Please just resend the whole thing at this point. > Well, I followed the guidance provided by Andrew, and I believe he applied all of the changes, including these, to the `mm` tree. Do you still want me to send v9 under these circumstances? Thanks, Stanislav > > > > You can find more details here: > > > > https://sashiko.dev/#/message/alaWmUEeIBeSkmO0%40skinsburskii > > > > Thanks, Stanislav > > > > > -- > > > Cheers, > > > > > > David > > Thanks, Lorenzo
On Wed, 15 Jul 2026 09:39:37 -0700 Stanislav Kinsburskii <skinsburskii@gmail.com> wrote: > > > The goal was to get a Sashiko review, and v8 has already been applied to > > > both `mm-new` and `linux-next`. > > > > Please don't do this, this is completely impossible to track for review :) > > > > mm review is currently very difficult based on volumes, it'll become impossible > > to manage if people sound fragments of series. > > > > Please just resend the whole thing at this point. > > > > Well, I followed the guidance provided by Andrew, and I believe he > applied all of the changes, including these, to the `mm` tree. > > Do you still want me to send v9 under these circumstances? Sure, if that's what reviewers prefer. This is a bit unfriendly to people who have already reviewed the code. Which is one of the reasons why I respond to a new version with a single diff showing reviewers (and the author, and myself) what changed since the previous version.
On 7/15/26 19:14, Andrew Morton wrote: > On Wed, 15 Jul 2026 09:39:37 -0700 Stanislav Kinsburskii <skinsburskii@gmail.com> wrote: > >>> >>> Please don't do this, this is completely impossible to track for review :) >>> >>> mm review is currently very difficult based on volumes, it'll become impossible >>> to manage if people sound fragments of series. >>> >>> Please just resend the whole thing at this point. >>> >> >> Well, I followed the guidance provided by Andrew, and I believe he >> applied all of the changes, including these, to the `mm` tree. >> >> Do you still want me to send v9 under these circumstances? > > Sure, if that's what reviewers prefer. > > This is a bit unfriendly to people who have already reviewed the code. > Which is one of the reasons why I respond to a new version with a > single diff showing reviewers (and the author, and myself) what changed > since the previous version. As much as I dislike fixup patches, I tolerate them in reply to the existing series. But having some random fixup series is just crazy, really. -- Cheers, David
On Thu, Jul 16, 2026 at 10:59:56AM +0200, David Hildenbrand (Arm) wrote: > On 7/15/26 19:14, Andrew Morton wrote: > > On Wed, 15 Jul 2026 09:39:37 -0700 Stanislav Kinsburskii <skinsburskii@gmail.com> wrote: > > > >>> > >>> Please don't do this, this is completely impossible to track for review :) > >>> > >>> mm review is currently very difficult based on volumes, it'll become impossible > >>> to manage if people sound fragments of series. > >>> > >>> Please just resend the whole thing at this point. > >>> > >> > >> Well, I followed the guidance provided by Andrew, and I believe he > >> applied all of the changes, including these, to the `mm` tree. > >> > >> Do you still want me to send v9 under these circumstances? > > > > Sure, if that's what reviewers prefer. > > > > This is a bit unfriendly to people who have already reviewed the code. > > Which is one of the reasons why I respond to a new version with a > > single diff showing reviewers (and the author, and myself) what changed > > since the previous version. > > As much as I dislike fixup patches, I tolerate them in reply to the existing series. > > But having some random fixup series is just crazy, really. > > -- > Cheers, > > David Yes. Stanislav - also see Jason's suggestion - if you give a base commit then sashiko seems to work better. Maybe look at using b4 which does all of this for you automatically? Thanks, Lorenzo
On Thu, Jul 16, 2026 at 10:12:56AM +0100, Lorenzo Stoakes (ARM) wrote: > On Thu, Jul 16, 2026 at 10:59:56AM +0200, David Hildenbrand (Arm) wrote: > > On 7/15/26 19:14, Andrew Morton wrote: > > > On Wed, 15 Jul 2026 09:39:37 -0700 Stanislav Kinsburskii <skinsburskii@gmail.com> wrote: > > > > > >>> > > >>> Please don't do this, this is completely impossible to track for review :) > > >>> > > >>> mm review is currently very difficult based on volumes, it'll become impossible > > >>> to manage if people sound fragments of series. > > >>> > > >>> Please just resend the whole thing at this point. > > >>> > > >> > > >> Well, I followed the guidance provided by Andrew, and I believe he > > >> applied all of the changes, including these, to the `mm` tree. > > >> > > >> Do you still want me to send v9 under these circumstances? > > > > > > Sure, if that's what reviewers prefer. > > > > > > This is a bit unfriendly to people who have already reviewed the code. > > > Which is one of the reasons why I respond to a new version with a > > > single diff showing reviewers (and the author, and myself) what changed > > > since the previous version. > > > > As much as I dislike fixup patches, I tolerate them in reply to the existing series. > > > > But having some random fixup series is just crazy, really. > > > > -- > > Cheers, > > > > David > > Yes. > > Stanislav - also see Jason's suggestion - if you give a base commit then sashiko > seems to work better. Maybe look at using b4 which does all of this for you > automatically? > Sure. Thank you all for the suggestions. I'll use b4 next time. Thanks, Stanislav > Thanks, Lorenzo
On Wed, Jul 15, 2026 at 07:42:48AM -0700, Stanislav Kinsburskii wrote: > > > Stanislav Kinsburskii (4): > > > fixup! mm/hmm: add hmm_range_fault_unlocked_timeout() for mmap lock-drop support > > > fixup! drm/nouveau: use hmm_range_fault_unlocked_timeout() for SVM faults > > > fixup! accel/amdxdna: use hmm_range_fault_unlocked_timeout() for range population > > > fixup! drm/gpusvm: use hmm_range_fault_unlocked_timeout() for range faults > > > > Why a fixup series instead of properly resending the full thing? > > > > The goal was to get a Sashiko review, and v8 has already been applied to > both `mm-new` and `linux-next`. I think if you send the whole thing with a base-commit tag that specifies a real base commit in linux-next sashiko should work Jason
On Wed, Jul 15, 2026 at 12:02:10PM -0300, Jason Gunthorpe wrote: > On Wed, Jul 15, 2026 at 07:42:48AM -0700, Stanislav Kinsburskii wrote: > > > > > Stanislav Kinsburskii (4): > > > > fixup! mm/hmm: add hmm_range_fault_unlocked_timeout() for mmap lock-drop support > > > > fixup! drm/nouveau: use hmm_range_fault_unlocked_timeout() for SVM faults > > > > fixup! accel/amdxdna: use hmm_range_fault_unlocked_timeout() for range population > > > > fixup! drm/gpusvm: use hmm_range_fault_unlocked_timeout() for range faults > > > > > > Why a fixup series instead of properly resending the full thing? > > > > > > > The goal was to get a Sashiko review, and v8 has already been applied to > > both `mm-new` and `linux-next`. > > I think if you send the whole thing with a base-commit tag that > specifies a real base commit in linux-next sashiko should work > > Jason Oh so just use b4 then :)
© 2016 - 2026 Red Hat, Inc.