datapath: Fix race.

ovs_vport_cmd_dump() did rcu_read_lock() only after getting the
datapath, which could have been deleted in between.  Resolved by
taking rcu_read_lock() before the get_dp() call.

Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com>
datapath: fix dp check in ovs_dp_reset_user_features

This fixes crash when userspace does "ovs-dpctl add-dp dev" where dev is
existing non-dp netdevice.

Introduced by:
commit 94358dcffbec33cbcfd425e925139fd7e9d6153f
"openvswitch: Drop user features if old user space attempted to create datapath"

Signed-off-by: Jiri Pirko <jiri@resnulli.us>
Signed-off-by: Jesse Gross <jesse@nicira.com>
ovs-vsctl: reconnect to the database if connection was dropped

If ovs-vsctl has to wait for ovs-vswitchd to reconfigure itself
according to the new database, then sometimes ovs-vsctl could
end up stuck in the event loop if OVSDB connection was dropped
while ovs-vsctl was still running.

This patch fixes this problem by letting ovs-vsctl to reconnect
to the OVSDB, if it has to wait cur_cfg field to be updated.

Issue: 1191997
Reported-by: Spiro Kourtessis <spiro@nicira.com>
Signed-Off-By: Ansis Atteka <aatteka@nicira.com>
ipfix: fix upcall cookie size checks to support 8 byte cookies

Commit 96ed775f resizes all userspace metadata to be 8 bytes minimum.
Fix the upcall size checks accordingly.

Signed-off-by: Romain Lenglet <rlenglet@vmware.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
ofproto: Update only OFPUTIL_PS_LINK_DOWN (not STP) from netdev state.

When a netdev indicates that its state or configuration has changed,
update_port() updates the OpenFlow port to match the changes.  However,
this was being taken too far: a netdev does not have an STP state, and a
state change was resetting the STP state of the port.  This fixes the
problem.

Signed-off-by: Ben Pfaff <blp@nicira.com>
Reported-by: Vasu Dasari <vdasari@gmail.com>
Tested-by: Vasu Dasari <vdasari@gmail.com>
ofproto-dpif: Fix segfault removing port when STP is enabled.

Reported-by: Sridhar Samudrala <samudrala.sridhar@gmail.com>
Tested-by: Sridhar Samudrala <samudrala.sridhar@gmail.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
ofproto-dpif: Complete all packet translations before freeing an ofproto.

The following scenario can occur:

   1. Handler thread grabs a pointer to an ofproto in handle_upcalls().

   2. Main thread removes ofproto and destroys it in destruct().

   3. Handler thread uses pointer to ofproto and accesses freed memory.
      BOOM!

Each individual step above happens under the xlate_rwlock, but the ofproto
pointer is retained from step 1 to step 3, hence the problem.  This commit
fixes the problem by ensuring that after an ofproto is removed but before
it is destroyed, all packet translations get pushed all the way through
the upcall handler pipeline.  (No new packet translations can get a pointer
to the removed ofproto.)

Bug #1200351.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Alex Wang <alexw@nicira.com>
ofproto-dpif: Test flow stats reporting.

Basic test to check that the datapath reports the correct number of
packets seen, after a delay of 1 second.

Signed-off-by: Joe Stringer <joestringer@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
upcall: Defer ukey deletion until after pushing stats.

It is possible for a datapath to dump the same flow twice, for instance
if the flow is the last in a batch of flows to be dumped, then a new
flow is inserted into the same bucket before the flow dumper fetches
another batch.

In this case, datapath flow stats may be duplicated: The revalidator
records the stats from the first flow, using the ukey to get the stats
delta. The ukey is deleted, then the revalidator reads the second
(duplicate) flow and cannot lookup the ukey for the delta. As such, it
will push the stats as-is.

This patch reduces the likelihood of such stats duplications by
deferring ukey deletion until after stats are pushed for deleted flows.

Signed-off-by: Joe Stringer <joestringer@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
upcall: Refactor ukey creation and dump handling

This splits out functions for re-use by later patches, and compacts the
udump revalidation code.

Co-authored-by: Ethan Jackson <ethan@nicira.com>
Signed-off-by: Joe Stringer <joestringer@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>

Conflicts:
	ofproto/ofproto-dpif-upcall.c
upcall: Delete flows that were not recently dumped.

Previously, we would clean up the ukeys whose flow was not seen in the
most recent dump, while leaving the flow in the datapath. In the
unlikely case that the datapath fails to dump a flow that still exists
in the datapath, this would cause double-counting of those flow stats.

This is currently very rare to see due to batching of datapath flow
deletion, but is more easily observable with upcoming patches which
modify the batch size based on dpif implementation.

