ovs-vswitchd: Don't register for SIGHUP.

We are registering an interest in SIGHUP to reopen
log files. But there is an 'ovs-appctl vlog/reopen'
command that does the same and is used in the
logrotate config for the distributions.

So remove the redundant functionality.

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

Signed-off-by: Gurucharan Shetty <gshetty@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
lib/process, socket-util: Update necessary headers

Fix the regression introduced by commit 4f57ad10.
("socket-util: Move get_max_fds() to process.c")

Signed-off-by: YAMAMOTO Takashi <yamamoto@valinux.co.jp>
Signed-off-by: Gurucharan Shetty <gshetty@nicira.com>
socket-util: drain_rcvbuf() for Windows.

Netlink sockets are created as blocking sockets. So, we can't
afford to remove MSG_DONTWAIT for Linux.

drain_rcvbuf() is currently called from netlink-socket.c and
netdev-linux.c. As of now, I don't see it being used for Windows.

Bug #1200865.
Reported-by: Len Gao <leng@vmware.com>
Signed-off-by: Gurucharan Shetty <gshetty@nicira.com>
Acked-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>
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>