Re: [PATCH 1/2] irqchip/gic-v3-its: Zero shared pages after conversion

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] its_alloc_pages_node() can sleep while allocating memory in an atomic context when running on Arm64 Realm systems, causing a "scheduling while atomic" BUG.
--

--- Patch [1]: [PATCH 1/2] irqchip/gic-v3-its: Zero shared pages after conversion ---
commit 36d3014f90a1ff0fea959d794f1e5680dcbc80f5
Author: Steven Price <steven.price@arm.com>

irqchip/gic-v3-its: Zero shared pages after conversion

its_alloc_pages_node() passes __GFP_ZERO to the page allocator before
calling set_memory_decrypted(), but for Arm CCA with MEC the key used to
access the page will change. This masks out __GFP_ZERO from the allocation
request and zeros the page after decryption instead.

> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
> index b57d81ad33a0a..1a69eef9209e7 100644
> --- a/drivers/irqchip/irq-gic-v3-its.c
> +++ b/drivers/irqchip/irq-gic-v3-its.c
> @@ -213,10 +213,12 @@ static gfp_t gfp_flags_quirk;
>  static struct page *its_alloc_pages_node(int node, gfp_t gfp,
>  					 unsigned int order)
>  {
> +	bool want_zero = gfp & __GFP_ZERO;
>  	struct page *page;
>  	int ret = 0;
>  
> -	page = alloc_pages_node(node, gfp | gfp_flags_quirk, order);
> +	page = alloc_pages_node(node, (gfp & ~__GFP_ZERO) | gfp_flags_quirk,
> +				order);
>  
>  	if (!page)
>  		return NULL;

[Severity: High]
This is a pre-existing issue, but does the set_memory_decrypted() call that
follows this allocation sleep in an atomic context?

During CPU hotplug, gic_starting_cpu() executes with interrupts disabled
and calls its_cpu_init_lpis() -> allocate_vpe_l1_table(). This function
requests an atomic memory allocation:

drivers/irqchip/irq-gic-v3-its.c:allocate_vpe_l1_table() {
    ...
    page = its_alloc_pages(GFP_ATOMIC | __GFP_ZERO, get_order(np * PAGE_SIZE));
    ...
}

This wraps its_alloc_pages_node(), which then calls set_memory_decrypted()
unconditionally.

On Arm64 Realm guests supporting BBML2, set_memory_decrypted() eventually
calls split_kernel_leaf_mapping(), which takes a mutex:

arch/arm64/mm/mmu.c:split_kernel_leaf_mapping() {
    ...
    mutex_lock(&pgtable_split_lock);
    ...
}

Could this acquire a mutex from an atomic context and trigger a kernel panic?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260820105026.53208-1-steven.price@arm.com?part=1