[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <30c3b1ae-8df0-4112-bfbb-988d6c8a04e0@kadam.mountain>
Date: Mon, 12 Jun 2023 07:53:03 +0300
From: Dan Carpenter <dan.carpenter@...aro.org>
To: Andi Shyti <andi.shyti@...nel.org>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
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 07:10:15PM +0200, Andi Shyti wrote:
> All errors are unlikely and if it's unlikely, why there is no
> unlikely(!rate)?
The likely/unlikely() annotations help performance at the expense of
readability. If they improved readability every if statement would have
them. They should only be used if it makes a difference in a benchmark.
I think I have heard other people say the rule is that they shouldn't be
used in the drivers/ directory.
Also the other thing to consider is that quite often GCC is clever
enough to figure out which paths are success paths and which are failure
paths. So sometimes adding the annotation is redundant.
regards,
dan carpenter
Powered by blists - more mailing lists