| 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
| ||
|
Message-ID: <20250427023018.GD13806@nxa18884-linux>
Date: Sun, 27 Apr 2025 10:30:18 +0800
From: Peng Fan <peng.fan@....nxp.com>
To: xiaolei wang <xiaolei.wang@...driver.com>
Cc: Mathieu Poirier <mathieu.poirier@...aro.org>, 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 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@...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
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
Powered by blists - more mailing lists