[ovs-dev] "brctl show" doesn't list attached interfaces

[Tadaaki Nagao]

Hi,

I recently noticed that "brctl show" doesn't list bridges' attached
interfaces as with the Linux kernel bridge, while of course "ovs-dpctl
show" lists them correctly:

    # ovs-vsctl add-br br0
    # ovs-vsctl add-port br0 eth3

    # brctl show br0
    bridge name     bridge id               STP enabled     interfaces
    br0             0000.000c299a1083       no
                                                            ^^^^^^^^^^
                                                         (should be "eth3")
    # ovs-dpctl show br0
    system at br0:
            lookups: hit:20080 missed:538 lost:0
            flows: 0
            port 0: br0 (internal)
            port 1: eth3

I'm not sure the right way to fix it, but I'll describe some of my
findings about it below.

		-*-					-*-

A colleague of mine found that commenting out the following if() statement
in datapath/dp_sysfs_if.c:ovs_dp_sysfs_add_if() "fixed" the issue and
"brctl show" now listed the interfaces as expected.

#ifdef CONFIG_NET_NS
	/* Due to bug in 2.6.32 kernel, sysfs_create_group() could panic
	 * in other namespace than init_net. Following check is to avoid it. */

	if (!p->kobj.sd)
		return -ENOENT;
#endif

Both of us were unsure if it was the right way to go particularly because
of the scary words "could panic" in the comment above ;-), so I looked
into it a bit more.  My findings are:

  - p->kobj.sd is always NULL at the check above.

  - This prevented the rest of the code from populating
    /sys/class/net/<bridge name>/brif/ with symlinks to the files
    corresponding to actual interfaces.  (This is the direct cause that
    prevented "brctl show" from listing attached real interfaces.)

  - If you comment out the check, p->kobj.sd is set to an apparently sane
    value by kobject_add() called immediately after the snippet of the
    code above.

  - Though the comment mentions sysfs_create_group(), nowhere in the code
    below it that function is called.

Any thoughts on how to fix it?

Thanks,
Tadaaki Nagao <nagao at stratosphere.co.jp>
Stratosphere Inc.