From: "Rafael J. Wysocki" <rafael@kernel.org>
To: GuangFei Luo <luogf2025@163.com>
Cc: dan.carpenter@linaro.org, linux-acpi@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org
Subject: Re: [PATCH v6] ACPI: battery: prevent sysfs_add_battery re-entry on rapid events
Date: Tue, 23 Sep 2025 21:10:37 +0200 [thread overview]
Message-ID: <5944379.DvuYhMxLoT@rafael.j.wysocki> (raw)
In-Reply-To: <CAJZ5v0j2UH31wJKsAE0Ppek9sSiGFbePZymzbuaLVNfKHXjK4A@mail.gmail.com>
On Tuesday, September 23, 2025 7:12:03 PM CEST Rafael J. Wysocki wrote:
> On Tue, Sep 23, 2025 at 6:14 PM GuangFei Luo <luogf2025@163.com> wrote:
> >
> > The functions battery_hook_add_battery(), battery_hook_remove_battery(),
> > and sysfs_remove_battery() already acquire locks, so their internal
> > accesses are safe.
>
> In fact, there are two locks in use, battery->sysfs_lock and
> hook_mutex. The latter is used for managing hooks and the former is
> only used by sysfs_remove_battery(), so it only prevents that function
> from racing with another instance of itself.
>
> I would suggest using battery->sysfs_lock for protecting battery->bat
> in general.
>
> > acpi_battery_refresh() does check battery->bat, but its child
> > functions (sysfs_add_battery() and sysfs_remove_battery()) already
> > handle locking.
>
> What locking? Before the $subject patch, sysfs_add_battery() doesn't
> do any locking at all AFAICS.
>
> > In acpi_battery_notify(), battery->bat has no lock. However, the
> > check of battery->bat is at the very end of the function. During
> > earlier calls, battery->bat has already been protected by locks, so
> > re-entry will not cause issues.
>
> All of the battery->bat checks and the code depending on them need to
> go under the same lock. I'd use battery->sysfs_lock for this as
> already mentioned above.
So my (untested) version of this fix is appended.
Note that it explicitly prevents acpi_battery_notify() from racing with
addition/removal, PM notifications, and resume.
---
drivers/acpi/battery.c | 36 +++++++++++++++++++++++-------------
1 file changed, 23 insertions(+), 13 deletions(-)
--- a/drivers/acpi/battery.c
+++ b/drivers/acpi/battery.c
@@ -92,7 +92,7 @@ enum {
struct acpi_battery {
struct mutex lock;
- struct mutex sysfs_lock;
+ struct mutex update_lock;
struct power_supply *bat;
struct power_supply_desc bat_desc;
struct acpi_device *device;
@@ -904,15 +904,12 @@ static int sysfs_add_battery(struct acpi
static void sysfs_remove_battery(struct acpi_battery *battery)
{
- mutex_lock(&battery->sysfs_lock);
- if (!battery->bat) {
- mutex_unlock(&battery->sysfs_lock);
+ if (!battery->bat)
return;
- }
+
battery_hook_remove_battery(battery);
power_supply_unregister(battery->bat);
battery->bat = NULL;
- mutex_unlock(&battery->sysfs_lock);
}
static void find_battery(const struct dmi_header *dm, void *private)
@@ -1072,6 +1069,9 @@ static void acpi_battery_notify(acpi_han
if (!battery)
return;
+
+ guard(mutex)(&battery->update_lock);
+
old = battery->bat;
/*
* On Acer Aspire V5-573G notifications are sometimes triggered too
@@ -1094,21 +1094,22 @@ static void acpi_battery_notify(acpi_han
}
static int battery_notify(struct notifier_block *nb,
- unsigned long mode, void *_unused)
+ unsigned long mode, void *_unused)
{
struct acpi_battery *battery = container_of(nb, struct acpi_battery,
pm_nb);
- int result;
- switch (mode) {
- case PM_POST_HIBERNATION:
- case PM_POST_SUSPEND:
+ if (mode == PM_POST_SUSPEND || mode == PM_POST_HIBERNATION) {
+ guard(mutex)(&battery->update_lock);
+
if (!acpi_battery_present(battery))
return 0;
if (battery->bat) {
acpi_battery_refresh(battery);
} else {
+ int result;
+
result = acpi_battery_get_info(battery);
if (result)
return result;
@@ -1120,7 +1121,6 @@ static int battery_notify(struct notifie
acpi_battery_init_alarm(battery);
acpi_battery_get_state(battery);
- break;
}
return 0;
@@ -1198,6 +1198,8 @@ static int acpi_battery_update_retry(str
{
int retry, ret;
+ guard(mutex)(&battery->update_lock);
+
for (retry = 5; retry; retry--) {
ret = acpi_battery_update(battery, false);
if (!ret)
@@ -1230,7 +1232,7 @@ static int acpi_battery_add(struct acpi_
if (result)
return result;
- result = devm_mutex_init(&device->dev, &battery->sysfs_lock);
+ result = devm_mutex_init(&device->dev, &battery->update_lock);
if (result)
return result;
@@ -1262,6 +1264,8 @@ fail_pm:
device_init_wakeup(&device->dev, 0);
unregister_pm_notifier(&battery->pm_nb);
fail:
+ guard(mutex)(&battery->update_lock);
+
sysfs_remove_battery(battery);
return result;
@@ -1281,6 +1285,9 @@ static void acpi_battery_remove(struct a
device_init_wakeup(&device->dev, 0);
unregister_pm_notifier(&battery->pm_nb);
+
+ guard(mutex)(&battery->update_lock);
+
sysfs_remove_battery(battery);
}
@@ -1297,6 +1304,9 @@ static int acpi_battery_resume(struct de
return -EINVAL;
battery->update_time = 0;
+
+ guard(mutex)(&battery->update_lock);
+
acpi_battery_update(battery, true);
return 0;
}
next prev parent reply other threads:[~2025-09-23 19:10 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-10 14:26 [PATCH v2] ACPI: battery: prevent sysfs_add_battery re-entry on rapid events GuangFei Luo
2025-09-12 15:48 ` [PATCH v3] " GuangFei Luo
2025-09-12 15:57 ` Greg KH
2025-09-12 16:25 ` GuangFei Luo
2025-09-13 6:05 ` Greg KH
2025-09-13 7:19 ` [PATCH v4] " GuangFei Luo
2025-09-13 7:33 ` Greg KH
2025-09-13 7:56 ` [PATCH v5] " GuangFei Luo
2025-09-14 11:12 ` [PATCH v6] " GuangFei Luo
2025-09-23 2:38 ` GuangFei Luo
2025-09-23 11:48 ` Rafael J. Wysocki
2025-09-23 16:13 ` GuangFei Luo
2025-09-23 17:12 ` [PATCH " Rafael J. Wysocki
2025-09-23 19:10 ` Rafael J. Wysocki [this message]
2025-09-23 22:38 ` GuangFei Luo
2025-09-24 10:40 ` [PATCH " Rafael J. Wysocki
2025-09-24 14:10 ` GuangFei Luo
2025-09-24 17:22 ` [PATCH " Rafael J. Wysocki
2025-09-23 16:18 ` GuangFei Luo
-- strict thread matches above, loose matches on Subject: below --
2025-09-18 13:55 [PATCH " GuangFei Luo
2025-09-22 17:29 ` Rafael J. Wysocki
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=5944379.DvuYhMxLoT@rafael.j.wysocki \
--to=rafael@kernel.org \
--cc=dan.carpenter@linaro.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=luogf2025@163.com \
/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