Re: [PATCH v4 6/9] dax: plumb hotplug online_type through dax

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The default auto-online policy is captured at DAX device creation time rather than at driver bind time, breaking dynamic sysfs policy changes.
--

commit d528bb5263ccfd880f3665a7e5e92516c3faabd8
Author: Gregory Price <gourry@gourry.net>

dax: plumb hotplug online_type through dax

This commit adds an online_type field to the DAX device creation path to
allow drivers to specify an auto-online policy when using the kmem driver.
Existing callers are updated to initialize this field to the system default
policy.

> diff --git a/drivers/dax/bus.c b/drivers/dax/bus.c
> index 492573b47f662..6611fe399f59e 100644
> --- a/drivers/dax/bus.c
> +++ b/drivers/dax/bus.c
> @@ -394,6 +395,7 @@ static ssize_t create_store(struct device *dev, struct device_attribute *attr,
>  			.size = 0,
>  			.id = -1,
>  			.memmap_on_memory = false,
> +			.online_type = mhp_get_default_online_type(),
>  		};
>  		struct dev_dax *dev_dax = __devm_create_dev_dax(&data);

[ ... ]

> diff --git a/drivers/dax/kmem.c b/drivers/dax/kmem.c
> index 592171ec10f49..41ccb618a1464 100644
> --- a/drivers/dax/kmem.c
> +++ b/drivers/dax/kmem.c
> @@ -172,8 +172,9 @@ static int dev_dax_kmem_probe(struct dev_dax *dev_dax)
>  		 * Ensure that future kexec'd kernels will not treat
>  		 * this as RAM automatically.
>  		 */
> -		rc = add_memory_driver_managed(data->mgid, range.start,
> -				range_len(&range), kmem_name, mhp_flags);
> +		rc = __add_memory_driver_managed(data->mgid, range.start,
> +				range_len(&range), kmem_name, mhp_flags,
> +				dev_dax->online_type);

[Severity: High]
Does capturing the auto-online policy at device creation time break dynamic
sysfs policy changes?

DAX devices are typically created early during boot, when the global
auto-online policy is still the kernel default. Previously,
add_memory_driver_managed() dynamically evaluated the policy when the dax_kmem
driver was bound. This allowed userspace to configure the auto-online policy
dynamically before binding the driver.

By caching the policy during device creation in create_store() (and other
creation paths) and consuming it later in dev_dax_kmem_probe(), the kmem driver
might use a stale policy and ignore runtime changes to the global policy.

Will this cause memory blocks to unintentionally remain offline if the policy
was changed after device creation?

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