Problem in changed VLAN code can cause systems to hang.

Stephen,

I noticed that the VLAN code of kernels >=2.6.8 contain the patch needed to mirror link state information from the real device to the vlan device.

This however causes the system to hang in combination with net-snmpd. The last thing that I see is an ioctl(0x8947...

From the net-snmp code:
---

        if (ioctl(fd, 0x8947, &ifr) >= 0) {
                new_ioctl_nums = 1;
        } else if (ioctl(fd, SIOCDEVPRIVATE, &ifr) >= 0) {
                new_ioctl_nums = 0;
        } else {
                DEBUGMSGTL(("mibII/interfaces", "SIOCGMIIPHY on %s 
failed\n", ifr.ifr_name));
                return retspeed;
        }

---

I suspected the code below so I commented out the SIOCGMIIPHY line:

int vlan_dev_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)

{
        struct net_device *real_dev = VLAN_DEV_INFO(dev)->real_dev;
        struct ifreq ifrr;
        int err = -EOPNOTSUPP;

        strncpy(ifrr.ifr_name, real_dev->name, IFNAMSIZ);
        ifrr.ifr_ifru = ifr->ifr_ifru;

        switch(cmd) {
        //case SIOCGMIIPHY:
        case SIOCGMIIREG:
        case SIOCSMIIREG:
                if (real_dev->do_ioctl && netif_device_present(real_dev))
                        err = real_dev->do_ioctl(dev, &ifrr, cmd);
                break;

        case SIOCETHTOOL:
                err = dev_ethtool(&ifrr);
        }

        if (!err)
                ifr->ifr_ifru = ifrr.ifr_ifru;

        return err;
}

This fixes the problem. I didn't bother to check what this call actually does and why it doesn't work.

Mark.

What kind of ethernet devices do you have making use of VLAN?

I suspect the underlying device doesn't support mii interface. If that is true, then the code is doing the right thing (and net-snmp) is being too dependant on MII.

It does, it's tg3. And it shouldn't hang the machine, it's not just hanging userspace. Therefore it is a kernel bug.

I can't reproduce the problem on a test machine (SMP) with eth0 (e100) and eth2 (e1000) Doesn't seem to hang either with commands or custom program.

[root@dev4-009 root]# vconfig add eth2 1
Added VLAN with VID == 1 to IF -:eth2:-
WARNING: VLAN 1 does not work with many switches, consider another number if you have problems. [root@dev4-009 root]# ifconfig eth2:1
eth2:1 Link encap:Ethernet HWaddr 00:03:47:9A:33:D5
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 Memory:fa420000-fa440000

[root@dev4-009 root]# mii-tool eth2:1 SIOCGMIIPHY on 'eth2:1' failed: Operation not supported

This is what we would expect since e1000 doesn't support MII ioctl when running in 1000Gbit mode.

[root@dev4-009 root]# vconfig add eth0 11
Added VLAN with VID == 11 to IF -:eth0:-
[root@dev4-009 root]# mii-tool eth0:11
eth0:11: negotiated 100baseTx-FD, link ok

The e100 link works, and also eth1 (e1000 in 100mbit mode). If someone can reproduce the problem, please tell me how and/or do it on a console; it is probably a OOPs.

This is not the VLAN interface. It is typically named eth2.1 (or possibly vlan1).

    ^

-Tommy

Thanks, brain misfunction...

I'll try to create a little tool to reproduce the problem. In the mean time, did you try net-snmp and snmpwalk?

Mark.

Stephen,

The production system that I use went down completely on this bug. My laptop didn't go down but it became unstable. (ifconfig -a would freeze etc.).

net-snmp is not the problem, it just shows it.

However when I type :
mii-tool eth0
SIOCGMIIPHY on 'eth0' failed: Operation not supported

This is the case for all interfaces in the production machine as well as my laptop.

So you're right about the not supported mii interface. But my point is that it shouldn't be possible to make the system unstable with an ioctl.

Mark.

Why would it cause a hang though? I would expect net-snmp to immediately fail the IOCTL and continue on it's merry way.

Ben

Ben Greear <[email protected]>
Candela Technologies Inc  http://www.candelatech.com

The machine that would hang had these cards installed ( and had vlan's on them) :

eth0: Tigon3 [partno(NA) rev 1002 PHY(5703)] (PCIX:100MHz:64-bit) 10/100/1000BaseT Ethernet 00:0f:20:32:35:53
eth0: HostTXDS[1] RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] Split[0] WireSpeed[1] TSOcap[1]
eth1: Tigon3 [partno(NA) rev 1002 PHY(5703)] (PCIX:100MHz:64-bit) 10/100/1000BaseT Ethernet 00:0f:20:32:35:52

e1000: eth2: e1000_probe: Intel(R) PRO/1000 Network Connection
e1000: eth3: e1000_probe: Intel(R) PRO/1000 Network Connection

The laptop that I use however shows the same results:

eth0: RealTek RTL8139 at 0xd902a800, 00:02:3f:6e:58:6e, IRQ 19
eth0: Identified 8139 chip type 'RTL-8101'

So I don't think it's related to the hardware.

net-snmp-5.1 will demonstrate the problem right away. Just start the deamon on the host and type:
snmpwalk -c public -v 2c 127.0.0.1

Mark.

I guess do_ioctl should be called with real_dev as parameter here.

-Tommy

Thanks Tommy, the vlan MII ioctl pass through was passing the wrong device.

--

diff -Nru a/net/8021q/vlan_dev.c b/net/8021q/vlan_dev.c
@@ -772,7 +772,7 @@
 	case SIOCGMIIREG:
 	case SIOCSMIIREG:
 		if (real_dev->do_ioctl && netif_device_present(real_dev)) 
-			err = real_dev->do_ioctl(dev, &ifrr, cmd);
+			err = real_dev->do_ioctl(real_dev, &ifrr, cmd);
 		break;
 
 	case SIOCETHTOOL:

Good eyes Tommy. I looked at that line many times and couldn't see this obvious error.

Patch applied.