[PATCH] misc: fastrpc: release pending invoke refs on rpmsg removal

[PATCH] misc: fastrpc: release pending invoke refs on rpmsg removal

[Yousef Alhouseen]

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 <alhouseenyousef@gmail.com>
---
 drivers/misc/fastrpc.c | 21 +++++++++++----------
 1 file changed, 11 insertions(+), 10 deletions(-)

diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c
index 90281859a..bfdf8ab6a 100644
--- a/drivers/misc/fastrpc.c
+++ b/drivers/misc/fastrpc.c
@@ -2580,30 +2580,31 @@ static int fastrpc_rpmsg_probe(struct rpmsg_device *rpdev)
 	return err;
 }
 
-static void fastrpc_notify_users(struct fastrpc_user *user)
+static int fastrpc_notify_context(int id, void *ptr, void *data)
 {
-	struct fastrpc_invoke_ctx *ctx;
+	struct fastrpc_invoke_ctx *ctx = ptr;
 
-	spin_lock(&user->lock);
-	list_for_each_entry(ctx, &user->pending, node) {
-		ctx->retval = -EPIPE;
-		complete(&ctx->work);
+	if (ctx->sent && !ctx->completed) {
+		ctx->completed = true;
+		schedule_work(&ctx->put_work);
 	}
-	spin_unlock(&user->lock);
+
+	ctx->retval = -EPIPE;
+	complete(&ctx->work);
+
+	return 0;
 }
 
 static void fastrpc_rpmsg_remove(struct rpmsg_device *rpdev)
 {
 	struct fastrpc_channel_ctx *cctx = dev_get_drvdata(&rpdev->dev);
 	struct fastrpc_buf *buf, *b;
-	struct fastrpc_user *user;
 	unsigned long flags;
 
 	/* No invocations past this point */
 	spin_lock_irqsave(&cctx->lock, flags);
 	cctx->rpdev = NULL;
-	list_for_each_entry(user, &cctx->users, user)
-		fastrpc_notify_users(user);
+	idr_for_each(&cctx->ctx_idr, fastrpc_notify_context, NULL);
 	spin_unlock_irqrestore(&cctx->lock, flags);
 
 	if (cctx->fdevice)
-- 
2.54.0

Re: [PATCH] misc: fastrpc: release pending invoke refs on rpmsg removal

[Konrad Dybcio]

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 <alhouseenyousef@gmail.com>
> ---

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

Re: [PATCH] misc: fastrpc: release pending invoke refs on rpmsg removal

[Yousef Alhouseen]

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.

Thanks,
Yousef

On Thu, 25 Jun 2026 09:40:53 +0200, Konrad Dybcio
<konrad.dybcio@oss.qualcomm.com> 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 <alhouseenyousef@gmail.com>
> > ---
>
> 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

Re: [PATCH] misc: fastrpc: release pending invoke refs on rpmsg removal

[Srinivas Kandagatla]

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
> <konrad.dybcio@oss.qualcomm.com> 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 <alhouseenyousef@gmail.com>
>>> ---
>>
>> 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

Re: [PATCH] misc: fastrpc: release pending invoke refs on rpmsg removal

[Yousef Alhouseen]

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 <srini@kernel.org> 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
> > <konrad.dybcio@oss.qualcomm.com> 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 <alhouseenyousef@gmail.com>
> >>> ---
> >>
> >> 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

Re: [PATCH] misc: fastrpc: release pending invoke refs on rpmsg removal

[kernel test robot]

Hi Yousef,

kernel test robot noticed the following build errors:

[auto build test ERROR on char-misc/char-misc-testing]
[also build test ERROR on char-misc/char-misc-next char-misc/char-misc-linus linus/master v7.2-rc6 next-20260806]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Yousef-Alhouseen/misc-fastrpc-release-pending-invoke-refs-on-rpmsg-removal/20260807-130030
base:   char-misc/char-misc-testing
patch link:    https://lore.kernel.org/r/20260624192700.5388-1-alhouseenyousef%40gmail.com
patch subject: [PATCH] misc: fastrpc: release pending invoke refs on rpmsg removal
config: alpha-allmodconfig (https://download.01.org/0day-ci/archive/20260807/202608071727.E43MoFeK-lkp@intel.com/config)
compiler: alpha-linux-gcc (GCC) 16.1.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260807/202608071727.E43MoFeK-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202608071727.E43MoFeK-lkp@intel.com/

All errors (new ones prefixed by >>):

   drivers/misc/fastrpc.c: In function 'fastrpc_notify_context':
>> drivers/misc/fastrpc.c:2661:16: error: 'struct fastrpc_invoke_ctx' has no member named 'sent'
    2661 |         if (ctx->sent && !ctx->completed) {
         |                ^~
>> drivers/misc/fastrpc.c:2661:30: error: 'struct fastrpc_invoke_ctx' has no member named 'completed'
    2661 |         if (ctx->sent && !ctx->completed) {
         |                              ^~
   drivers/misc/fastrpc.c:2662:20: error: 'struct fastrpc_invoke_ctx' has no member named 'completed'
    2662 |                 ctx->completed = true;
         |                    ^~


vim +2661 drivers/misc/fastrpc.c

  2656	
  2657	static int fastrpc_notify_context(int id, void *ptr, void *data)
  2658	{
  2659		struct fastrpc_invoke_ctx *ctx = ptr;
  2660	
> 2661		if (ctx->sent && !ctx->completed) {
  2662			ctx->completed = true;
  2663			schedule_work(&ctx->put_work);
  2664		}
  2665	
  2666		ctx->retval = -EPIPE;
  2667		complete(&ctx->work);
  2668	
  2669		return 0;
  2670	}
  2671	

--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

Re: [PATCH] misc: fastrpc: release pending invoke refs on rpmsg removal

[kernel test robot]

Hi Yousef,

kernel test robot noticed the following build errors:

[auto build test ERROR on char-misc/char-misc-testing]
[also build test ERROR on char-misc/char-misc-next char-misc/char-misc-linus linus/master v7.2-rc6 next-20260807]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Yousef-Alhouseen/misc-fastrpc-release-pending-invoke-refs-on-rpmsg-removal/20260807-130030
base:   char-misc/char-misc-testing
patch link:    https://lore.kernel.org/r/20260624192700.5388-1-alhouseenyousef%40gmail.com
patch subject: [PATCH] misc: fastrpc: release pending invoke refs on rpmsg removal
config: s390-randconfig-r122-20260807 (https://download.01.org/0day-ci/archive/20260808/202608080508.UGzRE4ZX-lkp@intel.com/config)
compiler: clang version 18.1.8 (https://github.com/llvm/llvm-project 3b5b5c1ec4a3095ab096dd780e84d7ab81f3d7ff)
sparse: v0.6.5-rc1
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260808/202608080508.UGzRE4ZX-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202608080508.UGzRE4ZX-lkp@intel.com/

All errors (new ones prefixed by >>):

>> drivers/misc/fastrpc.c:2661:11: error: no member named 'sent' in 'struct fastrpc_invoke_ctx'
    2661 |         if (ctx->sent && !ctx->completed) {
         |             ~~~  ^
>> drivers/misc/fastrpc.c:2661:25: error: no member named 'completed' in 'struct fastrpc_invoke_ctx'
    2661 |         if (ctx->sent && !ctx->completed) {
         |                           ~~~  ^
   drivers/misc/fastrpc.c:2662:8: error: no member named 'completed' in 'struct fastrpc_invoke_ctx'
    2662 |                 ctx->completed = true;
         |                 ~~~  ^
   3 errors generated.


vim +2661 drivers/misc/fastrpc.c

  2656	
  2657	static int fastrpc_notify_context(int id, void *ptr, void *data)
  2658	{
  2659		struct fastrpc_invoke_ctx *ctx = ptr;
  2660	
> 2661		if (ctx->sent && !ctx->completed) {
  2662			ctx->completed = true;
  2663			schedule_work(&ctx->put_work);
  2664		}
  2665	
  2666		ctx->retval = -EPIPE;
  2667		complete(&ctx->work);
  2668	
  2669		return 0;
  2670	}
  2671	

--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki