On Thu, Mar 10, 2016 at 1:23 AM, Felipe Ferreri Tonello
<e...@felipetonello.com> wrote:
>>> --- a/drivers/usb/gadget/function/f_midi.c
>>> +++ b/drivers/usb/gadget/function/f_midi.c
>>> @@ -366,7 +366,9 @@ static int f_midi_set_alt(struct usb_function *f,
>>> unsigned intf, unsigned alt)
>>> /* allocate a bunch of read buffers and queue them all at once. */
>>> for (i = 0; i < midi->qlen && err == 0; i++) {
>>> struct usb_request *req =
>>> - midi_alloc_ep_req(midi->out_ep, midi->buflen);
>>> + midi_alloc_ep_req(midi->out_ep,
>>> + max_t(unsigned, midi->buflen,
>>> + bulk_out_desc.wMaxPacketSize));
>>> if (req == NULL)
>>> return -ENOMEM;
>>>
>> Won't you get a buffer overrun if midi->buflen is less than wMaxPacketSize?
>>
>
> No, because of the *max_t(unsigned, midi->buflen,
> bulk_out_desc.wMaxPacketSize)*.
>
> Maybe that's not the most clear indentation but I had to break it in
> order to avoid passing 80 columns.
>
Yes, I understood that code. It is a little confusing that gadgets use
OUT endpoints to receive data.
I think we are talking about different buffers. I meant that if you
ever received data into your enlarged ep buffer, will you not copy it
into your midi buffer? If the code checks, I guess you will truncate
the received data? If not, it could be a midi buffer overrun.
Regards, Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
