netdev - Re: [linux-usb-devel] [PATCH] USB: net: Fix asix read transfer buffer allocations.

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 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]

Date:	Tue, 23 Oct 2007 21:20:18 +0400
From:	Valentine Barshak <vbarshak@...mvista.com>
To:	Ingo Oeser <netdev@...eo.de>
Cc:	Oliver Neukum <oliver@...kum.org>,
	linux-usb-devel@...ts.sourceforge.net, netdev@...r.kernel.org
Subject: Re: [linux-usb-devel] [PATCH] USB: net: Fix asix read transfer buffer
 allocations.

Ingo Oeser wrote:
> Valentine Barshak schrieb:
>> Oliver Neukum wrote:
>>> Am Montag 22 Oktober 2007 schrieb Valentine Barshak:
>>>>  static int asix_mdio_read(struct net_device *netdev, int phy_id, int loc)
>>>>  {
>>>>         struct usbnet *dev = netdev_priv(netdev);
>>>> +       void *buf;
>>>>         u16 res;
>>>>  
>>>>         mutex_lock(&dev->phy_mutex);
>>>>         asix_set_sw_mii(dev);
>>>> +
>>>> +       buf = kmalloc(2, GFP_KERNEL);
>>> This is done under lock. Can you allocate the buffer once and reuse it?
>> I think we can use 2 bytes of the usbnet data buffer for this.
>> I'll submit a new patch soon.
> 
> If this cannot be done for some reason, then you can at least kmalloc() before
> you do "mutex_lock(&dev->phy_mutex);" and kfree() after you did 
> "mutex_unlock(&dev->phy_mutex);"
> 
> The reason to can do this, is that "buf" has a life time limited to this function.
> 
> The reason you should do this, is that kmalloc(, GFP_KERNEL) is allowed to sleep,
> which will block the mutex for that time. While this is technically ok, 
> since mutexes can sleep, it is not desireable, since other users of that mutex
> are blocked until the allocation is done.
> 
> If you are able to implement the "2 bytes of  usbnet data buffer" version,
> please ignore that mail :-)
> 
> 
> Best Regards
> 
> Ingo Oeser

Looks like we cannot use usbnet data buffer for read transfers either, 
because it's just a part of the usbnet structure and we may still lose 
data while invalidating cache the same way we do using buffers on stack. 
Allocating a permanent buffer for phy transfer needs more driver 
changes: we should add unbind finction to the device_info for all asix 
devices to deallocate the buffer at exit.
And we still need to allocate buffers for other transfers dynamically, 
so having just one permanent buffer for phy doesn't help much.
I've reworked the original patch a bit: moved kmalloc out of the 
phy_mutex and added more clean-ups.
Will submit shortly.
Thanks,
Valentine.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html