| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a strong reference to a non-root table is ephemeral, the database log
can contain inconsistencies. In particular, if the column in question is
the only reference to a row, then the row will be created in one logged
transaction but the reference to it will not be logged (because it is
ephemeral). Thus, any later occurrence of the row later in the log (to
modify it, to delete it, or just to reference it) will yield a transaction
error and reading the database will abort at that point.
This commit fixes the problem by forcing any column with a strong reference
to a non-root table to be persistent.
The change to ovsdb_schema_from_json() looks bigger than it really is: it
just swaps the order of two operations on the schema and updates their
comments. Similarly for the update to ovs.db.DbSchema.__init__().
Bug #5144.
Reported-by: Sujatha Sumanth <ssumanth@nicira.com>
Bug #5149.
Reported-by: Ram Jothikumar <rjothikumar@nicira.com>
|
| |
|
|
|
|
|
|
|
|
| |
This function only worked properly inside OVSDB itself, because that is
the only place where the 'refTable' member of ovsdb_base_type is set.
Both inside and outside OVSDB, 'refTableName' is set for reference types,
so it's better to check for that.
This doesn't fix any existing bug because this function was only used
inside OVSDB until now.
|
| | |
|
| | |
|
| |
|
|
| |
Also deletes svec_split() since this was the only user.
|
| | |
|
| |
|
|
| |
Should be slightly cheaper than sorting a list (O(n) vs. O(n lg n)).
|
| | |
|
| | |
|
| |
|
|
|
|
| |
In each of the cases converted here, an shash was used simply to maintain
a set of strings, with the shash_nodes' 'data' values set to NULL. This
commit converts them to use sset instead.
|
| |
|
|
|
|
| |
Many uses of "shash" or "svec" data structures really call for a "set of
strings" data type. This commit introduces such a data structure. Later
commits convert inappropriate uses of shash and svec to use sset instead.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Scattered throughout the code base we use long integers to
implement timers. When the result of timer_msec() is greater than
the time stored, we preform some action.
This commit creates a new timer library intended to replace these
manually managed timers. Code using the timer library will be more
obviously correct, and more consistent with other code using the
library.
|
| |
|
|
|
| |
When the cfm module has never received a bad CCM message, it would
report a negative time.
|
| |
|
|
|
| |
Otherwise the ofproto's attempt to flush flows from the dpif will fail with
an error, causing a spurious log message.
|
| |
|
|
| |
Fixes a segfault when fail-open goes into effect.
|
| |
|
|
|
|
|
|
|
| |
ofproto_flush_flows() calls into the connmgr (via connmgr_flushed()) so
it must be called before destroying the connmgr to avoid a use-after-free
error.
Bug #5231.
Reported-by: Krishna Miriyala <krishna@nicira.com>
|
| |
|
|
|
|
|
|
|
| |
Update for flowi4 and ip_route_output_flow() changes
in 2.6.39-rc1.
Signed-off-by: Simon Horman <horms@verge.net.au>
[Jesse: drop redundant unlikely() from IS_ERR()]
Signed-off-by: Jesse Gross <jesse@nicira.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
My original intent for ofpbufs initialized with ofpbuf_use_stack() was that
the caller was providing enough space on the stack for the common case,
with dynamic allocation as a fallback. But in practice, none of the
clients actually do this. Instead, all of them actually know that the
stack-allocated buffer is big enough and, since they don't want to bother
with having to call ofpbuf_delete(), they instead assert that the buffer
wasn't reallocated.
Since this is a bit of a pain, this commit changes the semantics of
ofpbuf_use_stack() to be that the stack-allocated buffer cannot be
reallocated at all. This is more convenient for the existing clients.
|
| |
|
|
| |
This seems to me to better encapsulate the inherent ugliness.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
We've noticed that packets that go up to userspace and then back down to
the kernel and then enter an GRE tunnel that is then ESP encapsulated
by IPSEC end up with a bad ESP "next header" value: it ends up as zero
instead of 0x2f (IPPROTO_GRE). Just putting packets from userspace into
a freshly allocated skb fixes the problem.
The underlying problem that this works around is still unknown.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Jesse Gross <jesse@nicira.com>
Bug #4769.
|
| |
|
|
|
| |
The lock is asserted if its expiration time has not arrived yet, not the
reverse.
|
| | |
|
| |
|
|
|
| |
Nothing uses these anymore. ofputil_decode_flow_stats_reply() is a better
alternative.
|
| |
|
|
|
|
|
|
|
|
|
| |
When poll interval-based logging was introduced a long time, we were
actively interested in looking at almost every long poll interval. But
these days, with OVS working rather well, with pretty good latency, most
of the messages are red herrings that bother some administrators and
provoke false reports. So this commit suppresses all but the most
egregious long poll intervals that may in fact be worth looking at.
NIC-366.
|
| | |
|
| | |
|
| |
|
|
|
| |
This removes a lot of code from ofproto.c and makes the ofproto code
easier to understand.
|
| |
|
|
|
| |
This helps to increase the level of abstraction of "struct ofconn",
in preparation for moving it from ofproto.c into a new file.
|
| |
|
|
|
| |
This helps to increase the level of abstraction of "struct ofconn",
in preparation for moving it from ofproto.c into a new file.
|
| |
|
|
|
| |
This helps to increase the level of abstraction of "struct ofconn",
in preparation for moving it from ofproto.c into a new file.
|
| |
|
|
|
| |
This helps to increase the level of abstraction of "struct ofconn",
in preparation for moving it from ofproto.c into a new file.
|
| |
|
|
|
| |
This helps to increase the level of abstraction of "struct ofconn",
in preparation for moving it from ofproto.c into a new file.
|
| |
|
|
|
| |
This helps to increase the level of abstraction of "struct ofconn",
in preparation for moving it from ofproto.c into a new file.
|
| |
|
|
|
| |
This removes some code from ofproto.c that doesn't really seem to
belong there to begin with.
|
| |
|
|
| |
This removes some code from ofproto.c.
|
| |
|
|
| |
This removes some code from ofproto.c.
|
| |
|
|
|
| |
Noticed this last night while playing around with the clang static
analyzer.
|
| |
|
|
| |
Coverity #10710.
|
| |
|
|
|
|
|
|
|
|
| |
The test ofproto_has_primary_controller() is meaningless, since OFPP_NORMAL
can cause the MAC learning table and port bonding to be in use even when
there is a controller.
I see that this bug has been here since early 2009, when the OFPP_NORMAL
feature was introduced in the bridge. (Obviously it's not a severe
problem.)
|
| |
|
|
|
|
|
|
|
|
|
|
| |
It seems possible that "restart" or a quick application of "stop" then
"start" could kill ovs-xapi-sync without starting it again, if
ovs-xapi-sync takes a little while to die, long enough for the next
instance of it to see that its pidfile is still open and locked.
I hope that this fixes some odd races that we've noticed in the "restart"
command.
Signed-off-by: Ben Pfaff <blp@nicira.com>
|
| |
|
|
|
| |
This function substantially duplicated read_pidfile(), so reuse that
code instead.
|
| |
|
|
|
| |
Otherwise it's hard to diagnose later if the daemon failed to start because
it thinks that it is already running.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Ben pointed out that an attacker could cause OVS to use infinite
memory by sending a series of CCMs with different MAIDs. Each
message would cause a remote_maid to be allocated and stored for
several seconds.
Since Commit 1c2e2d2fc8 (cfm: Don't report unexpected remote
endpoints) no longer reports unexpected remote MAIDS and MPs in the
database, the only reason to keep track of this information is for
debugging purposes. In my judgment, it provides negligible useful
debugging information at the expense of significantly increased
code complexity. This commit rips it out entirely.
|
| |
|
|
| |
Reported-by: Paul Ingram <paul@nicira.com>
|