Re: [PATCH] KVM: guest_memfd: fix NUMA interleave index double-counting

From: Michael S. Tsirkin

Date: Fri Jun 05 2026 - 11:01:50 EST


On Fri, Jun 05, 2026 at 06:31:51PM +0530, Garg, Shivank wrote:
>
>
> On 6/5/2026 5:16 AM, Michael S. Tsirkin wrote:
> > [You don't often get email from mst@xxxxxxxxxx. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
> >
> > On Thu, Jun 04, 2026 at 12:21:15AM +0530, Garg, Shivank wrote:
> >>
> >>
> >> On 6/3/2026 9:27 PM, Michael S. Tsirkin wrote:
> >>> kvm_gmem_get_policy() sets *ilx to the full page offset
> >>> (vm_pgoff + vma offset). But get_vma_policy() adds the page
> >>> offset on top of *ilx, so the offset is counted twice. This
> >>> causes NUMA interleaving to skip nodes: for order-0 pages the
> >>> effective index jumps by 2 for each consecutive page.
> >>>
> >>> The get_policy vm_op should return only a per-file bias in *ilx
> >>> (like shmem_get_policy does with inode->i_ino), letting
> >>> get_vma_policy() add the page-offset component.
> >>>
> >>> Fix by setting *ilx to inode->i_ino instead of the full page
> >>> offset. The page offset is computed by get_vma_policy() in
> >>> mm/mempolicy.c. The full offset is still computed
> >>> in kvm_gmem_get_policy() for mpol_shared_policy_lookup().
> >>> shmem_get_policy() follows the same pattern.
> >>>
> >>> Found by Sashiko (sashiko.dev) AI code review.
> >>>
> >>> Fixes: ed1ffa810bd6 ("KVM: guest_memfd: Enforce NUMA mempolicy using shared policy")
> >>> Cc: Sean Christopherson <seanjc@xxxxxxxxxx>
> >>> Cc: Paolo Bonzini <pbonzini@xxxxxxxxxx>
> >>> Assisted-by: Claude:claude-opus-4-6
> >>> Signed-off-by: Michael S. Tsirkin <mst@xxxxxxxxxx>
> >>> ---
> >>> virt/kvm/guest_memfd.c | 7 ++++---
> >>> 1 file changed, 4 insertions(+), 3 deletions(-)
> >>>
> >>> diff --git a/virt/kvm/guest_memfd.c b/virt/kvm/guest_memfd.c
> >>> index 69c9d6d546b2..0bcf6fc08e2d 100644
> >>> --- a/virt/kvm/guest_memfd.c
> >>> +++ b/virt/kvm/guest_memfd.c
> >>> @@ -438,11 +438,12 @@ static int kvm_gmem_set_policy(struct vm_area_struct *vma, struct mempolicy *mpo
> >>> }
> >>>
> >>> static struct mempolicy *kvm_gmem_get_policy(struct vm_area_struct *vma,
> >>> - unsigned long addr, pgoff_t *pgoff)
> >>> + unsigned long addr, pgoff_t *ilx)
> >>> {
> >>> struct inode *inode = file_inode(vma->vm_file);
> >>> + pgoff_t pgoff = vma->vm_pgoff + ((addr - vma->vm_start) >> PAGE_SHIFT);
> >>>
> >>> - *pgoff = vma->vm_pgoff + ((addr - vma->vm_start) >> PAGE_SHIFT);
> >>> + *ilx = inode->i_ino;
> >>>
> >>> /*
> >>> * Return the memory policy for this index, or NULL if none is set.
> >>> @@ -453,7 +454,7 @@ static struct mempolicy *kvm_gmem_get_policy(struct vm_area_struct *vma,
> >>> * can then replace NULL with the default memory policy instead of the
> >>> * current task's memory policy.
> >>> */
> >>> - return mpol_shared_policy_lookup(&GMEM_I(inode)->policy, *pgoff);
> >>> + return mpol_shared_policy_lookup(&GMEM_I(inode)->policy, pgoff);
> >>> }
> >>> #endif /* CONFIG_NUMA */
> >>>
> >>> --
> >>> MST
> >>>
> >>
> >> Thanks for fixing this. LGTM!
> >>
> >> Reviewed-by: Shivank Garg <shivankg@xxxxxxx>
> >
> >
> > Can u actually test it though pls?
> > Because I think another patch I sent in response so Sashiko
> > is also needed.
>
> Hi Michael,
>
> Yes, I tested this.
>
> I used kretprobes to read *ilx on each kvm_gmem_get_policy(), while calling
> get_mempolicy(MPOL_F_ADDR) on consecutive offsets(0..7) of guest_memfd mapping:
>
> BEFORE:
> page offset: 0 1 2 3 4 5 6 7
> *ilx: 0 1 2 3 4 5 6 7
>
> get_vma_policy() again add the page offset on top. so, it will increase by stride 2.
>
> AFTER Fix:
> page offset: 0 1 2 3 ... 7
> *ilx: 128376 128376 128376 128376 ... 128376
>
> It store i_no, so after get_vma_policy(), it will increase by just 1.
>
> It's hard to show any wrong allocation with the bug because this index value is not
> used by allocation path, which uses NO_INTERLEAVE_INDEX.
>
> Tested-by: Shivank Garg <shivankg@xxxxxxx>
>
> Thanks,
> Shivank
>


So for this to be useful at all
we do need the patch I sent in response to sashiko, right?
Mind trying out that one?

--
MST