linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: "Fabio M. De Francesco" <fmdefrancesco@gmail.com>
Cc: Larry Finger <Larry.Finger@lwfinger.net>,
	Phillip Potter <phil@philpotter.co.uk>,
	Pavel Skripkin <paskripkin@gmail.com>,
	linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org,
	David Laight <david.Laight@aculab.com>,
	Dan Carpenter <dan.carpenter@oracle.com>
Subject: Re: [PATCH v7 19/19] staging: r8188eu: remove shared buffer for usb requests
Date: Fri, 17 Sep 2021 16:55:39 +0200	[thread overview]
Message-ID: <YUSsa+3NjQVGD9gb@kroah.com> (raw)
In-Reply-To: <20210917071837.10926-20-fmdefrancesco@gmail.com>

On Fri, Sep 17, 2021 at 09:18:37AM +0200, Fabio M. De Francesco wrote:
> From: Pavel Skripkin <paskripkin@gmail.com>
> 
> This driver used shared buffer for usb requests. It led to using
> mutexes, i.e no usb requests can be done in parallel.
> 
> USB requests can be fired in parallel since USB Core allows it. In
> order to allow them, remove usb_vendor_req_buf from dvobj_priv (since
> USB I/O is the only user of it) and remove also usb_vendor_req_mutex
> (since there is nothing to protect).

Ah, you are removing this buffer, nice!

But, just because the USB core allows multiple messages to be sent to a
device at the same time, does NOT mean that the device itself can handle
that sort of a thing.

Keeping that lock might be a good idea, until you can prove otherwise.
You never know, maybe there's never any contention at all for it because
these accesses are all done in a serial fashion and the lock
grab/release is instant.  But if that is not the case, you might really
get a device confused here by throwing multiple control messages at it
in ways that it is not set up to handle at all.

So please do not drop the lock.

More comments below.


> 
> Co-developed-by: Fabio M. De Francesco <fmdefrancesco@gmail.com>
> Signed-off-by: Fabio M. De Francesco <fmdefrancesco@gmail.com>
> Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
> ---
>  drivers/staging/r8188eu/hal/usb_ops_linux.c | 29 ++++++++-------
>  drivers/staging/r8188eu/include/drv_types.h |  5 ---
>  drivers/staging/r8188eu/os_dep/usb_intf.c   | 40 ++-------------------
>  3 files changed, 16 insertions(+), 58 deletions(-)
> 
> diff --git a/drivers/staging/r8188eu/hal/usb_ops_linux.c b/drivers/staging/r8188eu/hal/usb_ops_linux.c
> index 656f3a774e48..0ed4e6c8b1f5 100644
> --- a/drivers/staging/r8188eu/hal/usb_ops_linux.c
> +++ b/drivers/staging/r8188eu/hal/usb_ops_linux.c
> @@ -19,9 +19,9 @@ static int usb_read(struct intf_hdl *intfhdl, u16 addr, void *data, u8 size)
>  	if (adapt->bSurpriseRemoved || adapt->pwrctrlpriv.pnp_bstop_trx)
>  		return -EPERM;
>  
> -	mutex_lock(&dvobjpriv->usb_vendor_req_mutex);
> -
> -	io_buf = dvobjpriv->usb_vendor_req_buf;
> +	io_buf = kmalloc(size, GFP_KERNEL);
> +	if (!io_buf)
> +		return -ENOMEM;

Please read the docs for usb_control_msg_recv().  It can allow data off
of the stack, so no need to allocate/free the buffer like this all the
time.

Note, the usb_control_msg() call does require the data to be allocated
dynamically, like the code does today.  Which is why you probably got
confused here.

Same for usb_control_msg_send(), it can take data off of the stack.


