linux-kernel - Re: [PATCH V2 1/2] remoteproc: imx_rproc: release carveout under imx_rproc after rproc

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <f6e79b0e-5e0e-47fa-b2ac-fcefda19efa2@windriver.com>
Date: Sun, 27 Apr 2025 08:11:43 +0800
From: xiaolei wang <xiaolei.wang@...driver.com>
To: Mathieu Poirier <mathieu.poirier@...aro.org>
Cc: Peng Fan <peng.fan@....nxp.com>, andersson@...nel.org, shawnguo@...nel.org,
        s.hauer@...gutronix.de, kernel@...gutronix.de, festevam@...il.com,
        linux-remoteproc@...r.kernel.org, imx@...ts.linux.dev,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH V2 1/2] remoteproc: imx_rproc: release carveout under
 imx_rproc after rproc_attach() fails


On 4/27/25 04:14, Mathieu Poirier wrote:
> CAUTION: This email comes from a non Wind River email account!
> Do not click links or open attachments unless you recognize the sender and know the content is safe.
>
> On Sat, 26 Apr 2025 at 07:46, xiaolei wang <xiaolei.wang@...driver.com> wrote:
>>
>> On 4/26/25 21:18, Peng Fan wrote:
>>> CAUTION: This email comes from a non Wind River email account!
>>> Do not click links or open attachments unless you recognize the sender and know the content is safe.
>>>
>>> On Sat, Apr 26, 2025 at 02:53:47PM +0800, Xiaolei Wang wrote:
>>>> When rproc->state = RPROC_DETACHED and rproc_attach() is used
>>>> to attach to the remote processor, if rproc_handle_resources()
>>>> returns a failure, the resources allocated by rproc_prepare_device()
>>>> should be released, otherwise the following memory leak will occur.
>>>>
>>>> Therefore, add imx_rproc_unprepare() to imx_rproc to release the
>>>> memory allocated in imx_rproc_prepare().
>>>>
>>>> unreferenced object 0xffff0000861c5d00 (size 128):
>>>> comm "kworker/u12:3", pid 59, jiffies 4294893509 (age 149.220s)
>>>> hex dump (first 32 bytes):
>>>> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>>>> 00 00 02 88 00 00 00 00 00 00 10 00 00 00 00 00 ............
>>>> backtrace:
>>>> [<00000000f949fe18>] slab_post_alloc_hook+0x98/0x37c
>>>> [<00000000adbfb3e7>] __kmem_cache_alloc_node+0x138/0x2e0
>>>> [<00000000521c0345>] kmalloc_trace+0x40/0x158
>>>> [<000000004e330a49>] rproc_mem_entry_init+0x60/0xf8
>>>> [<000000002815755e>] imx_rproc_prepare+0xe0/0x180
>>>> [<0000000003f61b4e>] rproc_boot+0x2ec/0x528
>>>> [<00000000e7e994ac>] rproc_add+0x124/0x17c
>>>> [<0000000048594076>] imx_rproc_probe+0x4ec/0x5d4
>>>> [<00000000efc298a1>] platform_probe+0x68/0xd8
>>>> [<00000000110be6fe>] really_probe+0x110/0x27c
>>>> [<00000000e245c0ae>] __driver_probe_device+0x78/0x12c
>>>> [<00000000f61f6f5e>] driver_probe_device+0x3c/0x118
>>>> [<00000000a7874938>] __device_attach_driver+0xb8/0xf8
>>>> [<0000000065319e69>] bus_for_each_drv+0x84/0xe4
>>>> [<00000000db3eb243>] __device_attach+0xfc/0x18c
>>>> [<0000000072e4e1a4>] device_initial_probe+0x14/0x20
>>>>
>>> Fix Tag?
>> I will add it
>>
>>>> Signed-off-by: Xiaolei Wang <xiaolei.wang@...driver.com>
>>>> ---
>>>> drivers/remoteproc/imx_rproc.c | 14 ++++++++++++++
>>>> 1 file changed, 14 insertions(+)
>>>>
>>>> diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
>>>> index 74299af1d7f1..c489bd15ee91 100644
>>>> --- a/drivers/remoteproc/imx_rproc.c
>>>> +++ b/drivers/remoteproc/imx_rproc.c
>>>> @@ -595,6 +595,19 @@ static int imx_rproc_prepare(struct rproc *rproc)
>>>>         return  0;
>>>> }
>>>>
>>>> +static int imx_rproc_unprepare(struct rproc *rproc)
>>>> +{
>>>> +      struct rproc_mem_entry *entry, *tmp;
>>>> +
>>>> +      rproc_coredump_cleanup(rproc);
>>>> +      /* clean up carveout allocations */
>>>> +      list_for_each_entry_safe(entry, tmp, &rproc->carveouts, node) {
>>>> +              list_del(&entry->node);
>>>> +              kfree(entry);
>>>> +      }
>>>> +      return  0;
>>> Could "rproc_resource_cleanup(rproc);" be used here?
>> Thanks for your suggestion, I will try it
> Before sending another revision, please detail the steps needed to
> reproduce this problem.

Hi

When I was using the imx95 board, I found that attach remote

core failed during the startup process, and then I found many memory

leak prompts. The following may be some useful log information:


[    0.184904] remoteproc remoteproc0: neutron-rproc is available
[    3.009728] remoteproc remoteproc1: imx-rproc is available
[    3.016002] remoteproc remoteproc1: attaching to imx-rproc
[    3.026761] remoteproc remoteproc1: carveout rsc has non zero 
reserved bytes
[    3.039148] remoteproc remoteproc1: Failed to process resources: -22
[    3.057878] remoteproc remoteproc1: releasing imx-rproc

thanks

xiaolei

>
>> thanks
>>
>> xiaolei
>>
>>> Regards,
>>> Peng