| Age | Commit message (Collapse) | Author |
|---|
|
The previous calculation was wrong when n_links was a power of 2.
Reported-by: Paul Ingram <paul@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
|
|
Unix 64-bit ABIs have two 64-bit types: "long" and "long long". Either of
these is a reasonable choice for uint64_t (the userspace type) and for
__u64 (the kernel type). Unfortunately, kernel and userspace don't
necessarily agree on the choice, and in fact the choice varies across
kernel versions and architectures.
Now that OVS is actually using kernel types in its kernel header, this
can make a difference: when __u64 and uint64_t differ, passing a pointer
to __u64 to OVS function get_unaligned_u64() yields a compiler warning
or error.
This commit fixes up the problems of this type found in OVS, by making
get_unaligned_u64() accept all 64-bit unsigned integer types, not just
whichever one happens to be uint64_t. I didn't do the same thing for
put_unaligned_u64() because it is less likely to be a problem in
practice: usually, when userspace writes to kernel data structures it
does so with copies that it knows to be aligned, so that it's not
necessary to use put_unaligned_u64().
This problem won't occur for uint8_t, uint16_t, or uint32_t, since there is
only one reasonable choice of type for each. It won't occur for ovs_be<N>
because OVS always defines those as aliases for the kernel's __be<N> types
when those are available.
This compiled cleanly for me in Scientific Linux 6.0 x86-64.
Reported-by: Pravin Shelar <pshelar@nicira.com>
|
|
There are a few loose ends here. First, learning actions cause too much
flow revalidation. Upcoming commits will fix that problem. The following
additional issues have not yet been addressed:
* Resource limits: nothing yet limits the maximum number of flows that
can be learned. It is possible to exhaust all system memory.
* Age reporting: there is no way to find out how soon a learned table
entry is due to be evicted.
To try this action out, here's a recipe for a very simple-minded MAC
learning switch. It uses a 10-second MAC expiration time to make it easier
to see what's going on:
ovs-vsctl del-controller br0
ovs-ofctl del-flows br0
ovs-ofctl add-flow br0 "table=0 actions=learn(table=1, hard_timeout=10, \
NXM_OF_VLAN_TCI[0..11], NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[], \
output:NXM_OF_IN_PORT[]), resubmit(,1)"
ovs-ofctl add-flow br0 "table=1 priority=0 actions=flood"
You can then dump the MAC learning table with:
ovs-ofctl dump-flows br0 table=1
|
|
We had these functions scattered around the source tree anyway. packets.h
is a good place to centralize them.
I do plan to introduce some additional callers.
|
|
Useful in an upcoming commit.
|
|
Calculates the position of the most significant bit in a 32 bit
word.
|
|
This follows the rules I learned in school. Some locales may prefer to
omit the comma before "and" in a list of three or more items.
|
|
sparse simply doesn't like our build assertions on packed structures.
It seems that its ideas about struct packing are different from GCC's:
../lib/cfm.h:50:1: error: invalid bitfield width, -1.
../lib/packets.h:206:1: error: invalid bitfield width, -1.
../lib/packets.h:213:1: error: invalid bitfield width, -1.
../lib/packets.h:367:1: error: invalid bitfield width, -1.
sparse isn't generating code so we don't really care how it lays out
structures. We might as well just skip the assertions, as done here.
|
|
Until now, when the poll_loop module's log level was turned up to "debug",
it would log a backtrace of the call stack for the event that caused poll()
to wake up in poll_block(). This was pretty useful from time to time to
find out why ovs-vswitchd was using more CPU than expected, because we
could find out what was causing it to wake up.
But there were some issues. One is simply that the backtrace was printed
as a series of hexadecimal numbers, so GDB or another debugger was needed
to translate it into human-readable format. Compiler optimizations meant
that even the human-readable backtrace wasn't, in my experience, as helpful
as it could have been. And, of course, one needed to have the binary to
interpret the backtrace. When the backtrace couldn't be interpreted or
wasn't meaningful, there was essentially nothing to fall back on.
This commit changes the way that "debug" logging for poll_block() wakeups
works. Instead of logging a backtrace, it logs the source code file name
and line number of the call to a poll_loop function, using __FILE__ and
__LINE__. This is by itself much more meaningful than a sequence of
hexadecimal numbers, since no additional interpretation is necessary. It
can be useful even if the Open vSwitch version is only approximately known.
In addition to the file and line, this commit adds, for wakeups caused by
file descriptors, information about the file descriptor itself: what kind
of file it is (regular file, directory, socket, etc.), the name of the file
(on Linux only), and the local and remote endpoints for socket file
descriptors.
Here are a few examples of the new output format:
932-ms timeout at ../ofproto/in-band.c:507
[POLLIN] on fd 20 (192.168.0.20:35388<->192.168.0.3:6633) at ../lib/stream-fd.c:149
[POLLIN] on fd 7 (FIFO pipe:[48049]) at ../lib/fatal-signal.c:168
|
|
This commit adds a few initial users but more are coming up.
|
|
|
|
exit(EXIT_FAILURE) will make a monitoring process (the one created by
--monitor) think that it should exit. But the most likely reason for
out_of_memory() to be called is a bug: probably, the process is trying
to allocate more memory than there is available address space, e.g.
something like malloc(-1). So it's better, in my opinion, to call abort()
instead, so that the monitor process restarts the daemon and we are more
likely to stay alive and, in addition, get a core dump and a useful bug
report.
I decided to implement a new general-purpose function for this purpose in
case we run into other similar situations in the future.
(I haven't actually run into this problem in practice. This commit is
just speculation about what is better behavior.)
|
|
Static analyzers hate strncpy(). This new function shares its property of
initializing an entire buffer, without its nasty habit of failing to
null-terminate long strings.
Coverity #10697,10696,10695,10694,10693,10692,10691,10690.
|
|
Many OVS functions return 0, EOF, or errno. There are several places in the
codebase where a return value is converted to a string. All must decide whether
the return value is set, and if it is, whether it is an errno value, EOF, or
otherwise invalid. This commit consolidates that code.
Reviewed by Ben Pfaff.
|
|
|
|
|
|
Suggested-by: Justin Pettit <jpettit@nicira.com>
|
|
|
|
This macro is a variant on CONTAINER_OF that takes an object pointer
instead of a type name as its second argument. In the following commit
this will simplify many users of CONTAINER_OF.
|
|
Signed-off-by: Joe Perches <joe@perches.com>
Acked-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Jesse Gross <jesse@nicira.com>
|
|
On sparc, GCC would issue the following warning for every use of
CONTAINER_OF:
warning: cast increases required alignment of target type
This is a false positive: assuming that the data structure that it is
applied to was allocated properly, the use of CONTAINER_OF to reach it is
valid. And if it was not allocated properly, then code that accesses it
other ways will have trouble too.
|
|
These will be used further in an upcoming commit.
|
|
|
|
Great ideas in theory, but we haven't used them.
|
|
The main change here is the need to update all of the uses of UNUSED in
the next branch to OVS_UNUSED as it is now spelled on "master".
|
|
Some systems complain when certain functions' return values are not
checked. This commit fixes those warnings.
Creating ignore() function suggested by Ben Pfaff.
|
|
|
|
This will be used by the upcoming Open vSwitch configuration database.
|
|
|
|
|
|
ROUND_UP rounds up to a multiple of a given value. That means that
bitmap_allocate() was allocating one byte for each bit in the bitmap,
which is clearly excessive.
Instead, just allocate one bit for every bit in the bitmap.
|
|
|
|
|
