Le 08/05/2021 à 16:50, Edmundo Carmona Antoranz a écrit :
On Sat, May 8, 2021 at 1:23 AM Christophe JAILLET
<christophe.jaillet@xxxxxxxxxx> 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
