From: Felipe Balbi <balbi@kernel.org>
Cc: linux-arm-msm@vger.kernel.org,
Manu Gautam <mgautam@codeaurora.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"open list:DESIGNWARE USB3 DRD IP DRIVER"
<linux-usb@vger.kernel.org>,
open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] usb: dwc3: gadget: Fail request submission if it was already queued
Date: Fri, 11 Jan 2019 09:43:41 +0200 [thread overview]
Message-ID: <87pnt3od02.fsf@linux.intel.com> (raw)
In-Reply-To: <20190111060212.7390-1-mgautam@codeaurora.org>
[-- Attachment #1: Type: text/plain, Size: 1194 bytes --]
Hi,
Manu Gautam <mgautam@codeaurora.org> writes:
> If a function driver tries to re-submit an already queued request,
> it can results in corruption of pending/started request lists.
> Catch such conditions and fail the request submission to DCD.
>
> Signed-off-by: Manu Gautam <mgautam@codeaurora.org>
> ---
> drivers/usb/dwc3/gadget.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
> index 679c12e14522..51716c6b286a 100644
> --- a/drivers/usb/dwc3/gadget.c
> +++ b/drivers/usb/dwc3/gadget.c
> @@ -1290,6 +1290,12 @@ static int __dwc3_gadget_ep_queue(struct dwc3_ep *dep, struct dwc3_request *req)
> &req->request, req->dep->name))
> return -EINVAL;
>
> + if (req->request.status == -EINPROGRESS) {
this test is really not enough. What if gadget driver set status to
EINPROGRESS before submission? A better check would involve making sure
req isn't part of dep->pending_list or dep->started_list or
dep->cancelled_list. It's clear that this won't work very well as the
amount of requests grow.
Anyway, which gadget driver did this? Why is it only affecting dwc3?
--
balbi
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Felipe Balbi <balbi@kernel.org>
To: Manu Gautam <mgautam@codeaurora.org>
Cc: linux-arm-msm@vger.kernel.org,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"open list:DESIGNWARE USB3 DRD IP DRIVER"
<linux-usb@vger.kernel.org>,
open list <linux-kernel@vger.kernel.org>
Subject: usb: dwc3: gadget: Fail request submission if it was already queued
Date: Fri, 11 Jan 2019 09:43:41 +0200 [thread overview]
Message-ID: <87pnt3od02.fsf@linux.intel.com> (raw)
Hi,
Manu Gautam <mgautam@codeaurora.org> writes:
> If a function driver tries to re-submit an already queued request,
> it can results in corruption of pending/started request lists.
> Catch such conditions and fail the request submission to DCD.
>
> Signed-off-by: Manu Gautam <mgautam@codeaurora.org>
> ---
> drivers/usb/dwc3/gadget.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
> index 679c12e14522..51716c6b286a 100644
> --- a/drivers/usb/dwc3/gadget.c
> +++ b/drivers/usb/dwc3/gadget.c
> @@ -1290,6 +1290,12 @@ static int __dwc3_gadget_ep_queue(struct dwc3_ep *dep, struct dwc3_request *req)
> &req->request, req->dep->name))
> return -EINVAL;
>
> + if (req->request.status == -EINPROGRESS) {
this test is really not enough. What if gadget driver set status to
EINPROGRESS before submission? A better check would involve making sure
req isn't part of dep->pending_list or dep->started_list or
dep->cancelled_list. It's clear that this won't work very well as the
amount of requests grow.
Anyway, which gadget driver did this? Why is it only affecting dwc3?
WARNING: multiple messages have this Message-ID (diff)
From: Felipe Balbi <balbi@kernel.org>
To: Manu Gautam <mgautam@codeaurora.org>
Cc: linux-arm-msm@vger.kernel.org,
Manu Gautam <mgautam@codeaurora.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"open list\:DESIGNWARE USB3 DRD IP DRIVER"
<linux-usb@vger.kernel.org>,
open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] usb: dwc3: gadget: Fail request submission if it was already queued
Date: Fri, 11 Jan 2019 09:43:41 +0200 [thread overview]
Message-ID: <87pnt3od02.fsf@linux.intel.com> (raw)
In-Reply-To: <20190111060212.7390-1-mgautam@codeaurora.org>
[-- Attachment #1: Type: text/plain, Size: 1194 bytes --]
Hi,
Manu Gautam <mgautam@codeaurora.org> writes:
> If a function driver tries to re-submit an already queued request,
> it can results in corruption of pending/started request lists.
> Catch such conditions and fail the request submission to DCD.
>
> Signed-off-by: Manu Gautam <mgautam@codeaurora.org>
> ---
> drivers/usb/dwc3/gadget.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
> index 679c12e14522..51716c6b286a 100644
> --- a/drivers/usb/dwc3/gadget.c
> +++ b/drivers/usb/dwc3/gadget.c
> @@ -1290,6 +1290,12 @@ static int __dwc3_gadget_ep_queue(struct dwc3_ep *dep, struct dwc3_request *req)
> &req->request, req->dep->name))
> return -EINVAL;
>
> + if (req->request.status == -EINPROGRESS) {
this test is really not enough. What if gadget driver set status to
EINPROGRESS before submission? A better check would involve making sure
req isn't part of dep->pending_list or dep->started_list or
dep->cancelled_list. It's clear that this won't work very well as the
amount of requests grow.
Anyway, which gadget driver did this? Why is it only affecting dwc3?
--
balbi
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
next prev parent reply other threads:[~2019-01-11 7:43 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-11 6:02 [PATCH] usb: dwc3: gadget: Fail request submission if it was already queued Manu Gautam
2019-01-11 6:02 ` Manu Gautam
2019-01-11 6:02 ` Manu Gautam
2019-01-11 7:43 ` Felipe Balbi [this message]
2019-01-11 7:43 ` [PATCH] " Felipe Balbi
2019-01-11 7:43 ` Felipe Balbi
2019-01-11 8:24 ` [PATCH] " Manu Gautam
2019-01-11 8:24 ` Manu Gautam
2019-01-11 9:21 ` [PATCH] " Felipe Balbi
2019-01-11 9:21 ` Felipe Balbi
2019-01-11 9:21 ` Felipe Balbi
2019-01-16 4:34 ` [PATCH] " Manu Gautam
2019-01-16 4:34 ` Manu Gautam
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=87pnt3od02.fsf@linux.intel.com \
--to=balbi@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=mgautam@codeaurora.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.