From: Jianping Li <jianping.li@oss.qualcomm.com>
To: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Cc: srini@kernel.org, amahesh@qti.qualcomm.com, arnd@arndb.de,
Greg KH <gregkh@linuxfoundation.org>,
abelvesa@kernel.org, jorge.ramirez@oss.qualcomm.com,
linux-arm-msm@vger.kernel.org, dri-devel@lists.freedesktop.org,
linux-kernel@vger.kernel.org,
Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>,
quic_chennak@quicinc.com, stable@kernel.org
Subject: Re: [PATCH v7 3/5] misc: fastrpc: Fail Audio PD init when reserved memory is missing
Date: Mon, 8 Jun 2026 14:29:13 +0800 [thread overview]
Message-ID: <ddeff296-abc0-4e1b-a721-761e2cbd331d@oss.qualcomm.com> (raw)
In-Reply-To: <bcm2eufawifaq65i5qlqmbam4wtv2du5re6c54tiamdbynmras@lbfd44kjb6da>
On 6/8/2026 2:11 PM, Dmitry Baryshkov wrote:
> On Tue, Jun 02, 2026 at 03:17:48PM +0800, Jianping Li wrote:
>> 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.
>>
>> Fixes: 0871561055e66 ("misc: fastrpc: Add support for audiopd")
>> Cc: stable@kernel.org
>> Signed-off-by: Jianping Li <jianping.li@oss.qualcomm.com>
>> ---
>> drivers/misc/fastrpc.c | 7 +++++++
>> 1 file changed, 7 insertions(+)
>>
>> diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c
>> index a8a58f889d07..f46a8f53970d 100644
>> --- a/drivers/misc/fastrpc.c
>> +++ b/drivers/misc/fastrpc.c
>> @@ -1354,6 +1354,13 @@ static int fastrpc_init_create_static_process(struct fastrpc_user *fl,
>> } inbuf;
>> u32 sc;
>>
>> + if (!fl->cctx->remote_heap ||
>> + !fl->cctx->remote_heap->dma_addr ||
>> + !fl->cctx->remote_heap->size) {
>> + err = -ENOMEM;
>> + dev_dbg(fl->sctx->dev, "remote heap memory region is not added\n");
>> + return err;
>> + }
> Won't this check without the next commit break the kernel? I don't see
> where else the remote heap is being allocated.
Yes, this check depends on remote_heap being populated during rpmsg
probe from the reserved-memory region, introduced in a subsequent
patch in this series.
If there is no dependency on the next series, the remote_heap allocation here after the if check.
The logic will be wrong.
>
>> args = kzalloc_objs(*args, FASTRPC_CREATE_STATIC_PROCESS_NARGS);
>> if (!args)
>> return -ENOMEM;
>> --
>> 2.43.0
>>
next prev parent reply other threads:[~2026-06-08 6:29 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-02 7:17 [PATCH v7 0/5] misc: fastrpc: Add missing bug fixes Jianping Li
2026-06-02 7:17 ` [PATCH v7 1/5] misc: fastrpc: Fix initial memory allocation for Audio PD memory pool Jianping Li
2026-06-08 6:06 ` Dmitry Baryshkov
2026-06-02 7:17 ` [PATCH v7 2/5] misc: fastrpc: Remove buffer from list prior to unmap operation Jianping Li
2026-06-08 6:06 ` Dmitry Baryshkov
2026-06-02 7:17 ` [PATCH v7 3/5] misc: fastrpc: Fail Audio PD init when reserved memory is missing Jianping Li
2026-06-02 9:25 ` Jie Gan
2026-06-08 4:32 ` Jianping Li
2026-06-08 6:11 ` Dmitry Baryshkov
2026-06-08 6:29 ` Jianping Li [this message]
2026-06-08 6:37 ` Dmitry Baryshkov
2026-06-08 6:45 ` Jianping Li
2026-06-02 7:17 ` [PATCH v7 4/5] misc: fastrpc: Allocate entire reserved memory for Audio PD in probe Jianping Li
2026-06-02 9:41 ` Jie Gan
2026-06-08 4:35 ` Jianping Li
2026-06-02 7:17 ` [PATCH v7 5/5] misc: fastrpc: Allow fastrpc_buf_free() to accept NULL Jianping Li
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ddeff296-abc0-4e1b-a721-761e2cbd331d@oss.qualcomm.com \
--to=jianping.li@oss.qualcomm.com \
--cc=abelvesa@kernel.org \
--cc=amahesh@qti.qualcomm.com \
--cc=arnd@arndb.de \
--cc=dmitry.baryshkov@oss.qualcomm.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=ekansh.gupta@oss.qualcomm.com \
--cc=gregkh@linuxfoundation.org \
--cc=jorge.ramirez@oss.qualcomm.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=quic_chennak@quicinc.com \
--cc=srini@kernel.org \
--cc=stable@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox