FROMLIST: misc: fastrpc: fix context leak and hang on signal-interrupted invoke#1313
Open
quic-anane wants to merge 1 commit into
Open
FROMLIST: misc: fastrpc: fix context leak and hang on signal-interrupted invoke#1313quic-anane wants to merge 1 commit into
quic-anane wants to merge 1 commit into
Conversation
…ted invoke
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.
Also drain fl->interrupted on process exit and complete any sleeping
contexts with -EPIPE when the rpmsg channel is removed.
Link: https://lore.kernel.org/all/43a7laqb7mnrvleunnmbxwhvzr6w3au4ofjri4r4ap7clsx6mc@jxqlr4a2lw56/
Fixes: 387f625 ("misc: fastrpc: handle interrupted contexts")
Cc: stable@kernel.org
Signed-off-by: Anandu Krishnan E <anandu.e@oss.qualcomm.com>
qcomlnxci
requested review from
a team,
Chennak-quic and
ekanshibu
and removed request for
a team
ekanshibu
approved these changes
Jun 5, 2026
Chennak-quic
approved these changes
Jun 5, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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:
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.
Also drain fl->interrupted on process exit and complete any sleeping contexts with -EPIPE when the rpmsg channel is removed.
Link: https://lore.kernel.org/all/43a7laqb7mnrvleunnmbxwhvzr6w3au4ofjri4r4ap7clsx6mc@jxqlr4a2lw56/
Fixes: 387f625 ("misc: fastrpc: handle interrupted contexts")
Cc: stable@kernel.org
CRs-Fixed: 4411765