Re: [PATCH] mailbox: pcc: Free the channel before unmapping the shared memory

On Wed, Aug 12, 2026 at 05:36:03AM -0700, Breno Leitao wrote:
> 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 <[email protected]>

Digging my git repo, I found I had this fix initially as part of
Commit 9f3bbbb72ad0 ("mailbox: pcc: Initialize SHMEM before binding the
channel with the client") when I encountered that issue but then removed
to post it as separate fix which I never did 🙁.

Thanks for catching this, much appreciated!

-- 
Regards,
Sudeep