From: David Cohen <david.a.cohen@linux.intel.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: balbi@ti.com, gregkh@linuxfoundation.org,
linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 3/4] usb: ffs: check quirk to pad epout buf size when not aligned to maxpacketsize
Date: Tue, 05 Nov 2013 10:12:46 -0800 [thread overview]
Message-ID: <5279351E.2000300@linux.intel.com> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1311051026390.1360-100000@iolanthe.rowland.org>
Hi Alan,
On 11/05/2013 07:38 AM, Alan Stern wrote:
> On Tue, 5 Nov 2013, David Cohen wrote:
>
>>>> + /*
>>>> + * Controller requires buffer size to be aligned to
>>>> + * maxpacketsize of an out endpoint.
>>>> + */
>>>> + if (gadget->quirk_ep_out_aligned_size && read) {
>>>> + /*
>>>> + * We pass 'orig_len' to usp_ep_align_maxpacketsize()
>>>> + * due to we're in a loop and 'len' may have been
>>>> + * changed.
>>>> + */
>>>> + len = usb_ep_align_maxpacketsize(ep->ep, orig_len);
>>>> + if (data && len > data_len) {
>>>> + kfree(data);
>>>> + data = NULL;
>>>> + data_len = 0;
>>>> + }
>>>> + }
>>>
>>> Since the value of orig_len never changes, there's no point calling
>>> usb_ep_align_maxpacketsize() inside the loop. You should call it only
>>> once, before the loop starts. Once you do that, you won't need
>>> orig_len at all.
>>
>> orig_len doesn't change but ep->ep does. If USB specs say max packet
>> size won't change even if ep does, than we can call it from outside the
>> loop.
>
> I'm not too familiar with this driver. It looks like the only way
> ep->ep can change is if the endpoint gets enabled while you're sitting
> inside the wait_event_interruptible() call.
>
> In fact, the whole structure of that loop looks peculiar. Why not
> acquire the mutex first and then do everything else?
I'm not 100% familiar with this driver too. I'd keep this change to
another patch.
>
> Does it even make sense for ep to change? Would this change be visible
> to the host? What if the host changes the alternate setting while this
> loop is running -- does it make sense for the userspace program to
> start a read or write under one altsetting but then have the read/write
> take place under a different altsetting?
It doesn't make sense to do so, but gadget driver allows it. If we just
ignore, it would be a security or instability issue possible to xploit
(for DWC3 and any other controller which may depend on this quirk).
Br, David Cohen
next prev parent reply other threads:[~2013-11-05 18:14 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-04 22:12 [PATCH v4 0/4] add gadget quirk to adapt f_fs for DWC3 David Cohen
2013-11-04 22:12 ` [PATCH v4 1/4] usb: gadget: move bitflags to the end of usb_gadget struct David Cohen
2013-11-04 22:12 ` [PATCH v4 2/4] usb: gadget: add quirk_ep_out_aligned_size field to struct usb_gadget David Cohen
2013-11-05 14:50 ` Alan Stern
2013-11-05 15:08 ` David Cohen
2013-11-05 15:11 ` David Cohen
2013-11-05 15:41 ` Alan Stern
2013-11-05 18:13 ` David Cohen
2013-11-05 21:54 ` David Cohen
2013-11-05 23:45 ` [PATCH v4.1 " David Cohen
2013-11-06 16:06 ` Alan Stern
2013-11-04 22:12 ` [PATCH v4 3/4] usb: ffs: check quirk to pad epout buf size when not aligned to maxpacketsize David Cohen
2013-11-05 14:52 ` Alan Stern
2013-11-05 15:05 ` David Cohen
2013-11-05 15:38 ` Alan Stern
2013-11-05 18:12 ` David Cohen [this message]
2013-11-05 18:24 ` Alan Stern
2013-11-06 18:43 ` Michal Nazarewicz
2013-11-07 16:05 ` Alan Stern
2013-11-08 12:23 ` Michal Nazarewicz
2013-11-08 18:04 ` David Cohen
2013-11-05 15:15 ` Cohen, David A
2013-11-10 16:50 ` [PATCH 1/2] usb: gadget: f_fs: remove loop from I/O function Michal Nazarewicz
2013-11-10 16:50 ` [PATCH 2/2] check quirk to pad epout buf size when not aligned to maxpacketsize Michal Nazarewicz
2013-11-11 4:01 ` David Cohen
2013-11-11 11:21 ` [PATCHv2 " Michal Nazarewicz
2013-11-11 19:12 ` David Cohen
2013-11-11 21:12 ` Michal Nazarewicz
2013-11-11 20:20 ` Alan Stern
2013-11-11 21:09 ` Michal Nazarewicz
2013-11-11 22:25 ` David Cohen
2013-11-12 15:50 ` Alan Stern
2013-11-12 18:24 ` David Cohen
2013-11-12 23:09 ` Paul Zimmerman
2013-11-12 23:43 ` David Cohen
2013-11-13 0:24 ` Paul Zimmerman
2013-11-13 15:52 ` Alan Stern
2013-11-13 21:51 ` David Cohen
2013-11-21 18:29 ` David Cohen
2013-11-11 23:15 ` David Cohen
2013-11-11 20:07 ` [PATCH 1/2] usb: gadget: f_fs: remove loop from I/O function David Cohen
2013-11-11 21:13 ` Michal Nazarewicz
2013-11-11 23:11 ` David Cohen
2013-11-04 22:12 ` [PATCH v4 4/4] usb: dwc3: add quirk USB_GADGET_QUIRK_EP_OUT_ALIGNED_SIZE to gadget driver David Cohen
2013-11-04 22:17 ` [PATCH v4.1 4/4] usb: dwc3: set gadget's quirk ep_out_align_size David Cohen
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=5279351E.2000300@linux.intel.com \
--to=david.a.cohen@linux.intel.com \
--cc=balbi@ti.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=stern@rowland.harvard.edu \
/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.