Ben Pfaff [Mon, 15 Sep 2008 21:24:57 +0000 (14:24 -0700)]
Fix handling of port flags.
The "port watcher" in secchan was not keeping track of updates to port
flags by the controller, which caused some combinations of secchan
and controller to not turn on ports when the STP state otherwise should
have done so.
A recent change (696db2) modified the way stats were being sent over the
netlink socket. Unfortunately, the responder set the transaction id to the
type, which caused the requestor to ignore the repsone.
Actions are allocated as a pointer to an array of actions in flows. When
flows are freed, the code was always freeing the action pointer.
Under some circumstances the pointer may not be set.
Ben Pfaff [Thu, 11 Sep 2008 18:37:13 +0000 (11:37 -0700)]
Use vconn_init() instead of explicit initialization in one last place.
Commit b5e16b0723, "Respin "Make vconns keep track of their names and
include them in log messages,"" was supposed to do this everywhere, but
this instance was evidently missed.
Use new method to describe table entries in OpenFlow wire protocol.
Older versions of OpenFlow pre-defined a few different types of tables and the
Features Reply message would indicate how many of those entries existed. This
was very inflexible, so now the Features Reply just indicates how many tables
there are. The controller now sends a Table Stats request to find out how
many entries are supported and the fields that can be wildcarded.
This change also removes the "buffer_mb" field from the Features Reply, since
it was not being used and seemed to be of limited value.
Ben Pfaff [Tue, 9 Sep 2008 19:53:47 +0000 (12:53 -0700)]
Send of0 packets from workqueue, to avoid recursive locking of ofN device.
lockdep reported the following warning, showing that dev_queue_xmit()
for of0 and for another ethernet device (eth0?) were taking locks of
the same class. It was not a problem in this particular case, because
of0 != eth0, but if a flow were to send a packet back to of0 then we
would have a deadlock.
Solution: use a workqueue to send packets to avoid recursive locking.
We will still waste a lot of CPU time if we get a packet that loops back
to of0. Solution for that still needed.
=============================================
[ INFO: possible recursive locking detected ]
2.6.26.5 #1
---------------------------------------------
memcheck/1258 is trying to acquire lock:
(_xmit_ETHER){-+..}, at: [<c025b126>] __qdisc_run+0xa0/0x18a
but task is already holding lock:
(_xmit_ETHER){-+..}, at: [<c024f3cd>] dev_queue_xmit+0x23c/0x334
other info that might help us debug this:
9 locks held by memcheck/1258:
#0: (genl_mutex){--..}, at: [<c0262037>] genl_rcv+0x12/0x2b
#1: (dp_mutex){--..}, at: [<c88e9a13>] dp_genl_openflow+0x58/0x91 [openflow_mo
d]
#2: (rcu_read_lock){..--}, at: [<c024e749>] netif_receive_skb+0x9e/0x328
#3: (rcu_read_lock){..--}, at: [<c0267f77>] ip_local_deliver_finish+0x2a/0x1d7
#4: (slock-AF_INET/1){-+..}, at: [<c027f1b8>] tcp_v4_rcv+0x29f/0x5ef
#5: (rcu_read_lock){..--}, at: [<c024f308>] dev_queue_xmit+0x177/0x334
#6: (_xmit_ETHER){-+..}, at: [<c024f3cd>] dev_queue_xmit+0x23c/0x334
#7: (rcu_read_lock){..--}, at: [<c88ea214>] dp_dev_xmit+0x0/0x6c [openflow_mod
]
#8: (rcu_read_lock){..--}, at: [<c024f308>] dev_queue_xmit+0x177/0x334
Ben Pfaff [Sat, 6 Sep 2008 04:23:34 +0000 (21:23 -0700)]
Compatibility fixes for 2.6.18 kernel
Functions added in the 2.6.22 kernel in tcp.h and skbuff.h
have been added to the compatibility headers. Additionally
the data argument was dropped in 2.6.22 for the work queue
macros, requiring them to be redfined for previous kernels.
Ben Pfaff [Sat, 6 Sep 2008 00:09:53 +0000 (17:09 -0700)]
Do not send in-band control traffic to the controller.
This commit prevents the secure channel from sending any traffic to
or from the controller up to the controller over its OpenFlow connection.
Instead, such traffic is always handled completely locally. This is
what the changes to in-band control up until now have been converging on:
each time, we have reduced the category of traffic that can be sent up
to the controller because we have found that doing so can cause a control
loop. This change goes all the way.
Ben Pfaff [Wed, 3 Sep 2008 17:10:39 +0000 (10:10 -0700)]
Also disable atexit hooks in fatal_signal_fork().
This fixes a problem in ofp-discover, where it would daemonize itself
after setting an IP address on one of its interfaces. The daemonize
function would call fatal_signal_fork() then exit(0), which would in turn
cause the netdev code to disable the interface and thereby remove the IP
address.
The bug that this fixes was introduced in commit 3cc1ae6a3, "Add ability
to run fatal signal hooks upon normal termination too."
Ben Pfaff [Tue, 2 Sep 2008 22:44:58 +0000 (15:44 -0700)]
Do not send in-band control traffic to the controller.
This commit prevents the secure channel from sending any traffic to
or from the controller up to the controller over its OpenFlow connection.
Instead, such traffic is always handled completely locally. This is
what the changes to in-band control up until now have been converging on:
each time, we have reduced the category of traffic that can be sent up
to the controller because we have found that doing so can cause a control
loop. This change goes all the way.
Ben Pfaff [Tue, 2 Sep 2008 22:42:34 +0000 (15:42 -0700)]
Minimal fix for in-band control loop with hub.
When a hub has two switches and the controller on three of its ports,
control traffic from the controller to switch 1 is seen by switch 2 as
data traffic, and switch 2 sends it up over its OpenFlow connection. That
control traffic is in turn seen by the switch 1 as data traffic, and so
switch 1 sends it up over its OpenFlow connection. And so on: this is a
loop.
This commit fixes the situation by not sending up over the OpenFlow
connection traffic to the controller that arrived on the controller's
port, as well as traffic from the controller.
Ben Pfaff [Tue, 19 Aug 2008 18:14:52 +0000 (11:14 -0700)]
Change netdev_get_in4() to re-check the IP address on each call.
As part of implementing switch stats, secchan wants to report the
IP address currently configured on an interface. Caching it for
all time defeats that purpose.
Ben Pfaff [Fri, 22 Aug 2008 17:34:15 +0000 (10:34 -0700)]
rconn: Fix bug #100, "Inactivity time-out slow under heavy load."
The timeout() function returns a duration relative to the time at which the
current state was entered, but rconn_run_wait() was treating it as the
waiting time remaining.
Justin Pettit [Mon, 18 Aug 2008 06:17:07 +0000 (23:17 -0700)]
Fix dump-flows to be usable by add-flows.
Some of the fields when printing a flow are hex, but they don't have a
preceeding "0x". When one tries to import them, they're treated as decimal
and weird results occur. Bug 27.
Justin Pettit [Thu, 14 Aug 2008 07:02:14 +0000 (00:02 -0700)]
Switch to new packet-out format and add OFPP_IN_PORT.
The original packet-out format allowed multiple actions to be specified for
buffered packets, but only a destination port for messages including data.
This change makes packet-out more consistent by allowing multiple actions
regardless of how the packet is stored.
This change also disallows sending packets through the incoming port without
explicitly using the OFPP_IN_PORT virtual port.
Ben Pfaff [Wed, 13 Aug 2008 18:21:49 +0000 (11:21 -0700)]
rconn: Queue packets for tx only if connected.
Until now, the rconn code would queue up packets not just while connected
but also while connecting. This is not just unnecessary, however, it
actually causes a problem in secchan: if the secchan receives packets
from nl:0 and tries to transmit them, then they will quickly fill up
the rconn's transmit buffer (it uses a 1-packet buffer), which causes
secchan to stop reading packets from nl:0 until the buffer frees up.
That cannot happen until the connection completes. With in-band control,
however, the connection cannot complete until we receive and process
packet_in messages in our in-band hook. Thus, we have a deadlock.
Fixes bug #90, "Sometimes secchan has to go into fail-open mode to connect."
Ben Pfaff [Tue, 12 Aug 2008 23:15:42 +0000 (16:15 -0700)]
Reduce default burst limit to rate limit / 4.
With the previous default burst limit of rate limit * 2, we would queue
up 2 seconds worth of packet_in messages. This is not only much more
than actually needed, it causes an actual problem: the datapath only
retains buffered packets for up to 1 second, by default, so that flow
setups sent in response have no packet to work with.
Ben Pfaff [Mon, 11 Aug 2008 23:24:24 +0000 (16:24 -0700)]
Drop rconn's responsibility for limiting the tx queue.
Now it helps clients track the number of in-flight messages, but lets the
clients do the limiting themselves. This will come in handy for packet-in
rate limiting (in an upcoming commit), in which we want to track in-flight
packet-in messages separately from other in-flight messages.
Ben Pfaff [Tue, 12 Aug 2008 21:41:48 +0000 (14:41 -0700)]
Implement signal-driven time tracking.
Checking the current time only when a periodic timer expires allows us
to reduce the number of system calls to obtain the current time to 10 per
second (from an arbitrary number) plus one per poll loop.
This fixes poll_block() to properly handle being interrupted.
Otherwise, a timeout longer than the interval between signals will never
complete (because it will restart from the beginning after every
signal).
Ben Pfaff [Fri, 8 Aug 2008 22:39:20 +0000 (15:39 -0700)]
Set up flow to drop packets that come in on their output port.
Commit 0a3d4ba3a, "Don't allow the learning switch to send packets back
out the incoming port," drops packets that come in on their incoming port,
but it does not set up a flow to drop those packets. If we are connected
to a hub, then this can be very expensive, since we can continue to get
many packets in that flow and have to drop them in secchan one by one. So
now we set up a flow to drop them for us.
projects / openvswitch / log