All of
 help / color / mirror / Atom feed
From: Christophe JAILLET <>
To: Edmundo Carmona Antoranz <>
Subject: Re: [PATCH] ACPI: scan: Fix a memory leak in an error handling path
Date: Sat, 8 May 2021 20:47:26 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Le 08/05/2021 à 16:50, Edmundo Carmona Antoranz a écrit :
> On Sat, May 8, 2021 at 1:23 AM Christophe JAILLET
> <> wrote:
>> If 'acpi_device_set_name()' fails, we must free
>> 'acpi_device_bus_id->bus_id' or there is a (potential) memory leak.
> This is a question about the style used in kernel. This function
> (acpi_device_add) initializes acpi_device_bus_id and it could also
> initialize acpi_device_bus_id->bus_id and any of those might fail. And
> they will have to be freed if they are initialized and so on. I see
> that there are kfrees used for them in different places before using a
> goto err_unlock; I wonder if it is accepted practice to avoid doing
> these kfrees and have them in a single place instead, something like:
> err_onlock:
>      if (acpi_device_bus_id) {
>          if (acpi_device_bus_id->bus_id)
>              kfree(acpi_device_bus_id->bus_id);
>          kfree(acpi_device_bus_id);
>      }
>      mutex_unlock(&acpi_device_lock);
> .
> .
> .
> Thanks in advance.

Yes, usually, the preferred style is to have a error handling path which 
releases all that need to be released.
This is more future proof and usually more readable.

In this particular case, I don't think it would be a good idea because 
there are several different error handling pathd and it would look like 
spaghetti code.

First in your example, acpi_device_bus_id should be set to NULL in the 
declaration of this variable.

But, it is likely that the kfree and kfree_cont are not needed after the 
list_add_tail around line 707.

So, leaving these small pieces of resources freeing where they are now 
looks, IMHO, easier to understand.

But, as you say, it is sometimes a matter of taste, and if someone can 
propose something that is straightforward, it would be welcomed, I guess.


  reply	other threads:[~2021-05-08 18:47 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-08  7:23 Christophe JAILLET
2021-05-08 14:50 ` Edmundo Carmona Antoranz
2021-05-08 18:47   ` Christophe JAILLET [this message]
2021-05-10  5:39   ` Dan Carpenter
     [not found]     ` <>
2021-05-10 13:55       ` Dan Carpenter
2021-05-10 12:18 ` Andy Shevchenko
2021-05-10 17:04   ` 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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \
    --subject='Re: [PATCH] ACPI: scan: Fix a memory leak in an error handling path' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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.