On Wed, Oct 20, 2021 at 08:19:37AM -0700, Stephen Hemminger wrote: > > On Tue, Oct 19, 2021 at 07:09:42PM +0300, Nikolay Aleksandrov wrote: > > > > I started this patch when I saw there is not limit for setting > > > > multicast_membership_interval to 0, which will cause bridge remove the > > > > mdb directly after adding. Do you think this is a problem. > > > > > > > > And what about others? I don't think there is a meaning to set other > > > > intervals > > > > to 0. > > > > > > > > > > The problem is not if there is meaning, we cannot start restricting > > > option values now after > > > they've become uapi (and have been for a very long time) because we can > > > break user-space even > > > though chances are pretty low. I don't think this patch is acceptable, I > > > commented on the other > > > patch issues but they don't matter because of this. > > > > OK, I got your mean, we should not restrict the configurations based on > > whether > > there is a meaning. > > > > Thanks > > Hangbin > > Maybe the bridge command could enforce that the value set are sane relative > to the RFC? We already fixup some things in iproute2 utilities to workaround > places where changing defaults in kernel would break userspace.
I'm afraid this may make user more confused. As user could also echo the values via sys fs directly. e.g. # ip link set br0 type bridge mcast_query_interval 0 Error: Invalid QI, must greater than 0. # echo 0 > /sys/devices/virtual/net/br0/bridge/multicast_query_interval Then ip -d link show br0 would show the mcast_query_interval is 0. Thanks Hangbin
