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 <[email protected]> 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/[email protected]?part=1
