When use gre vport, openvswitch register a gre_cisco_protocol but
does not supply a err_handler with it. The gre_cisco_err() in
net/ipv4/gre_demux.c expect err_handler be provided with the
gre_cisco_protocol implementation, and call ->err_handler() without
existence check, cause the kernel crash.
This patch provide a err_handler to fix this bug.
Signed-off-by: Wei Zhang <asuka.com@163.com>
Signed-off-by: Jesse Gross <jesse@nicira.com>
Flow statistics need to take into account the TCP flags from the packet
currently being processed (in 'key'), not the TCP flags matched by the
flow found in the kernel flow table (in 'flow').
This bug made the Open vSwitch userspace fin_timeout action have no effect
in many cases.
Bug #1219516.
Reported-by: Len Gao <leng@vmware.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Jarno Rajahalme <jrajahalme@nicira.com>
Acked-by: Jesse Gross <jesse@nicira.com>
Direct use of 'data', 'base', and 'size' will break DPDK builds. Try
to wean us off the habit by renaming the fields.
Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com>
Acked-by: Alex Wang <alexw@nicira.com>
A recent commit reintroduced some direct use of the ofpbuf 'data' and
'size'. Use the access API instead.
Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com>
Acked-by: Alex Wang <alexw@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
Infrastructure to enable megaflow support for bond ports using
recirculation. This patch adds the following features:
* Generate RECIRC action when bond can benefit from recirculation.
* Populate post recirculation rules in a hidden table. Currently table 254.
* Uses post recirculation rules for bond rebalancing
* A recirculation implementation in dpif-netdev.
The goal of this patch is to be able to megaflow bond outputs and
thus greatly improve performance. However, this patch does not
actually improve the megaflow generation. It is left for a later commit.
Signed-off-by: Andy Zhou <azhou@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
Otherwise you get a fairly obscure message about a lockfile already being
locked.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Alex Wang <alexw@nicira.com>
The test "ovsdb-server combines updates on backlogged connections" first
checks that ovsdb-server can combine transactions, and then checks that
it can keep them separate. The latter part is hard to force because it
requires making sure that the socket buffer never fills up, and it also
isn't a very useful test (it doesn't check for any kind of correctness).
Therefore, this commit removes it.
Reported-by: YAMAMOTO Takashi <yamamoto@valinux.co.jp>
Acked-by: YAMAMOTO Takashi <yamamoto@valinux.co.jp>
Signed-off-by: Ben Pfaff <blp@nicira.com>
A call to ofpbuf_put() may cause the data of the passed to be resized and
its base address to change. Thus the address returned by ofpbuf_put()
should be used as the base address rather than relying on the base address
prior to ofpbuf_put().
This avoids the following assertion in ofpact_update_len() from failing
when ofpbuf_put() causes a resize in parse_note(), parse_noargs_dec_ttl(),
parse_dec_ttl().
ovs_assert(ofpact == ofpacts->frame);
This restores pointer updates removed by and resolves a regression
introduced by cf3b753866 ("ofpbuf: Abstract 'l2' pointer and document
usage conventions.").
Test cases have also been added to exercise this buffer resize in
parse_note(), parse_noargs_dec_ttl(), parse_dec_ttl().
Signed-off-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com>
These tests invokes ovs-ofctl monitor twice or more.
Because "ovs-appctl -t ofctl exit" does not wait for the target
process exit, there are chances to see the pid file from the previous
incarnation.
OVS_APP_EXIT_AND_WAIT macro was provided by Ben Pfaff.
Acked-by: Ben Pfaff <blp@nicira.com>
Co-authored-by: Ben Pfaff <blp@nicira.com>
Signed-off-by: YAMAMOTO Takashi <yamamoto@valinux.co.jp>
The body of an OpenFlow error message often contains an inner OpenFlow
message, and when it does, the inner message starts at an odd multiple of 4
bytes from the beginning of the outer message. That means that, on RISC
systems, accessing the inner message directly causes a bus error. This
commit fixes the problem in a way that should make it difficult to recur.
This fixes the failure of tests 643, 645, and 651 on sparc seen here:
https://buildd.debian.org/status/fetch.php?pkg=openvswitch&arch=sparc&ver=2.1.0%2Bgit20140325-1&stamp=1396438624
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Jarno Rajahalme <jrajahalme@nicira.com>
One case in the dpif_netdev_mask_from_nlattrs() function accidentally
wildcarded only a 16-bit subset of the mask's odp_port. On little-endian
machines this subset was the lower bits, which happened to work out OK,
but on big-endian machines this subset was the upper bits, which doesn't
work and causes a test failure. (The problem was actually visible in the
test expected results on little-endian machines, but we had not noticed.)
This commit unwildcards the whole field, fixing the problem, and updates
the test expected results to match.
This fixes the failure of test 732 seen here:
https://buildd.debian.org/status/fetch.php?pkg=openvswitch&arch=sparc&ver=2.1.0%2Bgit20140325-1&stamp=1396438624
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Jarno Rajahalme <jrajahalme@nicira.com>
Also, add some clarifications relative to RFC 7047 to ovsdb-server(1).
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Justin Pettit <jpettit@nicira.com>
Since the dp_hash will often be a hash of the 5 tuple, it makes sense
to put it with the L4 header so it hits in the last classifier lookup
stage.
Signed-off-by: Ethan Jackson <ethan@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
Acked-by: Andy Zhou <azhou@nicira.com>
This commit fixes the "return discards 'const' qualifier
from pointer target type" warning issued when compiling
test-reconnect.c.
Signed-off-by: Alex Wang <alexw@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
Visual studio does not like it.
This commit is similar to commit 3815d6c2c
(Avoid designated initializers and static decls of arrays
of unknown size.) but touches more files.
Signed-off-by: Gurucharan Shetty <gshetty@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
Until now, jsonrpc_recv() used separate iterations of its loop to receive
data, feed it to the JSON-RPC parser, and return the received message.
This is unnecessarily complicated and can occasionally mean that the
jsonrpc object has received and parsed but not returned a message. This
commit refactors the code to receive data, feed it to the parse, and
return the received message in a single iteration, and simplifies the code
in the process.
Reported-by: Chris Hydon <chydon@aristanetworks.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
OpenFlow 1.1 and 1.2 specify that if a table-miss occurs then the default
behaviour is to forward the packet the controller using a packet-in
message. And until this patch this is the default behaviour that Open
vSwitch uses for all OpenFlow versions.
OpenFlow1.3+ specifies that if a table-miss occurs then the default
behaviour is simply to drop the packet. This patch implements this
behaviour using the following logic:
If a table-miss occurs and the table-miss behaviour for the table
has not been set using a table_mod (in which case it is no longer
the default setting) then:
* Installing a facet in the datapath with a drop action in the
if there are no pre-OF1.3 controllers connected which would receive
an packet_in message.
Note that this covers both the case where there are only OF1.3
controllers and the case where there are no controllers at all.
* Otherwise sent a packet_in message to all pre-OF1.3 controllers.
This covers both the case where there are only pre-OF1.3
controllers and there are both pre-OF1.3 and OF1.3+ controllers.
Signed-off-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Ben Pfaff <blp@nicira.com>
Add support for building the in-tree kernel datapath for
Linux kernels up to 3.13. There were some changes in the
netlink area which required adding new compatibility code
for this layer. Also, some new per-cpu stats initialization
code was added.
Based on patch from Kyle Mestery.
Signed-off-by: Kyle Mestery <mestery@noironetworks.com>
Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
Acked-by: Kyle Mestery <mestery@noironetworks.com>
It should be an administrator task to bring up devices as they
are configured properly.
Currently, Fedora is deleting the bridges when the interface is
brought down. Therefore, there is no bridge on the next boot and
the initscripts can apply the networking configuration properly
for a new bridge.
However, if the system didn't execute ifdown for some reason, the
bridge is left in the ovsdb and since internal ports are brought
up by default, there is no way for initscripts to known if the
adminitrator has already configured it or not.
This patch reverts commit bef071a5fd
(bridge: Always "up" internal devices.).
Signed-off-by: Flavio Leitner <fbl@redhat.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
Rename 'l2' to 'frame' and add new ofpbuf_set_frame() and ofpbuf_l2().
ofpbuf_set_frame() alse resets all the layer offsets. ofpbuf_l2()
returns NULL if the packet has no Ethernet header, as indicated either
by unset l3 offset or NULL frame pointer. Callers of ofpbuf_l2() are
supposed to check the return value, unless they can otherwise be sure
that the packet has a valid Ethernet header.
The recent commit 437d0d22 made some assumptions that were not valid
regarding the use of the 'l2' pointer in rconn module and by
compose_rarp(). This is now fixed as follows: rconn now relies on the
fact that once OpenFlow messages are given to rconn for transport, the
frame pointer is no longer needed to refer to the OpenFlow header; and
compose_rarp() now sets the frame pointer and offsets as expected.
In addition to storing network frames, ofpbufs are also used for
handling OpenFlow messages and action lists. lib/ofpbuf.h now has a
comment documenting the current usage conventions and invariants.
Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
Code reads better without the "get", for example "ofpbuf_l3()"
v.s. "ofpbuf_get_l3()". L4 payoad access functions still use the
"get" (e.g., "ofpbuf_get_tcp_payload()").
Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com>
Improve link speed by linking 29 test programs into ovstest.
On my machine, running the following command against a fully
built tree:
$ touch lib/random.c; time make
Improve the overall build time from 7 seconds to 3.5 seconds.
Signed-off-by: Andy Zhou <azhou@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
Improve help output. Running without argument now exit with an error
message and an error code. Simplify OVSTEST_REGISTER() since not all
test programs uses sub_commands.
Signed-off-by: Andy Zhou <azhou@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
Connections that queue up too much data, because they are monitoring a
table that is changing quickly and failing to keep up with the updates,
cause problems with buffer management. Since commit 60533a405b
(jsonrpc-server: Disconnect connections that queue too much data.),
ovsdb-server has dealt with them by disconnecting the connection and
letting them start up again with a fresh copy of the database. However,
this is not ideal because of situations where disconnection happens
repeatedly. For example:
- A manager toggles a column back and forth between two or more values
quickly (in which case the data transmitted over the monitoring
connections always increases quickly, without bound).
- A manager repeatedly extends the contents of some column in some row
(in which case the data transmitted over the monitoring connection
grows with O(n**2) in the length of the string).
A better way to deal with this problem is to combine updates when they are
sent to the monitoring connection, if that connection is not keeping up.
In both the above cases, this reduces the data that must be sent to a
manageable amount. This commit implements this new way.
Bug #1211786.
Bug #1221378.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Andy Zhou <azhou@nicira.com>
This reverts commit 1600fa6853.
Connections that queue up too much data, because they are monitoring a
table that is changing quickly and failing to keep up with the updates,
cause problems with buffer management. Since commit 60533a405b
(jsonrpc-server: Disconnect connections that queue too much data.),
ovsdb-server has dealt with them by disconnecting the connection and
letting them start up again with a fresh copy of the database. However,
this is not ideal because of situations where disconnection happens
repeatedly. For example:
- A manager toggles a column back and forth between two or more values
quickly (in which case the data transmitted over the monitoring
connections always increases quickly, without bound).
- A manager repeatedly extends the contents of some column in some row
(in which case the data transmitted over the monitoring connection
grows with O(n**2) in the length of the string).
A better way to deal with this problem is to combine updates when they are
sent to the monitoring connection, if that connection is not keeping up.
In both the above cases, this reduces the data that must be sent to a
manageable amount. An upcoming patch implements this new way. This commit
reverts part of the previous solution that disconnects backlogged
connections, since it is no longer useful.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Andy Zhou <azhou@nicira.com>
This reverts commit 0ea7bec76d.
Connections that queue up too much data, because they are monitoring a
table that is changing quickly and failing to keep up with the updates,
cause problems with buffer management. Since commit 60533a405b
(jsonrpc-server: Disconnect connections that queue too much data.),
ovsdb-server has dealt with them by disconnecting the connection and
letting them start up again with a fresh copy of the database. However,
this is not ideal because of situations where disconnection happens
repeatedly. For example:
- A manager toggles a column back and forth between two or more values
quickly (in which case the data transmitted over the monitoring
connections always increases quickly, without bound).
- A manager repeatedly extends the contents of some column in some row
(in which case the data transmitted over the monitoring connection
grows with O(n**2) in the length of the string).
A better way to deal with this problem is to combine updates when they are
sent to the monitoring connection, if that connection is not keeping up.
In both the above cases, this reduces the data that must be sent to a
manageable amount. An upcoming patch implements this new way. This commit
reverts part of the previous solution that disconnects backlogged
connections, since it is no longer useful.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Andy Zhou <azhou@nicira.com>
This reverts commit 60533a405b.
Connections that queue up too much data, because they are monitoring a
table that is changing quickly and failing to keep up with the updates,
cause problems with buffer management. Since commit 60533a405b
(jsonrpc-server: Disconnect connections that queue too much data.),
ovsdb-server has dealt with them by disconnecting the connection and
letting them start up again with a fresh copy of the database. However,
this is not ideal because of situations where disconnection happens
repeatedly. For example:
- A manager toggles a column back and forth between two or more values
quickly (in which case the data transmitted over the monitoring
connections always increases quickly, without bound).
- A manager repeatedly extends the contents of some column in some row
(in which case the data transmitted over the monitoring connection
grows with O(n**2) in the length of the string).
A better way to deal with this problem is to combine updates when they are
sent to the monitoring connection, if that connection is not keeping up.
In both the above cases, this reduces the data that must be sent to a
manageable amount. An upcoming patch implements this new way. This commit
reverts part of the previous solution that disconnects backlogged
connections, since it is no longer useful.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Andy Zhou <azhou@nicira.com>
This reverts commit 631583739f.
Connections that queue up too much data, because they are monitoring a
table that is changing quickly and failing to keep up with the updates,
cause problems with buffer management. Since commit 60533a405b
(jsonrpc-server: Disconnect connections that queue too much data.),
ovsdb-server has dealt with them by disconnecting the connection and
letting them start up again with a fresh copy of the database. However,
this is not ideal because of situations where disconnection happens
repeatedly. For example:
- A manager toggles a column back and forth between two or more values
quickly (in which case the data transmitted over the monitoring
connections always increases quickly, without bound).
- A manager repeatedly extends the contents of some column in some row
(in which case the data transmitted over the monitoring connection
grows with O(n**2) in the length of the string).
A better way to deal with this problem is to combine updates when they are
sent to the monitoring connection, if that connection is not keeping up.
In both the above cases, this reduces the data that must be sent to a
manageable amount. An upcoming patch implements this new way. This commit
reverts part of the previous solution that disconnects backlogged
connections, since it is no longer useful.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Andy Zhou <azhou@nicira.com>
When a row was deleted, and that caused the transaction manager to remove
a remaining weak reference to the row, and no other change had been made
to the row in that transaction, and a client was monitoring modifications
of the _version column in the row, then the monitor update for the column
did not include the old contents of the _version column, even though it
should have. This commit fixes the problem.
Probably most clients only look at the new value of the column, if they
monitor _version at all, and this bug is really old, so it's probably
not a serious bug.
Found by inspection.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Andy Zhou <azhou@nicira.com>
Commit d473844693 (debian: Depend on 'kmod' instead of module-init-tools.)
switched from depending on module-init-tools to depending on kmod, which
is the new name of the appropriate package in Debian. Unfortunately,
while kmod is the right name for the latest Debian distribution, it doesn't
have that name in old distributions and thus breaks the build on those.
This commit should work OK in either case, since it allows both names.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Justin Pettit <jpettit@nicira.com>
Acked-by: Gurucharan Shetty <gshetty@nicira.com>
