From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>,
Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
x86@kernel.org, Hans de Goede <hansg@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Danilo Krummrich <dakr@kernel.org>,
Daniel Scally <djrscally@gmail.com>,
Heikki Krogerus <heikki.krogerus@linux.intel.com>,
Sakari Ailus <sakari.ailus@linux.intel.com>,
linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
driver-core@lists.linux.dev
Subject: Re: [PATCH v2 3/4] software node: verify that property data is not on stack
Date: Mon, 30 Mar 2026 14:49:52 -0700 [thread overview]
Message-ID: <acrvakIBxO76OAlU@google.com> (raw)
In-Reply-To: <acpRi0BOgT73pqpE@ashevche-desk.local>
On Mon, Mar 30, 2026 at 01:33:47PM +0300, Andy Shevchenko wrote:
> On Sun, Mar 29, 2026 at 07:27:50PM -0700, Dmitry Torokhov wrote:
> > When registering a software node, ensure that the property data is not
> > located on the stack, as it is expected to persist for the lifetime of
> > the node.
>
> ...
>
> > + for (prop = node->properties; prop && prop->name; prop++) {
> > + if (!prop->is_inline && object_is_on_stack(prop->pointer)) {
>
> I read more about this... Any code that uses vmalloc() (or potentially may
> switch to it from regular allocator with help of kvalloc() and similar) will
> fail now. While it might be no issue right now, this may become a such. So
> with this check in place you put a requirement that properties can only be
> allocated from a kernel low memory heap and not vm.
Can you tell me more about this? As far as I can see it will actually
have false negatives with CONFIG_VMAP_STACK, but should be OK not
trigger with vmalloced memory... But I am genuinely interested to know
more.
Thanks.
--
Dmitry
next prev parent reply other threads:[~2026-03-30 21:49 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-30 2:27 [PATCH v2 0/4] Fix handling of GPIO keys and LEDs on geode Dmitry Torokhov
2026-03-30 2:27 ` [PATCH v2 1/4] x86/geode: fix on-stack property data usage Dmitry Torokhov
2026-03-31 5:49 ` Dmitry Torokhov
2026-03-31 8:09 ` Ingo Molnar
2026-03-31 8:01 ` [tip: x86/urgent] x86/platform/geode: Fix on-stack property data use-after-return bug tip-bot2 for Dmitry Torokhov
2026-03-30 2:27 ` [PATCH v2 2/4] software node: allow passing reference args to PROPERTY_ENTRY_REF Dmitry Torokhov
2026-03-30 10:21 ` Andy Shevchenko
2026-03-30 2:27 ` [PATCH v2 3/4] software node: verify that property data is not on stack Dmitry Torokhov
2026-03-30 10:33 ` Andy Shevchenko
2026-03-30 21:49 ` Dmitry Torokhov [this message]
2026-03-31 8:02 ` Andy Shevchenko
2026-03-31 8:33 ` Andy Shevchenko
2026-04-05 3:27 ` Dmitry Torokhov
2026-04-05 3:29 ` Dmitry Torokhov
2026-03-30 2:27 ` [PATCH v2 4/4] x86/geode: use PROPERTY_ENTRY_REF for GPIO properties Dmitry Torokhov
2026-03-30 10:48 ` Andy Shevchenko
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=acrvakIBxO76OAlU@google.com \
--to=dmitry.torokhov@gmail.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=bp@alien8.de \
--cc=dakr@kernel.org \
--cc=dave.hansen@linux.intel.com \
--cc=djrscally@gmail.com \
--cc=driver-core@lists.linux.dev \
--cc=gregkh@linuxfoundation.org \
--cc=hansg@kernel.org \
--cc=heikki.krogerus@linux.intel.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=rafael@kernel.org \
--cc=sakari.ailus@linux.intel.com \
--cc=tglx@kernel.org \
--cc=x86@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 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.