FROMLIST: misc: fastrpc: Add missing bug fixes#1258
Conversation
The fdlist is currently part of the meta buffer, computed during put_args. This leads to code duplication when preparing and reading critical meta buffer contents used by the FastRPC driver. Move fdlist to the invoke context structure to improve maintainability and reduce redundancy. This centralizes its handling and simplifies meta buffer preparation and reading logic. Link: https://lore.kernel.org/all/20260215182136.3995111-2-ekansh.gupta@oss.qualcomm.com/ Signed-off-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>
Replace the hardcoded context ID mask (0xFF0) with GENMASK(11, 4) to improve readability and follow kernel bitfield conventions. Use FIELD_PREP and FIELD_GET instead of manual shifts for setting and extracting ctxid values. Link: https://lore.kernel.org/all/20260215182136.3995111-3-ekansh.gupta@oss.qualcomm.com/ Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>
…support Current FastRPC context uses a 12-bit mask: [ID(8 bits)][PD type(4 bits)] = GENMASK(11, 4) This works for normal calls but fails for DSP polling mode. Polling mode expects a 16-bit layout: [15:8] = context ID (8 bits) [7:5] = reserved [4] = async mode bit [3:0] = PD type (4 bits) If async bit (bit 4) is set, DSP disables polling. With current mask, odd IDs can set this bit, causing DSP to skip poll updates. Update FASTRPC_CTXID_MASK to GENMASK(15, 8) so IDs occupy upper byte and lower byte is left for DSP flags and PD type. Reserved bits remain unused. This change is compatible with polling mode and does not break non-polling behavior. Bit layout: [15:8] = CCCCCCCC (context ID) [7:5] = xxx (reserved) [4] = A (async mode) [3:0] = PPPP (PD type) Link: https://lore.kernel.org/all/20260215182136.3995111-4-ekansh.gupta@oss.qualcomm.com/ Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>
For any remote call to DSP, after sending an invocation message, fastRPC driver waits for glink response and during this time the CPU can go into low power modes. This adds latency to overall fastrpc call as CPU wakeup and scheduling latencies are included. Add polling mode support with which fastRPC driver will poll continuously on a memory after sending a message to remote subsystem which will eliminate CPU wakeup and scheduling latencies and reduce fastRPC overhead. Poll mode can be enabled by user by using FASTRPC_IOCTL_SET_OPTION ioctl request with FASTRPC_POLL_MODE request id. Link: https://lore.kernel.org/all/20260215182136.3995111-5-ekansh.gupta@oss.qualcomm.com/ Signed-off-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>
…cture Add reference counting using kref to the fastrpc_user structure to prevent use-after-free issues when contexts are freed from workqueue after device release. The issue occurs when fastrpc_device_release() frees the user structure while invoke contexts are still pending in the workqueue. When the workqueue later calls fastrpc_context_free(), it attempts to access buf->fl->cctx in fastrpc_buf_free(), leading to a use-after-free: pc : fastrpc_buf_free+0x38/0x80 [fastrpc] lr : fastrpc_context_free+0xa8/0x1b0 [fastrpc] ... fastrpc_context_free+0xa8/0x1b0 [fastrpc] fastrpc_context_put_wq+0x78/0xa0 [fastrpc] process_one_work+0x180/0x450 worker_thread+0x26c/0x388 Implement proper reference counting to fix this: - Initialize kref in fastrpc_device_open() - Take a reference in fastrpc_context_alloc() for each context - Release the reference in fastrpc_context_free() when context is freed - Release the initial reference in fastrpc_device_release() This ensures the user structure remains valid as long as there are contexts holding references to it, preventing the race condition. Link: https://lore.kernel.org/all/20260226151121.818852-1-anandu.e@oss.qualcomm.com/ Signed-off-by: Anandu Krishnan E <anandu.e@oss.qualcomm.com>
…emory pool The initial buffer allocated for the Audio PD memory pool is never added to the pool because pageslen is set to 0. As a result, the buffer is not registered with Audio PD and is never used, causing a memory leak. Audio PD immediately falls back to allocating memory from the remote heap since the pool starts out empty. Fix this by setting pageslen to 1 so that the initially allocated buffer is correctly registered and becomes part of the Audio PD memory pool. Link: https://lore.kernel.org/all/20260409062617.1182-2-jianping.li@oss.qualcomm.com/ Fixes: 0871561 ("misc: fastrpc: Add support for audiopd") Cc: stable@kernel.org Co-developed-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com> Signed-off-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com> Signed-off-by: Jianping Li <jianping.li@oss.qualcomm.com>
…tion fastrpc_req_munmap_impl() is called to unmap any buffer. The buffer is getting removed from the list after it is unmapped from DSP. This can create potential race conditions if any other thread removes the entry from list while unmap operation is ongoing. Remove the entry before calling unmap operation. Link: https://lore.kernel.org/all/20260409062617.1182-3-jianping.li@oss.qualcomm.com/ Fixes: 2419e55 ("misc: fastrpc: add mmap/unmap support") Cc: stable@kernel.org Co-developed-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com> Signed-off-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com> Signed-off-by: Jianping Li <jianping.li@oss.qualcomm.com>
… in probe Allocating and freeing Audio PD memory from userspace is unsafe because the kernel cannot reliably determine when the DSP has finished using the memory. Userspace may free buffers while they are still in use by the DSP, and remote free requests cannot be safely trusted. Allocate the entire Audio PD reserved-memory region upfront during rpmsg probe and tie its lifetime to the rpmsg channel. This avoids userspace- controlled alloc/free and ensures memory is reclaimed only when the DSP shuts down. Link: https://lore.kernel.org/all/20260409062617.1182-4-jianping.li@oss.qualcomm.com/ Signed-off-by: Jianping Li <jianping.li@oss.qualcomm.com>
Make fastrpc_buf_free() a no-op when passed a NULL pointer, allowing callers to avoid open-coded NULL checks. Link: https://lore.kernel.org/all/20260409062617.1182-5-jianping.li@oss.qualcomm.com/ Co-developed-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com> Signed-off-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com> Signed-off-by: Jianping Li <jianping.li@oss.qualcomm.com>
…rocess abort When a userspace FastRPC client is abruptly terminated, FastRPC cleanup paths can race with device and session teardown. This results in kernel panics in different release paths: - fastrpc_release() when using remote heap, originating from fastrpc_buf_free() - fastrpc_device_release() when using system heap, originating from fastrpc_free_map() In addition, fastrpc_map_put() may trigger refcount use-after-free due to concurrent cleanup without proper synchronization. The root cause is that buffer and map cleanup paths may access map and buf resources after the associated device or session has already been released. Fix this by: - Introducing mutex protection for map and buf lifetime - Serializing buffer and map cleanup against device teardown - Skipping buffer and map operations when the device is already gone These changes ensure cleanup paths are safe against unexpected process aborts and prevent use-after-free and kernel panic scenarios. Link: https://lore.kernel.org/all/20260427105310.4056-1-jianping.li@oss.qualcomm.com/ Fixes: c68cfb7 ("misc: fastrpc: Add support for context Invoke method") Cc: stable@kernel.org Signed-off-by: Jianping Li <jianping.li@oss.qualcomm.com>
…ULL" This change corresponds to the v4 version shared with the upstream community. Revert it to apply the complete v6 revision, which includes additional fixes and updates not present in the earlier version. This reverts commit e0ba718. Signed-off-by: Vinayak Katoch <vkatoch@qti.qualcomm.com>
…Audio PD in probe" This change corresponds to the v4 version shared with the upstream community. Revert it to apply the complete v6 revision, which includes additional fixes and updates not present in the earlier version. This reverts commit c9010fc. Signed-off-by: Vinayak Katoch <vkatoch@qti.qualcomm.com>
…ap operation" This change corresponds to the v4 version shared with the upstream community. Revert it to apply the complete v6 revision, which includes additional fixes and updates not present in the earlier version. This reverts commit cd522d4. Signed-off-by: Vinayak Katoch <vkatoch@qti.qualcomm.com>
…dio PD memory pool" This change corresponds to the v4 version shared with the upstream community. Revert it to apply the complete v6 revision, which includes additional fixes and updates not present in the earlier version. This reverts commit 9dcad42. Signed-off-by: Vinayak Katoch <vkatoch@qti.qualcomm.com>
…emory pool The initial buffer allocated for the Audio PD memory pool is never added to the pool because pageslen is set to 0. As a result, the buffer is not registered with Audio PD and is never used, causing a memory leak. Audio PD immediately falls back to allocating memory from the remote heap since the pool starts out empty. Fix this by setting pageslen to 1 so that the initially allocated buffer is correctly registered and becomes part of the Audio PD memory pool. Link: https://lore.kernel.org/all/20260526111124.515-2-jianping.li@oss.qualcomm.com/ Fixes: 0871561 ("misc: fastrpc: Add support for audiopd") Cc: stable@kernel.org Signed-off-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com> Signed-off-by: Jianping Li <jianping.li@oss.qualcomm.com> Signed-off-by: Vinayak Katoch <vkatoch@qti.qualcomm.com>
…tion fastrpc_req_munmap_impl() is called to unmap any buffer. The buffer is getting removed from the list after it is unmapped from DSP. This can create potential race conditions if multiple threads invoke unmap concurrently, where one thread may remove the entry from the list while another thread's unmap operation is still ongoing. Fix this by removing the buffer entry from the list before calling the unmap operation. If the unmap fails, the entry is re-added to the list so that userspace can retry the unmap, or alternatively, the buffer will be cleaned up during device release when the DSP process is torn down and all DSP-side mappings are freed along with remaining buffers in the list. Link: https://lore.kernel.org/all/20260526111124.515-3-jianping.li@oss.qualcomm.com/ Fixes: 2419e55 ("misc: fastrpc: add mmap/unmap support") Cc: stable@kernel.org Signed-off-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com> Signed-off-by: Jianping Li <jianping.li@oss.qualcomm.com> Signed-off-by: Vinayak Katoch <vkatoch@qti.qualcomm.com>
…issing Audio PD static process creation assumes that a reserved-memory region is defined in DT and exposed via cctx->remote_heap. If reserved-memory is missing or incomplete, the driver may pass invalid address/size information to the DSP, leading to undefined behavior or crashes. Add explicit validation for remote_heap presence and size before sending the memory to DSP, and fail early if the configuration is invalid. Link: https://lore.kernel.org/all/20260526111124.515-4-jianping.li@oss.qualcomm.com/ Fixes: 0871561 ("misc: fastrpc: Add support for audiopd") Cc: stable@kernel.org Signed-off-by: Jianping Li <jianping.li@oss.qualcomm.com> Signed-off-by: Vinayak Katoch <vkatoch@qti.qualcomm.com>
qcomlnxci
requested review from
a team,
Chennak-quic and
ekanshibu
and removed request for
a team
🔨 Build Failure Analysis — PR #1258PR: #1258
VerdictThis is a merge conflict, not a compilation error. The build failed during git merge before any compilation occurred. The PR changes conflict with the current baseline state of 📎 Detailed analysis: Full report |
🔨 Build Failure Analysis — PR #1258PR: #1258
VerdictThis is not a compilation error but a merge conflict. The PR cannot be automatically merged into the baseline (df3ae9703774b70a7b7758b53498a25de9f87174) due to conflicting changes in drivers/misc/fastrpc.c. 📎 Detailed analysis: Full report |
PR #1258 — validate-patchPR: #1258
Final Summary
|
PR #1258 — checker-log-analyzerPR: #1258
Detailed report: Full report
|
… in probe Allocating and freeing Audio PD memory from userspace is unsafe because the kernel cannot reliably determine when the DSP has finished using the memory. Userspace may free buffers while they are still in use by the DSP, and remote free requests cannot be safely trusted. Additionally, the current implementation allows userspace to repeatedly grow the Audio PD heap, but does not support shrinking it. This can lead to unbounded memory usage over time, effectively causing a memory leak. Fix this by allocating the entire Audio PD reserved-memory region during rpmsg probe and tying its lifetime to the rpmsg channel. This removes userspace-controlled alloc/free and ensures that memory is reclaimed only when the DSP process is torn down. Link: https://lore.kernel.org/all/20260526111124.515-5-jianping.li@oss.qualcomm.com/ Fixes: 0871561 ("misc: fastrpc: Add support for audiopd") Cc: stable@kernel.org Signed-off-by: Jianping Li <jianping.li@oss.qualcomm.com> Signed-off-by: Vinayak Katoch <vkatoch@qti.qualcomm.com>
Make fastrpc_buf_free() a no-op when passed a NULL pointer, allowing callers to avoid open-coded NULL checks. Link: https://lore.kernel.org/all/20260526111124.515-6-jianping.li@oss.qualcomm.com/ Signed-off-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com> Signed-off-by: Jianping Li <jianping.li@oss.qualcomm.com> Signed-off-by: Vinayak Katoch <vkatoch@qti.qualcomm.com>
quic-vkatoch
force-pushed
the
free-remote-heap
branch
from
fb26ed2 to
61ae30c
Compare
🔨 Build Failure Analysis — PR #1258PR: #1258
VerdictThis is a merge conflict, not a compilation error. The PR introduces changes that cannot be automatically merged with the current baseline branch. 📎 Detailed analysis: Full report |
🔨 Build Failure Analysis — PR #1258PR: #1258
VerdictThis is not a compilation failure. The build failed during the pre-build integration phase due to a merge conflict in 📎 Detailed analysis: Full report |
PR #1258 — validate-patchPR: #1258
Final Summary
|
PR #1258 — checker-log-analyzerPR: #1258
Detailed report: Full report
|
ekanshibu
force-pushed
the
tech/mm/fastrpc
branch
2 times, most recently
from
98070bb to
561a33b
Compare
4 participants
This series adds missing bug fixes.
Patch 1: Fix initial memory allocation for the Audio PD memory pool.
Patch 2: Remove buffer from the list prior to unmap operation.
Patch 3: Fail Audio PD initialization when reserved memory is missing.
Patch 4: Allocate the entire reserved memory for Audio PD during probe.
Patch 5: Allow fastrpc_buf_free() to accept NULL.
Link: https://lore.kernel.org/all/20260526111124.515-2-jianping.li@oss.qualcomm.com/