[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <59596244622c4a15ac8cc0747332d0be@AcuMS.aculab.com>
Date: Thu, 22 Apr 2021 16:21:40 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Dan Carpenter' <dan.carpenter@...cle.com>,
Joel Stanley <joel@....id.au>
CC: Andrew Jeffery <andrew@...id.au>,
"Chia-Wei, Wang" <chiawei_wang@...eedtech.com>,
Jae Hyun Yoo <jae.hyun.yoo@...el.com>,
"John Wang" <wangzhiqiang.bj@...edance.com>,
Brad Bishop <bradleyb@...ziesquirrel.com>,
Patrick Venture <venture@...gle.com>,
"Benjamin Fair" <benjaminfair@...gle.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Robert Lippert <rlippert@...gle.com>,
"linux-aspeed@...ts.ozlabs.org" <linux-aspeed@...ts.ozlabs.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"kernel-janitors@...r.kernel.org" <kernel-janitors@...r.kernel.org>
Subject: RE: [PATCH] soc: aspeed: fix a ternary sign expansion bug
From: Dan Carpenter
> Sent: 22 April 2021 10:12
>
> The intent here was to return negative error codes but it actually
> returns positive values. The problem is that type promotion with
> ternary operations is quite complicated.
>
> "ret" is an int. "copied" is a u32. And the snoop_file_read() function
> returns long. What happens is that "ret" is cast to u32 and becomes
> positive then it's cast to long and it's still positive.
>
> Fix this by removing the ternary so that "ret" is type promoted directly
> to long.
>
> Fixes: 3772e5da4454 ("drivers/misc: Aspeed LPC snoop output using misc chardev")
> Signed-off-by: Dan Carpenter <dan.carpenter@...cle.com>
> ---
> drivers/soc/aspeed/aspeed-lpc-snoop.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/soc/aspeed/aspeed-lpc-snoop.c b/drivers/soc/aspeed/aspeed-lpc-snoop.c
> index 210455efb321..eceeaf8dfbeb 100644
> --- a/drivers/soc/aspeed/aspeed-lpc-snoop.c
> +++ b/drivers/soc/aspeed/aspeed-lpc-snoop.c
> @@ -94,8 +94,10 @@ static ssize_t snoop_file_read(struct file *file, char __user *buffer,
> return -EINTR;
> }
> ret = kfifo_to_user(&chan->fifo, buffer, count, &copied);
> + if (ret)
> + return ret;
>
> - return ret ? ret : copied;
> + return copied;
I wonder if changing it to:
return ret ? ret + 0L : copied;
Might make people think in the future and not convert it back
as an 'optimisation'.
I much prefer adding 0 to a cast to fix integer types.
In can go less wrong!
IMHO there are far too many casts in the kernel sources.
Especially the ones that are only there to appease sparse.
A functional notation for those would remove some of
the potential problems.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Powered by blists - more mailing lists