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

On 8/17/26 05:42, Breno Leitao wrote:
> Hello Adam,
>
> On Sat, Aug 15, 2026 at 11:58:16PM -0400, Adam Young wrote:
>> On 8/12/26 08:36, Breno Leitao wrote:
>>> Free the channel first, before the memory unmap. mbox_free_channel()
>>> calls pcc_shutdown(), which frees the platform interrupt, and then unmap
>>> shared memory.
>> I posted a related fix undere the MCTP PCC Driver changes.
>>
>> This fix is necessary but not sufficient to deal with the race conditions.
>> Take a look at the series of patches under here:
>>
>> https://lore.kernel.org/all/[email protected]/
> That looks like a much bigger series, with new features, open discussions,
> Nacks, and already 45 revisions.
>
> This curent fix is only meant to address a real problem (user after
> free) I am hitting in production systems.
>
> My suggestion is that we get this real issue unblocked, even if not
> complete, while you keep working on your larger series.
>
> Thanks,
> --breno

Yes.  In order to get MCTP over PCC working, and get through both Human 
and now AI code review, the series has grown again.

The Race condition you see is solved by one of the patches in the 
series.  However, it moves the start up out of the PCC specific function 
and into the Mailbox start up and teardown.  You cannot deal with the 
race conditions without doing that.

I have been chasing PCC issues for a couple years now.  The Type 2 
drivers do not typically have the issues that the extended drivers have, 
as they typically deal with a minimal amount of memory, usually just a 
single atomic word that can be coupled with the doorbell.  Extended 
memory is much more likely to trigger hidden rac conditions as the 
amount of work done per doorbell-ring or message-send is non-atomic.  
THe cases include: a doorbell coming during start up or during tear down.

I am happy to resubmit any of the changes from that series in a differnt 
name/order to get them reviewed and merged.  However, previous patches I 
submited have gotten minimal review.  I put them all in one series as I 
need the Network reviewers to be able to sign off on the end-to-end of 
the MCTP over PCC patch.

So, I am very flexible as far as what to do with the patches, but lets 
not put in half-fixes that make that process harder.