On Tue, Sep 28, 2010 at 10:11:06PM +0100, Al Viro wrote: > IOW, it _must_ use the last one in such cases. > > As for the driver, I smell an interface change (in eth_mac_addr() arguments) > that has been missed... FWIW, grep through the tree shows one more instance > of eth_mac_addr() called with such argument and it's also in net_kern.c; there > we simply want memcpy() instead, since device is definitely not running at > that point and we'd done the validity checks earlier. > > Not sure if we need lp->lock around that eth_mac_addr() call - not familiar > with the driver in question. If we don't, we should switch to eth_mac_addr > for the method, indeed...
FWIW, after looking at that code... I don't think we need lp->lock there, but I really wonder if we need to update lp->mac as well, or, perhaps simply remove it completely. Who maintains these drivers? It's not just net_kern/net_user; there's a bunch of subdrivers for that sucker... ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
