From: Jean Tourrilhes <hidden> Date: 2007-02-28 01:44:45
Hi all,
Various hotplug packages have had trouble dealing with network
interface being renamed. I've decided to tackle this issue from two
angles :
o export ifindex to those apps, as ifindex is persistent.
o expose interface renaming as a hotplug event.
Those two changes are complementary, even an application that
would track interface by ifindex would sometime needs to know about
ifname change. My assumption is that most apps would still use ifname
for a long while to be backward compatible with older kernels.
The kobject framework is well designed, so adding these
features is trivial change and won't run the risk of breaking anything
(famous last words). Obviously, hotplug apps are free to ignore those
additional features.
Patch for 2.6.20 is attached. The patch was tested on a system
running the hotplug scripts, and on another system running udev.
Have fun...
Jean
Signed-off-by: Jean Tourrilhes <redacted>
---------------------------------------------------------
diff -u -p linux/include/linux/kobject.j1.h linux/include/linux/kobject.h
@@ -841,6 +841,8 @@ int class_device_rename(struct class_dev{interror=0;char*old_class_name=NULL,*new_class_name=NULL;+char*devname_string=NULL;+char*envp[2];class_dev=class_device_get(class_dev);if(!class_dev)
@@ -849,6 +851,15 @@ int class_device_rename(struct class_devpr_debug("CLASS: renaming '%s' to '%s'\n",class_dev->class_id,new_name);+devname_string=kmalloc(strlen(class_dev->class_id)+15,GFP_KERNEL);+if(!devname_string){+class_device_put(class_dev);+return-ENOMEM;+}+sprintf(devname_string,"INTERFACE_OLD=%s",class_dev->class_id);+envp[0]=devname_string;+envp[1]=NULL;+#ifdef CONFIG_SYSFS_DEPRECATEDif(class_dev->dev)old_class_name=make_class_name(class_dev->class->name,
@@ -868,8 +879,16 @@ int class_device_rename(struct class_devsysfs_remove_link(&class_dev->dev->kobj,old_class_name);}#endif++/* This function is only used for network interface.+*Somehotplugpackagetrackinterfacesbytheirnameand+*thereforewanttoknowwhenthenameischangedbytheuser.*/+if(!error)+kobject_uevent_env(&class_dev->kobj,KOBJ_RENAME,envp);+class_device_put(class_dev);+kfree(devname_string);kfree(old_class_name);kfree(new_class_name);
From: Johannes Berg <johannes@sipsolutions.net> Date: 2007-02-28 09:16:35
Hi,
Patch for 2.6.20 is attached.
... and in the meantime netdevices aren't class_device any more :) IOW,
your patch isn't going to work any more. Also, I think wireless could
benefit from this as well.
The kobject framework is well designed, so adding these
features is trivial change and won't run the risk of breaking anything
(famous last words). Obviously, hotplug apps are free to ignore those
additional features.
Why not just add this to base kobject_rename instead? That way,
userspace is notified for all renames in sysfs.
The patch then collapses down to the change in net's sysfs code to add
the ifindex to the environment, and another change in kobject to invoke
a new event when a name changes and show the old name.
johannes
Patch for 2.6.20 is attached. The patch was tested on a system
running the hotplug scripts, and on another system running udev.
Have fun...
Jean
Signed-off-by: Jean Tourrilhes <redacted>
---------------------------------------------------------
@@ -412,6 +412,17 @@ static int netdev_uevent(struct class_deif((size<=0)||(i>=num_envp))return-ENOMEM;+/* pass ifindex to uevent.+*ifindexisusefulasitwon'tchange(interfacenamemaychange)+*andiswhatRtNetlinkusesnatively.*/+envp[i++]=buf;+n=snprintf(buf,size,"IFINDEX=%d",dev->ifindex)+1;+buf+=n;+size-=n;++if((size<=0)||(i>=num_envp))
Btw.:
1. if size == 10 and snprintf returns 9 (without NULL)
then n == 10 (with NULL), so isn't it enough (here and above):
if ((size < 0) || (i >= num_envp))
2. shouldn't there be (here and above):
envp[--i] = NULL;
@@ -841,6 +841,8 @@ int class_device_rename(struct class_dev{interror=0;char*old_class_name=NULL,*new_class_name=NULL;+char*devname_string=NULL;+char*envp[2];class_dev=class_device_get(class_dev);if(!class_dev)
@@ -849,6 +851,15 @@ int class_device_rename(struct class_devpr_debug("CLASS: renaming '%s' to '%s'\n",class_dev->class_id,new_name);+devname_string=kmalloc(strlen(class_dev->class_id)+15,GFP_KERNEL);+if(!devname_string){+class_device_put(class_dev);+return-ENOMEM;+}+sprintf(devname_string,"INTERFACE_OLD=%s",class_dev->class_id);+envp[0]=devname_string;+envp[1]=NULL;+#ifdef CONFIG_SYSFS_DEPRECATEDif(class_dev->dev)old_class_name=make_class_name(class_dev->class->name,
@@ -868,8 +879,16 @@ int class_device_rename(struct class_devsysfs_remove_link(&class_dev->dev->kobj,old_class_name);}#endif++/* This function is only used for network interface.+*Somehotplugpackagetrackinterfacesbytheirnameand+*thereforewanttoknowwhenthenameischangedbytheuser.*/+if(!error)+kobject_uevent_env(&class_dev->kobj,KOBJ_RENAME,envp);+class_device_put(class_dev);+kfree(devname_string);
Maybe I miss something, but it seems kobject_uevent_env copies
pointers from envp instead of buffers' contents.
Regards,
Jarek P.
On Wed, Feb 28, 2007 at 10:34:37AM +0100, Jarek Poplawski wrote:
On 28-02-2007 02:27, Jean Tourrilhes wrote:
...
quoted
+ /* This function is only used for network interface.
+ * Some hotplug package track interfaces by their name and
+ * therefore want to know when the name is changed by the user. */
+ if(!error)
+ kobject_uevent_env(&class_dev->kobj, KOBJ_RENAME, envp);
+
class_device_put(class_dev);
+ kfree(devname_string);
Maybe I miss something, but it seems kobject_uevent_env copies
pointers from envp instead of buffers' contents.
@@ -841,6 +841,8 @@ int class_device_rename(struct class_dev
This function is not in the 2.6.21-rc2 kernel, so you might want to
rework this patch a bit :)
Also, it's userspace that causes the rename to happen, so it knows it
did it, why should the kernel have to emit a message to tell userspace
again what just happened?
thanks,
greg k-h
@@ -841,6 +841,8 @@ int class_device_rename(struct class_dev
This function is not in the 2.6.21-rc2 kernel, so you might want to
rework this patch a bit :)
It was a trial balloon to gather feedback. I will do.
Also, it's userspace that causes the rename to happen, so it knows it
did it, why should the kernel have to emit a message to tell userspace
again what just happened?
Username is not one big program, but a collection of program,
and one program does not know what another program do.
In particular, udev does not know when people are using
iproute2 to rename interface and loose its marbles. We don't really
want to ban iproute2 or udev ;-)
From: Jean Tourrilhes <hidden> Date: 2007-02-28 18:46:08
On Wed, Feb 28, 2007 at 10:34:37AM +0100, Jarek Poplawski wrote:
On 28-02-2007 02:27, Jean Tourrilhes wrote:
quoted
Hi all,
...
quoted
Patch for 2.6.20 is attached. The patch was tested on a system
running the hotplug scripts, and on another system running udev.
Have fun...
Jean
Signed-off-by: Jean Tourrilhes <redacted>
---------------------------------------------------------
@@ -412,6 +412,17 @@ static int netdev_uevent(struct class_deif((size<=0)||(i>=num_envp))return-ENOMEM;+/* pass ifindex to uevent.+*ifindexisusefulasitwon'tchange(interfacenamemaychange)+*andiswhatRtNetlinkusesnatively.*/+envp[i++]=buf;+n=snprintf(buf,size,"IFINDEX=%d",dev->ifindex)+1;+buf+=n;+size-=n;++if((size<=0)||(i>=num_envp))
Btw.:
1. if size == 10 and snprintf returns 9 (without NULL)
then n == 10 (with NULL), so isn't it enough (here and above):
if ((size < 0) || (i >= num_envp))
I just cut'n'pasted the code a few line above. If the original
code is incorrect, it need fixing. And it will need fixing in probably
a lot of places.
2. shouldn't there be (here and above):
envp[--i] = NULL;
From: Jean Tourrilhes <hidden> Date: 2007-02-28 18:52:51
On Wed, Feb 28, 2007 at 10:16:05AM +0100, Johannes Berg wrote:
Hi,
quoted
Patch for 2.6.20 is attached.
... and in the meantime netdevices aren't class_device any more :) IOW,
your patch isn't going to work any more.
That's why I always specify the kernel version. I'll look into
that, I'm sure it's not the end of the world ;-)
Also, I think wireless could benefit from this as well.
In which sense ? Wireless interface are regular netdevices.
quoted
The kobject framework is well designed, so adding these
features is trivial change and won't run the risk of breaking anything
(famous last words). Obviously, hotplug apps are free to ignore those
additional features.
Why not just add this to base kobject_rename instead? That way,
userspace is notified for all renames in sysfs.
The patch then collapses down to the change in net's sysfs code to add
the ifindex to the environment, and another change in kobject to invoke
a new event when a name changes and show the old name.
I'm just trying to follow the established pattern. Both
class_device_add() and class_device_del() are generating the
event. Also, I'm not sure if other subsystem would benefit from it, I
don't want to generate too many useless events.
From: Johannes Berg <johannes@sipsolutions.net> Date: 2007-02-28 19:04:15
On Wed, 2007-02-28 at 10:51 -0800, Jean Tourrilhes wrote:
That's why I always specify the kernel version. I'll look into
that, I'm sure it's not the end of the world ;-)
Sure, just wanted to point it out.
In which sense ? Wireless interface are regular netdevices.
Yeah but in mac80211 we have the wiphy concept since multiple virtual
interfaces can be associated to one hardware, and that is where QoS is
done, not the netdevs. Of course, those interested can just listen to
nl80211 events to figure out if someone renamed a 802.11 phy, but things
like hal would probably not want to and still know about the name
change.
I'm just trying to follow the established pattern. Both
class_device_add() and class_device_del() are generating the
event. Also, I'm not sure if other subsystem would benefit from it, I
don't want to generate too many useless events.
I don't think many other subsystems (can) rename things ;)
johannes
@@ -841,6 +841,8 @@ int class_device_rename(struct class_dev
This function is not in the 2.6.21-rc2 kernel, so you might want to
rework this patch a bit :)
Thanks for all you good comments. I ported my patch to
2.6.21-rc2, and tested it both on a hotplug and a udev system. Patch
is attached, I would be glad if you could push that through the usual
channels.
Also, I realised that I forgot to say in my original e-mail
that migrating udev to use ifindex instead of ifname would fix the
remove/add race condition for network devices. But that's not going to
happen overnight...
Have fun...
Jean
Signed-off-by: Jean Tourrilhes <redacted>
---------------------------------------------------------
diff -u -p linux/include/linux/kobject.j1.h linux/include/linux/kobject.h
@@ -1007,6 +1007,8 @@ int device_rename(struct device *dev, chchar*new_class_name=NULL;char*old_symlink_name=NULL;interror;+char*devname_string=NULL;+char*envp[2];dev=get_device(dev);if(!dev)
@@ -1014,6 +1016,15 @@ int device_rename(struct device *dev, chpr_debug("DEVICE: renaming '%s' to '%s'\n",dev->bus_id,new_name);+devname_string=kmalloc(strlen(dev->bus_id)+15,GFP_KERNEL);+if(!devname_string){+put_device(dev);+return-ENOMEM;+}+sprintf(devname_string,"INTERFACE_OLD=%s",dev->bus_id);+envp[0]=devname_string;+envp[1]=NULL;+#ifdef CONFIG_SYSFS_DEPRECATEDif((dev->class)&&(dev->parent))old_class_name=make_class_name(dev->class->name,&dev->kobj);
@@ -1049,12 +1060,20 @@ int device_rename(struct device *dev, chsysfs_create_link(&dev->class->subsys.kset.kobj,&dev->kobj,dev->bus_id);}++/* This function is only used for network interface.+*Somehotplugpackagetrackinterfacesbytheirnameand+*thereforewanttoknowwhenthenameischangedbytheuser.*/+if(!error)+kobject_uevent_env(&dev->kobj,KOBJ_RENAME,envp);+put_device(dev);kfree(new_class_name);kfree(old_symlink_name);out_free_old_class:kfree(old_class_name);+kfree(devname_string);returnerror;}
From: Johannes Berg <johannes@sipsolutions.net> Date: 2007-03-01 00:38:40
On Wed, 2007-02-28 at 16:26 -0800, Jean Tourrilhes wrote:
+ /* This function is only used for network interface.
+ * Some hotplug package track interfaces by their name and
+ * therefore want to know when the name is changed by the user. */
Right now, that's true, but wireless is going to start using
device_rename pretty soon as well. Could you rephrase this comment?
johannes
From: Jean Tourrilhes <hidden> Date: 2007-03-01 00:52:43
On Thu, Mar 01, 2007 at 01:37:46AM +0100, Johannes Berg wrote:
On Wed, 2007-02-28 at 16:26 -0800, Jean Tourrilhes wrote:
quoted
+ /* This function is only used for network interface.
+ * Some hotplug package track interfaces by their name and
+ * therefore want to know when the name is changed by the user. */
Right now, that's true, but wireless is going to start using
device_rename pretty soon as well. Could you rephrase this comment?
johannes
I would prefer to fix the comment when this change actually
happens. I prefer comments to refer to the current reality, rather
than past/future situation. When you introduce wireless renaming, you
will need to verify the whole chain anyway, so you might as well fix
the comment while merging wireless renaming.
Note also that my comment is technically correct. I did not
say 'netdev' but the more generic term 'network interface', and I
believe your wireless interface is a 'network interface', even if it's
not a netdev ;-)
But if this really bugs you, please feel free to respin my
patch.
Have fun...
Jean
From: Johannes Berg <johannes@sipsolutions.net> Date: 2007-03-01 00:58:16
On Wed, 2007-02-28 at 16:51 -0800, Jean Tourrilhes wrote:
I would prefer to fix the comment when this change actually
happens. I prefer comments to refer to the current reality, rather
than past/future situation.
Uh, no. device_rename is perfectly fine, even other people may use it in
the future.
When you introduce wireless renaming, you
will need to verify the whole chain anyway, so you might as well fix
the comment while merging wireless renaming.
No again, device_rename is perfectly fine API, I shouldn't have to look
at it's internals to see if it's broken in my use case. Even if it's
only a broken comment.
I'm not going to respin your patches though, if this doesn't make it in
I don't care.
johannes
On Wed, Feb 28, 2007 at 10:45:41AM -0800, Jean Tourrilhes wrote:
On Wed, Feb 28, 2007 at 10:34:37AM +0100, Jarek Poplawski wrote:
quoted
On 28-02-2007 02:27, Jean Tourrilhes wrote:
quoted
Hi all,
...
quoted
Patch for 2.6.20 is attached. The patch was tested on a system
running the hotplug scripts, and on another system running udev.
Have fun...
Jean
Signed-off-by: Jean Tourrilhes <redacted>
---------------------------------------------------------
@@ -412,6 +412,17 @@ static int netdev_uevent(struct class_deif((size<=0)||(i>=num_envp))return-ENOMEM;+/* pass ifindex to uevent.+*ifindexisusefulasitwon'tchange(interfacenamemaychange)+*andiswhatRtNetlinkusesnatively.*/+envp[i++]=buf;+n=snprintf(buf,size,"IFINDEX=%d",dev->ifindex)+1;+buf+=n;+size-=n;++if((size<=0)||(i>=num_envp))
Btw.:
1. if size == 10 and snprintf returns 9 (without NULL)
then n == 10 (with NULL), so isn't it enough (here and above):
if ((size < 0) || (i >= num_envp))
I just cut'n'pasted the code a few line above. If the original
code is incorrect, it need fixing. And it will need fixing in probably
a lot of places.
I think you're kind of responsible for your part, at least.
quoted
2. shouldn't there be (here and above):
envp[--i] = NULL;
No, envp is local, so who cares.
But envp[i] isn't (at least here). So, I guess, a caller
of this function could care.
quoted
quoted
+ if ((size <= 0) || (i >= num_envp))
+ return -ENOMEM;
And one more thing (not necessarily for you):
ENOBUFS is probably more adequate here.
Cheers,
Jarek P.
From: Jean Tourrilhes <hidden> Date: 2007-03-01 19:28:15
On Thu, Mar 01, 2007 at 08:42:09AM +0100, Jarek Poplawski wrote:
On Wed, Feb 28, 2007 at 10:45:41AM -0800, Jean Tourrilhes wrote:
quoted
quoted
quoted
+
+ if ((size <= 0) || (i >= num_envp))
Btw.:
1. if size == 10 and snprintf returns 9 (without NULL)
then n == 10 (with NULL), so isn't it enough (here and above):
if ((size < 0) || (i >= num_envp))
I just cut'n'pasted the code a few line above. If the original
code is incorrect, it need fixing. And it will need fixing in probably
a lot of places.
I think you're kind of responsible for your part, at least.
I personally don't go fixing stuff without having a full
undersunding of the context and why it was done this way. To me it
look this test was intentionally done this way, so there may be
something I don't know about. I guess I would need to double check
more closely what weid calculation the caller does with the buffer
size.
That's why I would prefer a separate patch about those issues
that give the opportunity for the stakeholder to really talk about
this, rather than slipping it under the carpet.
In the worse case, this is not a bug, this just means that we
may not use the last char of the buffer.
quoted
quoted
2. shouldn't there be (here and above):
envp[--i] = NULL;
No, envp is local, so who cares.
But envp[i] isn't (at least here). So, I guess, a caller
of this function could care.
Check the full source code of the caller, and you will see
that the caller does not care (and it's local to the caller).
quoted
quoted
quoted
+ if ((size <= 0) || (i >= num_envp))
+ return -ENOMEM;
And one more thing (not necessarily for you):
ENOBUFS is probably more adequate here.
This error should never happen. If it happens, the caller need
to be fixed.
Cheers,
Jarek P.
Note that there are various other things that are puzzling in
this function. The internal object name and the symlinks are changed
even if the kcore rename returns an error. That does not seem right.
But, this is separate from this patch...
Have fun...
Jean
On Thu, Mar 01, 2007 at 11:27:34AM -0800, Jean Tourrilhes wrote:
On Thu, Mar 01, 2007 at 08:42:09AM +0100, Jarek Poplawski wrote:
quoted
On Wed, Feb 28, 2007 at 10:45:41AM -0800, Jean Tourrilhes wrote:
quoted
quoted
quoted
+
+ if ((size <= 0) || (i >= num_envp))
Btw.:
1. if size == 10 and snprintf returns 9 (without NULL)
then n == 10 (with NULL), so isn't it enough (here and above):
if ((size < 0) || (i >= num_envp))
I just cut'n'pasted the code a few line above. If the original
code is incorrect, it need fixing. And it will need fixing in probably
a lot of places.
I think you're kind of responsible for your part, at least.
I personally don't go fixing stuff without having a full
undersunding of the context and why it was done this way. To me it
look this test was intentionally done this way, so there may be
something I don't know about. I guess I would need to double check
more closely what weid calculation the caller does with the buffer
size.
That's why I would prefer a separate patch about those issues
that give the opportunity for the stakeholder to really talk about
this, rather than slipping it under the carpet.
Sure, but adding a functionality is a kind of fixing, too.
I don't blame you - I simply think that the patch like yours
is an occasion for people reading this list to look at the
adjacent code too. So I wrote about my doubts here hoping
somebody with a better knowledge of this place could verify
them.
In the worse case, this is not a bug, this just means that we
may not use the last char of the buffer.
Sorry, I can't agree with this.
quoted
quoted
quoted
2. shouldn't there be (here and above):
envp[--i] = NULL;
No, envp is local, so who cares.
But envp[i] isn't (at least here). So, I guess, a caller
of this function could care.
Check the full source code of the caller, and you will see
that the caller does not care (and it's local to the caller).
I can't agree with this, too. There is no reason to leave
a bad pointer there - you need to analyze more than one
caller to verify this now, and any changes in the future
are endangered, too.
quoted
quoted
quoted
quoted
+ if ((size <= 0) || (i >= num_envp))
+ return -ENOMEM;
And one more thing (not necessarily for you):
ENOBUFS is probably more adequate here.
This error should never happen. If it happens, the caller need
to be fixed.
Yes, but an error handling should be correct or removed,
if unnecessary.
...
Note that there are various other things that are puzzling in
this function. The internal object name and the symlinks are changed
even if the kcore rename returns an error. That does not seem right.
But, this is separate from this patch...
So, I hope somebody will help to make this code perfect!
Best regards,
Jarek P.