[ovs-build] Passed: ovsrobot/ovs#3552 (series_229528 - 13b5d35)

Travis CI builds at travis-ci.com
Mon Feb 15 10:13:04 UTC 2021


Build Update for ovsrobot/ovs
-------------------------------------

Build: #3552
Status: Passed

Duration: 16 mins and 12 secs
Commit: 13b5d35 (series_229528)
Author: Peng He
Message: ofproto-dpif-xlate: fix zone set from non frozen metadata field

CT zone could be set from a field that is not included in frozen
metedata. Consider the belowing cases which is normally used in
OpenStack security group rules:

priority=100,in_port=1,tcp,ct_state=-trk,action=ct(zone=5,table=0)
priority=100,in_port=1,tcp,ct_state=+trk,action=ct(commit,zone=NXM_NX_CT_ZONE[]),2

The zone is set from the first rule's ct action. These two rules will
generate two megaflows: the first one uses zone=5 to query the CT module,
the second one set zone from the first megaflow and commit to CT.

The current implementation will generate a megaflow which does not use
ct_zone=5 as a match, but directly commit into the ct using zone=5, as zone is
set by an Imm not a field.

Consider a situation that one changes the zone id (for example to 15)
in the first rule however still keep the second rule unchanged. During
this change, there is traffic hitting the two generated megaflows, the
revaldiator would revalidate all megaflows, however, the revalidator will
not change the second megaflow, because zone=5 is recorded in the
megaflow, so the xlate will still translate the commit action into zone=5,
and the new traffic will still commit to CT as zone=5, not zone=15,
resulting in taffic drops and other issues.

Just like OVS set-field action, if the field X is set by Y, we should also
mask Y as a match in the generated megaflow. An exception is that, if the zone
is set by the field that is included in the frozen state and this upcall is
a resume of a thawed xlate, the masking can be skipped, as if one changes
the previous rule, the generated recirc_id will be changed, and all megaflows
with the old recirc id will be invalid later, i.e. the revalidator will
not reuse the old megaflows at all.

Fixes: 07659514c3 ("Add support for connection tracking.")
Reported-by: Sai Su <susai.ss at bytedance.com>
Signed-off-by: Peng He <hepeng.0320 at bytedance.com>
Signed-off-by: 0-day Robot <robot at bytheb.org>

View the changeset: https://github.com/ovsrobot/ovs/commit/13b5d35e084d

View the full build log and details: https://travis-ci.com/github/ovsrobot/ovs/builds/217086328?utm_medium=notification&utm_source=email


--

You can unsubscribe from build emails from the ovsrobot/ovs repository going to https://travis-ci.com/account/preferences/unsubscribe?repository=9111024&utm_medium=notification&utm_source=email.
Or unsubscribe from *all* email updating your settings at https://travis-ci.com/account/preferences/unsubscribe?utm_medium=notification&utm_source=email.
Or configure specific recipients for build notifications in your .travis.yml file. See https://docs.travis-ci.com/user/notifications.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-build/attachments/20210215/229b74be/attachment-0001.html>


More information about the build mailing list