linux-kernel - Re: [PATCH 1/2] tty: serial: samsung_tty: Fix a memory leak in s3c24xx_serial

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] [thread-next>] [day] [month] [year] [list]

Date:   Sat, 10 Jun 2023 19:10:15 +0200
From:   Andi Shyti <andi.shyti@...nel.org>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Cc:     Christophe JAILLET <christophe.jaillet@...adoo.fr>,
        Alim Akhtar <alim.akhtar@...sung.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jiri Slaby <jirislaby@...nel.org>,
        Thomas Abraham <thomas.abraham@...aro.org>,
        Kukjin Kim <kgene.kim@...sung.com>,
        linux-kernel@...r.kernel.org, kernel-janitors@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org,
        linux-samsung-soc@...r.kernel.org, linux-serial@...r.kernel.org
Subject: Re: [PATCH 1/2] tty: serial: samsung_tty: Fix a memory leak in
 s3c24xx_serial_getclk() in case of error

On Sat, Jun 10, 2023 at 06:23:58PM +0200, Krzysztof Kozlowski wrote:
> On 10/06/2023 16:54, Andi Shyti wrote:
> > On Sat, Jun 10, 2023 at 04:07:51PM +0200, Christophe JAILLET wrote:
> >> Le 10/06/2023 à 12:26, Andi Shyti a écrit :
> >>>> @@ -1459,8 +1459,10 @@ static unsigned int s3c24xx_serial_getclk(struct s3c24xx_uart_port *ourport,
> >>>>   			continue;
> >>>>   		rate = clk_get_rate(clk);
> >>>> -		if (!rate)
> >>>> +		if (!rate) {
> >>>> +			clk_put(clk);
> >>>>   			continue;
> >>>
> >>> could you also print an error here?
> >>>
> >>
> >> Is:
> >> 	dev_err(ourport->port.dev,
> >> 		"Failed to get clock rate for %s.\n", clkname);
> 
> Why do we need it? Most of other users of clk_get_rate() don't print.

that's not a reason not to print it.

> Probably because such condition is highly unlikely if not impossible.

still... that's not a reason not to print it.

All errors are unlikely and if it's unlikely, why there is no
unlikely(!rate)? Which doesn't improve the reason not to print
it.

The more unlikely, the lauder you need to be:

WARN_ON(!rate)... maybe too much!
BUG_ON(!rate)... way too much!

But these are inversely proportional to the likeliness of the
error.

> This makes simple function unnecessarily bigger...

and... that's not a reason not to print it :)

If it's needed, it's needed. If we are considering the error,
then we need to treat it as an error.

In any case, I'm not strong with it, indeed, I r-b it anyway. I
personally prefer and suggested printing the error. Up to
Christophe.

Thanks,
Andi