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 19:00:14 +0200
From:	Ingo Oeser <netdev@...eo.de>
To:	Valentine Barshak <vbarshak@...mvista.com>
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.

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

Powered by blists - more mailing lists