lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 27 Nov 2017 11:21:15 +0100
From:   Johan Hovold <johan@...nel.org>
To:     Gimcuan Hui <gimcuan@...il.com>
Cc:     Johan Hovold <johan@...nel.org>, gregkh@...uxfoundation.org,
        linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] USB: serial: Correct return value on read

On Sun, Nov 26, 2017 at 04:18:51PM +0000, Gimcuan Hui wrote:
> It's meaningless to return buf[0] on read. Because the caller of this
> interface checks the return value negative or not. Instead, we should
> return the result variable.

It's not really meaningless, it's just that the return value is no
longer being used the way it was originally intended. I think
"redundant" and/or "confusing" would be a more appropriate description.

> Signed-off-by: Gimcuan Hui <gimcuan@...il.com>
> ---
>  drivers/usb/serial/ark3116.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/drivers/usb/serial/ark3116.c b/drivers/usb/serial/ark3116.c
> index 3c544782f60b..bfdbc7164e7b 100644
> --- a/drivers/usb/serial/ark3116.c
> +++ b/drivers/usb/serial/ark3116.c
> @@ -101,11 +101,9 @@ static int ark3116_read_reg(struct usb_serial *serial,
>  				reg, result);
>  		if (result >= 0)
>  			result = -EIO;
> -
> -		return result;
>  	}
>  
> -	return buf[0];
> +	return result;

Also we do not want to return the value of result on success as that
would always be 1 (i.e. the buffer size).

You could change this function, and also the write_reg one, to return 0
on success since this is a more common pattern.

Please also rephrase your commit summary (Subject) since you're not
really "correcting" (as in fixing) anything here. This is more a of nice
clean up, even if it could potentially also prevent future bugs.

Thanks,
Johan

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