Re: [PATCH 0/2] ACPI: battery: Do not generate too much pressure on ACPI methods

[Rafael J. Wysocki]

On Tue, May 26, 2026 at 8:33 PM Rong Zhang <i@xxxxxxxx> wrote:
>
> The acpi_battery_get_property() and acpi_battery_notify() callbacks
> sometimes generate too much pressure on corresponding ACPI methods. On
> some devices with fragile ACPI implementation, these methods share the
> same mutex protecting EC accesses (hence slow to execute) with a lot of
> other EC-related methods. Such pressure on them eventually leads to a
> catastrophic situation that a bunch of ACPI method calls fail to acquire
> the same mutex due to timeout. The firmware of these devices doesn't
> handle mutex acquisition failure gracefully and return garbage data,
> causing even more chaos.
>
> For acpi_battery_get_property(), it generates too much pressure on the
> _BST method because of the lack of synchronization. In detail, it
> sometimes nullifies the cache mechanism of acpi_battery_get_state() when
> multiple processes read power supply properties simultaneously, which
> usually happens after a uevent. Normally, emitting a uevent implies that
> the cache must have been refreshed due to power_supply_uevent() reading
> all properties, so the mentioned processes should have seen cache hits.
> Unfortunately, these fragile devices' power_supply_ext properties are
> somehow slow to read after battery events, resulting in cache expiration
> before power_supply_uevent() finishes. Hence, once the uevent reaches
> userspace, the _BST method will be executed multiple times within a
> short period due to userspace processes reading all properties again.
>
> For acpi_battery_notify(), a very common pattern in EC queries that
> emits two consecutive battery notifications with event IDs 0x80 and 0x81
> updates battery state and calls power_supply_changed() twice within a
> short period, generating significant pressure on _STA, _BST and
> _BIX/_BIF methods. Not only that, power_supply_ext properties may also
> rely on some other ACPI methods, so both uevent assembling and userspace
> processes call them. It becomes a nightmare when all these methods share
> the same ACPI mutex and hence vulnerable to lock starvation. Even worse,
> after the first uevent reaches userspace, some userspace processes start
> to read all battery properties in order to refresh their internal
> states, which competes with the second notification's handling and
> uevent assembling, exacerbating the lock starvation.
>
> Fix acpi_battery_get_property() by protecting it with update_lock to
> synchronize it. This also prevents potential race conditions, e.g., when
> multiple tasks read power supply properties simultaneously, or when
> other synchronized methods are called during its execution.
>
> Improve acpi_battery_notify() by merging consecutive battery
> notifications within 10ms using a delayed work, so that they only
> refresh and/or update battery state once. ACPI netlink event and
> notifier call chain are still triggered multiple times in order not to
> break other components. Finally, call power_supply_changed() once and
> lead to a single uevent instead of a bunch, preventing userspace
> programs from causing too much pressure on power supply properties and
> the underlying ACPI methods.
>
> With the series, the lock starvation issue on mentioned devices is
> greatly improved according to the feedback from one of the device
> owners.
>
> Tested-by: Jeffrey Wälti <jeffrey@xxxxxxxxxx>
> Cc: stable@xxxxxxxxxxxxxxx
> Reported-by: Rick <rickk1166@xxxxxxxxx>
> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221065
>
> Signed-off-by: Rong Zhang <i@xxxxxxxx>
> ---
> Rong Zhang (2):
>       ACPI: battery: Synchronize get_property() callback
>       ACPI: battery: Merge consecutive battery notifications
>
>  drivers/acpi/battery.c | 113 +++++++++++++++++++++++++++++++++++++------------
>  1 file changed, 87 insertions(+), 26 deletions(-)
> ---

Please see sashiko.dev's feedback on this series:

https://sashiko.dev/#/patchset/20260527-b4-acpi-battery-notification-v1-0-2303bed8ec0b%40rong.moe

and address it or let me know why you think that it doesn't need to be
addressed.

Thanks!