[PATCH V2 0/2] Fix two memory leaks in rproc_attach()

[PATCH V2 0/2] Fix two memory leaks in rproc_attach()

[Xiaolei Wang]

In the rproc_attach() function, if rproc_handle_resources() returns
failure, if the rproc->ops->unprepare callback function is not set,
the resources allocated by rproc_prepare_device() cannot be released,
and rproc->clean_table should also be released

patch1 adds rproc->ops->unprepare callback function to imx_rproc
patch2 releases rproc->clean_table

Changes in v2:
    Updated the commit log of these two patches
    Link to v1: https://patchwork.kernel.org/project/linux-remoteproc/patch/20250424122252.2777363-1-xiaolei.wang@windriver.com/
                https://patchwork.kernel.org/project/linux-remoteproc/patch/20250424122252.2777363-2-xiaolei.wang@windriver.com/

Xiaolei Wang (2):
  remoteproc: imx_rproc: release carveout under imx_rproc after
    rproc_attach() fails
  remoteproc: core: release rproc->clean_table after rproc_attach()
    fails

 drivers/remoteproc/imx_rproc.c       | 14 ++++++++++++++
 drivers/remoteproc/remoteproc_core.c |  1 +
 2 files changed, 15 insertions(+)

-- 
2.25.1

[PATCH V2 1/2] remoteproc: imx_rproc: release carveout under imx_rproc after rproc_attach() fails

[Xiaolei Wang]

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

