On Thu, Mar 10, 2016 at 1:23 AM, Felipe Ferreri Tonello <eu@xxxxxxxxxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html