From: sashiko-bot@kernel.org
To: "Fuad Tabba" <fuad.tabba@linux.dev>
Cc: kvmarm@lists.linux.dev, "Oliver Upton" <oupton@kernel.org>,
"Marc Zyngier" <maz@kernel.org>
Subject: Re: [PATCH 2/3] irqchip/gic-v4: Unwind what its_alloc_vcpu_irqs() allocated on failure
Date: Thu, 20 Aug 2026 13:03:02 +0000 [thread overview]
Message-ID: <20260820130302.E89531F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260820125053.2951078-3-fuad.tabba@linux.dev>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] vgic_v4_init() truncates its_vm.nr_vpes on vgic_v4_request_vpe_irq() failure, causing a resource leak of previously allocated VPE IRQs and SGIs during teardown.
--
--- Patch [2]: [PATCH 2/3] irqchip/gic-v4: Unwind what its_alloc_vcpu_irqs() allocated on failure ---
commit 09380ca1832d1b65e5229cfbb8e1f8ab95b65846
Author: Fuad Tabba <fuad.tabba@linux.dev>
irqchip/gic-v4: Unwind what its_alloc_vcpu_irqs() allocated on failure
This commit fixes a resource leak in its_alloc_vcpu_irqs() where SGI
domains and vPE irqs were not properly freed if the allocation loop
failed midway.
> diff --git a/drivers/irqchip/irq-gic-v4.c b/drivers/irqchip/irq-gic-v4.c
> index 754839e409f88..f707a3cb281aa 100644
> --- a/drivers/irqchip/irq-gic-v4.c
> +++ b/drivers/irqchip/irq-gic-v4.c
[ ... ]
> @@ -189,11 +191,14 @@ int its_alloc_vcpu_irqs(struct its_vm *vm)
> vm->vpes[i]->irq = vpe_base_irq + i;
> ret = its_alloc_vcpu_sgis(vm->vpes[i], i);
> if (ret)
> - goto err;
> + goto err_free_irqs;
> }
>
> return 0;
>
> +err_free_irqs:
> + its_free_sgi_irqs(vm);
> + irq_domain_free_irqs(vpe_base_irq, vm->nr_vpes);
> err:
[Severity: High]
This is a pre-existing issue, but does the teardown path in
its_free_vcpu_irqs() fully clean up resources if its_vm.nr_vpes gets
truncated?
If vgic_v4_init() in arch/arm64/kvm/vgic/vgic-v4.c fails to request an IRQ
via vgic_v4_request_vpe_irq(), it explicitly truncates nr_vpes to avoid
calling free_irq() on unrequested IRQs:
arch/arm64/kvm/vgic/vgic-v4.c:vgic_v4_init() {
...
/* Trick: adjust the number of vpes so we know how many to nuke on teardown... */
dist->its_vm.nr_vpes = i;
break;
...
}
When cleanup subsequently calls its_free_vcpu_irqs(), it relies on this
truncated nr_vpes value:
drivers/irqchip/irq-gic-v4.c:its_free_vcpu_irqs() {
...
its_free_sgi_irqs(vm);
irq_domain_free_irqs(vm->vpes[0]->irq, vm->nr_vpes);
...
}
Will this sequence leave the previously allocated IRQ domains, fwnodes, and
SGI domains orphaned for the vCPUs beyond the failure index, since they are
no longer tracked by the truncated nr_vpes count?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260820125053.2951078-1-fuad.tabba@linux.dev?part=2
next prev parent reply other threads:[~2026-08-20 13:03 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-20 12:50 [PATCH 0/3] irqchip/gic-v4, KVM: arm64: Fix the vgic init error paths Fuad Tabba
2026-08-20 12:50 ` [PATCH 1/3] irqchip/gic-v4: Clear the domain and fwnode pointers after freeing them Fuad Tabba
2026-08-20 13:06 ` sashiko-bot
2026-08-20 14:11 ` Fuad Tabba
2026-08-20 12:50 ` [PATCH 2/3] irqchip/gic-v4: Unwind what its_alloc_vcpu_irqs() allocated on failure Fuad Tabba
2026-08-20 13:03 ` sashiko-bot [this message]
2026-08-20 14:13 ` Fuad Tabba
2026-08-20 12:50 ` [PATCH 3/3] KVM: arm64: vgic: Tear down what vgic_init() created when it fails Fuad Tabba
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260820130302.E89531F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=fuad.tabba@linux.dev \
--cc=kvmarm@lists.linux.dev \
--cc=maz@kernel.org \
--cc=oupton@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.