linux-kernel - Re: [PATCH] hwmon: (dell-smm) Simplify with cleanup.h

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <cbcf8eb9-1817-4451-9c1e-a0daa81a18ea@roeck-us.net>
Date: Wed, 3 Jul 2024 14:56:39 -0700
From: Guenter Roeck <linux@...ck-us.net>
To: Pali Rohár <pali@...nel.org>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
 Jean Delvare <jdelvare@...e.com>, linux-hwmon@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH] hwmon: (dell-smm) Simplify with cleanup.h

On 7/3/24 12:16, Pali Rohár wrote:
> On Wednesday 03 July 2024 11:52:14 Guenter Roeck wrote:
>> On 7/3/24 01:31, Krzysztof Kozlowski wrote:
>>> Allocate memory, which is being freed at end of the scope, to make the
>>> code a bit simpler.
>>>
>>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
>>> ---
>>>    drivers/hwmon/dell-smm-hwmon.c | 7 +++----
>>>    1 file changed, 3 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/hwmon/dell-smm-hwmon.c b/drivers/hwmon/dell-smm-hwmon.c
>>> index 0362a13f6525..e72e26db6e10 100644
>>> --- a/drivers/hwmon/dell-smm-hwmon.c
>>> +++ b/drivers/hwmon/dell-smm-hwmon.c
>>> @@ -14,6 +14,7 @@
>>>    #include <linux/acpi.h>
>>>    #include <linux/capability.h>
>>> +#include <linux/cleanup.h>
>>>    #include <linux/cpu.h>
>>>    #include <linux/ctype.h>
>>>    #include <linux/delay.h>
>>> @@ -1095,9 +1096,9 @@ static int dell_smm_init_cdev(struct device *dev, u8 fan_num)
>>>    	struct thermal_cooling_device *cdev;
>>>    	struct dell_smm_cooling_data *cdata;
>>>    	int ret = 0;
>>> -	char *name;
>>> -	name = kasprintf(GFP_KERNEL, "dell-smm-fan%u", fan_num + 1);
>>> +	char *name __free(kfree) = kasprintf(GFP_KERNEL, "dell-smm-fan%u",
>>> +					     fan_num + 1);
>>>    	if (!name)
>>>    		return -ENOMEM;
>>> @@ -1115,8 +1116,6 @@ static int dell_smm_init_cdev(struct device *dev, u8 fan_num)
>>>    		ret = -ENOMEM;
>>>    	}
>>> -	kfree(name);
>>> -
>>>    	return ret;
>>>    }
>>
>> If you really want to clean this up, just use
>> 	char name[32];
>> 	...
>> 	snprintf(name, sizeof(name), "dell-smm-fan%u", fan_num + 1);
>>
>> I don't see the point of all this complexity.
>>
>> Guenter
>>
> 
> Lets first ask a question: And what the problem we are solving there?

None.

> I do not see any memory leak here, it is neither mentioned in the commit
> message. So I think that there is no real problem, and code has just
> clear and explicit alloc/free pattern.
> 
Correct.

> On the other hand proposed change with __free does not make it simpler.
> It has still same complexity, plus magic around.
> 
Again correct.

> snprintf with stack allocation at the first glance looks simpler.
> 
> But has a problem that if in future the device name will change then it
> would be required also check (and maybe modify) size of stack buffer. In
> its usage you are specifying pair <sizeof(name), "dell-smm-fan%u"> which
> has size not related to the string. But something more common sense
> would be to specify pair <32,"dell-smm-fan%u"> which could say that it
> is always maximally 32 (and you can easily check if the string is not
> going to be larger). So for long term maintenance this is maybe worse.
> 

Agreed, but I very much prefer that over the complexity introduced with
the "free" magic.

Unfortunately, once framework code such as the free magic is introduced, it
doesn't help to just say "please go away", because people will just keep
submitting patches like this one which don't improve the code but still take
review time.

Guenter