| Age | Commit message (Collapse) | Author |
|---|
|
The bonding code is supposed to tag flows two ways:
- According to the chosen bond slave, to make it easy to invalidate all
of the flows assigned to a given slave.
- According to the hash value for a flow, to make it easy to invalidate
all of the flows that hash into the same bucket.
However, the code wasn't actually applying the hash-based tags. This
meant that rebalancing didn't take effect immediately, and so after
rebalancing we could get log messages like this:
inconsistency in subfacet (actions were: 5) (correct actions: 4)
specifying some flow that was moved by the rebalance.
This commit fixes the problem by applying the hash-based tags.
Bug #12847.
Reported-by: Pratap Reddy <preddy@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Ethan Jackson <ethan@nicira.com>
|
|
Open vSwitch 1.4 and later is compatible with the upstream Linux kernel
module but the init scripts hadn't been adapted to work with the upstream
module name.
Debian bug #684057.
Signed-off-by: Ben Pfaff <blp@nicira.com>
|
|
When installing a flow with an action to set a particular field we
need to validate that the packets that are part of the flow actually
contain that header. With IP we use zeroed addresses and with TCP/UDP
the check is for zeroed ports. This check is overly broad and can catch
packets like DHCP requests that have a zero source address in a
legitimate header. This changes the check to look for a zeroed protocol
number for IP or for both ports be zero for TCP/UDP before considering
the header to not exist.
Bug #12769
Reported-by: Ethan Jackson <ethan@nicira.com>
Signed-off-by: Jesse Gross <jesse@nicira.com>
Acked-by: Pravin B Shelar <pshelar@nicira.com>
|
|
This probably means that some classifier functions based on the fragment
type of packets have never worked properly.
Signed-off-by: Ben Pfaff <blp@nicira.com>
|
|
POSIX states that the string returned by strerror() may be overwritten
by a subsequent call (i.e., because it returns a pointer to a static
buffer). Make a copy of one of the two strerror() strings to avoid
this.
Background: FreeBSD historically returned such a pointer only in the
case of an invalid errno. With the addition of NLS strerror was changed
to do so for all calls.
Prior to this change I had confusing results from the test suite like
"... is 22 (Invalid argument) but should be 0 (Invalid argument)".
Signed-off-by: Ed Maste <emaste@adaranet.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
|
|
This may be more useful in practice than failing the entire OVS startup
sequence.
Debian bug #681955.
CC: 681955@bugs.debian.org
Reported-by: Bastian Blank <waldi@debian.org>
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Simon Horman <horms@verge.net.au>
|
|
ovs-vsctl is listed, incorrectly, in both bin_PROGRAMS and bin_SCRIPTS.
This meant that "make install" with the -j option could try to install
ovs-vsctl two times in parallel, a race that occasionally caused a build
failure, e.g.:
http://buildd.debian.org/status/fetch.php?pkg=openvswitch&arch=s390&ver=1.4.2%2Bgit20120612-5&stamp=1342851603
Debian bug #682384.
CC: 682384@bugs.debian.org
Reported-by: Bastian Blank <waldi@debian.org>
Signed-off-by: Ben Pfaff <blp@nicira.com>
|
|
A Debian package is expected to remove all its configuration files (which
includes all files in /etc) when it is purged, but the
openvswitch-controller package wasn't doing that. This fixes the problem.
Debian bug #682187.
CC: 682187@bugs.debian.org
Reported-by: Andreas Beckmann <debian@abeckmann.de>
Signed-off-by: Ben Pfaff <blp@nicira.com>
|
|
Debian kernel maintainer Bastian Blank writes, at
http://bugs.debian.org/680537:
The netfilter rules are a shared resource. There is no synchronization,
so the admin have the last word. As kernel maintainer, I see it similar
to a configuration file, so ยง10.7 policy applies.
The purpose of openvswitch is to provide support for switching, not to
setup filter rules. This means it violates the principle of least
surprise.
I believe that the argument by analogy to configuration files is weak,
given that the Debian policy section in question is very specifically about
files, not about general principles. On the other hand, Debian does not
install any firewall by default, so the presence of a rule that blocks GRE
traffic is a sign that the administrator has taken an explicit action to
install a firewall that blocks GRE, and therefore it is rather rude to
override this. Therefore, this patch simply turns off this behavior on
Debian, given that in ordinary Debian installations it will have no
adverse effect on Open vSwitch.
Debian bug #680537.
CC: 680537@bugs.debian.org
Reported-by: Bastian Blank <waldi@debian.org>
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Simon Horman <horms@verge.net.au>
|
|
Found by valgrind:
Syscall param socketcall.sendmsg(msg.msg_iov[i]) points to uninitialised
byte(s)
at 0x42D3021: sendmsg (in /lib/libc-2.5.so)
by 0x80E4D23: nl_sock_transact (netlink-socket.c:670)
by 0x80D9086: dpif_linux_execute__ (dpif-linux.c:872)
by 0x807D6AE: dpif_execute__ (dpif.c:957)
by 0x807D6FE: dpif_execute (dpif.c:987)
by 0x805DED9: send_packet (ofproto-dpif.c:4727)
by 0x805F8E1: port_run_fast (ofproto-dpif.c:2441)
by 0x8065CF6: run_fast (ofproto-dpif.c:926)
by 0x805674F: ofproto_run_fast (ofproto.c:1148)
by 0x804C957: bridge_run_fast (bridge.c:1980)
by 0x8053F49: main (ovs-vswitchd.c:123)
Address 0xbea0895c is on thread 1's stack
Bug #11797.
Signed-off-by: Ben Pfaff <blp@nicira.com>
|
|
At the point where it was used, skb_shinfo(skb)->gso_type referred to a
post-GSO sk_buff. Thus, it would always be 0. We want to know the pre-GSO
gso_type, so we need to obtain it before segmenting.
Before this change, the kernel would pass inconsistent data to userspace:
packets for UDP fragments with nonzero offset would be passed along with
flow keys that indicate a zero offset (that is, the flow key for "later"
fragments claimed to be "first" fragments). This inconsistency tended
to confuse Open vSwitch userspace, causing it to log messages about
"failed to flow_del" the flows with "later" fragments.
Bug #12394.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Jesse Gross <jesse@nicira.com>
|
|
This hasn't been necessary for a long time.
Signed-off-by: Ben Pfaff <blp@nicira.com>
|
|
ovs-ctl.in uses /etc/protocols, which is in the "netbase" package, so a
dependency is required.
Debian bug #680537.
CC: 680537@bugs.debian.org
Reported-by: Bastian Blank <waldi@debian.org>
Signed-off-by: Ben Pfaff <blp@nicira.com>
|
|
Bug #12301.
Reported-by: Mike Kruze <mkruze@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
|
|
mlockall(2) says:
Memory locks are not inherited by a child created via fork(2) and are
automatically removed (unlocked) during an execve(2) or when the
process terminates.
which means that --mlockall was ineffective in combination with --detach
or --monitor or both. Both are used in the most common production
configuration of Open vSwitch, so this means that --mlockall has never been
effective in production.
Signed-off-by: Ben Pfaff <blp@nicira.com>
|
|
On FreeBSD sig_atomic_t is long, which causes the comparison in
fatal_signal_run to be true when no signal has been reported.
Signed-off-by: Ed Maste <emaste@freebsd.org>
Signed-off-by: Ben Pfaff <blp@nicira.com>
|
|
By default DKMS doesn't build on demand for each kernel booted or updated.
Adding AUTOINSTALL=yes gives it this behavior. Based on a small sample of
Debian packages and how-to guides for Ubuntu, AUTOINSTALL=yes is what most
packages use and what users expect.
Fix-suggested-by: Kirill Kabardin
Reported-by: Ralf Heiringhoff <ralf@frosty-geek.net>
Reported-at: https://bugs.launchpad.net/bugs/962189
Signed-off-by: Ben Pfaff <blp@nicira.com>
|
|
Found by valgrind.
Signed-off-by: Ben Pfaff <blp@nicira.com>
|
|
Fix return check typo.
Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
Acked-by: Jesse Gross <jesse@nicira.com>
Bug #11933
|
|
In one edge case, ofoperation_complete() destroys its rule, without
updating its ofoperation that the rule is gone. Later in the same
function, ofoperation_destroy() attempts to modify the rule which
already destroyed.
Bug #11797.
Signed-off-by: Ethan Jackson <ethan@nicira.com>
|
|
|
|
Reported-by: Justin Pettit <jpettit@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
|
|
Before we submitted the kernel module upstream, we updated the flow format
by adding two fields to the description of packets with VLAN headers, but
we forgot to update ODPUTIL_FLOW_KEY_BYTES to reflect these changes. The
result was that a maximum-length flow did not fit in the given space.
This fixes a crash processing IPv6 neighbor discovery packets with VLAN
headers received in a tunnel configured with key=flow or in_key=flow.
This updates some comments to better describe the implications of
ODPUTIL_FLOW_KEY_BYTES (suggested by Justin).
This also updates test-odp.c so that it would have caught this problem, and
updates odp.at to demonstrate that a full 156 bytes are necessary. (To see
that, revert the change to ODPUTIL_FLOW_KEY_BYTES and run the test.)
Reported-by: Dan Wendlandt <dan@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
|
|
Until now, bridges with datapath_type=netdev did not destroy the datapath
when deleted. In particular, the tap device implementing the internal
interface was not close()d, and therefore the tap persists until
ovs-vswitchd exit()s.
This behaviour was caused by the missing callback for 'enumerate' in the
dpif-netdev class. Without this callback 'bridge_reconfigure' failed to
realize that there are datapaths with no bridge, and thus cannot destroy
them. Providing an 'enumerate' callback fixes this.
Signed-off-by: Giuseppe Lettieri <g.lettieri@iet.unipi.it>
Signed-off-by: Ben Pfaff <blp@nicira.com>
|
|
Some OpenFlow 1.0 controllers incorrectly use OPFP_CONTROLLER as the
in_port in packet-out messages, when OFPP_NONE is their intent. Until now,
Open vSwitch has rejected such requests with an error message. This commit
makes Open vSwitch instead treat OFPP_CONTROLLER the same as OFPP_NONE for
compatibility with those controllers.
(Also, as of this writing, OpenFlow 1.0.1 appears to be changing the port
to use from OFPP_NONE to OFPP_CONTROLLER.)
Suggested-by: Rob Sherwood <rob.sherwood@bigswitch.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
|
|
Signed-off-by: Ben Pfaff <blp@nicira.com>
|
|
If the daemon(s) aren't running for whatever reason, the RHEL ovs
ifup/ifdown scripts don't take that into account and an attempt to reboot a
system could take forever. (literally. endless loop!) Here are a couple of
patches (one of ifup, one for ifdown) to add timeouts (10 seconds), because
it runs per interface you have configured and that could take awhile to
reboot a system if needed.
Signed-off-by: Brian Kruger <bkruger+ovsdev@gmail.com>
[blp@nicira.com fixed up a conflict against master]
Signed-off-by: Ben Pfaff <blp@nicira.com>
|
|
When the kernel validates set TCP/UDP port actions, it looks at
the ports in the existing flow to make sure that the L4 header exists.
However, these actions always use the IPv4 version of the struct.
Following patch fixes this by checking for flow ip protocol first.
Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
Acked-by: Jesse Gross <jesse@nicira.com>
Bug #11205
|
|
Reported-by: Greg Dahlman <gdahlman@hotmail.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
|
|
|
|
Signed-off-by: Ben Pfaff <blp@nicira.com>
|
|
These tests had a hidden dependency on the hash function in use,
which yields different results on big-endian and little-endian
architectures. This commit fixes the problem by properly
parameterizing the parts that can differ.
Signed-off-by: Ben Pfaff <blp@nicira.com>
|
|
Found by valgrind.
Reported-by: Ethan Jackson <ethan@nicira.com>
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>
|
|
Commit 24e81092a1 (debian: Bring Debian packaging in-line with new file
locations) introduced an ambiguous "--t" option invoking ovs-appctl, so
ovs-vswitchd and ovsdb-server were not reopening their log files following
log rotation. This fixes the problem by correct the option name.
Reported-by: Paul Ingram <paul@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
|
|
Somehow we forgot to put the md5sums for 5.6-SP2 so users were getting
scary error messages.
Bug #10210.
Reported-by: Ronald Lee <rlee@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
|
|
The PKI directory is mutable state, so it should be in /var, not in /usr.
This commit changes its location and, on systems upgraded from earlier
versions, moves the existing PKI and leaves behind a symlink.
CC: 661090@bugs.debian.org
Reported-by: Andreas Beckmann <debian@abeckmann.de>
Signed-off-by: Ben Pfaff <blp@nicira.com>
|
|
This code in xlate_table_action() is supposed to tag flows in tables that
have special forms so that changes do not require revalidating every flow.
When rule->tag is nonzero, its value can be used, because we know in this
case that rule->cr.wc is the same as table->other_table->wc and that thus
rule->tag caches the return value of the rule_calculate_tag() expression.
When rule->tag is zero (a "catchall" rule) we need to calculate the tag
manually because we have no way to cache it in that case.
I discovered this bug by running an "hping3" between a couple of VMs plus
the following commands on OVS in the middle:
ovs-ofctl del-flows br0
ovs-ofctl add-flow br0 "table=0 actions=learn(table=1, \
idle_timeout=600, NXM_OF_VLAN_TCI[0..11], \
NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[], \
output:NXM_OF_IN_PORT[], fin_idle_timeout=10), resubmit(,1)"
ovs-ofctl add-flow br0 "table=1 priority=0 actions=flood"
Without this patch, flows don't get properly invalidated upon initial MAC
learning, so one sees warnings like the following:
in_port(2),eth(src=50:54:00:00:00:05,dst=50:54:00:00:00:07),
eth_type(0x0800),ipv4(src=192.168.0.1,dst=192.168.0.2,proto=6,tos=0,
ttl=64,frag=no),tcp(src=13966,dst=0): inconsistency in subfacet
(actions were: 3,0,1) (correct actions: 1)
This patch fixes the problem and thus avoids these warnings.
Signed-off-by: Ben Pfaff <blp@nicira.com>
|
|
"ovs-ofctl del-flows <bridge>" can result in the following call path:
delete_flows_loose() in ofproto.c
-> collect_rules_loose() -- uses 'ofproto_node' inside 'struct rule'
-> rule_destruct() in ofproto-dpif.c
-> facet_revalidate()
-> facet_remove()
-> facet_flush_stats()
-> facet_account()
-> xlate_actions()
-> xlate_learn_action()
-> ofproto_flow_mod() back in ofproto.c
-> modify_flow_strict()
-> collect_rules_strict() -- also uses 'ofproto_node'
which goes "boom" when we fall back up the call chain because the nested
use of ofproto_node steps on the outer use of ofproto_node.
This commit fixes the problem by refusing to translate "learn" actions
within facet_flush_stats(), breaking the doubled use.
Another possible approach would be to switch to another way to keep track
of rules in the flow_mod implementations, so that there'd be no fighting
over 'ofproto_node'. But then "ovs-ofctl del-flows" might still leave some
flows around (ones created by "learn" actions as flows are accounted as
facets get deleted), which would be surprising behavior. And it seems in
general a bad idea to allow recursive flow_mods; the consequences have not
been carefully thought through.
Before this commit, one can reproduce the problem by running an "hping3"
between a couple of VMs plus the following commands on OVS in the middle.
Sometimes you have to run them a few times:
ovs-ofctl del-flows br0
ovs-ofctl add-flow br0 "table=0 actions=learn(table=1, \
idle_timeout=600, NXM_OF_VLAN_TCI[0..11], \
NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[], \
output:NXM_OF_IN_PORT[], fin_idle_timeout=10), resubmit(,1)"
ovs-ofctl add-flow br0 "table=1 priority=0 actions=flood"
This commit has a side effect that leftover unaccounted packets no longer
update the timeouts in MAC learning actions in some cases, when the facets
that cause updates are deleted. At most one second of updates should be
lost.
Bug #10184.
Reported-by: Michael Mao <mmao@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
|
|
This is useful in a situation where one knows that an hmap_node is in some
hmap, but it's not certain which one, and one needs to know whether it is
in a particular one. This is not a very common case; I don't see any
potential users in the current tree, although an upcoming commit will add
one.
Signed-off-by: Ben Pfaff <blp@nicira.com>
|
|
tag_type is currently uint32_t but using uint32_t directly is conceptually
wrong.
Signed-off-by: Ben Pfaff <blp@nicira.com>
|
|
A fake bridge for VLAN 0 is useful, because it provides a way to create
access ports for VLAN 0. There is no good reason to prevent it.
NIC-464.
Reported-by: Rob Hoes <Rob.Hoes@citrix.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
|
|
iface_configure_qos() passes a callback to netdev_dump_queues() that can
delete queues. The netdev-linux implementation of this function was
unprepared for the callback to delete queues, so this could cause a
use-after-free. This fixes the problem in netdev_linux_dump_queues() and
documents that netdev_dump_queues() implementations must support deletions
in the callback.
Found by valgrind:
==1593== Invalid read of size 8
==1593== at 0x4A8C43: netdev_linux_dump_queues (hmap.h:326)
==1593== by 0x4305F7: bridge_reconfigure (bridge.c:3084)
==1593== by 0x431384: bridge_run (bridge.c:1892)
==1593== by 0x432749: main (ovs-vswitchd.c:96)
==1593== Address 0x632e078 is 8 bytes inside a block of size 32 free'd
==1593== at 0x4C240FD: free (vg_replace_malloc.c:366)
==1593== by 0x4A4D74: hfsc_class_delete (netdev-linux.c:3250)
==1593== by 0x42AA59: iface_delete_queues (bridge.c:3055)
==1593== by 0x4A8C8C: netdev_linux_dump_queues (netdev-linux.c:1881)
==1593== by 0x4305F7: bridge_reconfigure (bridge.c:3084)
==1593== by 0x431384: bridge_run (bridge.c:1892)
Bug #10164.
Reported-by: Ram Jothikumar <ram@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
|
|
The dh_installinit --error-handler option makes a lot of sense, but after
playing with it for a while I could not figure out a nice way to use it
only for openvswitch-switch without either duplicating the dh_installinit
fragments in postinst and prerm (the actual bug that was reported) or
omitting them for some package.
Also, we forgot to write the error handler function for the prerm.
This commit switches to a different way to avoid failing the install when
the kernel module is not available, without using --error-handler.
CC: 663051@bugs.debian.org
Reported-by: Thomas Goirand <zigo@debian.org>
Reviewed-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Ben Pfaff <blp@nicira.com>
|
|
ovs-vswitchd.conf.db.5 has autogenerated text "at least -1" in one place.
This '-' should be a minus sign, but ovsdb-doc was generating it as a
hyphen.
Found by lintian.
Reported-by: Thomas Goirand <zigo@debian.org>
Reviewed-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Ben Pfaff <blp@nicira.com>
|
|
ovs-vswitchd.conf.db.5 contains the following sentence:
If the interface cannot be added then Open vSwitch sets this column
to -1.
The '-' in "-1" should be a minus sign, not a hyphen, but the heuristic
in ovsdb-doc wasn't smart enough. This commit improves the heuristic and
fixes the problem.
Found by lintian.
Reported-by: Thomas Goirand <zigo@debian.org>
Reviewed-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Ben Pfaff <blp@nicira.com>
|
|
This makes the manpage indexable by standard system tools.
Found by lintian.
Reported-by: Thomas Goirand <zigo@debian.org>
Reviewed-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Ben Pfaff <blp@nicira.com>
|
|
The configure option --with-build-number=0 is interpreted differently in
different places. The configure script itself accepts 0 as an actual
build number and puts '#define BUILDNR "+build0"' into config.h. The
code in python/automake.mk treats 0 as "no build number" and puts
'BUILDNR = ""' into version.py.
This commit avoids the problem by not passing 0 as a build number.
Reviewed-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Ben Pfaff <blp@nicira.com>
|
|
Found by lintian.
Reviewed-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Thomas Goirand <zigo@debian.org>
Signed-off-by: Ben Pfaff <blp@nicira.com>
|
|
No other changes necessary.
Reviewed-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Thomas Goirand <zigo@debian.org>
Signed-off-by: Ben Pfaff <blp@nicira.com>
|
