All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Gregory Price" <gourry@gourry.net>
Cc: linux-cxl@vger.kernel.org
Subject: Re: [PATCH v4 3/9] mm/memory_hotplug: export mhp_get_default_online_type
Date: Fri, 05 Jun 2026 21:29:16 +0000	[thread overview]
Message-ID: <20260605212916.7B3591F00893@smtp.kernel.org> (raw)
In-Reply-To: <20260605211911.2160954-4-gourry@gourry.net>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Lazy initialization of `mhp_default_online_type` can race with sysfs updates, silently clobbering the user-specified hotplug policy.
--

commit 7d00f30f087affb00391db7c7b27504af6cf3ac3
Author: Gregory Price <gourry@gourry.net>

mm/memory_hotplug: export mhp_get_default_online_type

Drivers which may pass hotplug policy down to DAX need MMOP_ symbols
and the mhp_get_default_online_type function for hotplug use cases.
This commit exports the mhp_get_default_online_type function to allow
these drivers to build and function when hotplug is disabled.

> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> index 6833208cc17cb..4942570540956 100644
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
[ ... ]
> @@ -239,6 +239,7 @@ enum mmop mhp_get_default_online_type(void)
>  
>  	return mhp_default_online_type;
>  }
> +EXPORT_SYMBOL_GPL(mhp_get_default_online_type);

[Severity: High]
This isn't a bug introduced by this patch, but exporting this function for
asynchronous driver module initialization paths significantly increases the
probability of a data race with sysfs updates.

Can this lazy initialization clobber a user-specified hotplug policy?

If a driver calls mhp_get_default_online_type() and reads the uninitialized
state just as userspace writes to /sys/devices/system/memory/auto_online_blocks,
could the following sequence occur?

CPU1 (Driver init calling mhp_get_default_online_type):
    if (mhp_default_online_type >= 0) // reads -1

CPU2 (Sysfs write calling auto_online_blocks_store in drivers/base/memory.c):
    mhp_set_default_online_type(online_type); // sets user policy

CPU1 (Continuing in mhp_get_default_online_type):
    if (IS_ENABLED(CONFIG_MHP_DEFAULT_ONLINE_TYPE_OFFLINE))
        mhp_default_online_type = MMOP_OFFLINE; // clobbers user policy

Does this unprotected check-and-set sequence on a global configuration
variable need serialization to prevent the user-specified policy from being
silently lost?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260605211911.2160954-1-gourry@gourry.net?part=3

  reply	other threads:[~2026-06-05 21:29 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-05 21:19 [PATCH v4 0/9] dax/kmem: atomic whole-device hotplug via sysfs Gregory Price
2026-06-05 21:19 ` [PATCH v4 1/9] mm/memory: add memory_block_aligned_range() helper Gregory Price
2026-06-09  9:50   ` David Hildenbrand (Arm)
2026-06-05 21:19 ` [PATCH v4 2/9] mm/memory_hotplug: pass online_type to online_memory_block() via arg Gregory Price
2026-06-05 21:19 ` [PATCH v4 3/9] mm/memory_hotplug: export mhp_get_default_online_type Gregory Price
2026-06-05 21:29   ` sashiko-bot [this message]
2026-06-05 21:43     ` Gregory Price
2026-06-09  9:52   ` David Hildenbrand (Arm)
2026-06-09 15:11     ` Gregory Price
2026-06-05 21:19 ` [PATCH v4 4/9] mm/memory_hotplug: add __add_memory_driver_managed() with online_type arg Gregory Price
2026-06-09  9:55   ` David Hildenbrand (Arm)
2026-06-09 15:12     ` Gregory Price
2026-06-05 21:19 ` [PATCH v4 5/9] mm/memory_hotplug: add multi-range hotunplug Gregory Price
2026-06-05 21:30   ` sashiko-bot
2026-06-09 10:06   ` David Hildenbrand (Arm)
2026-06-09 15:15     ` Gregory Price
2026-06-05 21:19 ` [PATCH v4 6/9] dax: plumb hotplug online_type through dax Gregory Price
2026-06-05 21:31   ` sashiko-bot
2026-06-05 21:54     ` Gregory Price
2026-06-09 10:21       ` David Hildenbrand (Arm)
2026-06-09 15:33         ` Gregory Price
2026-06-05 21:19 ` [PATCH v4 7/9] dax/kmem: extract hotplug/hotremove helper functions Gregory Price
2026-06-05 21:36   ` sashiko-bot
2026-06-05 22:03     ` Gregory Price
2026-06-05 21:19 ` [PATCH v4 8/9] dax/kmem: add sysfs interface for atomic hotplug Gregory Price
2026-06-05 21:37   ` sashiko-bot
2026-06-09 10:26   ` David Hildenbrand (Arm)
2026-06-09 15:35     ` Gregory Price
2026-06-09 18:11       ` David Hildenbrand (Arm)
2026-06-09 18:19         ` Gregory Price
2026-06-09 18:22           ` David Hildenbrand (Arm)
2026-06-09 18:33             ` Gregory Price
2026-06-05 21:19 ` [PATCH v4 9/9] selftests/dax: add dax/kmem hotplug sysfs regression test Gregory Price
2026-06-05 21:34   ` sashiko-bot

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=20260605212916.7B3591F00893@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=gourry@gourry.net \
    --cc=linux-cxl@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /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.