[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <dd58a6a5-c65c-ea3b-6ed7-dcbcfc2263bc@wanadoo.fr>
Date: Sat, 10 Jun 2023 19:40:39 +0200
From: Christophe JAILLET <christophe.jaillet@...adoo.fr>
To: Andi Shyti <andi.shyti@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Cc: 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
Le 10/06/2023 à 19:10, Andi Shyti a écrit :
> 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.
git grep -A5 clk_get_rate | grep dev_err | wc -l
173
git grep clk_get_rate | wc -l
1464
(+ Krzysztof's argumentation)
So lets go for v1.
Can v1 be taken as is?
(knowing that I don't really care about the new 3/3 related to abs())
Or should I send a v3 to ease the process?
CJ
>
> Thanks,
> Andi
>
Powered by blists - more mailing lists