>  
>  	status = usb_control_msg_recv(udev, 0, REALTEK_USB_VENQT_CMD_REQ,
>  				      REALTEK_USB_VENQT_READ, addr,
> @@ -39,7 +39,7 @@ static int usb_read(struct intf_hdl *intfhdl, u16 addr, void *data, u8 size)
>  		 * exist or is not enabled.
>  		 */
>  		adapt->bSurpriseRemoved = true;
> -		goto mutex_unlock;
> +		goto end;
>  	}
>  
>  	if (status < 0) {
> @@ -49,15 +49,14 @@ static int usb_read(struct intf_hdl *intfhdl, u16 addr, void *data, u8 size)
>  		if (rtw_inc_and_chk_continual_urb_error(dvobjpriv))
>  			adapt->bSurpriseRemoved = true;
>  
> -		goto mutex_unlock;
> +		goto end;
>  	}
>  
>  	rtw_reset_continual_urb_error(dvobjpriv);
>  	memcpy(data, io_buf, size);
>  
> -mutex_unlock:
> -	mutex_unlock(&dvobjpriv->usb_vendor_req_mutex);
> -
> +end:
> +	kfree(io_buf);
>  	return status;
>  }
>  
> @@ -72,9 +71,10 @@ static int usb_write(struct intf_hdl *intfhdl, u16 addr, void *data, u8 size)
>  	if (adapt->bSurpriseRemoved || adapt->pwrctrlpriv.pnp_bstop_trx)
>  		return -EPERM;
>  
> -	mutex_lock(&dvobjpriv->usb_vendor_req_mutex);
> +	io_buf = kmalloc(size, GFP_KERNEL);
> +	if (!io_buf)
> +		return -ENOMEM;
>  
> -	io_buf = dvobjpriv->usb_vendor_req_buf;
>  	memcpy(io_buf, data, size);
>  
>  	status = usb_control_msg_send(udev, 0, REALTEK_USB_VENQT_CMD_REQ,
> @@ -93,7 +93,7 @@ static int usb_write(struct intf_hdl *intfhdl, u16 addr, void *data, u8 size)
>  		 * exist or is not enabled.
>  		 */
>  		adapt->bSurpriseRemoved = true;
> -		goto mutex_unlock;
> +		goto end;
>  	}
>  
>  	if (status < 0) {
> @@ -103,14 +103,13 @@ static int usb_write(struct intf_hdl *intfhdl, u16 addr, void *data, u8 size)
>  		if (rtw_inc_and_chk_continual_urb_error(dvobjpriv))
>  			adapt->bSurpriseRemoved = true;
>  
> -		goto mutex_unlock;
> +		goto end;
>  	}
>  
>  	rtw_reset_continual_urb_error(dvobjpriv);
>  
> -mutex_unlock:
> -	mutex_unlock(&dvobjpriv->usb_vendor_req_mutex);
> -
> +end:
> +	kfree(io_buf);
>  	return status;
>  }
>  
> diff --git a/drivers/staging/r8188eu/include/drv_types.h b/drivers/staging/r8188eu/include/drv_types.h
> index 626c6273be6f..499b2bce8cbe 100644
> --- a/drivers/staging/r8188eu/include/drv_types.h
> +++ b/drivers/staging/r8188eu/include/drv_types.h
> @@ -168,11 +168,6 @@ struct dvobj_priv {
>  	int	ep_num[5]; /* endpoint number */
>  	int	RegUsbSS;
>  	struct semaphore usb_suspend_sema;
> -	struct mutex  usb_vendor_req_mutex;
> -
> -	u8 *usb_alloc_vendor_req_buf;
> -	u8 *usb_vendor_req_buf;

I do like removing these buffers, and I think that is all that this
change should be doing.

thanks,

greg k-h

  reply	other threads:[~2021-09-17 14:55 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-17  7:18 [PATCH v7 00/19] staging: r8188eu: shorten and simplify calls chains Fabio M. De Francesco
2021-09-17  7:18 ` [PATCH v7 01/19] staging: r8188eu: remove usb_{read,write}_mem() Fabio M. De Francesco
2021-09-17  7:18 ` [PATCH v7 02/19] staging: r8188eu: remove the helpers of rtw_read8() Fabio M. De Francesco
2021-09-17  7:18 ` [PATCH v7 03/19] staging: r8188eu: remove the helpers of rtw_read16() Fabio M. De Francesco
2021-09-17  7:18 ` [PATCH v7 04/19] staging: r8188eu: remove the helpers of rtw_read32() Fabio M. De Francesco
2021-09-17  7:18 ` [PATCH v7 05/19] staging: r8188eu: remove the helpers of usb_write8() Fabio M. De Francesco
2021-09-17  7:18 ` [PATCH v7 06/19] staging: r8188eu: remove the helpers of usb_write16() Fabio M. De Francesco
2021-09-17  7:18 ` [PATCH v7 07/19] staging: r8188eu: remove the helpers of usb_write32() Fabio M. De Francesco
2021-09-17  7:18 ` [PATCH v7 08/19] staging: r8188eu: remove the helpers of usb_writeN() Fabio M. De Francesco
2021-09-17  7:18 ` [PATCH v7 09/19] staging: r8188eu: remove the helpers of usb_read_port() Fabio M. De Francesco
2021-09-17  7:18 ` [PATCH v7 10/19] staging: r8188eu: remove the helpers of usb_write_port() Fabio M. De Francesco
2021-09-17  7:18 ` [PATCH v7 11/19] staging: r8188eu: remove the helpers of usb_read_port_cancel() Fabio M. De Francesco
2021-09-17  7:18 ` [PATCH v7 12/19] staging: r8188eu: remove the helpers of usb_write_port_cancel() Fabio M. De Francesco
2021-09-17  7:18 ` [PATCH v7 13/19] staging: r8188eu: remove core/rtw_io.c Fabio M. De Francesco
2021-09-17  7:18 ` [PATCH v7 14/19] staging: r8188eu: remove struct _io_ops Fabio M. De Francesco
2021-09-17  7:18 ` [PATCH v7 15/19] staging: r8188eu: clean up usbctrl_vendorreq() Fabio M. De Francesco
2021-09-17 14:44   ` Greg Kroah-Hartman
2021-09-18 11:13     ` Fabio M. De Francesco
2021-09-17  7:18 ` [PATCH v7 16/19] staging: r8188eu: clean up rtw_read*() and rtw_write*() Fabio M. De Francesco
2021-09-17 14:44   ` Greg Kroah-Hartman
2021-09-17 14:45   ` Greg Kroah-Hartman
2021-09-18 11:41     ` Fabio M. De Francesco
2021-09-17  7:18 ` [PATCH v7 17/19] staging: r8188eu: shorten calls chain of rtw_read{8,16,32}() Fabio M. De Francesco
2021-09-17 14:50   ` Greg Kroah-Hartman
2021-09-17 15:01     ` David Laight
2021-09-17 15:17       ` 'Greg Kroah-Hartman'
2021-09-18 12:19     ` Fabio M. De Francesco
2021-09-17  7:18 ` [PATCH v7 18/19] staging: r8188eu: shorten calls chain of rtw_write{8,16,32,N}() Fabio M. De Francesco
2021-09-17  7:18 ` [PATCH v7 19/19] staging: r8188eu: remove shared buffer for usb requests Fabio M. De Francesco
2021-09-17 14:55   ` Greg Kroah-Hartman [this message]
2021-09-17 15:03     ` Pavel Skripkin
2021-09-17 15:06       ` Pavel Skripkin
2021-09-17 15:18       ` Greg Kroah-Hartman
2021-09-17 15:23         ` Pavel Skripkin
2021-09-17 11:07 ` [PATCH v7 00/19] staging: r8188eu: shorten and simplify calls chains Dan Carpenter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YUSsa+3NjQVGD9gb@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=Larry.Finger@lwfinger.net \
    --cc=dan.carpenter@oracle.com \
    --cc=david.Laight@aculab.com \
    --cc=fmdefrancesco@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-staging@lists.linux.dev \
    --cc=paskripkin@gmail.com \
    --cc=phil@philpotter.co.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).