This patch fixes a possible lock-up bug where rtnl_lock might not
get released.
Acked-by: Jesse Gross <jesse@nicira.com>
Signed-off-by: Ansis Atteka <aatteka@nicira.com>
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>
As part of the bridge's main loop, it queries the STP status of all
ports. If the port doesn't exist, log files can become filled with
warning messages. This situation is very unusual, since system devices
do not normally disappear, but it's easy enough to rate-limit these
messages.
Bug #10936
Reported-by: Reid Price <reid@nicira.com>
Signed-off-by: Justin Pettit <jpettit@nicira.com>
The paragraph near the end that starts out "However, unlike OpenFlow 1.1,
..." seems to correctly document OVS behavior, but it also seems like
pretty lousy behavior. Justin says that he's going to fix it before we
put out an OVS release version with this behavior.
CC: Justin Pettit <jpettit@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
This should make it more obvious when the admin needs to restart a DHCP
client (or other daemon). Without this, unless the admin carefully reads
the documentation, the first notice he gets about a need to restart the
DHCP client can easily be when the lease expires and the machine drops off
the network.
Bug #5391.
Tested-by: Gurucharan Shetty <gshetty@nicira.com>
Suggested-by: Duffie Cooley <dcooley@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
Before idle_age and hard_age were added, in the absence of timeouts there
was a space between the statistics for a flow and the start of the flow
match. This restores that space.
Requested-by: Paul Ingram <paul@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
Otherwise occasionally during debugging it can hard to figure out why a
controller connection seemed to drop for a while (when in fact it happened
because the configuration changed).
Suggested-by: Natasha Gude <natasha@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
The information output by "ovs-vsctl show" is a subset of that available
elsewhere in bugtool output, but it is human-readable instead of needing
to be processed through ovsdb-server or ovsdb-tool, so it is much more
convenient for basic diagnosis.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Currently, when we upgrade the userspace rpm for XenServer,
we print a message asking users to reboot the hypervisor.
This is not needed. The reboot of hypervisor is needed when
we upgrade the rpm containing the kernel module. This
reboot can sometimes be avoided by running a
"service openvswitch force-reload-kmod".
Signed-off-by: Gurucharan Shetty <gshetty@nicira.com>
Before this patch, rconn_send() would delete 'b' on success, and
not on error. This is confusing and error-prone. This patch
causes rconn_send() to always delete 'b'.
Signed-off-by: Ethan Jackson <ethan@nicira.com>
I've had a few complaints that ovs-vswitchd logs its coverage counters
at WARN level, but this is mainly wrong: ovs-vswitchd only logs coverage
counters at WARN level when the "coverage/log" command is used through
ovs-appctl. This was even documented.
The reason to log at such a high level was to make it fairly certain that
these messages specifically requested by the admin would not be filtered
out before making it to the log. But it's even better if the admin just
gets the coverage counters as a reply to the ovs-appctl command. So that
is what this commit does.
This commit also improves the documentation of the ovs-appctl command.
Signed-off-by: Ben Pfaff <blp@nicira.com>
I'd always assumed that the exponentially weighted moving average code in
timeval was enough rate-limiting, but I actually encountered a pathological
case some time ago that forced this coverage information to print once a
second or so, which seems too often.
Signed-off-by: Ben Pfaff <blp@nicira.com>
I'd always assumed that the exponentially weighted moving average code
here was sufficient rate-limiting, but I actually encountered a
pathological case some time ago that forced this rusage information to
print once a second or so, which seems too often.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Until now, fault status changes just log the new status. This means that
the administrator has to find two consecutive status change messages to
see what actually changed.
This commit changes the log message format to prefix new faults with '+'
and faults that disappeared with '-'. Existing faults that are still
present are not prefixed.
This also simplifies the code a little by making ds_put_cfm_fault()
put spaces before fault names instead of after.
Signed-off-by: Ben Pfaff <blp@nicira.com>
When json_lex_input() returns false, the parser does not consume the byte
passed in. That byte will get processed again in the next iteration of
the json_parser_feed() loop. Therefore, until now, this code has
double-counted bytes that cause a false return from json_lex_input().
This fixes the problem. Every input byte is now counted only once.
Signed-off-by: Ben Pfaff <blp@nicira.com>
jsonrpc_recv() could take an unbounded amount of CPU time as long as data
kept arriving, preventing other work from taking place. This limits the
amount of work to processing at most 25 kB of received data and then
yielding to the caller.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Add oxm_name and oxm_header elements to struct mf_field
and populate those entries for fields that are present
in both NXM and the OXM basic class.
This implementation was suggested by Ben Pfaff.
This does not address any possible differences in the NXM and
OXM basic class fields, for instance different maskability.
That may be addressed later as needed.
Signed-off-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Ben Pfaff <blp@nicira.com>
These oxm_type definitions values will may be used
when parsing serialising OXM TLVs.
Signed-off-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Ben Pfaff <blp@nicira.com>
This corrects errors that appear to have been included
by me in the original version.
Signed-off-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Ben Pfaff <blp@nicira.com>
iface_create() did its work in an order that meant it had to do a lot more
cleanup on error paths than is otherwise needed. This commit reorders the
work to avoid this extra cleanup.
bridge_ofproto_port_del() is no longer used after the refactoring so this
commit deletes it.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Commit bae7208e91 (bridge: Refactor bridge_reconfigure().) introduced
a regression in bridge reconfiguration. Previously, reconfiguration would
update the configuration of each bridge port, so that if the controller
(or the admin) changed a port's options, then that change would propagate
to the datapath. Following that commit, that no longer happened.
This commit restores that feature.
Bug #10972.
Reported-by: Michael Hu <mhu@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
This is the minimal change that gets the job done. There are much nicer
ways to do this, but I'll leave that refactoring for later in the series.
The return value will have its first user in an upcoming commit.
Signed-off-by: Ben Pfaff <blp@nicira.com>
The calculation that this function does will need to be used in a
context where no "struct iface" is available in an upcoming commit.
Signed-off-by: Ben Pfaff <blp@nicira.com>
This issue has been around for quite some time. It doesn't really
cause problems beyond some spurious warnings.
Signed-off-by: Ethan Jackson <ethan@nicira.com>
The existing bridge_reconfigure() implementation is suboptimal.
When adding lots of new ports, on every pass through the run loop
it allocates a bunch of "struct iface"s and "struct port"s, only to
destroy them when out of time. Additionally, when there are errors
adding or deleting ports, it can fail to converge. Instead it will
attempt and fail to add the same set of ports forever.
This patch rewrites bridge_reconfigure() using a new strategy.
Whenever the database changes, some initial bookkeeping is done,
and a list of future work is compiled. The bridge begins whittling
down this list, and stops processing database changes until
finished.
Bug #10902.
Signed-off-by: Ethan Jackson <ethan@nicira.com>
With "check-valgrind" the test can take more than 10 seconds to run, so
replacing only a single trailing digit with ? ends up with 1? which causes
the test to fail.
Signed-off-by: Ben Pfaff <blp@nicira.com>
update_port() can delete the port for which it is called, if the underlying
network device has been destroyed, so HMAP_FOR_EACH is unsafe in
ofproto_run().
Less obviously, update_port() can delete unrelated ports. For example,
suppose that initially device A is port 1 and device B is port 2. If
update_port("A") runs just after this, then it will ofport_remove() both
ports, then ofport_install() A as the new port 2.
So this commit first assembles a list of ports to update, then updates them
in a separate loop.
Without this commit, running "ovs-dpctl del-dp" while ovs-vswitchd is
running consistently causes a crash for me within a few seconds.
Signed-off-by: Ben Pfaff <blp@nicira.com>
There's no need to log this to the on-disk database.
Spotted while examining "ovsdb-tool show-log" output.
Reported-by: Ethan Jackson <ethan@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
