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 <[email protected]> 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/[email protected]?part=1
