Hi Srini, The patches received strict checkpatch and focused compile/static review only. I do not have Qualcomm FastRPC hardware or a DSP setup, so there was no runtime validation of teardown, reply, or refcount races.
That is not sufficient for this lifetime change, especially given the concurrency problems raised in review. Please do not apply this patch as-is. I am pausing the FastRPC set while I reconcile it with current mailing-list work and re-audit the lifecycle assumptions. Any replacement would be an ordered series with targeted fault/race testing and clear hardware-testing limitations. Thanks, Yousef On Wed, 1 Jul 2026 21:08:58 +0100, Srinivas Kandagatla <[email protected]> wrote: > 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
