[26.04_linux-nvidia]: Backport: "mm/gup: fix GUP-fast fallback for NULL-mapping order-0 folios" - #531
Closed
jamieNguyenNVIDIA wants to merge 1 commit into
Conversation
Contributor
PR Validation ReportPatchscan ✅ No Missing FixesAll cherry-picked commits checked — no missing upstream fixes found. PR Lint ❌ Errors foundDetailsChecking 1 commits...
Cherry-pick digest:
┌──────────────┬──────────────────────────────────────────────────────────────────┬────────────┬─────────┬───────────────────────────┐
│ Local │ Referenced upstream / Patch subject │ Patch-ID │ Subject │ SoB chain │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ 3d700fb5ab3a │ [SAUCE] mm/gup: fix gup-fast fallback for null-mapping order-0 f │ N/A │ N/A │ jhubbard, akpm, jamien │
└──────────────┴──────────────────────────────────────────────────────────────────┴────────────┴─────────┴───────────────────────────┘
Lint results:
E: 3d700fb5ab3a ("mm/gup: fix GUP-fast fallback for NULL-mapping ord"): not SAUCE/UBUNTU/Revert but has no upstream reference trailer (cherry picked from commit ... or backported from ...)
|
nirmoy
approved these changes
Aug 5, 2026
nirmoy
left a comment
nirmoy
left a comment
Collaborator
There was a problem hiding this comment.
Acked-by: Nirmoy Das <nirmoyd@nvidia.com>
clsotog
approved these changes
Aug 5, 2026
clsotog
left a comment
clsotog
left a comment
Collaborator
There was a problem hiding this comment.
Acked-by: Carol L Soto <csoto@nvidia.com>
Collaborator
|
@jamieNguyenNVIDIA Can you double check the source SHA? I'm seeing a different SHA in linux-next. vs. |
Since commit f002882 ("mm: merge folio_is_secretmem() and folio_fast_pin_allowed() into gup_fast_folio_allowed()"), gup_fast_folio_allowed() falls back to the slow path for any order-0 folio with a NULL mapping when CONFIG_SECRETMEM=y. This causes a performance regression for drivers that allocate pages with alloc_page() and insert them into VMAs via vm_insert_page(). These pages legitimately have a NULL folio->mapping, but they cannot be secretmem pages. Secretmem pages are always added to the secretmem inode's page cache via filemap_add_folio(), which sets folio->mapping to the inode's i_mapping. A folio with a NULL mapping can never be a secretmem folio. The NULL-mapping check was intended to handle truncated file-backed pages (a reject_file_backed concern), not secretmem detection. When only check_secretmem is true (and reject_file_backed is false), a NULL mapping is sufficient to prove the folio is not secretmem, so the fast path can proceed. Link: https://lore.kernel.org/20260708005745.164928-1-jhubbard@nvidia.com Fixes: f002882 ("mm: merge folio_is_secretmem() and folio_fast_pin_allowed() into gup_fast_folio_allowed()") Signed-off-by: John Hubbard <jhubbard@nvidia.com> Tested-by: Sourab Gupta <sougupta@nvidia.com> Acked-by: David Hildenbrand (Arm) <david@kernel.org> Cc: Alistair Popple <apopple@nvidia.com> Cc: Balbir Singh <balbirs@nvidia.com> Cc: Zi Yan <ziy@nvidia.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> (cherry picked from commit c494788faffe67216c56623d240541fde50139c3 linux-next) Signed-off-by: Jamie Nguyen <jamien@nvidia.com>
jamieNguyenNVIDIA
force-pushed
the
jamien/7.0/gup-fast-null-mapping
branch
from
August 5, 2026 17:07
b24c16e to
3d700fb
Compare
Collaborator
|
Thanks for fixing the SHA!
|
Collaborator
|
Acked-by: Carol L Soto csoto@nvidia.com |
Collaborator
Author
|
Patched applied: https://git.launchpad.net/~canonical-kernel/ubuntu/+source/linux-nvidia/+git/resolute/commit/?h=main-next Closing PR. |
Collaborator
BaseOS Kernel ReviewSummaryNo issues found across the reviewed commits. Findings: no problems found Latest watcher review: open review Generated test plan: open test plan Kernel deb build: successful (download debs, 4 files) Head: This comment is maintained by nv-pr-bot. It is updated when the GitHub watcher publishes a newer review. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Target:
26.04_linux-nvidia· Topic:jamien/7.0/gup-fast-null-mapping· Base:c5d9f1a36baeaClean cherry-pick from linux-next:
John Hubbard, Acked-by David Hildenbrand, applied by Andrew Morton.
Lore thread.
Problem
f002882ca369(present on this branch) madegup_fast_folio_allowed()bail to theslow path for any order-0 folio with a NULL
->mappingwhenCONFIG_SECRETMEM=y.Pages from
alloc_page()+vm_insert_page()legitimately have a NULL mapping, soevery
pin_user_pages_fast()over such a range misses the fast path — nvidia-fs(GPUDirect Storage) allocates its shadow buffers exactly this way.
The NULL check was meant to catch truncated file-backed pages, not secretmem.
Secretmem folios are published via
filemap_add_folio(), which always sets->mapping, so a NULL mapping proves the folio is not secretmem. Returning!reject_file_backedkeeps long-term writable pins on the slow path and restoresthe fast path otherwise — exactly the pre-
f002882ca369behaviour.CONFIG_SECRETMEM=yon amd64 and arm64, so this is live on every flavour we ship.Measurement (GH200, 288 cores)
A module reproducing the nvidia-fs pattern (
alloc_page+vm_insert_page, thenpin_user_pages_fast(..., FOLL_WRITE, ...)), with an anonymous-memory control thepatch cannot affect.
get_user_pages_fast_only()gives the GUP-fast verdictdirectly: 0/N unpatched, N/N patched.
Median ns/page, 512 pages/thread, 5 reps:
The anon control held at 30-35 ns/page across all four kernels, so only the affected
range moved. Stock
7.0.0-1015-nvidia-64kindependently reproduces the unpatched 64Knumbers (8 threads: 1176 vs 37), so this isn't a test-config artefact.
Single-threaded it's a wash; the win is under concurrency.
perfon the unpatched64K kernel shows the slow path is ~90% lock contention (
queued_spin_lock_slowpath72%), gone entirely once patched — contention that scales with thread count, not a
fixed per-page cost.
Risk
Low. One line in a static function with three callers, all in GUP-fast. Only
reject_file_backed == false && check_secretmem && mapping == NULLchangesbehaviour; long-term writable pins are untouched.
A secretmem folio caught mid-truncate can't happen here:
secretmem_setattr()refuses to shrink, there's no
.fallocate(so no punch-hole), andsecretmem_migrate_folio()returns-EBUSY. Only inode eviction remains, whichrequires every VMA gone — no VMA, no PTE for GUP-fast to walk. Raised by David
Hildenbrand on v1 and resolved before he Acked.
Testing
Applies cleanly; built arm64 4K/64K and x86_64, no new warnings; verified in the
binary (unpatched
mov w0, #0x0vs patchedeor w0, w0, #0x1); benchmarked as above.Bugs
nvbug: 6064778
LP: https://bugs.launchpad.net/ubuntu/+source/linux-nvidia-7.0/+bug/2162917