Drivers: hv: mshv_vtl: fix vmemmap race in low pgmap resolver#144
Merged
Conversation
There was a problem hiding this comment.
Pull request overview
This PR addresses a race in mshv_vtl_low_huge_fault() where get_dev_pagemap() could observe a pgmap before arch_add_memory() finishes populating the vmemmap, allowing a concurrent fault to resolve a PFN whose struct page is not yet safe to dereference.
Changes:
- Introduces a driver-owned (RCU) list of “completed” VTL0 PFN ranges, published only after
devm_memremap_pages()returns. - Updates PFN-to-page resolution to consult the completed-range list rather than relying on
get_dev_pagemap()visibility timing.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
memremap_pages() makes a pgmap visible to get_dev_pagemap() before arch_add_memory() populates the vmemmap. A concurrent mshv_vtl_low_huge_fault() running while another thread is still inside MSHV_ADD_VTL0_MEMORY can resolve a pfn whose struct page sits behind an empty vmemmap PMD, oopsing on the first page_folio() deref: BUG: unable to handle page fault for address: ffffea000404ca08 PGD ... PUD ... PMD 0 RIP: 0010:mshv_vtl_low_huge_fault+0x4b/0x240 Call Trace: mshv_vtl_low_fault+0xb/0x10 __do_fault+0x32/0xa0 __handle_mm_fault+0xc2f/0x2110 Replace get_dev_pagemap()-based resolution with a driver-owned RCU list of completed VTL0 ranges. Each range is added only after devm_memremap_pages() returns, so a hit guarantees the vmemmap is populated and the struct page is initialized. Entries are never removed (pgmaps live for the life of the module). Fixes: 775741a ("Drivers: hv: mshv_vtl: use folio-aware inserters for huge VTL0 mappings") Signed-off-by: Naman Jain <namjain@linux.microsoft.com>
namancse
force-pushed
the
user/namjain/6.18-warn-fix-v4
branch
from
f6be15f to
73f6f85
Compare
hargar19
approved these changes
Jun 9, 2026
namancse
pushed a commit
to namancse/openvmm
that referenced
this pull request
Jun 10, 2026
Upgrade kernel used in OpenVMM to 6.18.0.6 release tag. This adds a fix for try_grab_folio warning in VTL2 kernel and associated Hyper-V GuestBVT test failure. Kernel PRs: microsoft/OHCL-Linux-Kernel#141 microsoft/OHCL-Linux-Kernel#144 Bug: https://microsoft.visualstudio.com/OS/_workitems/edit/62100614 Signed-off-by: Naman Jain <namjain@linux.microsoft.com>
namancse
pushed a commit
to namancse/openvmm
that referenced
this pull request
Jun 10, 2026
Upgrade kernel used in OpenVMM to 6.18.0.6 release tag. This adds a fix for try_grab_folio warning in VTL2 kernel and associated Hyper-V GuestBVT test failure. Kernel PRs: microsoft/OHCL-Linux-Kernel#141 microsoft/OHCL-Linux-Kernel#144 Bug: https://microsoft.visualstudio.com/OS/_workitems/edit/62100614 Signed-off-by: Naman Jain <namjain@linux.microsoft.com>
benhillis
pushed a commit
to microsoft/openvmm
that referenced
this pull request
Jun 10, 2026
Upgrade kernel used in OpenHCL to 6.18.0.6 release tag. This adds a fix for try_grab_folio warning in VTL2 kernel and associated Hyper-V GuestBVT test failure. Kernel PRs: microsoft/OHCL-Linux-Kernel#141 microsoft/OHCL-Linux-Kernel#144 Bug: https://microsoft.visualstudio.com/OS/_workitems/edit/62100614 Signed-off-by: Naman Jain <namjain@linux.microsoft.com> Co-authored-by: Naman Jain <namjain@linux.microsoft.com>
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
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.
memremap_pages() makes a pgmap visible to get_dev_pagemap() before arch_add_memory() populates the vmemmap. A concurrent mshv_vtl_low_huge_fault() running while another thread is still inside MSHV_ADD_VTL0_MEMORY can resolve a pfn whose struct page sits behind an empty vmemmap PMD, oopsing on the first page_folio() deref:
BUG: unable to handle page fault for address: ffffea000404ca08
PGD ... PUD ... PMD 0
RIP: 0010:mshv_vtl_low_huge_fault+0x4b/0x240
Call Trace:
mshv_vtl_low_fault+0xb/0x10
__do_fault+0x32/0xa0
__handle_mm_fault+0xc2f/0x2110
Replace get_dev_pagemap()-based resolution with a driver-owned RCU list of completed VTL0 ranges. Each range is added only after devm_memremap_pages() returns, so a hit guarantees the vmemmap is populated and the struct page is initialized. Entries are never removed (pgmaps live for the life of the module).
Fixes: 775741a ("Drivers: hv: mshv_vtl: use folio-aware inserters for huge VTL0 mappings")