On Thu, Jan 09, 2014 at 08:51:00AM +0100, Helmut Schaa wrote: > 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.
Thank you! _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
