Re: [PATCH v3 04/17] KVM: arm64: Add a heap allocator for the pKVM hyp

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] ABBA deadlock between `allocator->lock` and global component locks (`host_lock_component` / `hyp_lock_component`) during memory reclaim.
--

--- Patch [4]: [PATCH v3 04/17] KVM: arm64: Add a heap allocator for the pKVM hyp ---
commit d447b5e9c6a4ffa49271c884ed8ffeb170f35542
Author: Vincent Donnefort <vdonnefort@google.com>
    
KVM: arm64: Add a heap allocator for the pKVM hyp

This commit introduces a generic heap allocator for the pKVM hypervisor
to manage VA-contiguous memory dynamically. It allows the hypervisor to
allocate and free memory on demand, replacing static memory donations
from the host. The allocator supports memory reclaim, topping up, and 
includes chunk metadata hashing for corruption detection.

> diff --git a/arch/arm64/kvm/hyp/nvhe/alloc.c b/arch/arm64/kvm/hyp/nvhe/alloc.c
> new file mode 100644
> index 0000000000000..32c923d83f78b
> --- /dev/null
> +++ b/arch/arm64/kvm/hyp/nvhe/alloc.c

[ ... ]

> +static unsigned long hyp_allocator_drain_memcache(struct hyp_allocator *allocator,
> +						  struct kvm_hyp_memcache *host_mc,
> +						  unsigned long target)
> +{
> +	struct kvm_hyp_memcache *mc = &allocator->mc;
> +	unsigned long drained = 0;
> +
> +	while (target && mc->nr_pages) {
> +		void *page = pop_hyp_memcache(mc, hyp_phys_to_virt);
> +
> +		memset(page, 0, PAGE_SIZE);
> +		kvm_flush_dcache_to_poc(page, PAGE_SIZE);
> +		push_hyp_memcache(host_mc, page, hyp_virt_to_phys);
> +		WARN_ON(__pkvm_hyp_donate_host(hyp_virt_to_pfn(page), 1));
> +
> +		target--;
> +		drained++;
> +	}
> +
> +	return drained;
> +}
> +
> +static void hyp_allocator_reclaim(struct hyp_allocator *allocator, struct kvm_hyp_memcache *host_mc,
> +				  unsigned long target)
> +{
> +	if (!target)
> +		return;
> +
> +	guard(hyp_spinlock)(&allocator->lock);
> +
> +	target -= hyp_allocator_drain_memcache(allocator, host_mc, target);

[Severity: High]
Does this sequence create an ABBA deadlock?

In hyp_allocator_reclaim(), allocator->lock is held via the guard()
before calling hyp_allocator_drain_memcache().

hyp_allocator_drain_memcache() then calls __pkvm_hyp_donate_host(),
which acquires the global component locks (host_lock_component() and
hyp_lock_component()). This establishes a locking order of:
allocator->lock -> component locks.

Since hyp_alloc() is intended to be a generic heap allocator called
during hypervisor operations (such as VM or vCPU creation) where
component locks are likely already held prior to the allocation, could a
concurrent reclaim trigger a deadlock when it tries to acquire the
component locks?

> +	if (!target)
> +		return;
> +
> +	do {

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260720171513.1415357-1-vdonnefort@google.com?part=4