summaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/bin/stackcollapse-report
diff options
context:
space:
mode:
authorBreno Leitao <leitao@debian.org>2026-09-03 12:13:27 +0100
committerJassi Brar <jassisinghbrar@gmail.com>2026-10-11 19:35:45 -0500
commit4ac21f3fac3e8584fd395c59044a8e99ac618572 (patch)
tree2cb9eb47e471d3ecaaa34a6e1eca2f36789f78a8 /tools/perf/scripts/python/bin/stackcollapse-report
parente5d1c68922f04f3d0dff757dccc1c5afcaa01506 (diff)
mailbox: pcc: Free the channel before unmapping the shared memory
I am seeing a crash on PCC that is related to a an shared memory being unmapped before the IRQ is disabled, and the IRQ kicks in and hits the unmapped (NULL) address. This is a summary of what I see on my box: scmi_protocol scmi_dev.1: Message for 1 type 0 is not expected! Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004 __handle_irq_event_percpu+0x1c4/0x9e0 handle_irq_event+0x98/0x218 handle_fasteoi_irq+0x230/0x750 generic_handle_domain_irq+0xac/0x138 gic_handle_irq+0x344/0x740 call_on_irq_stack+0x30/0x48 The trapping store is iowrite32(SCMI_SHMEM_FLAG_INTR_ENABLED, &shmem->header.flags), a write of 1 at offset 4 of a NULL base. But, back to the problem, pcc_mbox_free_channel() unmaps the shared memory and clears pchan->chan.shmem *before* freeing the IRQ (aka calling mbox_free_channel()). The interrupt is still live when the mapping goes away. Free the channel first, before the memory unmap. mbox_free_channel() calls pcc_shutdown(), which frees the platform interrupt, and then unmap shared memory. Fixes: 7f9e19f207be ("mailbox: pcc: Check before sending MCTP PCC response ACK") Reviewed-by: Sudeep Holla <sudeep.holla@kernel.org> Signed-off-by: Breno Leitao <leitao@debian.org> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
Diffstat (limited to 'tools/perf/scripts/python/bin/stackcollapse-report')
0 files changed, 0 insertions, 0 deletions