| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <CAMRc=McEB+yVYxropzsqLExZCU5Pd_iy_=5N3pTxu28-ZX=7_w@mail.gmail.com>
Date: Fri, 2 Jan 2026 11:05:50 +0100
From: Bartosz Golaszewski <brgl@...nel.org>
To: Shivendra Pratap <shivendra.pratap@....qualcomm.com>
Cc: Lorenzo Pieralisi <lpieralisi@...nel.org>, Arnd Bergmann <arnd@...db.de>,
Bjorn Andersson <andersson@...nel.org>, Sebastian Reichel <sre@...nel.org>, Rob Herring <robh@...nel.org>,
Sudeep Holla <sudeep.holla@....com>, Souvik Chakravarty <Souvik.Chakravarty@....com>,
Krzysztof Kozlowski <krzk+dt@...nel.org>, Andy Yan <andy.yan@...k-chips.com>,
John Stultz <john.stultz@...aro.org>, Matthias Brugger <matthias.bgg@...il.com>,
Moritz Fischer <moritz.fischer@...us.com>, Mark Rutland <mark.rutland@....com>,
Conor Dooley <conor+dt@...nel.org>, Konrad Dybcio <konradybcio@...nel.org>,
Florian Fainelli <florian.fainelli@...adcom.com>, Krzysztof Kozlowski <krzk@...nel.org>,
Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>,
Mukesh Ojha <mukesh.ojha@....qualcomm.com>, Andre Draszik <andre.draszik@...aro.org>,
Kathiravan Thirumoorthy <kathiravan.thirumoorthy@....qualcomm.com>, linux-pm@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
Srinivas Kandagatla <srini@...nel.org>
Subject: Re: [PATCH v19 01/10] power: reset: reboot-mode: Remove devres based allocations
On Sun, Dec 28, 2025 at 6:20 PM Shivendra Pratap
<shivendra.pratap@....qualcomm.com> wrote:
>
> Devres APIs are intended for use in drivers, where the managed lifetime
> of resources is tied directly to the driver attach/detach cycle. In
> shared subsystem code, there is no guarantee that the subsystem
> functions will only be called after a driver has been attached, nor that
> they will not be referenced after the managed resources have been
> released during driver detach.
>
> To ensure correct lifetime handling, avoid using devres-based
> allocations in the reboot-mode and explicitly handle allocation and
> cleanup of resources.
>
> Fixes: 4fcd504edbf7 ("power: reset: add reboot mode driver")
> Signed-off-by: Shivendra Pratap <shivendra.pratap@....qualcomm.com>
> ---
> drivers/power/reset/reboot-mode.c | 34 ++++++++++++++++++++++------------
> 1 file changed, 22 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/power/reset/reboot-mode.c b/drivers/power/reset/reboot-mode.c
> index fba53f638da04655e756b5f8b7d2d666d1379535..3af6bc16a76daee686e8110b74e71b0e62b13ef8 100644
> --- a/drivers/power/reset/reboot-mode.c
> +++ b/drivers/power/reset/reboot-mode.c
> @@ -3,6 +3,8 @@
> * Copyright (c) 2016, Fuzhou Rockchip Electronics Co., Ltd
> */
>
> +#define pr_fmt(fmt) "reboot-mode: " fmt
> +
> #include <linux/device.h>
> #include <linux/init.h>
> #include <linux/kernel.h>
> @@ -10,6 +12,7 @@
> #include <linux/of.h>
> #include <linux/reboot.h>
> #include <linux/reboot-mode.h>
> +#include <linux/slab.h>
>
> #define PREFIX "mode-"
>
> @@ -71,9 +74,11 @@ static int reboot_mode_notify(struct notifier_block *this,
> int reboot_mode_register(struct reboot_mode_driver *reboot)
> {
> struct mode_info *info;
> + struct mode_info *next;
> struct property *prop;
> struct device_node *np = reboot->dev->of_node;
> size_t len = strlen(PREFIX);
> + u32 magic;
> int ret;
>
> INIT_LIST_HEAD(&reboot->head);
> @@ -82,19 +87,17 @@ int reboot_mode_register(struct reboot_mode_driver *reboot)
> if (strncmp(prop->name, PREFIX, len))
> continue;
>
> - info = devm_kzalloc(reboot->dev, sizeof(*info), GFP_KERNEL);
> + if (of_property_read_u32(np, prop->name, &magic)) {
Please use device_property_read_u32() if you have access to a device struct.
> + pr_err("reboot mode %s without magic number\n", prop->name);
If this is an error, shouldn't we bail out?
> + continue;
> + }
> +
> + info = kzalloc(sizeof(*info), GFP_KERNEL);
> if (!info) {
> ret = -ENOMEM;
> goto error;
> }
>
> - if (of_property_read_u32(np, prop->name, &info->magic)) {
> - dev_err(reboot->dev, "reboot mode %s without magic number\n",
> - info->mode);
> - devm_kfree(reboot->dev, info);
> - continue;
> - }
> -
> info->mode = kstrdup_const(prop->name + len, GFP_KERNEL);
> if (!info->mode) {
> ret = -ENOMEM;
> @@ -102,8 +105,7 @@ int reboot_mode_register(struct reboot_mode_driver *reboot)
> } else if (info->mode[0] == '\0') {
> kfree_const(info->mode);
> ret = -EINVAL;
> - dev_err(reboot->dev, "invalid mode name(%s): too short!\n",
> - prop->name);
> + pr_err("invalid mode name(%s): too short!\n", prop->name);
> goto error;
> }
>
> @@ -116,8 +118,12 @@ int reboot_mode_register(struct reboot_mode_driver *reboot)
> return 0;
>
> error:
> - list_for_each_entry(info, &reboot->head, list)
> + kfree(info);
> + list_for_each_entry_safe(info, next, &reboot->head, list) {
> + list_del(&info->list);
> kfree_const(info->mode);
> + kfree(info);
> + }
>
> return ret;
> }
> @@ -130,11 +136,15 @@ EXPORT_SYMBOL_GPL(reboot_mode_register);
> int reboot_mode_unregister(struct reboot_mode_driver *reboot)
> {
> struct mode_info *info;
> + struct mode_info *next;
>
> unregister_reboot_notifier(&reboot->reboot_notifier);
>
> - list_for_each_entry(info, &reboot->head, list)
> + list_for_each_entry_safe(info, next, &reboot->head, list) {
> + list_del(&info->list);
> kfree_const(info->mode);
> + kfree(info);
> + }
The code is repeated here, maybe factor it out into a separate function?
>
> return 0;
> }
>
> --
> 2.34.1
>
Bart
Powered by blists - more mailing lists