From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 416ED2E62AC for ; Wed, 15 Jul 2026 02:17:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784081876; cv=none; b=EzO1s310nNyydRkInfLvSPSKlWzDzv+FZu/GKsbZM3CNYrxSHru1RxBbxze0qs5DGZtRlWb9l7lAVuD9FjF330xEMhPVz5RWheXPa8KwuakvpbkHs29ezTIhRs56/x1rFP9LFEoPhawcOleEQUvyG2qVrR3OKuWJgqVMcnyGsDA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784081876; c=relaxed/simple; bh=LzkHq1LqkvMMsmI7BKGu5W2VqF8IRGuBD199RUS3F2g=; h=Date:To:From:Subject:Message-Id; b=Z1w57rU5sFcKBPUbzogSfBLwkyOdW8/DadhidtsX6C/64BzAWYbejQQZpchrVtUgNywdiNzH3WvZUUxdsR6M2JoaBeWYJVFDuboS3C3K33sUxdQs32nrV+gBH1DoIC2DAUyxvmZuCc8mYgsHlam5+yA5FUMOVYNrwSHzlXIAqGw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=dApuWqCB; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="dApuWqCB" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B214D1F000E9; Wed, 15 Jul 2026 02:17:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=korg; t=1784081874; bh=zei9JuetC7c0sNuQfwkSZdj8feO3FCkhewMjpCfaSK0=; h=Date:To:From:Subject; b=dApuWqCB6GDpa1SzZ0r/YBT56IflceHQfUKKSBgrRVmKZAvK2QOrCWCXSJYVi7RMb aICscI8PwvH7IdFSXchtxj5LzssfjtbR4yPKWQBGfojwyS5bSOZdquJZPXFnOCSkxB AsJy/A/vfq/NUwolgSssU5JslfmqrBKGy7v/VDTA= Date: Tue, 14 Jul 2026 19:17:54 -0700 To: mm-commits@vger.kernel.org,wei.liu@kernel.org,vbabka@kernel.org,tzimmermann@suse.de,surenb@google.com,shuah@kernel.org,rppt@kernel.org,oleg@redhat.com,ogabbay@kernel.org,mripard@kernel.org,mhocko@suse.com,maarten.lankhorst@linux.intel.com,lyude@redhat.com,longli@microsoft.com,ljs@kernel.org,lizhi.hou@amd.com,liam@infradead.org,leon@kernel.org,kys@microsoft.com,kees@kernel.org,jgg@nvidia.com,haiyangz@microsoft.com,decui@microsoft.com,david@kernel.org,dakr@kernel.org,corbet@lwn.net,airlied@gmail.com,skinsburskii@gmail.com,akpm@linux-foundation.org From: Andrew Morton Subject: + mm-hmm-add-hmm_range_fault_unlocked_timeout-for-mmap-lock-drop-support-fix.patch added to mm-unstable branch Message-Id: <20260715021754.B214D1F000E9@smtp.kernel.org> Precedence: bulk X-Mailing-List: mm-commits@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: The patch titled Subject: mm-hmm-add-hmm_range_fault_unlocked_timeout-for-mmap-lock-drop-support-fix has been added to the -mm mm-unstable branch. Its filename is mm-hmm-add-hmm_range_fault_unlocked_timeout-for-mmap-lock-drop-support-fix.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/mm-hmm-add-hmm_range_fault_unlocked_timeout-for-mmap-lock-drop-support-fix.patch This patch will later appear in the mm-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via various branches at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there most days ------------------------------------------------------ From: Stanislav Kinsburskii Subject: mm-hmm-add-hmm_range_fault_unlocked_timeout-for-mmap-lock-drop-support-fix Date: Tue, 14 Jul 2026 15:21:28 -0700 The hmm_range_fault_unlocked_timeout() example checks for a concurrent mmu_interval_notifier invalidation after the HMM fault has succeeded. The sequence number used for that check is stored in range->notifier_seq by hmm_range_fault_unlocked_timeout(), so the retry check should use the same notifier stored in range as well. Update the example to pass range.notifier to mmu_interval_read_retry(), and spell out that the retry check uses the notifier and sequence number stored in range by the HMM fault helper. This makes the relationship between the HMM walk and the later invalidation check explicit. Link: https://lore.kernel.org/178406768885.1106335.9955379956617151440.stgit@skinsburskii Signed-off-by: Stanislav Kinsburskii Cc: Danilo Krummrich Cc: Dave Airlie Cc: David Hildenbrand Cc: Dexuan Cui Cc: Haiyang Zhang Cc: Jason Gunthorpe Cc: Jonathan Corbet Cc: Kees Cook Cc: K. Y. Srinivasan Cc: Leon Romanovsky Cc: Liam R. Howlett Cc: Lizhi Hou Cc: Long Li Cc: Lorenzo Stoakes Cc: Lyude Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Michal Hocko Cc: Mike Rapoport Cc: Oded Gabbay Cc: Oleg Nesterov Cc: Shuah Khan Cc: Suren Baghdasaryan Cc: Thomas Zimemrmann Cc: Vlastimil Babka Cc: Wei Liu Signed-off-by: Andrew Morton --- Documentation/mm/hmm.rst | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) --- a/Documentation/mm/hmm.rst~mm-hmm-add-hmm_range_fault_unlocked_timeout-for-mmap-lock-drop-support-fix +++ a/Documentation/mm/hmm.rst @@ -206,7 +206,7 @@ The usage pattern is:: goto out_put; take_lock(driver->update); - if (mmu_interval_read_retry(&interval_sub, range.notifier_seq)) { + if (mmu_interval_read_retry(range.notifier, range.notifier_seq)) { release_lock(driver->update); goto again; } @@ -225,7 +225,8 @@ The usage pattern is:: The driver->update lock is the same lock that the driver takes inside its invalidate() callback. That lock must be held before calling mmu_interval_read_retry() to avoid any race with a concurrent CPU page table -update. +update. The retry check must use the same notifier and sequence number stored +in ``range`` by ``hmm_range_fault_unlocked_timeout()``. Holding the mmap lock across HMM faults ======================================= _ Patches currently in -mm which might be from skinsburskii@gmail.com are lib-test_hmm-use-device-devt-for-coherent-device-range-selection.patch mm-hmm-move-page-fault-handling-out-of-walk-callbacks.patch mm-hmm-add-hmm_range_fault_unlocked_timeout-for-mmap-lock-drop-support.patch mm-hmm-add-hmm_range_fault_unlocked_timeout-for-mmap-lock-drop-support-fix.patch selftests-mm-add-hmm-test-for-mmap-lock-dropping-faults.patch mshv-use-hmm_range_fault_unlocked_timeout-for-region-faults.patch drm-nouveau-use-hmm_range_fault_unlocked_timeout-for-svm-faults.patch drm-nouveau-use-hmm_range_fault_unlocked_timeout-for-svm-faults-fix.patch rdma-umem-use-hmm_range_fault_unlocked_timeout-for-odp-faults.patch accel-amdxdna-use-hmm_range_fault_unlocked_timeout-for-range-population.patch accel-amdxdna-use-hmm_range_fault_unlocked_timeout-for-range-population-fix.patch drm-gpusvm-use-hmm_range_fault_unlocked_timeout-for-range-faults.patch drm-gpusvm-use-hmm_range_fault_unlocked_timeout-for-range-faults-fix.patch