On Wed, 2007-10-24 at 16:52 -0700, Greg KH wrote:
> On Wed, Oct 24, 2007 at 04:43:48PM -0700, Greg KH wrote:
> > On Wed, Oct 17, 2007 at 12:16:54PM +0200, Kay Sievers wrote:
> > > On Tue, 2007-10-16 at 16:23 -0700, Greg KH wrote:
> > > > On Tue, Oct 16, 2007 at 03:32:48PM -0700, David Miller wrote:
> > > > > From: Greg KH <[email protected]>
> > > > > Date: Tue, 16 Oct 2007 14:37:30 -0700
> > > > >
> > > > > > Kay, are we doing something wrong in userspace when renaming wireless
> > > > > > devices such that we can overlap names?
> > >
> > > Not udev, but SUSE 10.2's network renaming. It uses udev and calls
> > > ifrename in the same code path. 10.3 uses the unified version from the
> > > udev tree.
> > >
> > > > > It does it for all network devices, I see this ugly message on every
> > > > > single system I have from Fedora foo to RHEL foo to ubuntu foo to
> > > > > debian foo.
> > > > >
> > > > > udev simply applies the MAC address to device name rules blindly, it
> > > > > doesn't check if the device already has the desired name already
> > >
> > > There is a check for the same name in udev for long.
> > >
> > > > Ugh :(
> > > >
> > > > > It's been like this forever, and since userland has been doing it for
> > > > > so long, you can't warn on this there is too much established
> > > > > practice. Expecting people to install "fixed" udev is not an
> > > > > acceptable answer, the warning is a regression and therefore you'll
> > > > > have to remove the kernel warning for this case and live with this
> > > > > issue essentially forever.
> > >
> > > We should probably just add the check to kobject_rename() and print a
> > > simple warning and then do nothing. Or just do the check in the network
> > > ioctl, if we really don't want to see this.
> >
> > I agree that perhaps kobject_rename() should check for this. Let me go
> > see if I can get that to work...
>
> Can someone try this patch, and see what happens when they try to rename
> an object to something that is already existing?
That may still fail if a netif creation, and a rename compete about the
same name, right?
The driver core name of the netdev is part of the netdev, so the net
core might need to rename the driver core part while holding its usual
lock, just like it does when it changes the net internal name?
The netdev rename should also fail, if the core rename fails, right?
Thanks,
Kay
diff --git a/net/core/dev.c b/net/core/dev.c
index 8726589..ed3db06 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -899,9 +899,12 @@ int dev_change_name(struct net_device *dev, char *newname)
strlcpy(dev->name, newname, IFNAMSIZ);
rollback:
- device_rename(&dev->dev, dev->name);
-
write_lock_bh(&dev_base_lock);
+ err = device_rename(&dev->dev, dev->name);
+ if (err) {
+ write_unlock_bh(&dev_base_lock);
+ return err;
+ }
hlist_del(&dev->name_hlist);
hlist_add_head(&dev->name_hlist, dev_name_hash(net, dev->name));
write_unlock_bh(&dev_base_lock);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
