Re: [PATCH net 1/4] pegasus: Use heap buffers for all register access

On 17-02-07 11:45:06, Greg KH wrote:

On Tue, Feb 07, 2017 at 12:24:12PM +0200, Petko Manolov wrote:

quoted

On 17-02-06 14:46:21, Johan Hovold wrote:

quoted

On Mon, Feb 06, 2017 at 02:32:23PM +0100, Johan Hovold wrote:

quoted

On Mon, Feb 06, 2017 at 02:21:24PM +0100, Johan Hovold wrote:

quoted

On Mon, Feb 06, 2017 at 02:51:09PM +0200, Petko Manolov wrote:

quoted

On 17-02-06 09:28:22, Greg KH wrote:

quoted

On Mon, Feb 06, 2017 at 10:14:44AM +0200, Petko Manolov wrote:

quoted

quoted

quoted

Random thought: isn't it better to add the alloc/free code in 
usb_control_msg() and avoid code duplication all over the driver space?

A very long time ago we considered it, but realized that the majority of 
drivers already had the memory dynamically allocated, so we just went with 
this.  Perhaps we could revisit that if it turns out we were wrong, and would 
simplify things.

A quick glance at usb_control_msg() users (looked only at .../net/usb and 
.../usb/serial) shows that most of them have the buffer allocated in stack.  

That's simply not true at all for usb-serial. If you find an instance
were a stack allocated buffer is used for DMA that hasn't yet been
fixed in USB serial, then please point it out so we can fix it up (I
doubt you'll find one, though).

Heh, I just found one myself (in ark3116) that I'll fix up. Please let
me know if you find any more.

False alarm, the ark3116 driver is fine too.

You may want to check pl2303_vendor_read() in drivers/usb/serial/pl2303.c
It seems to me that 'buf' is allocated in the stack. ;)

Really?  Doesn't look like it to me, it's passed in from the caller and it's 
allocated in that caller.  What am I missing here?

Sorry, got confused by the weird pointer definition of the last argument:

static int pl2303_vendor_read(struct usb_serial *serial, u16 value, unsigned char buf[1])


cheers,
Petko
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html