This lets us call ovs_lasterror_to_string() and not having
to do an extra call of LocalFree() on the returned string.
Signed-off-by: Gurucharan Shetty <gshetty@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
Start with a simple implementation that does not support
symbolic links.
Signed-off-by: Gurucharan Shetty <gshetty@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
Found by Clang.
Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Ethan Jackson <ethan@nicira.com>
This commit adds annotations for thread safety check. And the
check can be conducted by using -Wthread-safety flag in clang.
Co-authored-by: Alex Wang <alexw@nicira.com>
Signed-off-by: Alex Wang <alexw@nicira.com>
Signed-off-by: Ethan Jackson <ethan@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
lockfile_lock() accepts a timeout argument but, aside from unit tests
pertaining to timeout, its value is always 0. Since this feature relies on
a periodic SIGALRM signal, which is not a given if we're not caching time,
the cleanest solution is just to remove it.
Signed-off-by: Leo Alterman <lalterman@nicira.com>
As the database is being transitioned from /etc to /var, there is a symlink
from the old to the new location for the database and a symlink for its
lockfile. This works OK, but it would be more user-friendly to still work
correctly in case the symlink for the lockfile isn't there (since its
existence is non-obvious), so this commit implements that behavior.
Signed-off-by: Ben Pfaff <blp@nicira.com>
open() with O_CREAT|O_EXCL yields EEXIST if the file being opened is a
symlink. lockfile_try_lock() interpreted that error code to mean that
some other process had created the lock file in the meantime, so it went
around its loop again, which found out the same thing, which led to a hang.
This commit fixes the problem by dropping O_EXCL. I don't see any reason
that it's actually necessary. That means that the loop itself is
unnecessary, so this commit drops that too.
Debian bug #681880.
CC: 681880@bugs.debian.org
Reported-by: Bastian Blank <waldi@debian.org>
Signed-off-by: Ben Pfaff <blp@nicira.com>
Reviewed-by: Simon Horman <horms@verge.net.au>
Replaced all instances of Nicira Networks(, Inc) to Nicira, Inc.
Feature #10593
Signed-off-by: Raju Subramanian <rsubramanian@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
This code issues a warning if obtaining a lock takes even 1 millisecond.
That's far too aggressive. There's no need to warn if we have to wait
a few milliseconds. This function already warns elsewhere if locking takes
more than 1 second, which is much more reasonable.
This change allows us to test ovsdb-server stderr output more carefully.
Before now, the tests had to ignore what ovsdb-server writes to stderr
because sometimes it would log a warning that locking took 1 ms (or so).
Reviewed-by: Simon Horman <horms@verge.net.au>
Until now, the collection of coverage counters supported by a given OVS
program was not specific to that program. That means that, for example,
even though ovs-dpctl does not have anything to do with mac_learning, it
still has a coverage counter for it. This is confusing, at best.
This commit fixes the problem on some systems, in particular on ones that
use GCC and the GNU linker. It uses the feature of the GNU linker
described in its manual as:
If an orphaned section's name is representable as a C identifier then
the linker will automatically see PROVIDE two symbols: __start_SECNAME
and __end_SECNAME, where SECNAME is the name of the section. These
indicate the start address and end address of the orphaned section
respectively.
Systems that don't support these features retain the earlier behavior.
This commit also fixes the annoyance that files that include coverage
counters must be listed on COVERAGE_FILES in lib/automake.mk.
This commit also fixes the annoyance that modifying any source file that
includes a coverage counter caused all programs that link against
libopenvswitch.a to relink, even programs that the source file was not
linked into. For example, modifying ofproto/ofproto.c (which includes
coverage counters) caused tests/test-aes128 to relink, even though
test-aes128 does not link again ofproto.o.
Adding a macro to define the vlog module in use adds a level of
indirection, which makes it easier to change how the vlog module must be
defined. A followup commit needs to do that, so getting these widespread
changes out of the way first should make that commit easier to review.
Waiting for a lockfile can cause mysterious pauses for users. Logging a
warning to the console every so often gives them feedback on what is
happening.
Reported-by: Justin Pettit <jpettit@nicira.com>
