Re: [PATCH v8 07/46] KVM: Rename memory attribute APIs to prepare for in-place gmem conversion

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] `kvm_range_has_vm_memory_attributes` iterates over potentially massive ranges under `rcu_read_lock()` without yielding, leading to RCU stalls.
--

Note: The format of this report is altered to provide a free-form summary
without quoting the original patch code directly due to recitation restrictions.

commit 05536cc2fad8dac656829127ace4d82d1b522580
Author: Sean Christopherson <seanjc@google.com>
Subject: KVM: Rename memory attribute APIs to prepare for in-place gmem conversion

This patch renames the memory attribute APIs to include "vm_" in anticipation
of moving PRIVATE tracking into guest_memfd. It introduces no functional
changes.

[Severity: High]
This is a pre-existing issue, but the kvm_range_has_vm_memory_attributes()
function in virt/kvm/kvm_main.c appears to iterate over a potentially massive
range under an RCU read lock without yielding.

The bounds for the loop come from the KVM_SET_MEMORY_ATTRIBUTES ioctl
handler (kvm_vm_ioctl_set_mem_attributes()), which does not place an upper
limit on the size other than preventing arithmetic overflow. If a user with a
large memcg limit pre-populates a massive range, and then calls the ioctl
again on the same range, the loop using xas_next() inside the guard(rcu)()
block will iterate over the entire range.

Since it does not yield, a sufficiently large range (e.g., billions of
elements) could run for tens of seconds, causing an RCU stall or soft lockup.

Could this code drop the RCU lock and yield periodically, or process in
batches, to prevent unprivileged userspace from causing lockups here?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260618-gmem-inplace-conversion-v8-0-9d2959357853@google.com?part=7