| Age | Commit message (Collapse) | Author |
|---|
|
If the last receive time for a remote MP was before the last fault
check, the CFM code would not declare a fault. This is, of course,
exactly the wrong response.
Bug #5303.
|
|
CFM configuration requires the ofproto_run function to have been
executed at least once in order to guarantee that the relevant
ports exist.
Bug #5303.
|
|
|
|
|
|
Before this patch the kernel chose the lowest available number for
newly created datapath ports. This patch moves the port number
choosing responsibility to user space, and implements a least
recently used port number queue in an attempt to avoid reuse.
Bug #2140.
|
|
ovs-xapi-sync is supposed to always keep external-ids:iface-id up to date,
but in fact it would only set it when an interface initially appeared. If
the interface quickly disappeared and reappeared, then it failed to notice
that iface-id had changed or disappeared. This happens in practice on
Citrix XenServer, where VM "tap" devices often disappear and then reappear
almost immediately during VM boot. This commit fixes the problem.
This also fixes the similar problem for external-ids:bridge-id in Bridge
records. Bridges aren't ordinarily destroyed and re-created quickly, so
this problem might never have manifested in practice for bridges.
Many thanks to Reid Price <reid@nicira.com> for identifying the problem
and supplying an initial fix.
Bug #5239.
Reported-by: Henrik Amren <henrik@nicira.com>
|
|
Sometimes lockfile will emit a message saying that it took a little while
to get the lock, which caused spurious test failures. This commit
suppresses the message. With this change, I was able to run these tests
continuously for some time without failures.
This was a bug in the testsuite, not in the code under test.
|
|
Before this (and the previous) patch, whenever cfm_configure was
called it would set the fault_timer to expired. Thus, the next
call to cfm_run would notice a lack of CCM reception and trigger a
faulted status. This is a bug in and of itself, but normally would
not be a big deal because cfm_configure should only be called
infrequently (when the database changes). However due to an
unrelated bug, cfm_configure() was getting called approximately once
per second. This resulted in all monitors showing faults all of
the time.
This patch fixes the problem by not expiring the timer at
cfm_configure(). Instead it gives it the appropriate
fault_interval amount of time to miss heartbeats.
Bug #5244.
|
|
Calling cfm_configure often could cause timers to be reset
resulting in unexpected behavior. This commit only updates when
cfm configuration actually changed.
Bug #5244.
|
|
When ovsdb-server reads a database file that is corrupted at the
transaction level (that is, the transaction is valid JSON and has the
correct SHA-1 hash, but it does not describe a valid database transaction),
then ovsdb-server should truncate it and overwrite it by valid
transactions. However, until now, it didn't. Instead, it would keep the
invalid transaction and possibly every transaction in the database file
(depending on in what way the transaction was invalid), which would just
cause the same trouble again the next time the database was read.
This fixes the problem. An invalid transaction will be deleted from the
database file at the first write to the database.
Bug #5144.
Bug #5149.
|
|
When ovsdb-server reads a database that is corrupted at the log level
(that is, when ovsdb_log detects the corruption by checking the SHA-1 hash
of the record or JSON parser error reporting), then writing to the database
should discard the corrupted data and thereby fix the problem for future
ovsdb-server runs.
This already worked OK. This just adds an extra test.
|
|
If there's database corruption then it indicates that something went wrong,
e.g. the machine was powered-off by power failure. It's definitely
something that the admin should know about. This sounds like an error to
me, so use that log level.
|
|
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.
|
