Converting network devices from class devices causes namespace pollution

Converting network devices from class devices causes namespace pollution

[Eric W. Biederman]

I believe the culprit is 43cb76d91ee85f579a69d42bc8efc08bac560278.

For some reason network devices are now showing up under the pci
device tree, in directories that have something other than network
devices.

# ls -l /sys/class/net/eth0
lrwxrwxrwx 1 root root 0 Feb 17 23:19 /sys/class/net/eth0 -> ../../devices/pci0000:00/0000:00:0a.0/eth0

# ls /sys/devices/pci0000\:00/0000\:00\:0a.0/
broken_parity_status  device  eth0        modalias  resource   subsystem         uevent
class                 driver  irq         msi_bus   resource0  subsystem_device  vendor
config                enable  local_cpus  power     resource1  subsystem_vendor

User space is allowed to rename network devices to anything any name
not currently taken by another network device.

However when I now do something like:

ip link set eth0 name irq

The rename half happens (because it is legal), but sysfs can't support
it because of the ridiculous directory eth0 is in.  After that
point things go hideously wrong.

The current situation is hideous namespace pollution, and breaks user
space, and is only likely only a matter of time before we have a
reasonable instead of an strained conflict of names.

Is there any simple fix or do we need to revert the change away
from class_device?

Eric

Re: Converting network devices from class devices causes namespace pollution

[Greg KH]

On Sun, Feb 18, 2007 at 08:55:20AM -0700, Eric W. Biederman wrote:
> 
> I believe the culprit is 43cb76d91ee85f579a69d42bc8efc08bac560278.
> 
> For some reason network devices are now showing up under the pci
> device tree, in directories that have something other than network
> devices.
> 
> # ls -l /sys/class/net/eth0
> lrwxrwxrwx 1 root root 0 Feb 17 23:19 /sys/class/net/eth0 -> ../../devices/pci0000:00/0000:00:0a.0/eth0
> 
> # ls /sys/devices/pci0000\:00/0000\:00\:0a.0/
> broken_parity_status  device  eth0        modalias  resource   subsystem         uevent
> class                 driver  irq         msi_bus   resource0  subsystem_device  vendor
> config                enable  local_cpus  power     resource1  subsystem_vendor

That's the PCI device directory where eth0 is attached to, what is wrong
with that?

> User space is allowed to rename network devices to anything any name
> not currently taken by another network device.
> 
> However when I now do something like:
> 
> ip link set eth0 name irq
> 
> The rename half happens (because it is legal), but sysfs can't support
> it because of the ridiculous directory eth0 is in.  After that
> point things go hideously wrong.

What goes wrong?  What is not renamed properly?

Oh, you can't rename it to something like "irq".  Well that's pretty
foolish on your behalf :)

> The current situation is hideous namespace pollution, and breaks user
> space, and is only likely only a matter of time before we have a
> reasonable instead of an strained conflict of names.

Do we really have a problem here?

> Is there any simple fix or do we need to revert the change away
> from class_device?

We need the class_device change to get suspend/resume working properly,
and to make a lot of other things better (unified device tree, smaller
kernel images, etc.)

But my main point remains, is this really a problem?  Do systems really
name their network devices with names that stop working with this change
today?  Distros use the mac address these days to name network devices
in a unique way, and that namespace does not conflict with the pci
attributes.

thanks,

greg k-h

Re: Converting network devices from class devices causes namespace pollution

[Eric W. Biederman]

Greg KH <gregkh@suse.de> writes:

> On Sun, Feb 18, 2007 at 08:55:20AM -0700, Eric W. Biederman wrote:
>> User space is allowed to rename network devices to anything any name
>> not currently taken by another network device.
>> 
>> However when I now do something like:
>> 
>> ip link set eth0 name irq
>> 
>> The rename half happens (because it is legal), but sysfs can't support
>> it because of the ridiculous directory eth0 is in.  After that
>> point things go hideously wrong.
>
> What goes wrong?  What is not renamed properly?

It gets half renamed. 

> Oh, you can't rename it to something like "irq".  Well that's pretty
> foolish on your behalf :)

No it is pretty foolish on your behalf to add this extra restriction.
Currently this is a worse set of restrictions than DOS had with
it's magic character devices.

>> The current situation is hideous namespace pollution, and breaks user
>> space, and is only likely only a matter of time before we have a
>> reasonable instead of an strained conflict of names.
>
> Do we really have a problem here?

Yes.

>> Is there any simple fix or do we need to revert the change away
>> from class_device?
>
> We need the class_device change to get suspend/resume working properly,
> and to make a lot of other things better (unified device tree, smaller
> kernel images, etc.)

Which is why I'm asking for a fix, that we can merge.

> But my main point remains, is this really a problem?  Do systems really
> name their network devices with names that stop working with this change
> today?  Distros use the mac address these days to name network devices
> in a unique way, and that namespace does not conflict with the pci
> attributes.

- The error handling is not correct so if someone tries it you loose
  your network device.  Bad BUG.

