On Fri, Jan 17, 2014 at 05:20:13PM +0100, Helmut Schaa wrote: > On Thu, Jan 9, 2014 at 5:48 PM, Ben Pfaff <b...@nicira.com> wrote: > > 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! > > I haven't found time to respin this yet. Maybe I'll go with just adding > the VALID_FLAGS back to get this fixed within a reasonable time frame.
Yes, that is a fine place to start. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
