From: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
To: Edmundo Carmona Antoranz <eantoranz@gmail.com>
Cc: kernel-janitors@vger.kernel.org
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: <2d1269d8-89e4-684c-2a6e-63cf047b8c1a@wanadoo.fr> (raw)
In-Reply-To: <CAOc6etbPaPOjdcfYBY1i_N0V6Tua9p-OL5Hw7PgJ6T7dfRrhfA@mail.gmail.com>
Le 08/05/2021 à 16:50, Edmundo Carmona Antoranz a écrit :
> On Sat, May 8, 2021 at 1:23 AM Christophe JAILLET
> <christophe.jaillet@wanadoo.fr> 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.
CJ
next prev parent 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 [PATCH] ACPI: scan: Fix a memory leak in an error handling path 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] ` <CAOc6etbVZkANHVVmP5rss-nQqSYNiSFRXrg_nVUBV-719xKqJw@mail.gmail.com>
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:
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=2d1269d8-89e4-684c-2a6e-63cf047b8c1a@wanadoo.fr \
--to=christophe.jaillet@wanadoo.fr \
--cc=eantoranz@gmail.com \
--cc=kernel-janitors@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).