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>
Windows implementation of stream-fd.

Use send/recv for socket stream instead of read/write.
Use event handle for polling on socket stream.
Check windows specific return code.

Signed-off-by: Linda Sun <lsun@vmware.com>
Signed-off-by: Gurucharan Shetty <gshetty@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>
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>
ofproto-dpif-upcall: Fix null dereference in push_dump_ops().

revalidator_sweep__() does not provide udumps, so push_dump_ops() can't
look them up.

This is my fault: I introduced it during review.

Signed-off-by: Ben Pfaff <blp@nicira.com>
tests: Sort output from dump-flows to avoid hash order dependency.

Signed-off-by: Ben Pfaff <blp@nicira.com>
socket-util: Avoid using the identical message for different errors

Signed-off-by: YAMAMOTO Takashi <yamamoto@valinux.co.jp>
Signed-off-by: Ben Pfaff <blp@nicira.com>
ofproto-dpif: Fix "sFlow packet sampling" tests on BSDs

The name of loopback interface is "lo0" on BSDs.

Signed-off-by: YAMAMOTO Takashi <yamamoto@valinux.co.jp>
Signed-off-by: Ben Pfaff <blp@nicira.com>
socket-util: Fix set_dscp for IPv6

Try IPPROTO_IPV6/IPV6_TCLASS socket option as well as IPPROTO_IP/IP_TOS
so that this can work for IPv6 sockets.

IPPROTO_IP/IP_TOS socket option is, as it's SOL indicates, for IPv4.
What happens when it's used for IPv6 sockets?  On Linux, it seems to
be forwarded to IPv4 code and affects IPv4 part of the socket.
(e.g. non-V6ONLY case)  But it doesn't seem to be the intention of
this function.  On other platforms including NetBSD, it just fails
with ENOPROTOOPT.

Probably this function should take the address family but passing
it around lib/*stream*.c would be a bigger change.

Cc: Arun Sharma <arun.sharma@calsoftinc.com>
Signed-off-by: YAMAMOTO Takashi <yamamoto@valinux.co.jp>
Signed-off-by: Ben Pfaff <blp@nicira.com>
ofproto: Send port status message for port-mods, right away.

Until now, when it processes OFPT_PORT_MOD message, Open vSwitch has waited
for ports to notify it that their status has changed before it sends a
port status update to controllers.

Also, Open vSwitch never sent port config updates at all for port
modifications other than OFPPC_PORT_DOWN.  I guess that this is a relic
from the era when there was only one controller, since presumably the
controller already knew that it changed the port configuration.  But in the
multi-controller world, it makes sense to send such port status updates,
and I couldn't quickly find anything in OF1.3 or OF1.4 that said they
shouldn't be sent.

EXT-338.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Reported-by: Kmindg G <kmindg@gmail.com>
meta-flow: Remove duplicate break statements.

Commit 8bfd0fda mistakenly introduced duplicate "break;" statements to
MFF_MPLS_BOS handling. This patch removes them.

Found by inspection.

Signed-off-by: Joe Stringer <joestringer@nicira.com>
Acked-by: Jarno Rajahalme <jrajahalme@nicira.com>
Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com>
INSTALL: Mention that building a kernel module is optional.

It used to be essentially required, but now it's reasonable to use the
kernel's builtin module.

Signed-off-by: Ben Pfaff <blp@nicira.com>
Reviewed-by: Flavio Leitner <fbl@redhat.com>
cccl: Remove the seemingly wrong "lib" prefix.

I have not seen a use case where the "lib" prefix is needed.
In my tests, I see that adding the additional "lib" prefix
causes libraries to not be recognized.

Signed-off-by: Gurucharan Shetty <gshetty@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
fatal-signal: Fatal signal handling for Windows.

Windows does not have a SIGHUP or SIGALRM. It does have
a SIGINT and SIGTERM. The documentation at msdn says that
SIGINT is not supported for win32 applications because
WIN32 operating systems generate a new thread to specifically
handle Ctrl+C.

This commit handles SIGTERM for Windows. The documentation also
states that nothing generates SIGTERM in Windows, but one can
use raise(SIGTERM) to manage it. The idea for handling SIGTERM
for Windows is to just have a place holder if there is need to
raise() a signal for some other purpose.

We use SIGALRM in timeval.c if we wake up from a sleep after
'deadline'. For Windows, print an error message and then
use SIGTERM.

There is an atexit() function for Windows, so we can call cleanup
functions during exit.

An upcoming commit separately handles Ctrl+C so that we can call
clean up functions for that use case.

Signed-off-by: Gurucharan Shetty <gshetty@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
signals: Don't compile for Windows.

There are no users in Windows for any of the
function in signals.c

Signed-off-by: Gurucharan Shetty <gshetty@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
socket-util: pipe for Windows.

Windows does have pipes (the interface is a little different).
We mostly use pipes in Linux to synchronize between parent and
children and also to handle fatal signals and then wake from poll_loop().

For Windows, we are using events for the same purpose. So don't
implement pipes for Windows.

Signed-off-by: Gurucharan Shetty <gshetty@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
fatal-signal: Handle SIGINT for Windows.

Ctrl+C signals are a special case for Windows and can
be handled by registering a handle through
SetConsoleCtrlHandler() routine. This is only useful
when we run it directly on console and not as services in
the background.

Once we get a Ctrl+C signal, we call the cleanup functions
and then exit.

One thing to know here is that MinGW terminal handles
Ctrl+C signal differently (and looks a little buggy. I see
it exiting the handler midway with some sort of timeout).
So this implementation is only useful when run on Windows
terminal. Since we only use MinGW for compilation and
eventually to run unit tests, it should be okay. (The unit
tests would ideally use windows services and not expect
Ctrl+C)

Signed-off-by: Gurucharan Shetty <gshetty@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>