ofproto-dpif-sflow: Fix memory leak.

dpif_sflow_set_options() uses xcalloc() to allocate space for the SFLAgent
structure, but nothing ever freed it.  This fixes the problem.

Found by valgrind.

Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Ethan Jackson <ethan@nicira.com>
Use "error-checking" mutexes in place of other kinds wherever possible.

We've seen a number of deadlocks in the tree since thread safety was
introduced.  So far, all of these are self-deadlocks, that is, a single
thread acquiring a lock and then attempting to re-acquire the same lock
recursively.  When this has happened, the process simply hung, and it was
somewhat difficult to find the cause.

POSIX "error-checking" mutexes check for this specific problem (and
others).  This commit switches from other types of mutexes to
error-checking mutexes everywhere that we can, that is, everywhere that
we're not using recursive mutexes.  This ought to help find problems more
quickly in the future.

There might be performance advantages to other kinds of mutexes in some
cases.  However, the existing mutex type choices were just guesses, so I'd
rather go for easy detection of errors until we know that other mutex
types actually perform better in specific cases.  Also, I did a quick
microbenchmark of glibc mutex types on my host and found that the
error checking mutexes weren't any slower than the other types, at least
when the mutex is uncontended.

Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Ethan Jackson <ethan@nicira.com>
coverage: Make thread-safe.

This makes each of the coverage counters per-thread.  It abandons the
idea of trying to keep track of the number of hits in the "current" poll
loop, since there are many poll loops running, each in its own thread, as
well as the idea of numbering epochs for the same reason.  Instead, we
just keep track of overall totals for the process for each coverage
counter, accumulating per-thread counts into the global total each time
a thread's main loop passes through poll_block().

Signed-off-by: Ben Pfaff <blp@nicira.com>
bfd: Implement BFD decay.

When there is no incoming data traffic at the interface for a period,
BFD decay allows the bfd session to increase the min_rx. This is
helpful in that some interfaces may usually be idle for a long time.
And cpu consumption can be reduced by processing fewer bfd control
packets.

Signed-off-by: Alex Wang <alexw@nicira.com>
Signed-off-by: Ethan Jackson <ethan@nicira.com>
Acked-by: Ethan Jackson <ethan@nicira.com>
ofproto-dpif: Enable smooth transition between CFM and BFD.

When user switches between using CFM and BFD, there will be a short
down time before the new protocol goes up.  This can unintentionally
change the traffic pattern of the bundled ports.  To prevent this,
it is proposed that user can enable both CFM and BFD before transition,
wait for the new protocol to go up, and then disable the old protocol.

To make this scheme work, this commit modifies the port_run() in
ofproto-dpif.c, so that when both CFM and BFD are used, if either shows
correct status, the port is considered usable in the bundle.

Signed-off-by: Alex Wang <alexw@nicira.com>
ovs-atomic: atomic_load() must take a non-const argument.

C11 says that atomic_load() requires a non-const argument, and Clang
enforces that.  This fixes warnings with FreeBSD <stdatomic.h> that uses
the Clang extensions.

Reported-by: Ed Maste <emaste@freebsd.org>
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Ed Maste <emaste@freebsd.org>
ovs-atomic: Fix typo in comment.

Signed-off-by: Ben Pfaff <blp@nicira.com>
ovs-atomic: Add native Clang implementation.

With this implementation I get warnings with Clang on GNU/Linux when the
previous patch is not applied.  This ought to make it easier to avoid
introducing new problems in the future even without building on FreeBSD.

Signed-off-by: Ben Pfaff <blp@nicira.com>
ovs-thread: Work around apparent Clang bug.

Without this patch, I get Clang warnings that I don't understand for each
of the non-static functions in dirs.c:

    warning: control reaches end of non-void function

I get the same warning for this test program with "clang -c -Wall":

    struct foo {
         const char *y;
        _Atomic(int) x;
    };

    const char *
    bar(const struct foo *fp)
    {
       return fp->y;
    }

    const char *f(void)
    {
        static struct foo f = {"xyzzy", 0};
        return bar(&f);
    }

If I change {"xyzzy", 0} to just {"xyzzy"}, the warning goes away, and the
same is true for the current patch.

Signed-off-by: Ben Pfaff <blp@nicira.com>