- This is gratuitous ABI breakage.  Give me the 2 years notice that is
  implied in Documentation/ABI/README and you may have a case.

- The namespace conflicts because the pci attributes are legal network
  device names, and there is nothing that causes me to expect that
  we won't add a pci attribute that will not be an interesting network
  device name.

Fixing this theoretically isn't very hard all you have do to is insert
an extra subdirectory and remove any possible conflict.

Eric

Re: Converting network devices from class devices causes namespace pollution

[Greg KH]

On Sun, Feb 18, 2007 at 03:52:05PM -0700, Eric W. Biederman wrote:
> Greg KH <gregkh@suse.de> writes:
> 
> > On Sun, Feb 18, 2007 at 08:55:20AM -0700, Eric W. Biederman wrote:
> >> User space is allowed to rename network devices to anything any name
> >> not currently taken by another network device.
> >> 
> >> However when I now do something like:
> >> 
> >> ip link set eth0 name irq
> >> 
> >> The rename half happens (because it is legal), but sysfs can't support
> >> it because of the ridiculous directory eth0 is in.  After that
> >> point things go hideously wrong.
> >
> > What goes wrong?  What is not renamed properly?
> 
> It gets half renamed. 

Ick :(

> > Oh, you can't rename it to something like "irq".  Well that's pretty
> > foolish on your behalf :)
> 
> No it is pretty foolish on your behalf to add this extra restriction.
> Currently this is a worse set of restrictions than DOS had with
> it's magic character devices.

Hey, don't be mean here...

> >> The current situation is hideous namespace pollution, and breaks user
> >> space, and is only likely only a matter of time before we have a
> >> reasonable instead of an strained conflict of names.
> >
> > Do we really have a problem here?
> 
> Yes.

Actually, you are right, I fixed this problem over a year ago, and then
introduced it recently again :(

We need our own namespace for these devices, and we have it today
already.  Look if you enable CONFIG_SYSFS_DEPRECATED, or on a pre-2.6.19
machine at what shows up in the pci device directories:
$ ls -l /sys/devices/pci0000:00/0000:00:1c.0/0000:02:00.0/
total 0
lrwxrwxrwx  1 root root     0 2007-02-18 18:56 bus -> ../../../../bus/pci
-r--r--r--  1 root root  4096 2007-02-18 18:56 class
-rw-r--r--  1 root root  4096 2007-02-18 18:56 config
-r--r--r--  1 root root  4096 2007-02-18 13:06 device
lrwxrwxrwx  1 root root     0 2007-02-18 18:56 driver -> ../../../../bus/pci/drivers/tg3
-r--r--r--  1 root root  4096 2007-02-18 18:56 irq
-r--r--r--  1 root root  4096 2007-02-18 18:56 local_cpus
-r--r--r--  1 root root  4096 2007-02-18 18:56 modalias
lrwxrwxrwx  1 root root     0 2007-02-18 18:56 net:eth0 -> ../../../../class/net/eth0
drwxr-xr-x  2 root root     0 2007-02-12 08:06 power
-r--r--r--  1 root root  4096 2007-02-18 18:56 resource
-rw-------  1 root root 65536 2007-02-18 18:56 resource0
-r--r--r--  1 root root  4096 2007-02-18 13:06 subsystem_device
-r--r--r--  1 root root  4096 2007-02-18 13:06 subsystem_vendor
--w-------  1 root root  4096 2007-02-18 18:56 uevent
-r--r--r--  1 root root  4096 2007-02-18 13:06 vendor

So, all we need to do is rename these devices back to the "net:eth0"
name, and everything will be fine.  I'll work on fixing that tomorrow as
it will take a bit of hacking on the kobject symlink function and the
driver core code (but it gets us rid of a symlink in "compatiblity
mode", which is always a nice win...)

And thanks for your calm and reasoned statements in pointing out this
bug, it wasn't deliberate by any means :)

thanks,

greg k-h

Re: Converting network devices from class devices causes namespace pollution

[Eric W. Biederman]

Greg KH <gregkh@suse.de> writes:

> We need our own namespace for these devices, and we have it today
> already.  Look if you enable CONFIG_SYSFS_DEPRECATED, or on a pre-2.6.19
> machine at what shows up in the pci device directories:
> -r--r--r--  1 root root  4096 2007-02-18 13:06 vendor

Interesting.  I hadn't noticed that before.

> So, all we need to do is rename these devices back to the "net:eth0"
> name, and everything will be fine.  I'll work on fixing that tomorrow as
> it will take a bit of hacking on the kobject symlink function and the
> driver core code (but it gets us rid of a symlink in "compatiblity
> mode", which is always a nice win...)

Ok.  I'm groaning a little bit at what a nuisance this is going to be
to get support for multiple network namespaces in there after your fix
goes in, directories can be easier to deal with.  But once you figure this
part out I will figure something out.

For me the nasty case is 1 pci device that has multiple ethernet devices
coming from it (I think IB devices have this property today), each
showing up in a different network namespace, so they might all have
the same name. Ugh.

Eric