Signed-off-by: Xiaolei Wang <xiaolei.wang@windriver.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;
+}
+
 static int imx_rproc_parse_fw(struct rproc *rproc, const struct firmware *fw)
 {
 	int ret;
@@ -675,6 +688,7 @@ imx_rproc_elf_find_loaded_rsc_table(struct rproc *rproc, const struct firmware *
 
 static const struct rproc_ops imx_rproc_ops = {
 	.prepare	= imx_rproc_prepare,
+	.unprepare	= imx_rproc_unprepare,
 	.attach		= imx_rproc_attach,
 	.detach		= imx_rproc_detach,
 	.start		= imx_rproc_start,
-- 
2.25.1

Re: [PATCH V2 1/2] remoteproc: imx_rproc: release carveout under imx_rproc after rproc_attach() fails

[Peng Fan]

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?

>Signed-off-by: Xiaolei Wang <xiaolei.wang@windriver.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?

Regards,
Peng

Re: [PATCH V2 1/2] remoteproc: imx_rproc: release carveout under imx_rproc after rproc_attach() fails

[xiaolei wang]

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@windriver.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

thanks

xiaolei

>
> Regards,
> Peng

Re: [PATCH V2 1/2] remoteproc: imx_rproc: release carveout under imx_rproc after rproc_attach() fails

[Mathieu Poirier]

On Sat, 26 Apr 2025 at 07:46, xiaolei wang <xiaolei.wang@windriver.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@windriver.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.

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

Re: [PATCH V2 1/2] remoteproc: imx_rproc: release carveout under imx_rproc after rproc_attach() fails

[xiaolei wang]

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@windriver.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@windriver.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

Re: [PATCH V2 1/2] remoteproc: imx_rproc: release carveout under imx_rproc after rproc_attach() fails

[Peng Fan]

On Sun, Apr 27, 2025 at 08:11:43AM +0800, xiaolei wang wrote:
>
>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@windriver.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@windriver.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

ok. i.MX95 is not supported in upstream. But this error seems
valid to other i.MX SoCs.

With M7 binary being packed in flash.bin(boot image used by ROM and SCMI firmware),
M7 is in a separate logic machine, and linux has no permission
to control M7.

But if M7 does not publish a valid resource table, linux will report 
error when using the resource table from the fixed address(rsc_table).

>
>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

So to make it clear, I would update the commit log:

To support cases remote cores are started by ROM/System Firmware/bootloader,
"rsc-table" property is to indicate the address of resource table to build
rpmsg connection between Linux and remote cores. However remote cores
may not publish a valid resource table or resource table is attacked
to be filled with garbage data.

Then when remoteproc driver handles the resource table, it will
report "Failed to process resources: -22", then failed attach to
remote cores. In this cases, to avoid memory leak, need to free
the allocated resources.

This was found on i.MX95, but it also applies to i.MX93 and i.MX8M family.

---------------------

You may need to wait Mathieu to see whether he agrees on the upper update
or you have more information to be added.

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

Re: [PATCH V2 1/2] remoteproc: imx_rproc: release carveout under imx_rproc after rproc_attach() fails

[Mathieu Poirier]

Hi Xiaolei,

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
> 
> Signed-off-by: Xiaolei Wang <xiaolei.wang@windriver.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;
> +}
> +

I have reflected long and hard on this.  The problem with the above approach is
that we do almost the same thing in imx_rproc_prepare() and
rproc_resource_cleanup().  Function rproc_resource_cleanup() is able to deal
with empty lists so I think it is better to fix the "goto" statements in
rproc_attach().  More specifically, replace the "unprepare_device" goto
statement with "clean_up_resources" and get rid of the "unprepare_device" label.  

Please see if that works on your side.  I am good with 2/2 of this series.

Thanks,
Mathieu

>  static int imx_rproc_parse_fw(struct rproc *rproc, const struct firmware *fw)
>  {
>  	int ret;
> @@ -675,6 +688,7 @@ imx_rproc_elf_find_loaded_rsc_table(struct rproc *rproc, const struct firmware *
>  
>  static const struct rproc_ops imx_rproc_ops = {
>  	.prepare	= imx_rproc_prepare,
> +	.unprepare	= imx_rproc_unprepare,
>  	.attach		= imx_rproc_attach,
>  	.detach		= imx_rproc_detach,
>  	.start		= imx_rproc_start,
> -- 
> 2.25.1
> 

Re: [PATCH V2 1/2] remoteproc: imx_rproc: release carveout under imx_rproc after rproc_attach() fails

[Xiaolei Wang]

On 4/29/25 00:49, 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.
>
> Hi Xiaolei,
>
> 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
>>
>> Signed-off-by: Xiaolei Wang <xiaolei.wang@windriver.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;
>> +}
>> +
> I have reflected long and hard on this.  The problem with the above approach is
> that we do almost the same thing in imx_rproc_prepare() and
> rproc_resource_cleanup().  Function rproc_resource_cleanup() is able to deal
> with empty lists so I think it is better to fix the "goto" statements in
> rproc_attach().  More specifically, replace the "unprepare_device" goto
> statement with "clean_up_resources" and get rid of the "unprepare_device" label.
>
> Please see if that works on your side.  I am good with 2/2 of this series.
Thanks to Mathieu for the suggestion, I will try this approach,

and also thanks to Peng for the more detailed explanation

thanks

xiaolei

>
> Thanks,
> Mathieu
>
>>   static int imx_rproc_parse_fw(struct rproc *rproc, const struct firmware *fw)
>>   {
>>        int ret;
>> @@ -675,6 +688,7 @@ imx_rproc_elf_find_loaded_rsc_table(struct rproc *rproc, const struct firmware *
>>
>>   static const struct rproc_ops imx_rproc_ops = {
>>        .prepare        = imx_rproc_prepare,
>> +     .unprepare      = imx_rproc_unprepare,
>>        .attach         = imx_rproc_attach,
>>        .detach         = imx_rproc_detach,
>>        .start          = imx_rproc_start,
>> --
>> 2.25.1
>>

[PATCH V2 2/2] remoteproc: core: release rproc->clean_table after rproc_attach() fails

[Xiaolei Wang]

When rproc->state = RPROC_DETACHED is attached to remote processor
through rproc_attach(), if rproc_handle_resources() returns failure,
then the clean table should be released, otherwise the following
memory leak will occur.

unreferenced object 0xffff000086a99800 (size 1024):
comm "kworker/u12:3", pid 59, jiffies 4294893670 (age 121.140s)
hex dump (first 32 bytes):
00 00 00 00 00 80 00 00 00 00 00 00 00 00 10 00 ............
00 00 00 00 00 00 08 00 00 00 00 00 00 00 00 00 ............
backtrace:
 [<000000008bbe4ca8>] slab_post_alloc_hook+0x98/0x3fc
 [<000000003b8a272b>] __kmem_cache_alloc_node+0x13c/0x230
 [<000000007a507c51>] __kmalloc_node_track_caller+0x5c/0x260
 [<0000000037818dae>] kmemdup+0x34/0x60
 [<00000000610f7f57>] rproc_boot+0x35c/0x56c
 [<0000000065f8871a>] rproc_add+0x124/0x17c
 [<00000000497416ee>] imx_rproc_probe+0x4ec/0x5d4
 [<000000003bcaa37d>] platform_probe+0x68/0xd8
 [<00000000771577f9>] really_probe+0x110/0x27c
 [<00000000531fea59>] __driver_probe_device+0x78/0x12c
 [<0000000080036a04>] driver_probe_device+0x3c/0x118
 [<000000007e0bddcb>] __device_attach_driver+0xb8/0xf8
 [<000000000cf1fa33>] bus_for_each_drv+0x84/0xe4
 [<000000001a53b53e>] __device_attach+0xfc/0x18c
 [<00000000d1a2a32c>] device_initial_probe+0x14/0x20
 [<00000000d8f8b7ae>] bus_probe_device+0xb0/0xb4
 unreferenced object 0xffff0000864c9690 (size 16):

Signed-off-by: Xiaolei Wang <xiaolei.wang@windriver.com>
---
 drivers/remoteproc/remoteproc_core.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
index b21eedefff87..6226e2d12a97 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -1656,6 +1656,7 @@ static int rproc_attach(struct rproc *rproc)
 unprepare_device:
 	/* release HW resources if needed */
 	rproc_unprepare_device(rproc);
+	kfree(rproc->clean_table);
 disable_iommu:
 	rproc_disable_iommu(rproc);
 	return ret;
-- 
2.25.1

Re: [PATCH V2 2/2] remoteproc: core: release rproc->clean_table after rproc_attach() fails

[Xiaolei Wang]

On 4/26/25 14:53, Xiaolei Wang wrote:
> When rproc->state = RPROC_DETACHED is attached to remote processor
> through rproc_attach(), if rproc_handle_resources() returns failure,
> then the clean table should be released, otherwise the following
> memory leak will occur.
>
> unreferenced object 0xffff000086a99800 (size 1024):
> comm "kworker/u12:3", pid 59, jiffies 4294893670 (age 121.140s)
> hex dump (first 32 bytes):
> 00 00 00 00 00 80 00 00 00 00 00 00 00 00 10 00 ............
> 00 00 00 00 00 00 08 00 00 00 00 00 00 00 00 00 ............
> backtrace:
>   [<000000008bbe4ca8>] slab_post_alloc_hook+0x98/0x3fc
>   [<000000003b8a272b>] __kmem_cache_alloc_node+0x13c/0x230
>   [<000000007a507c51>] __kmalloc_node_track_caller+0x5c/0x260
>   [<0000000037818dae>] kmemdup+0x34/0x60
>   [<00000000610f7f57>] rproc_boot+0x35c/0x56c
>   [<0000000065f8871a>] rproc_add+0x124/0x17c
>   [<00000000497416ee>] imx_rproc_probe+0x4ec/0x5d4
>   [<000000003bcaa37d>] platform_probe+0x68/0xd8
>   [<00000000771577f9>] really_probe+0x110/0x27c
>   [<00000000531fea59>] __driver_probe_device+0x78/0x12c
>   [<0000000080036a04>] driver_probe_device+0x3c/0x118
>   [<000000007e0bddcb>] __device_attach_driver+0xb8/0xf8
>   [<000000000cf1fa33>] bus_for_each_drv+0x84/0xe4
>   [<000000001a53b53e>] __device_attach+0xfc/0x18c
>   [<00000000d1a2a32c>] device_initial_probe+0x14/0x20
>   [<00000000d8f8b7ae>] bus_probe_device+0xb0/0xb4
>   unreferenced object 0xffff0000864c9690 (size 16):
>
> Signed-off-by: Xiaolei Wang <xiaolei.wang@windriver.com>
> ---
>   drivers/remoteproc/remoteproc_core.c | 1 +
>   1 file changed, 1 insertion(+)
>
> diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
> index b21eedefff87..6226e2d12a97 100644
> --- a/drivers/remoteproc/remoteproc_core.c
> +++ b/drivers/remoteproc/remoteproc_core.c
> @@ -1656,6 +1656,7 @@ static int rproc_attach(struct rproc *rproc)
>   unprepare_device:
>   	/* release HW resources if needed */
>   	rproc_unprepare_device(rproc);
> +	kfree(rproc->clean_table);
>   disable_iommu:
>   	rproc_disable_iommu(rproc);
>   	return ret;

Hi Mathieu

For this patch, if I use devm_kmemdup() instead of kmemdup()

in rproc_set_rsc_table() function, is it better? Also delete

kfree(rproc->clean_table) in rproc_set_rsc_table()

thanks

xiaolei

Re: [PATCH V2 2/2] remoteproc: core: release rproc->clean_table after rproc_attach() fails

[Mathieu Poirier]

On Mon, 28 Apr 2025 at 20:20, Xiaolei Wang <xiaolei.wang@windriver.com> wrote:
>
>
> On 4/26/25 14:53, Xiaolei Wang wrote:
> > When rproc->state = RPROC_DETACHED is attached to remote processor
> > through rproc_attach(), if rproc_handle_resources() returns failure,
> > then the clean table should be released, otherwise the following
> > memory leak will occur.
> >
> > unreferenced object 0xffff000086a99800 (size 1024):
> > comm "kworker/u12:3", pid 59, jiffies 4294893670 (age 121.140s)
> > hex dump (first 32 bytes):
> > 00 00 00 00 00 80 00 00 00 00 00 00 00 00 10 00 ............
> > 00 00 00 00 00 00 08 00 00 00 00 00 00 00 00 00 ............
> > backtrace:
> >   [<000000008bbe4ca8>] slab_post_alloc_hook+0x98/0x3fc
> >   [<000000003b8a272b>] __kmem_cache_alloc_node+0x13c/0x230
> >   [<000000007a507c51>] __kmalloc_node_track_caller+0x5c/0x260
> >   [<0000000037818dae>] kmemdup+0x34/0x60
> >   [<00000000610f7f57>] rproc_boot+0x35c/0x56c
> >   [<0000000065f8871a>] rproc_add+0x124/0x17c
> >   [<00000000497416ee>] imx_rproc_probe+0x4ec/0x5d4
> >   [<000000003bcaa37d>] platform_probe+0x68/0xd8
> >   [<00000000771577f9>] really_probe+0x110/0x27c
> >   [<00000000531fea59>] __driver_probe_device+0x78/0x12c
> >   [<0000000080036a04>] driver_probe_device+0x3c/0x118
> >   [<000000007e0bddcb>] __device_attach_driver+0xb8/0xf8
> >   [<000000000cf1fa33>] bus_for_each_drv+0x84/0xe4
> >   [<000000001a53b53e>] __device_attach+0xfc/0x18c
> >   [<00000000d1a2a32c>] device_initial_probe+0x14/0x20
> >   [<00000000d8f8b7ae>] bus_probe_device+0xb0/0xb4
> >   unreferenced object 0xffff0000864c9690 (size 16):
> >
> > Signed-off-by: Xiaolei Wang <xiaolei.wang@windriver.com>
> > ---
> >   drivers/remoteproc/remoteproc_core.c | 1 +
> >   1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
> > index b21eedefff87..6226e2d12a97 100644
> > --- a/drivers/remoteproc/remoteproc_core.c
> > +++ b/drivers/remoteproc/remoteproc_core.c
> > @@ -1656,6 +1656,7 @@ static int rproc_attach(struct rproc *rproc)
> >   unprepare_device:
> >       /* release HW resources if needed */
> >       rproc_unprepare_device(rproc);
> > +     kfree(rproc->clean_table);
> >   disable_iommu:
> >       rproc_disable_iommu(rproc);
> >       return ret;
>
> Hi Mathieu
>
> For this patch, if I use devm_kmemdup() instead of kmemdup()

I don't think using devm_kmemdup() would work in this case since the
memory is only free'd when rproc->dev is released.  So if you have
Attach()->detach()->attach(), we'd only keep accumulating memory that
is no longer used.

>
> in rproc_set_rsc_table() function, is it better? Also delete
>
> kfree(rproc->clean_table) in rproc_set_rsc_table()
>
> thanks
>
> xiaolei
>

Re: [PATCH V2 2/2] remoteproc: core: release rproc->clean_table after rproc_attach() fails

[xiaolei wang]

On 4/30/25 01:30, 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 Mon, 28 Apr 2025 at 20:20, Xiaolei Wang <xiaolei.wang@windriver.com> wrote:
>>
>> On 4/26/25 14:53, Xiaolei Wang wrote:
>>> When rproc->state = RPROC_DETACHED is attached to remote processor
>>> through rproc_attach(), if rproc_handle_resources() returns failure,
>>> then the clean table should be released, otherwise the following
>>> memory leak will occur.
>>>
>>> unreferenced object 0xffff000086a99800 (size 1024):
>>> comm "kworker/u12:3", pid 59, jiffies 4294893670 (age 121.140s)
>>> hex dump (first 32 bytes):
>>> 00 00 00 00 00 80 00 00 00 00 00 00 00 00 10 00 ............
>>> 00 00 00 00 00 00 08 00 00 00 00 00 00 00 00 00 ............
>>> backtrace:
>>>    [<000000008bbe4ca8>] slab_post_alloc_hook+0x98/0x3fc
>>>    [<000000003b8a272b>] __kmem_cache_alloc_node+0x13c/0x230
>>>    [<000000007a507c51>] __kmalloc_node_track_caller+0x5c/0x260
>>>    [<0000000037818dae>] kmemdup+0x34/0x60
>>>    [<00000000610f7f57>] rproc_boot+0x35c/0x56c
>>>    [<0000000065f8871a>] rproc_add+0x124/0x17c
>>>    [<00000000497416ee>] imx_rproc_probe+0x4ec/0x5d4
>>>    [<000000003bcaa37d>] platform_probe+0x68/0xd8
>>>    [<00000000771577f9>] really_probe+0x110/0x27c
>>>    [<00000000531fea59>] __driver_probe_device+0x78/0x12c
>>>    [<0000000080036a04>] driver_probe_device+0x3c/0x118
>>>    [<000000007e0bddcb>] __device_attach_driver+0xb8/0xf8
>>>    [<000000000cf1fa33>] bus_for_each_drv+0x84/0xe4
>>>    [<000000001a53b53e>] __device_attach+0xfc/0x18c
>>>    [<00000000d1a2a32c>] device_initial_probe+0x14/0x20
>>>    [<00000000d8f8b7ae>] bus_probe_device+0xb0/0xb4
>>>    unreferenced object 0xffff0000864c9690 (size 16):
>>>
>>> Signed-off-by: Xiaolei Wang <xiaolei.wang@windriver.com>
>>> ---
>>>    drivers/remoteproc/remoteproc_core.c | 1 +
>>>    1 file changed, 1 insertion(+)
>>>
>>> diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
>>> index b21eedefff87..6226e2d12a97 100644
>>> --- a/drivers/remoteproc/remoteproc_core.c
>>> +++ b/drivers/remoteproc/remoteproc_core.c
>>> @@ -1656,6 +1656,7 @@ static int rproc_attach(struct rproc *rproc)
>>>    unprepare_device:
>>>        /* release HW resources if needed */
>>>        rproc_unprepare_device(rproc);
>>> +     kfree(rproc->clean_table);
>>>    disable_iommu:
>>>        rproc_disable_iommu(rproc);
>>>        return ret;
>> Hi Mathieu
>>
>> For this patch, if I use devm_kmemdup() instead of kmemdup()
> I don't think using devm_kmemdup() would work in this case since the
> memory is only free'd when rproc->dev is released.  So if you have
> Attach()->detach()->attach(), we'd only keep accumulating memory that
> is no longer used.

Got it, thanks for the explanation, I will send a new version

thanks

xiaolei

>
>> in rproc_set_rsc_table() function, is it better? Also delete
>>
>> kfree(rproc->clean_table) in rproc_set_rsc_table()
>>
>> thanks
>>
>> xiaolei
>>