On Mon, Jun 24, 2013 at 6:10 PM, Konstantin Filatov <kfilatov@xxxxxxxxxxxxx> wrote: > On 06/23/2013 07:05 PM, Alan Stern wrote: >>>> >>>> That's why, if the check is checked, I feel it should be added to each >>>> HCD driver separately. Maybe I'm wrong. But before doing anything, >>>> you should check with Thomas Pugliese. He recently added SG support to >>>> the wireless USB driver. >>> >>> Suppose wireless USB is one exception, it should the only one, so we can >>> rule it out easily by using hcd->wireless, right? >> >> Yes, that's true. >> >> Alan Stern >> > This test passed for many years. It became to fail only for the recent > kernels. So this event looks like a broken thing. > > It's not a good idea to force a higher driver to care about the max pkt size > in a dynamically selected usb configuration. Note that a sg-list could be The constraint is from USB spec(1.1/2.0/3.0), and a short packet simply means the end of one transfer, I think we can see it as a API about sg list passed to usb_submit_urb(). > created even in another subsystem. Considered that there isn't much such kind of usages now, we need to consider the problem, and introducing check in usb_submit_urb() is necessary, so we can avoid and kill such mistaken usages at early stage. Otherwise, we have to introduce buffer debounce in usbcore or hcd to work around the problem when many users start to do that. > > If we decided to treat such sg-lists as acceptable, then we have only two > options: > 1. Send a shorter packet between two full packets of a TD list. > 2. Introduce a bounce buffer similarly in lib/swiotlb.c > Option 2 is very costed. If the option 1 is acceptable, then we should > choose it. No, option 1 isn't accepted, and option 2 isn't necessary since there aren't much such usage. In fact, except for usbtest, I don't know there are other drivers which may pass such kind of sg list. If anyone knows, please share it. > > But ehci does resolve this issue in such way already, so the option 1 is > acceptable. No, ehci only doesn't cause memory access error but the way is wrong, and it does violate USB spec. > > From my point of view this choice is unrelated to the wireless USB > requirements. We just want to confirm if wireless USB need the same check. Thanks, -- Ming Lei -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
