Re: [PATCH v1] misc: fastrpc: fix context leak and hang on signal-interrupted invoke

[Anandu Krishnan E <anandu.e@oss.qualcomm.com>]

On 25-05-2026 06:58 pm, Dmitry Baryshkov wrote:
> On Mon, May 25, 2026 at 06:12:22PM +0530, Anandu Krishnan E wrote:
>> fastrpc invokes work by sending an RPC message to the DSP and blocking
>> in wait_for_completion_interruptible() until the DSP responds. If a
>> signal arrives during this wait, the syscall returns -ERESTARTSYS and
>> the invoke context which holds the in-flight DMA buffers and
>> completion state is left stranded in fl->pending.
>>
>> On the next syscall attempt (either auto-restarted by the kernel via
>> SA_RESTART or manually retried by user-space after EINTR), a fresh
>> context is allocated and the RPC message is re-sent to the DSP. This
>> has two consequences:
>>
>>   - The original context leaks in fl->pending until the file is closed.
>>   - The DSP receives a duplicate invocation. If the DSP was mid-way
>>     through processing the first request and had issued a reverse RPC
>>     call back to the host, the retry sends a new forward request
>>     instead of the expected reverse-RPC response. The DSP thread
>>     waiting for that response is never woken, causing a hang.
>>
>> Fix this by saving the interrupted context to a new fl->interrupted
>> list on -ERESTARTSYS. When the same thread retries the invoke with a
>> matching sc, restore the context and jump directly to the wait,
>> skipping context allocation and message re-send.
> What if the userspace doesn't honour -ERESTARTSYS and submits a new
> workload?
If the same thread submits a new workload with a different sc while an
interrupted context is pending, 
fastrpc_context_restore_interrupted() detects the mismatch (ictx->sc !=
sc) and returns -EINVAL .
This blocks the new submission and forces the thread to resolve its
in-flight interrupted context first.

This is intentional. The original DSP request is still in-flight and the
DSP may issue a reverse RPC back to 
the host as part of completing it. If we allowed a new forward request
from the same thread in parallel, 
the DSP would receive an unexpected message instead of the reverse-RPC
response it is waiting for, 
causing a hang/ unexpected behavior.

i am open to new suggestions as well , can you please help suggest what
is the correct way to handle 
interrupted scenarios ?. 
>
>> Also drain fl->interrupted on process exit and complete any sleeping
>> contexts with -EPIPE when the rpmsg channel is removed.
>>
>> Fixes: 387f625585d1 ("misc: fastrpc: handle interrupted contexts")
>> Cc: stable@kernel.org
>> Signed-off-by: Anandu Krishnan E <anandu.e@oss.qualcomm.com>
>> ---
>>  drivers/misc/fastrpc.c | 69 ++++++++++++++++++++++++++++++++----------
>>  1 file changed, 53 insertions(+), 16 deletions(-)
>>