From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
To: Andi Shyti <andi.shyti@kernel.org>
Cc: Christophe JAILLET <christophe.jaillet@wanadoo.fr>,
Alim Akhtar <alim.akhtar@samsung.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Jiri Slaby <jirislaby@kernel.org>,
Thomas Abraham <thomas.abraham@linaro.org>,
Kukjin Kim <kgene.kim@samsung.com>,
linux-kernel@vger.kernel.org, kernel-janitors@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-samsung-soc@vger.kernel.org, linux-serial@vger.kernel.org
Subject: Re: [PATCH 1/2] tty: serial: samsung_tty: Fix a memory leak in s3c24xx_serial_getclk() in case of error
Date: Sat, 10 Jun 2023 19:32:57 +0200 [thread overview]
Message-ID: <7a66ca20-0f79-6182-1f5c-1770e83b53a9@linaro.org> (raw)
In-Reply-To: <20230610171015.vf7emd5crpr7n4mg@intel.intel>
On 10/06/2023 19:10, Andi Shyti wrote:
> 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.
This is the reason, because it was the conscious choice - not to print,
otherwise drivers are unreadable.
>
>> Probably because such condition is highly unlikely if not impossible.
>
> still... that's not a reason not to print it.
It is a reason not to print it in the driver. Code readability is more
important than adding error messages for every possible case in the driver.
>
> 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 :)
This is the reason not to print it in the driver, because it makes the
code less maintainable. Such unlikely errors should be handled by core,
not by every driver. If this error message here is reasonable, I would
argue that it is reasonable to add it to other places... try doing it.
You will see to what silly code it leads.
It's like adding dev_err to regmap_mmio read/write failures - code will
be difficult to read.
Best regards,
Krzysztof
next prev parent reply other threads:[~2023-06-10 17:33 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-09 4:45 [PATCH 1/2] tty: serial: samsung_tty: Fix a memory leak in s3c24xx_serial_getclk() in case of error Christophe JAILLET
2023-06-09 4:45 ` [PATCH 2/2] tty: serial: samsung_tty: Fix a memory leak in s3c24xx_serial_getclk() when iterating clk Christophe JAILLET
2023-06-09 8:57 ` AW: " Walter Harms
2023-06-09 11:56 ` Krzysztof Kozlowski
2023-06-09 16:17 ` Christophe JAILLET
2023-06-09 11:53 ` Krzysztof Kozlowski
2023-06-10 10:39 ` Andi Shyti
2023-06-10 10:45 ` Krzysztof Kozlowski
2023-06-10 10:57 ` Andi Shyti
2023-06-09 11:51 ` [PATCH 1/2] tty: serial: samsung_tty: Fix a memory leak in s3c24xx_serial_getclk() in case of error Krzysztof Kozlowski
2023-06-10 10:26 ` Andi Shyti
2023-06-10 14:07 ` Christophe JAILLET
2023-06-10 14:54 ` Andi Shyti
2023-06-10 16:23 ` Krzysztof Kozlowski
2023-06-10 17:10 ` Andi Shyti
2023-06-10 17:32 ` Krzysztof Kozlowski [this message]
2023-06-10 17:40 ` Christophe JAILLET
2023-06-12 4:53 ` Dan Carpenter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7a66ca20-0f79-6182-1f5c-1770e83b53a9@linaro.org \
--to=krzysztof.kozlowski@linaro.org \
--cc=alim.akhtar@samsung.com \
--cc=andi.shyti@kernel.org \
--cc=christophe.jaillet@wanadoo.fr \
--cc=gregkh@linuxfoundation.org \
--cc=jirislaby@kernel.org \
--cc=kernel-janitors@vger.kernel.org \
--cc=kgene.kim@samsung.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=thomas.abraham@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).