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

[Petko Manolov <petkan-nPnTwAqkgEqakBO8gow8eQ@public.gmane.org>]

On 17-02-07 11:45:06, Greg KH wrote:
> On Tue, Feb 07, 2017 at 12:24:12PM +0200, Petko Manolov wrote:
> > On 17-02-06 14:46:21, Johan Hovold wrote:
> > > On Mon, Feb 06, 2017 at 02:32:23PM +0100, Johan Hovold wrote:
> > > > On Mon, Feb 06, 2017 at 02:21:24PM +0100, Johan Hovold wrote:
> > > > > On Mon, Feb 06, 2017 at 02:51:09PM +0200, Petko Manolov wrote:
> > > > > > On 17-02-06 09:28:22, Greg KH wrote:
> > > > > > > On Mon, Feb 06, 2017 at 10:14:44AM +0200, Petko Manolov wrote:
> > > > > 
> > > > > > > > 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