From: Catalin Marinas <catalin.marinas@arm.com>
To: Cristian Marussi <cristian.marussi@arm.com>
Cc: Alice Ryhl <aliceryhl@google.com>,
Sudeep Holla <sudeep.holla@arm.com>,
linux-arm-kernel@lists.infradead.org, arm-scmi@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [Bug report] Memory leak in scmi_device_create
Date: Thu, 6 Mar 2025 16:18:38 +0000 [thread overview]
Message-ID: <Z8nK3uFkspy61yjP@arm.com> (raw)
In-Reply-To: <Z8nDj129ZVeZBVSp@pluto>
On Thu, Mar 06, 2025 at 03:47:27PM +0000, Cristian Marussi wrote:
> On Thu, Mar 06, 2025 at 02:36:16PM +0000, Catalin Marinas wrote:
> > This loop in scmi_device_create() looks strange:
> >
> > list_for_each_entry(rdev, phead, node) {
> > struct scmi_device *sdev;
> >
> > sdev = __scmi_device_create(np, parent,
> > rdev->id_table->protocol_id,
> > rdev->id_table->name);
> > /* Report errors and carry on... */
> > if (sdev)
> > scmi_dev = sdev;
> > else
> > pr_err("(%s) Failed to create device for protocol 0x%x (%s)\n",
> > of_node_full_name(parent->of_node),
> > rdev->id_table->protocol_id,
> > rdev->id_table->name);
> > }
> >
> > We can override scmi_dev a few times in the loop and lose the previous
> > sdev allocations. Is this intended?
>
> Yes...it is weird..but by design I would say :P ...
>
> ...because this is called to instantiate one single device OR instantiate at
> once all the multiple devices needed for a protocol: in this latter case it
> returns just one of the created devices to signal success or NULL if all the
> devices' creation failed....we dont need to keep the allocated devices references
> anyway here since on success those devices are now referenced and kept on the
> SCMI bus, so they can be searched/scanned/destroyed from there.
Not sure why the pointer isn't found, device_add() should link it with
the parent. Unless something else fails, the parent is freed and the
linked devices unreachable. I'm not familiar at all with this code, I
just saw kmemleak and thought of replying.
The loop is still weird, scmi_chan_setup() seems to use the pointer to
scmi_device for something more meaningful than a pass/fail check. Also
the overall result is based only on what the last __scmi_device_create()
return value was, irrespective of the previous iterations of the loop.
You do have a pr_err() but no early bailing out of the loop on failure.
I'm curious if there are any SCMI errors in the Alice's kernel log.
--
Catalin
next prev parent reply other threads:[~2025-03-06 16:18 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-05 11:59 [Bug report] Memory leak in scmi_device_create Alice Ryhl
2025-03-05 17:10 ` Cristian Marussi
2025-03-06 11:09 ` Alice Ryhl
2025-03-06 12:50 ` Cristian Marussi
2025-03-06 13:25 ` Alice Ryhl
2025-03-06 14:36 ` Catalin Marinas
2025-03-06 15:47 ` Cristian Marussi
2025-03-06 16:18 ` Catalin Marinas [this message]
2025-03-06 18:43 ` Cristian Marussi
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=Z8nK3uFkspy61yjP@arm.com \
--to=catalin.marinas@arm.com \
--cc=aliceryhl@google.com \
--cc=arm-scmi@vger.kernel.org \
--cc=cristian.marussi@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sudeep.holla@arm.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.