nikolay at cumulusnetworks.com
2019-Oct-15 10:48 UTC
[Bridge] Bridge port userspace events broken?
On 14 October 2019 22:33:22 CEST, Richard Weinberger <richard.weinberger at gmail.com> wrote:>Hi! > >My userspace needs /sys/class/net/eth0/brport/group_fwd_mask, so I set >up udev rules >to wait for the sysfs file. >Without luck. >Also "udevadm monitor" does not show any event related to >/sys/class/net/eth0/brport when I assign eth0 to a bridge. > >First I thought that the bridge code just misses to emit some events >but >br_add_if() calls kobject_uevent() which is good. > >Greg gave me the hint that the bridge code might not use the kobject >model >correctly. > >Enabling kobjekt debugging shows that all events are dropped: >[ 36.904602] device eth0 entered promiscuous mode >[ 36.904786] kobject: 'brport' (0000000028a47e33): kobject_uevent_env >[ 36.904789] kobject: 'brport' (0000000028a47e33): >kobject_uevent_env: filter function caused the event to drop! > >If I understood Greg correctly this is because the bridge code uses >plain kobjects which >have a parent object. Therefore all events are dropped. > >Shouldn't brport be a kset just like net_device->queues_kset?Hi Richard, I'm currently traveling and will be out of reach until mid-next week when I'll be able to take a closer look, but one thing which comes to mind is that on any bridge/port option change there should also be a netlink notification which you could use. I'll look into this and will probably cook a fix, if anyone hasn't beaten me to it by then. :) Cheers, Nik
nikolay at cumulusnetworks.com
2019-Oct-15 10:53 UTC
[Bridge] Bridge port userspace events broken?
On 15 October 2019 12:48:58 CEST, nikolay at cumulusnetworks.com wrote:>On 14 October 2019 22:33:22 CEST, Richard Weinberger ><richard.weinberger at gmail.com> wrote: >>Hi! >> >>My userspace needs /sys/class/net/eth0/brport/group_fwd_mask, so I set >>up udev rules >>to wait for the sysfs file. >>Without luck. >>Also "udevadm monitor" does not show any event related to >>/sys/class/net/eth0/brport when I assign eth0 to a bridge. >> >>First I thought that the bridge code just misses to emit some events >>but >>br_add_if() calls kobject_uevent() which is good. >> >>Greg gave me the hint that the bridge code might not use the kobject >>model >>correctly. >> >>Enabling kobjekt debugging shows that all events are dropped: >>[ 36.904602] device eth0 entered promiscuous mode >>[ 36.904786] kobject: 'brport' (0000000028a47e33): >kobject_uevent_env >>[ 36.904789] kobject: 'brport' (0000000028a47e33): >>kobject_uevent_env: filter function caused the event to drop! >> >>If I understood Greg correctly this is because the bridge code uses >>plain kobjects which >>have a parent object. Therefore all events are dropped. >> >>Shouldn't brport be a kset just like net_device->queues_kset? > > >Hi Richard, >I'm currently traveling and will be out of reach until mid-next week >when I'll be >able to take a closer look, but one thing which comes to mind is that >on >any bridge/port option change there should also be a netlink >notification which >you could use. I'll look into this and will probably cook a fix, if >anyone hasn't >beaten me to it by then. :) > >Cheers, > NikI meant the notifications could be used to configure the port mask once the netdev is enslaved as well as for monitoring changes to them. Generally we prefer using netlink for configuration changes, some of the bridge options are only accessible via netlink (e. g. vlan config).