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. Helmut _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
