public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
* [PATCH v1 1/1] ACPI: battery: Check for error code from devm_mutex_init() call
@ 2024-10-30 16:27 Andy Shevchenko
  2024-10-30 16:42 ` Thomas Weißschuh
  0 siblings, 1 reply; 6+ messages in thread
From: Andy Shevchenko @ 2024-10-30 16:27 UTC (permalink / raw)
  To: Rafael J. Wysocki, Thomas Weißschuh, linux-acpi,
	linux-kernel
  Cc: Rafael J. Wysocki, Len Brown, Andy Shevchenko

Even if it's not critical, the avoidance of checking the error code
from devm_mutex_init() call today diminishes the point of using devm
variant of it. Tomorrow it may even leak something. Add the missed
check.

Fixes: 0710c1ce5045 ("ACPI: battery: initialize mutexes through devm_ APIs")
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 drivers/acpi/battery.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/acpi/battery.c b/drivers/acpi/battery.c
index 66662712e288..70f706d7634f 100644
--- a/drivers/acpi/battery.c
+++ b/drivers/acpi/battery.c
@@ -1226,8 +1226,12 @@ static int acpi_battery_add(struct acpi_device *device)
 	strscpy(acpi_device_name(device), ACPI_BATTERY_DEVICE_NAME);
 	strscpy(acpi_device_class(device), ACPI_BATTERY_CLASS);
 	device->driver_data = battery;
-	devm_mutex_init(&device->dev, &battery->lock);
-	devm_mutex_init(&device->dev, &battery->sysfs_lock);
+	result = devm_mutex_init(&device->dev, &battery->lock);
+	if (result)
+		return result;
+	result = devm_mutex_init(&device->dev, &battery->sysfs_lock);
+	if (result)
+		return result;
 	if (acpi_has_method(battery->device->handle, "_BIX"))
 		set_bit(ACPI_BATTERY_XINFO_PRESENT, &battery->flags);
 
-- 
2.43.0.rc1.1336.g36b5255a03ac


^ permalink raw reply related	[flat|nested] 6+ messages in thread

* Re: [PATCH v1 1/1] ACPI: battery: Check for error code from devm_mutex_init() call
  2024-10-30 16:27 [PATCH v1 1/1] ACPI: battery: Check for error code from devm_mutex_init() call Andy Shevchenko
@ 2024-10-30 16:42 ` Thomas Weißschuh
  2024-10-30 17:31   ` Andy Shevchenko
  2024-11-04 16:56   ` Rafael J. Wysocki
  0 siblings, 2 replies; 6+ messages in thread
From: Thomas Weißschuh @ 2024-10-30 16:42 UTC (permalink / raw)
  To: Andy Shevchenko
  Cc: Rafael J. Wysocki, Thomas Weißschuh, linux-acpi,
	linux-kernel, Rafael J. Wysocki, Len Brown

Hi Andy,

Oct 30, 2024 10:28:03 Andy Shevchenko <andriy.shevchenko@linux.intel.com>:

> Even if it's not critical, the avoidance of checking the error code
> from devm_mutex_init() call today diminishes the point of using devm
> variant of it. Tomorrow it may even leak something. Add the missed
> check.

Thanks!

Assuming you found this via some sort of tool and you already fixed up all the other places in the tree missing these checks,
wouldn't it make sense to mark devm_mutex_init() as __must_check?

> Fixes: 0710c1ce5045 ("ACPI: battery: initialize mutexes through devm_ APIs")
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

Reviewed-by: Thomas Weißschuh <linux@weissschuh.net>

