linux-kernel - Re: [PATCH] serial: 8250_of: replace kzalloc with devm

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: <2c6a3bc2-abd3-4d57-99e9-1c341c13d554@gmail.com>
Date: Fri, 29 Aug 2025 16:19:10 +0200
From: Osama Abdelkader <osama.abdelkader@...il.com>
To: Greg KH <gregkh@...uxfoundation.org>
Cc: jirislaby@...nel.org, andriy.shevchenko@...ux.intel.com,
 elder@...cstar.com, benjamin.larsson@...exis.eu,
 u.kleine-koenig@...libre.com, linux-kernel@...r.kernel.org,
 linux-serial@...r.kernel.org
Subject: Re: [PATCH] serial: 8250_of: replace kzalloc with devm_kzalloc


On 8/29/25 2:44 PM, Greg KH wrote:
> On Fri, Aug 29, 2025 at 11:49:41AM +0200, Osama Abdelkader wrote:
>> On 8/28/25 7:51 AM, Greg KH wrote:
>>> On Thu, Aug 28, 2025 at 01:11:05AM +0200, Osama Abdelkader wrote:
>>>> Use devm_kzalloc for automatic memory cleanup.
>>> Why?
>>>
>>> I do not see a good reason here as to how this makes anything better
>>> overall?  How was it tested?
>>>
>>> thanks,
>>>
>>> greg k-h
>> Hi Greg,
>>
>> Thanks for the feedback, the change to devm_kzalloc ensures the allocated
>> memory is tied to the device's lifetime. This removed the need for explicit
>> kfree() calls in the remove path and avoids potential leaks in probe error 
>> paths.
> But there are no existing errors, so why change working code?
>
>> It also aligns the driver with others in the 8250 subsystem which 
>> already use devm-managed resources.
> This code is older than the devm api :)
>
>> For testing, I built the kernel and booted it on QEMU riscv with of_serial
>> enabled. The driver probed successfully and the serial console worked as
>> expected, also tested unbinding/rebinding the driver via sysfs to confirm
>> no leaks or errors occur.
> But did you test the error paths?  That is what you changed here.
>
> And changes like this, for old, working, code, is usually not needed
> unless you are fixing a bug somewhere.
>
> thanks,
>
> greg k-h

Thanks Greg, totally understandable. I was looking for a simple patch to be honest
though looked for modernizing some APIs but looks like I chose the wrong driver:D
If you guide me to a simple bug or a simple contribution here would be much appreciated.

Thanks,
Osama