On Thu, Jan 9, 2014 at 1:59 AM, Ben Pfaff <b...@nicira.com> wrote: > On Wed, Jan 08, 2014 at 04:43:47PM +0100, Helmut Schaa wrote: >> Due to a race condition when bringing up an internal port on Linux >> some interface flags (e.g. IFF_MULTICAST) are falsely reset. This >> happens because netlink events may be processed after the according >> netdev has been brought up (which sets interface flags). >> >> Fix this by reading the interface flags just before updating them >> if they have not been updated by from the kernel yet. >> >> Signed-off-by: Helmut Schaa <helmut.sc...@googlemail.com> > > Hmm. I see the problem. Thanks for finding and reporting it, and for > the patch. > > I have two ideas here: > > 1. Add (back) VALID_FLAGS and check for it here. (It will > generally be valid, except in the case of initial > construction of internal devices.) I think that this would > probably be better than abusing VALID_DRVINFO.
Agreed, that makes sense ... > 2. Instead of using an ioctl and ifreq to set interface flags, > use rtnetlink with RTM_SETLINK, with ifi_flags and > ifi_change. In Linux 2.6.22 and later, this allows one to > set a subset of flags, rather than all flags overall, and > that generally reflects OVS userspace intent, which never > tries to change more than one flag at a time. I think that > we could even look at ifi_change in the Netlink response to > see whether the change actually made a difference and (in > pre-2.6.22) spot whether it had some unintended effect so > that we could reverse it. > > Ideally, we'd do both. > > What do you think? Hmm, good point. Let me look into this. Helmut _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