> ---
> drivers/acpi/battery.c | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/acpi/battery.c b/drivers/acpi/battery.c
> index 66662712e288..70f706d7634f 100644
> --- a/drivers/acpi/battery.c
> +++ b/drivers/acpi/battery.c
> @@ -1226,8 +1226,12 @@ static int acpi_battery_add(struct acpi_device *device)
>     strscpy(acpi_device_name(device), ACPI_BATTERY_DEVICE_NAME);
>     strscpy(acpi_device_class(device), ACPI_BATTERY_CLASS);
>     device->driver_data = battery;
> -   devm_mutex_init(&device->dev, &battery->lock);
> -   devm_mutex_init(&device->dev, &battery->sysfs_lock);
> +   result = devm_mutex_init(&device->dev, &battery->lock);
> +   if (result)
> +       return result;
> +   result = devm_mutex_init(&device->dev, &battery->sysfs_lock);
> +   if (result)
> +       return result;
>     if (acpi_has_method(battery->device->handle, "_BIX"))
>         set_bit(ACPI_BATTERY_XINFO_PRESENT, &battery->flags);
>
> --
> 2.43.0.rc1.1336.g36b5255a03ac


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH v1 1/1] ACPI: battery: Check for error code from devm_mutex_init() call
  2024-10-30 16:42 ` Thomas Weißschuh
@ 2024-10-30 17:31   ` Andy Shevchenko
  2024-10-30 18:29     ` Thomas Weißschuh
  2024-11-04 16:56   ` Rafael J. Wysocki
  1 sibling, 1 reply; 6+ messages in thread
From: Andy Shevchenko @ 2024-10-30 17:31 UTC (permalink / raw)
  To: Thomas Weißschuh
  Cc: Rafael J. Wysocki, Thomas Weißschuh, linux-acpi,
	linux-kernel, Rafael J. Wysocki, Len Brown

On Wed, Oct 30, 2024 at 10:42:18AM -0600, Thomas Weißschuh wrote:
> Oct 30, 2024 10:28:03 Andy Shevchenko <andriy.shevchenko@linux.intel.com>:

...

> Assuming you found this via some sort of tool and you already fixed up all
> the other places in the tree missing these checks,

The tool is called `git grep`.

> wouldn't it make sense to mark devm_mutex_init() as __must_check?

It's macro, any idea how to do that for the macros?

...

> Reviewed-by: Thomas Weißschuh <linux@weissschuh.net>

Thanks!

-- 
With Best Regards,
Andy Shevchenko



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH v1 1/1] ACPI: battery: Check for error code from devm_mutex_init() call
  2024-10-30 17:31   ` Andy Shevchenko
@ 2024-10-30 18:29     ` Thomas Weißschuh
  2024-10-31  7:08       ` Andy Shevchenko
  0 siblings, 1 reply; 6+ messages in thread
From: Thomas Weißschuh @ 2024-10-30 18:29 UTC (permalink / raw)
  To: Andy Shevchenko
  Cc: Rafael J. Wysocki, linux-acpi, linux-kernel, Rafael J. Wysocki,
	Len Brown

Oct 30, 2024 11:31:21 Andy Shevchenko <andriy.shevchenko@linux.intel.com>:

> On Wed, Oct 30, 2024 at 10:42:18AM -0600, Thomas Weißschuh wrote:
>> Oct 30, 2024 10:28:03 Andy Shevchenko <andriy.shevchenko@linux.intel.com>:
>
> ...

>> wouldn't it make sense to mark devm_mutex_init() as __must_check?
>
> It's macro, any idea how to do that for the macros?

It should work on __devm_mutex_init().
I don't think the expression macro  in between should interfere.
Unfortunately I can't test it myself right now.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH v1 1/1] ACPI: battery: Check for error code from devm_mutex_init() call
  2024-10-30 18:29     ` Thomas Weißschuh
