public inbox for linux-usb@vger.kernel.org
 help / color / mirror / Atom feed
From: Hongren Zheng <i@zenithal.me>
To: Simon Holesch <simon@holesch.de>
Cc: Valentina Manea <valentina.manea.m@gmail.com>,
	Shuah Khan <shuah@kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Shuah Khan <skhan@linuxfoundation.org>,
	linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4] usbip: Don't submit special requests twice
Date: Sun, 5 May 2024 23:31:44 +0800	[thread overview]
Message-ID: <ZjemYB6CpAx4Kx5f@Sun> (raw)
In-Reply-To: <20231217194624.102385-1-simon@holesch.de>

On Sun, Dec 17, 2023 at 08:30:40PM +0100, Simon Holesch wrote:
> Skip submitting URBs, when identical requests were already sent in
> tweak_special_requests(). Instead call the completion handler directly
> to return the result of the URB.

Reproduced the behavior and this patch fixed the bahavior

> 
> Even though submitting those requests twice should be harmless, there
> are USB devices that react poorly to some duplicated requests.
> 
> One example is the ChipIdea controller implementation in U-Boot: The
> second SET_CONFIURATION request makes U-Boot disable and re-enable all
> endpoints. Re-enabling an endpoint in the ChipIdea controller, however,
> was broken until U-Boot commit b272c8792502 ("usb: ci: Fix gadget
> reinit").
> 
> Signed-off-by: Simon Holesch <simon@holesch.de>
> Acked-by: Shuah Khan <skhan@linuxfoundation.org>
> ---

>  /*
> @@ -468,6 +477,7 @@ static void stub_recv_cmd_submit(struct stub_device *sdev,
>  	int support_sg = 1;
>  	int np = 0;
>  	int ret, i;
> +	int is_tweaked;
>  
>  	if (pipe == -1)
>  		return;
> @@ -580,8 +590,7 @@ static void stub_recv_cmd_submit(struct stub_device *sdev,
>  		priv->urbs[i]->pipe = pipe;
>  		priv->urbs[i]->complete = stub_complete;
>  
> -		/* no need to submit an intercepted request, but harmless? */
> -		tweak_special_requests(priv->urbs[i]);
> +		is_tweaked = tweak_special_requests(priv->urbs[i]);

One question though, if there are mutiple urbs and one of them is
SET CONFIGURATION, then all of them would not be submitted,
as is_tweaked is a *global* flag instead of a per-urb flag.

Now it is assumed that when the urb is SET CONFIGURATION then
num_urbs is 1. I assume it just happens to be the case and I do
not know if it holds for all scenario.

>  
>  		masking_bogus_flags(priv->urbs[i]);
>  	}
> @@ -594,22 +603,32 @@ static void stub_recv_cmd_submit(struct stub_device *sdev,
>  
>  	/* urb is now ready to submit */
>  	for (i = 0; i < priv->num_urbs; i++) {
> -		ret = usb_submit_urb(priv->urbs[i], GFP_KERNEL);
> +		if (!is_tweaked) {
> +			ret = usb_submit_urb(priv->urbs[i], GFP_KERNEL);
>  
> -		if (ret == 0)
> -			usbip_dbg_stub_rx("submit urb ok, seqnum %u\n",
> -					pdu->base.seqnum);
> -		else {
> -			dev_err(&udev->dev, "submit_urb error, %d\n", ret);
> -			usbip_dump_header(pdu);
> -			usbip_dump_urb(priv->urbs[i]);
> +			if (ret == 0)
> +				usbip_dbg_stub_rx("submit urb ok, seqnum %u\n",
> +						pdu->base.seqnum);
> +			else {
> +				dev_err(&udev->dev, "submit_urb error, %d\n", ret);
> +				usbip_dump_header(pdu);
> +				usbip_dump_urb(priv->urbs[i]);
>  
> +				/*
> +				 * Pessimistic.
> +				 * This connection will be discarded.
> +				 */
> +				usbip_event_add(ud, SDEV_EVENT_ERROR_SUBMIT);
> +				break;
> +			}
> +		} else {
>  			/*
> -			 * Pessimistic.
> -			 * This connection will be discarded.
> +			 * An identical URB was already submitted in
> +			 * tweak_special_requests(). Skip submitting this URB to not
> +			 * duplicate the request.
>  			 */
> -			usbip_event_add(ud, SDEV_EVENT_ERROR_SUBMIT);
> -			break;
> +			priv->urbs[i]->status = 0;
> +			stub_complete(priv->urbs[i]);
>  		}
>  	}
>  
> -- 
> 2.43.0
> 

  reply	other threads:[~2024-05-05 15:31 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-17 19:30 [PATCH v4] usbip: Don't submit special requests twice Simon Holesch
2024-05-05 15:31 ` Hongren Zheng [this message]
2024-05-05 17:54   ` Simon Holesch
2024-05-06  7:04     ` Hongren Zheng

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=ZjemYB6CpAx4Kx5f@Sun \
    --to=i@zenithal.me \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=shuah@kernel.org \
    --cc=simon@holesch.de \
    --cc=skhan@linuxfoundation.org \
    --cc=valentina.manea.m@gmail.com \
    /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