On Thu, Sep 27, 2012 at 10:52 AM, Tadaaki Nagao <na...@stratosphere.co.jp> wrote: > 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@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?
Probably the right thing to do is tighten the set of circumstances where we use this workaround. I'm guessing that since you're seeing correct values one of these two conditions is true: * You're not running on 2.6.32 (or another kernel with this problem). * You're not using network namespaces (even if the kernel is compiled with support). _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
