Re: [PATCH v8 1/4] misc: fastrpc: Fix initial memory allocation for Audio PD memory pool

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [High] `fastrpc_map_attach()` doubly detaches and frees `map->buf` when error checks fail after mapping.
- [High] Pending invocation contexts and associated DMA mappings are permanently leaked if the remote DSP crashes.
--

commit c836369bdd9f243155871c03517e477035418fb9
Author: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>

misc: fastrpc: Fix initial memory allocation for Audio PD memory pool

This commit fixes an issue where the initial buffer allocated for the
Audio PD memory pool was not registered because pageslen was 0. It updates
pageslen to 1 to ensure the buffer is correctly added to the pool.

> diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c
> index a9b2ae44c06f6..96961217b8569 100644
> --- a/drivers/misc/fastrpc.c
> +++ b/drivers/misc/fastrpc.c

[ ... ]

[Severity: High]
This is a pre-existing issue, but does fastrpc_map_attach() doubly detach
and free map->buf when error checks fail after mapping?

If an error occurs after map->table is successfully assigned, the error
handling block runs:

fastrpc_map_attach() {
        ...
map_err:
        dma_buf_detach(map->buf, map->attach);
attach_err:
        dma_buf_put(map->buf);
get_err:
        fastrpc_map_put(map);
}

Since fastrpc_map_put() invokes fastrpc_free_map(), which also calls
dma_buf_detach() and dma_buf_put() if map->table is set, does this cause a
double free and reference count underflow?

[Severity: High]
This is a pre-existing issue, but does fastrpc_rpmsg_remove() permanently
leak pending invocation contexts and associated DMA mappings if the remote
DSP crashes?

When fastrpc_invoke_send() sends a message to the DSP, it takes a reference
on the context via fastrpc_context_get(ctx) to represent DSP ownership. If
the DSP crashes, fastrpc_rpmsg_remove() runs:

fastrpc_rpmsg_remove() {
        ...
        list_for_each_entry(user, &cctx->users, user)
                fastrpc_notify_users(user);
        ...
}

Since the rpmsg channel is removed, the callback will never fire. Does
fastrpc_notify_users() wake up waiting threads without dropping the DSP's
reference count, preventing the ctx reference count from ever reaching zero?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260609025938.457-1-jianping.li@oss.qualcomm.com?part=1