@ 2024-10-31  7:08       ` Andy Shevchenko
  0 siblings, 0 replies; 6+ messages in thread
From: Andy Shevchenko @ 2024-10-31  7:08 UTC (permalink / raw)
  To: Thomas Weißschuh
  Cc: Rafael J. Wysocki, linux-acpi, linux-kernel, Rafael J. Wysocki,
	Len Brown

On Wed, Oct 30, 2024 at 12:29:31PM -0600, Thomas Weißschuh wrote:
> Oct 30, 2024 11:31:21 Andy Shevchenko <andriy.shevchenko@linux.intel.com>:
> > On Wed, Oct 30, 2024 at 10:42:18AM -0600, Thomas Weißschuh wrote:
> >> Oct 30, 2024 10:28:03 Andy Shevchenko <andriy.shevchenko@linux.intel.com>:

...

> >> wouldn't it make sense to mark devm_mutex_init() as __must_check?
> >
> > It's macro, any idea how to do that for the macros?
> 
> It should work on __devm_mutex_init().
> I don't think the expression macro  in between should interfere.
> Unfortunately I can't test it myself right now.

Okay, when you have a patch, feel free to Cc me for review.

-- 
With Best Regards,
Andy Shevchenko



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH v1 1/1] ACPI: battery: Check for error code from devm_mutex_init() call
  2024-10-30 16:42 ` Thomas Weißschuh
  2024-10-30 17:31   ` Andy Shevchenko
@ 2024-11-04 16:56   ` Rafael J. Wysocki
  1 sibling, 0 replies; 6+ messages in thread
From: Rafael J. Wysocki @ 2024-11-04 16:56 UTC (permalink / raw)
  To: Thomas Weißschuh, Andy Shevchenko
  Cc: Rafael J. Wysocki, Thomas Weißschuh, linux-acpi,
	linux-kernel, Rafael J. Wysocki, Len Brown

On Wed, Oct 30, 2024 at 5:42 PM Thomas Weißschuh <thomas@weissschuh.net> wrote:
>
> Hi Andy,
>
> Oct 30, 2024 10:28:03 Andy Shevchenko <andriy.shevchenko@linux.intel.com>:
>
> > Even if it's not critical, the avoidance of checking the error code
> > from devm_mutex_init() call today diminishes the point of using devm
> > variant of it. Tomorrow it may even leak something. Add the missed
> > check.
>
> Thanks!
>
> Assuming you found this via some sort of tool and you already fixed up all the other places in the tree missing these checks,
> wouldn't it make sense to mark devm_mutex_init() as __must_check?
>
> > Fixes: 0710c1ce5045 ("ACPI: battery: initialize mutexes through devm_ APIs")
> > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>
> Reviewed-by: Thomas Weißschuh <linux@weissschuh.net>

Applied, thanks!

> > ---
> > drivers/acpi/battery.c | 8 ++++++--
> > 1 file changed, 6 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/acpi/battery.c b/drivers/acpi/battery.c
> > index 66662712e288..70f706d7634f 100644
> > --- a/drivers/acpi/battery.c
> > +++ b/drivers/acpi/battery.c
> > @@ -1226,8 +1226,12 @@ static int acpi_battery_add(struct acpi_device *device)
> >     strscpy(acpi_device_name(device), ACPI_BATTERY_DEVICE_NAME);
> >     strscpy(acpi_device_class(device), ACPI_BATTERY_CLASS);
> >     device->driver_data = battery;
> > -   devm_mutex_init(&device->dev, &battery->lock);
> > -   devm_mutex_init(&device->dev, &battery->sysfs_lock);
> > +   result = devm_mutex_init(&device->dev, &battery->lock);
> > +   if (result)
> > +       return result;
> > +   result = devm_mutex_init(&device->dev, &battery->sysfs_lock);
> > +   if (result)
> > +       return result;
> >     if (acpi_has_method(battery->device->handle, "_BIX"))
> >         set_bit(ACPI_BATTERY_XINFO_PRESENT, &battery->flags);
> >
> > --
> > 2.43.0.rc1.1336.g36b5255a03ac
>

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2024-11-04 16:56 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-10-30 16:27 [PATCH v1 1/1] ACPI: battery: Check for error code from devm_mutex_init() call Andy Shevchenko
2024-10-30 16:42 ` Thomas Weißschuh
2024-10-30 17:31   ` Andy Shevchenko
2024-10-30 18:29     ` Thomas Weißschuh
2024-10-31  7:08       ` Andy Shevchenko
2024-11-04 16:56   ` Rafael J. Wysocki

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox