Linux driver-core infrastructure
 help / color / mirror / Atom feed
From: "Danilo Krummrich" <dakr@kernel.org>
To: "Bartosz Golaszewski" <bartosz.golaszewski@oss.qualcomm.com>
Cc: "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	"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>,
	"Len Brown" <lenb@kernel.org>, "Rob Herring" <robh@kernel.org>,
	"Saravana Kannan" <saravanak@kernel.org>,
	<driver-core@lists.linux.dev>, <linux-acpi@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>, <brgl@kernel.org>,
	<stable@vger.kernel.org>
Subject: Re: [PATCH] device property: set fwnode->secondary to NULL in fwnode_init()
Date: Fri, 08 May 2026 02:03:44 +0200	[thread overview]
Message-ID: <DICUSYTHZ339.3DW3CRNZ32K6U@kernel.org> (raw)
In-Reply-To: <20260506115701.23035-1-bartosz.golaszewski@oss.qualcomm.com>

On Wed May 6, 2026 at 1:57 PM CEST, Bartosz Golaszewski wrote:
> If a firmware node is allocated on the stack (for instance: temporary
> software node whose life-time we control) or on the heap - but using a
> non-zeroing allocation function - and initialized using fwnode_init(),
> its secondary pointer will contain uninitalized memory which likely will
> be neither NULL nor IS_ERR().

I see why secondary is generally more prone to this, but if the justification of
this change is to not rely on the caller to zero out the memory, then we might
just want to initialize all fields.

For instance, if the caller is allowed to not zero-initialize the memory then
having flags with a random value isn't correct either; all accessors are atomic
bitwise operations that never zero the whole field.

      parent reply	other threads:[~2026-05-08  0:03 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-06 11:57 [PATCH] device property: set fwnode->secondary to NULL in fwnode_init() Bartosz Golaszewski
2026-05-06 13:10 ` Andy Shevchenko
2026-05-06 13:16   ` Bartosz Golaszewski
2026-05-06 19:26 ` Rafael J. Wysocki
2026-05-07  7:25 ` Sakari Ailus
2026-05-08  0:03 ` Danilo Krummrich [this message]

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=DICUSYTHZ339.3DW3CRNZ32K6U@kernel.org \
    --to=dakr@kernel.org \
    --cc=andriy.shevchenko@linux.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=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rafael@kernel.org \
    --cc=robh@kernel.org \
    --cc=sakari.ailus@linux.intel.com \
    --cc=saravanak@kernel.org \
    --cc=stable@vger.kernel.org \
    /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