All of lore.kernel.org
 help / color / mirror / Atom feed
From: Armin Wolf <W_Armin@gmx.de>
To: Andres Salomon <dilinger@queued.net>
Cc: mjg59@srcf.ucam.org, pali@kernel.org, rafael@kernel.org,
	lenb@kernel.org, hdegoede@redhat.com,
	ilpo.jarvinen@linux.intel.com,
	platform-driver-x86@vger.kernel.org, linux-acpi@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] platform/x86: dell-laptop: Fix crash when unregistering battery hook
Date: Thu, 19 Sep 2024 09:48:02 +0200	[thread overview]
Message-ID: <115271db-b7dd-4490-9f24-9e0a99dbf133@gmx.de> (raw)
In-Reply-To: <20240919031329.3e0f76d0@5400>

Am 19.09.24 um 09:13 schrieb Andres Salomon:

> On Thu, 19 Sep 2024 08:33:32 +0200
> Armin Wolf <W_Armin@gmx.de> wrote:
>
>> If the battery hook encounters a unsupported battery, it will
>> return an error. This in turn will cause the battery driver to
>> automatically unregister the battery hook.
>>
>> However as soon as the driver itself attempts to unregister the
>> already unregistered battery hook, a crash occurs due to a
>> corrupted linked list.
>>
>> Fix this by simply ignoring unsupported batteries.
>>
>> Tested on a Dell Inspiron 3505.
>>
>> Fixes: ab58016c68cc ("platform/x86:dell-laptop: Add knobs to change battery charge settings")
>> Signed-off-by: Armin Wolf <W_Armin@gmx.de>
>> ---
>> I CCed the maintainers of the ACPI battery driver since i believe
>> that this patch highlights a general issue inside the battery hook
>> mechanism.
>>
>> This is because the same crash will be triggered should for example
>> device_add_groups() fail.
>>
>> Any ideas on how to solve this problem?
>> ---
> Hm, I see that when battery_hook_register() has the add_battery hook fail,
> then __battery_hook_unregister() calls the remove_battery hook. Does
> something like the following fix it?
>
> (note: not any kind of final patch, just a test.)

Not really, since the error can happen even while a new battery is being added,
which can happen anytime (even during battery hook removal). This means that using
a global variable would be prone to race conditions.

The issue can only be solved inside the ACPI battery driver itself, that is the reason
why i CCed the ACPI maintainers.

Aside from that, ignoring unsupported batteries allows the driver to work on
machines with multiple batteries.

Thanks,
Armin Wolf

>
> ---
>   drivers/platform/x86/dell/dell-laptop.c | 12 ++++++++++--
>   1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/platform/x86/dell/dell-laptop.c b/drivers/platform/x86/dell/dell-laptop.c
> index a9de19799f01..c7b92b2f7ed2 100644
> --- a/drivers/platform/x86/dell/dell-laptop.c
> +++ b/drivers/platform/x86/dell/dell-laptop.c
> @@ -2390,21 +2390,29 @@ static struct attribute *dell_battery_attrs[] = {
>   	NULL,
>   };
>   ATTRIBUTE_GROUPS(dell_battery);
> +static bool bgroup_registered = false;
>
>   static int dell_battery_add(struct power_supply *battery,
>   		struct acpi_battery_hook *hook)
>   {
> +	int err;
> +
>   	/* this currently only supports the primary battery */
>   	if (strcmp(battery->desc->name, "BAT0") != 0)
>   		return -ENODEV;
>
> -	return device_add_groups(&battery->dev, dell_battery_groups);
> +	err = device_add_groups(&battery->dev, dell_battery_groups);
> +	if (!err)
> +		bgroup_registered = true;
> +
> +	return err;
>   }
>
>   static int dell_battery_remove(struct power_supply *battery,
>   		struct acpi_battery_hook *hook)
>   {
> -	device_remove_groups(&battery->dev, dell_battery_groups);
> +	if (bgroup_registered)
> +		device_remove_groups(&battery->dev, dell_battery_groups);
>   	return 0;
>   }
>

      reply	other threads:[~2024-09-19  7:48 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-19  6:33 [PATCH] platform/x86: dell-laptop: Fix crash when unregistering battery hook Armin Wolf
2024-09-19  7:13 ` Andres Salomon
2024-09-19  7:48   ` Armin Wolf [this message]

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=115271db-b7dd-4490-9f24-9e0a99dbf133@gmx.de \
    --to=w_armin@gmx.de \
    --cc=dilinger@queued.net \
    --cc=hdegoede@redhat.com \
    --cc=ilpo.jarvinen@linux.intel.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mjg59@srcf.ucam.org \
    --cc=pali@kernel.org \
    --cc=platform-driver-x86@vger.kernel.org \
    --cc=rafael@kernel.org \
    /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.