| Message ID | e4359d5ef206f5b349c1d15a515a1205e78dda55.1686285892.git.christophe.jaillet@wanadoo.fr (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | [1/2] tty: serial: samsung_tty: Fix a memory leak in s3c24xx_serial_getclk() in case of error | expand |
On 09/06/2023 06:45, Christophe JAILLET wrote: > If clk_get_rate() fails, the clk that has just been allocated needs to be > freed. > > Fixes: 5f5a7a5578c5 ("serial: samsung: switch to clkdev based clock lookup") > Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> > --- Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Best regards, Krzysztof
Hi Christophe, On Fri, Jun 09, 2023 at 06:45:38AM +0200, Christophe JAILLET wrote: > If clk_get_rate() fails, the clk that has just been allocated needs to be > freed. > > Fixes: 5f5a7a5578c5 ("serial: samsung: switch to clkdev based clock lookup") > Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> As this is a fix, can you cc the stable kernel Cc: <stable@vger.kernel.org> # v3.3+ > --- > drivers/tty/serial/samsung_tty.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/drivers/tty/serial/samsung_tty.c b/drivers/tty/serial/samsung_tty.c > index 2a7520ad3abd..dd751e7010e3 100644 > --- a/drivers/tty/serial/samsung_tty.c > +++ b/drivers/tty/serial/samsung_tty.c > @@ -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? In any case: Reviewed-by: Andi Shyti <andi.shyti@kernel.org> Andi > + } > > if (ourport->info->has_divslot) { > unsigned long div = rate / req_baud; > -- > 2.34.1 >
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); fine for you? CJ
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); Fantastic! Thanks! Andi
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. Probably because such condition is highly unlikely if not impossible. This makes simple function unnecessarily bigger... Best regards, Krzysztof
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
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
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 >
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
diff --git a/drivers/tty/serial/samsung_tty.c b/drivers/tty/serial/samsung_tty.c index 2a7520ad3abd..dd751e7010e3 100644 --- a/drivers/tty/serial/samsung_tty.c +++ b/drivers/tty/serial/samsung_tty.c @@ -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; + } if (ourport->info->has_divslot) { unsigned long div = rate / req_baud;
If clk_get_rate() fails, the clk that has just been allocated needs to be freed. Fixes: 5f5a7a5578c5 ("serial: samsung: switch to clkdev based clock lookup") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> --- drivers/tty/serial/samsung_tty.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)