Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   Felipe Balbi <balbi@kernel.org>
To:     Alexandru Ardelean <alexandru.ardelean@analog.com>,
        linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org
Cc:     gregkh@linuxfoundation.org, bigeasy@linutronix.de,
        Lars-Peter Clausen <lars@metafoo.de>,
        Michael Olbrich <m.olbrich@pengutronix.de>,
        Alexandru Ardelean <alexandru.ardelean@analog.com>
Subject: Re: [PATCH][RESEND] usb: dwc3: gadget: Handle dequeuing of non queued URB gracefully
In-Reply-To: <20200116132459.22383-1-alexandru.ardelean@analog.com>
References: <20191106144553.16956-1-alexandru.ardelean@analog.com> <20200116132459.22383-1-alexandru.ardelean@analog.com>
Date:   Thu, 30 Jan 2020 14:02:05 +0200
Message-ID: <87d0b1885e.fsf@kernel.org>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
        micalg=pgp-sha256; protocol="application/pgp-signature"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

--=-=-=
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable


Hi,

Alexandru Ardelean <alexandru.ardelean@analog.com> writes:

> From: Lars-Peter Clausen <lars@metafoo.de>
>
> Trying to dequeue and URB that is currently not queued should be a no-op
> and be handled gracefully.
>
> Use the list field of the URB to indicate whether it is queued or not by
> setting it to the empty list when it is not queued.
>
> Handling this gracefully allows for race condition free synchronization
> between the complete callback being called to to a completed transfer and
> trying to call usb_ep_dequeue() at the same time.

We need a little more information here. Can you further explain what
happens and how you caught this?

> Tested-by: Michael Olbrich <m.olbrich@pengutronix.de>
> Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
> Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
> ---
>
> * Added Michael Olbrich's Tested-by tag
>   https://lore.kernel.org/linux-usb/20191112144108.GA1859@pengutronix.de/
>
>  drivers/usb/dwc3/gadget.c | 7 ++++++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
> index 1b8014ab0b25..22a78eb41a5b 100644
> --- a/drivers/usb/dwc3/gadget.c
> +++ b/drivers/usb/dwc3/gadget.c
> @@ -177,7 +177,7 @@ static void dwc3_gadget_del_and_unmap_request(struct =
dwc3_ep *dep,
>  {
>  	struct dwc3			*dwc =3D dep->dwc;
>=20=20
> -	list_del(&req->list);
> +	list_del_init(&req->list);

this should *not* be necessary. Neither the INIT_LIST_HEAD() below.

>  	req->remaining =3D 0;
>  	req->needs_extra_trb =3D false;
>=20=20
> @@ -847,6 +847,7 @@ static struct usb_request *dwc3_gadget_ep_alloc_reque=
st(struct usb_ep *ep,
>  	req->epnum	=3D dep->number;
>  	req->dep	=3D dep;
>  	req->status	=3D DWC3_REQUEST_STATUS_UNKNOWN;
> +	INIT_LIST_HEAD(&req->list);
>=20=20
>  	trace_dwc3_alloc_request(req);
>=20=20
> @@ -1549,6 +1550,10 @@ static int dwc3_gadget_ep_dequeue(struct usb_ep *e=
p,
>=20=20
>  	spin_lock_irqsave(&dwc->lock, flags);
>=20=20
> +	/* Not queued, nothing to do */
> +	if (list_empty(&req->list))
> +		goto out0;

The loop below is actually looking for the request in our lists. You
just made the entire loop below unnecessary, but you didn't change it
accordingly. Moreover, I think that a user dequeueing a request that
wasn't queued for the current endpoint indicates a possible bug in the
gadget driver which needs to be fixed.

If you really disagree, suffice to change "ret =3D -EINVAL;" to "ret =3D
0;" and you would get what you want, without any of the extra cruft.

cheers

=2D-=20
balbi

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEElLzh7wn96CXwjh2IzL64meEamQYFAl4yxb0ACgkQzL64meEa
mQa6yRAA3qZXokGaKbxI6YrzLjwzLNFTAfuzXmIzXQdyzTU5RKaFW/QMno+DKv/B
vBdYcrsuBInSw74GU4IRTwDTsy9q2Xpyn2lsRqQqjfGys0XzCX/b47HxdiPDlClT
rGwBXjp96qxcr/eeOLELxrH6EjhRBptD85/tK91Vqi0PmaAt1mt/7kPk80df92PH
h7kcxC0ZgsERFU3O5maWlNo5oHzWqr0aiRWOV8wsbWpecCk3UJhS00cQb0y+BHQ3
ByiQjIBCNpOxXvA7cerSeMTuJd2IaQ1GOzAwynGE+2VCzNR91/xJ24GMysD25KD2
XoiKOqgG1fm38UjI0WYdYRzTyuQwhvch+8FuBVO1grH55bJ1y16m4g9ZrMkv9LJP
ciob6UlmsuuYBBHBD/puZmeAPW4DPmhS7ZYaa1OdYwjIMf1EOO/iEiyENyysDHE+
ZnmOj4lO8Loip1HeFOE+HmmPi3Gg4zPlzdrtHSGGJFhVgciQ46SAHfRGf7+6TGR2
4U3pAZGsR69tuirwCbVWKRVmrH1ybxnuOOzM//rUhrK/IMRrFWnROCU57WXnDAh5
v8c8mxKiHTQ3aN4tD5P6w7DDC528gT555g6J3iyc1/85vrkdkFu3JEO+gMRNSuea
ubV8SgriXmYHAd4+ggcRed6AYUtpYAAIrt+8f9yV57PpH3gP0OE=
=BG5P
-----END PGP SIGNATURE-----
--=-=-=--