On 6/25/26 10:07 AM, Yousef Alhouseen wrote:
> Hi Konrad,
>
> You're right. These touch related FastRPC lifetime and bounds paths,
> and several of them depend on the same state cleanup. I grouped the
> follow-up fixes I still think are valid into a small series, and I'll
> keep any further FastRPC changes batched instead of sending more
> standalone threads.
I also like to understand how are these patches tested?
--srini
>
> Thanks,
> Yousef
>
> On Thu, 25 Jun 2026 09:40:53 +0200, Konrad Dybcio
> <[email protected]> wrote:
>> On 6/24/26 9:27 PM, Yousef Alhouseen wrote:
>>> fastrpc_rpmsg_remove() wakes pending invoke waiters when the rpmsg device
>>> is removed, but it does not release the send references taken before each
>>> request was submitted. Those references normally disappear only when a DSP
>>> reply arrives, which cannot be relied on after endpoint removal.
>>>
>>> Walk the channel IDR during removal, mark in-flight contexts completed,
>>> and schedule the send-reference put while waking waiters with -EPIPE. This
>>> prevents disconnected channels from pinning invoke contexts indefinitely.
>>>
>>> Signed-off-by: Yousef Alhouseen <[email protected]>
>>> ---
>>
>> You sent ~10 patches to fastrpc as separate threads, do they have
>> any sort of co-dependence? Can they be applied in random order?
>>
>> Generally if your changes are even vaguely related, it's best to
>> send them in a single series, if only to reduce the possibility of
>> a merge conflict
>>
>> Konrad