Signed-off-by: Joe Stringer <joestringer@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
upcall: Remove datapath flows when setting n-threads.

Previously, we would delete all ukeys when changing the number of
threads, but leave all flows in the datapath. This would cause
double-counting of stats for any flows that remain in the datapath. This
patch fixes the issue by ensuring that all flows are deleted from the
datapath before changing the number of threads.

Signed-off-by: Joe Stringer <joestringer@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
dpif-linux: Lookup netdev to get netdev type string.

When creating tap ports in dpif-linux, the "tap" type is treated the
same as "system", and the type is discarded. When dumping datapath
port types, this would cause "tap" type to be reported as a "system"
type.

Each time we see a port of the wrong type in bridge_reconfigure(), we
remove it and add a port with the correct configuration. This would
always occur for tap ports, causing deletion and re-creation of all tap
ports each time the bridge was reconfigured.

This patch makes dpif-linux use netdev to look up port types if the
datapath reports that they are of type OVS_VPORT_TYPE_NETDEV.

Bug #1196289.

Reported-by: James Schmidt <jschmidt@vmware.com>
Signed-off-by: Joe Stringer <joestringer@nicira.com>
Acked-by: Alex Wang <alexw@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
datapath: Correctly report flow used times for first 5 minutes after boot.

The kernel starts out its "jiffies" timer as 5 minutes below zero, as
shown in include/linux/jiffies.h:

  /*
   * Have the 32 bit jiffies value wrap 5 minutes after boot
   * so jiffies wrap bugs show up earlier.
   */
  #define INITIAL_JIFFIES ((unsigned long)(unsigned int) (-300*HZ))

The loop in ovs_flow_stats_get() starts out with 'used' set to 0, then
takes any "later" time.  This means that for the first five minutes after
boot, flows will always be reported as never used, since 0 is greater than
any time already seen.

Bug #1192516.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Pravin B Shelar <pshelar@nicira.com>
odp-util: Include tun_id when nonzero even if "key" flag not set.

When a flow_tnl is being translated to Netlink attributes, the tun_id field
was included only if the FLOW_TNL_F_KEY flag was set.  This meant that for
a mask, where one would not necessarily expect that flag to be set even if
there were a key, the tun_id could be omitted even if it were nonzero.
This led to kernel flows that did not match on a field that was required
to be matched (possibly causing incorrect treatment of packets) and
premature deletion of kernel flows due to mask mismatch.  This commit
fixes the problem.

Bug #1192516.
Reported-by: Krishna Miriyala <miriyalak@vmware.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Ethan Jackson <ethan@nicira.com>
tunnel: Do not set padding bits in tunnel mask.

On most architectures other than 32-bit x86, struct flow_tnl ends with 4
padding bytes.  Until now, tnl_xlate_init() set those bytes to nonzero
values in the wildcard mask.  When the wildcard mask passed through Netlink
attributes and back to userspace, the padding bytes of course became zero
again, which caused a wildcard mask mismatch and premature deletion of the
flow in revalidation.  This commit fixes the problem.

Bug #1192516.
Reported-by: Krishna Miriyala <miriyalak@vmware.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Ethan Jackson <ethan@nicira.com>
stp: Fix bpdu tx problem in listening state

The restriction only allows to send bpdu in forwarding state in
compose_output_action__. But a port could send bpdu in listening
and learning state according to comments in lib/stp.h(State of
an STP port).

Until this commit, OVS did not send out BPDUs in listening and learning
states.  But those two states are temporary, the stp port will be in
forwarding state and send out BPDUs eventually (In the default
configuration listening and learning states last 15+15 second).  Therefore,
this bug increased convergence time but did not entirely break STP.

Signed-off-by: kmindg <kmindg@gmail.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
ofproto-dpif: Revalidate flows when the group table changes.

Otherwise group table modifications won't be immediately reflected in the
treatment of flows already passing through the switch.

Reported-by: Hyojoon Kim <joonk@gatech.edu>
Signed-off-by: Ben Pfaff <blp@nicira.com>
Tested-by: Hyojoon Kim <joonk@gatech.edu>
cfm: Notify connectivity_seq on remote maintenance points change.

Commit f23d157c ("ofproto-dpif: Don't poll ports when nothing changes")
did not ensure the update of the row of remote maintenance points in ovsdb
when it changes.  This commit makes the update happen by notifying the
global connectivity_seq.

Bug #1192265

Signed-off-by: Alex Wang <alexw@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
Set release date for 2.1.0.

Signed-off-by: Justin Pettit <jpettit@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>