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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20170206132124.GA3038@localhost>
Date:   Mon, 6 Feb 2017 14:21:24 +0100
From:   Johan Hovold <johan@...nel.org>
To:     Petko Manolov <petkan@...leusys.com>
Cc:     Greg KH <greg@...ah.com>, Ben Hutchings <ben@...adent.org.uk>,
        netdev@...r.kernel.org, linux-usb@...r.kernel.org,
        Lisandro Damián Nicanor Pérez Meyer 
        <lisandro@...ian.org>
Subject: Re: [PATCH net 1/4] pegasus: Use heap buffers for all register access

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).

> These transfers are relatively infrequent and quite small the performance hit 
> caused by memcpy() should also be negligible.

Note that some drivers allocate a single buffer which is reused for
several (or all) control transfers.

Johan