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?
>
> 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: [email protected]
> Signed-off-by: Anandu Krishnan E <[email protected]>
> ---
> drivers/misc/fastrpc.c | 69 ++++++++++++++++++++++++++++++++----------
> 1 file changed, 53 insertions(+), 16 deletions(-)
>
--
With best wishes
Dmitry
