From: "Danilo Krummrich" <dakr@kernel.org>
To: "Johan Hovold" <johan@kernel.org>
Cc: "Bartosz Golaszewski" <bartosz.golaszewski@oss.qualcomm.com>,
"Andy Shevchenko" <andriy.shevchenko@linux.intel.com>,
"Daniel Scally" <djrscally@gmail.com>,
"Heikki Krogerus" <heikki.krogerus@linux.intel.com>,
"Sakari Ailus" <sakari.ailus@linux.intel.com>,
"Bartosz Golaszewski" <brgl@kernel.org>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
<linux-acpi@vger.kernel.org>, <driver-core@lists.linux.dev>,
<linux-kernel@vger.kernel.org>,
"Balasubramani Vivekanandan"
<balasubramani.vivekanandan@intel.com>
Subject: Re: [PATCH] software node: only let the owner release a managed node
Date: Mon, 09 Nov 2026 15:45:29 +0100 [thread overview]
Message-ID: <DMQREV9DFQST.1Z4ZFOFTS0Z7W@kernel.org> (raw)
In-Reply-To: <avHZ5U_YR9QSqd0G@hovoldconsulting.com>
On Mon Nov 9, 2026 at 3:34 PM CET, Johan Hovold wrote:
> On Mon, Nov 09, 2026 at 03:10:31PM +0100, Danilo Krummrich wrote:
>> On Mon Nov 9, 2026 at 2:37 PM CET, Johan Hovold wrote:
>> > On Mon, Nov 02, 2026 at 04:25:16PM +0100, Bartosz Golaszewski wrote:
>> >> device_create_managed_software_node() creates a node whose lifetime is
>> >> tied to the device it was created for. software_node_notify_remove() is
>> >> called for every device that has the node as its fwnode (primary OR
>> >> secondary) and, if the node is managed, unconditionally detaches it from
>> >> that device and drops the creation reference.
>> >>
>> >> This breaks when the node is shared with another device. Example: the
>> >> i2c-designware copies the parent's fwnode to the adapter's struct device.
>> >> When the adapter is deleted, it releases the reference that belongs to
>> >> the owner and the latter ends up with a dangling pointer.
>> >>
>> >> Record the device's "manager" and only perform the actual release when
>> >> notify is called for that "owner" device.
>> >>
>> >> Reported-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com>
>> >> Closes: https://lore.kernel.org/all/20261009164241.923756-2-balasubramani.vivekanandan@intel.com/
>> >> Fixes: 151f6ff78cdf ("software node: Provide replacement for device_add_properties()")
>>
>> Hm...the documentation of device_create_managed_software_node() does point out
>> the limitation that it shouldn't be shared with other devices.
>>
>> Now, that's rather fragile and the reason I pointed out [1] it should be
>> changed, but it's technically not a fix?
>>
>> [1] https://lore.kernel.org/all/DM1FMM3KEYU9.1D26IINII93FO@kernel.org/
>
> It's hard to determine at allocation time whether a node will eventually
> end up being reused. That's why added the following clarification to the
> commit message:
>
> Note that it was never the intention that managed software nodes
> would be shared, but descendants reusing ancestor firmware nodes
> is not uncommon and such use is hard to predict when allocating
> software nodes.
Yeah, that's why I said it's fragile. :)
(Not trying to split hairs, I guess both can be argued for, whether we treat
something like this as fix or not, so I'm fine with either.)
>> >> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
>
>> > The end-result applied for 7.4 (to fix the 7.3 regression) is here:
>>
>> A previous reply from Balasubramani suggested to adjust the doc-comment of
>> device_create_managed_software_node(), so I thought Bartosz will send a new
>> version.
>
> I missed that comment (and his Reviewed-by tag, will add).
>
> The function still does not return the allocated node and managed nodes
> should generally not be shared. The exception would be descendants
> reusing ancestor nodes, and that may happen elsewhere in the stack.
>
> So I think the kernel doc is fine as-is, for now.
That's fair.
>> Also, are we sure this is -rc material? I think the original commit wasn't
>> technically broken and the bug in Xe was fixed otherwise.
>
> The regression was introduced by 0f485f88656a ("drm/xe/i2c: use
> device_create_managed_software_node()") in 7.3 and Bartosz framed it as
> an alternative fix for that bug.
>
> Are you saying this has since been fixed differently?
>
> If so, this can obviously wait.
There's the fix in [1] and Andy said he'll pick it up for Xe in one of the
replies.
[1] https://lore.kernel.org/all/20261009164241.923756-2-balasubramani.vivekanandan@intel.com/
next prev parent reply other threads:[~2026-11-09 14:45 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-02 15:25 Bartosz Golaszewski
2026-11-04 6:47 ` Vivekanandan, Balasubramani
2026-11-04 8:19 ` Andy Shevchenko
2026-11-04 8:26 ` Vivekanandan, Balasubramani
2026-11-04 8:35 ` Andy Shevchenko
2026-11-04 8:40 ` Vivekanandan, Balasubramani
2026-11-06 17:47 ` Heikki Krogerus
2026-11-09 13:37 ` Johan Hovold
2026-11-09 14:10 ` Danilo Krummrich
2026-11-09 14:30 ` Bartosz Golaszewski
2026-11-09 14:34 ` Johan Hovold
2026-11-09 14:45 ` Danilo Krummrich [this message]
2026-11-09 14:59 ` Johan Hovold
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=DMQREV9DFQST.1Z4ZFOFTS0Z7W@kernel.org \
--to=dakr@kernel.org \
--cc=andriy.shevchenko@linux.intel.com \
--cc=balasubramani.vivekanandan@intel.com \
--cc=bartosz.golaszewski@oss.qualcomm.com \
--cc=brgl@kernel.org \
--cc=djrscally@gmail.com \
--cc=driver-core@lists.linux.dev \
--cc=gregkh@linuxfoundation.org \
--cc=heikki.krogerus@linux.intel.com \
--cc=johan@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rafael.j.wysocki@intel.com \
--cc=rafael@kernel.org \
--cc=sakari.ailus@linux.intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®