On Tue, Feb 26, 2013 at 08:18:17PM -0800, Ethan Jackson wrote: > For most of the history of Open vSwitch, one could assume that a > given datapath flow key would consistently translate into the same > userspace struct flow representation. However, with the switch to > flow based tunneling, we now have a situation where a database > configuration change can cause a datapath flow key's in_port to > correspond to a completely different OpenFlow in_port possibly on a > completely different bridge. This can cause all sorts of problems, > including traffic black holes due to confused facet revalidations. > > To solve the problem, this patch verifies that each facet's > subfacets still result in the appropriate struct flow. If a facet > fails this test, it is simply removed. > > Bug #15213. > Signed-off-by: Ethan Jackson <et...@nicira.com>
I think that there is a risky situation here. handle_flow_miss_with_facet() retains a pointer to a subfacet in the "flow_miss_op"s that it generates, and later handle_miss_upcalls() uses that to update the 'path' if the flow installation was successful (which is the normal case). But if something in the meantime causes revalidation then facet_lookup_valid() could theoretically delete the facet and the subfacet. I'm not sure that can actually happen now, but it's a nasty corner case that I don't really want lurking if we can avoid it. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
