[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <413f4e50-b722-427f-ab30-d320efe71cc0@kili.mountain>
Date: Tue, 23 May 2023 10:05:45 +0300
From: Dan Carpenter <dan.carpenter@...aro.org>
To: Guenter Roeck <linux@...ck-us.net>
Cc: Su Hui <suhui@...china.com>, Jeremy Kerr <jk@...abs.org>,
Joel Stanley <joel@....id.au>,
Alistar Popple <alistair@...ple.id.au>,
Eddie James <eajames@...ux.ibm.com>, eajames@...ibm.com,
kernel-janitors@...r.kernel.org, linux-kernel@...r.kernel.org,
cbostic@...ux.vnet.ibm.com, linux-fsi@...ts.ozlabs.org
Subject: Re: [PATCH] drivers/fsi/scom: Return -EFAULT if copy fails
On Mon, May 22, 2023 at 03:30:06PM -0700, Guenter Roeck wrote:
> On Fri, May 19, 2023 at 09:37:10AM +0800, Su Hui wrote:
> > The copy_to/from_user() functions return the number of bytes remaining
> > to be copied, but we want to return -EFAULT to the user.
> >
> Why ? EFAULT means that a bad address was provided, and it is not
> immediately obvious why that would be the case.
>
Right now the function is returning success so that's definitely wrong.
The copy_to/from_user() function will only fail if a bad address is
provided so -EFAULT is correct.
There is a different Smatch warning for when people return a different
error code such as -EINVAL.
drivers/fsi/fsi-scom.c:337 scom_read() warn: return -EFAULT instead of '-EINVAL'
The return affects the user and -EFAULT but that level of pendantry feel
like possibly too much? There aren't many instances of this warning.
regards,
dan carpenter
Powered by blists - more mailing lists