ovsdb: Fix double-free in ovsdb_jsonrpc_session_close().
ovsdb_session_destroy() was called twice but it should only be called once.
This double-free is unlikely to cause problems in practice because it only
triggers if there were ever more than two outstanding requests in the
session at a time (because the only data being freed is an hmap, which
does not allocate any heap memory unless the hmap has more than two
elements).
Signed-off-by: Ben Pfaff <email address hidden>
Acked-by: Ethan Jackson <email address hidden>
Revert "datapath: Avoid null deref when GSO is for verifying header integrity only."
This reverts commit 00c7faf3e5b7d4020e995a1429cf94313f197171.
In general, it should not be possible have a NULL return value from
skb_gso_segment() since we're not actually trying to verify the
header integrity. No other callers with similar needs have NULL
checks. The actual cause of the problem was LRO packets, which
OVS isn't equipped to handle. The commit
33e031e99cc630baf1b0cb9256710dee7d9ab66d (datapath: Move LRO check
from transmit to receive.) solves that problem by fixing the LRO
check. In order to avoid possibly masking any other problems, this
reverts the GSO check which should no longer be needed.
datapath: Move LRO check from transmit to receive.
Commit 24b019f808211a95078efd916064af0975ca5733 (datapath: Disable
LRO from userspace instead of the kernel.) accidentally moved the
check for LRO packets from the receive path to transmit. Since
this check is supposed to protect OVS (and other parts of the system)
from packets that it cannot handle it is obviously not useful on
egress. Therefore, this commit moves it back to the receive side.
The primary problem that this caused is upcalls to userspace tried
to segment the packet even though no segmentation information is
available. This would later cause NULL pointer dereferences when
skb_gso_segment() did nothing.
datapath: Avoid null deref when GSO is for verifying header integrity only.
skb_gso_segment() has the following comment:
* It may return NULL if the skb requires no segmentation. This is
* only possible when GSO is used for verifying header integrity.
Somehow queue_gso_packets() has never hit this case before, but some
failures have suddenly been reported. This commit should fix the problem.
Additional commentary by Jesse: We shouldn't normally be hitting this case
because we're actually trying to do GSO, not header validation. However, I
guess the guest/backend must be generating a packet with an MSS, which
tricks us into thinking that it's GSO, but no GSO is actually requested.
In the case of the bridge, header validation does take place so the
situation is handled already. It seems not ideal that the network backend
doesn't sanitize these packets but it's probably good that we handle
it in any case.
ovs-ctl: Exit, instead of resuming, after handling fatal signals.
When I wrote the "trap" calls in ovs-ctl, I had the mistaken notion that
"trap $cmd $signal" would execute $cmd and then exit when $signal was
caught. This is incorrect. Instead, it executes $cmd and then resumes
executing the shell script.
On the other hand, "trap $cmd 0" does by itself what I wanted: it causes
the shell to execute $cmd and then exits due to the signal. So this commit
changes the offending traps to use this form.
python/ovs/stream: Fix Stream.connect() retval for incomplete connection.
If the loop condition in Stream.connect() was false, which is especially
likely for TCP connections, then Stream.connect() would return None,
which violates its documented behavior. This commit fixes the problem.
bond: Tag flows according to their hash bucket, not just their slave.
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 <email address hidden>
Signed-off-by: Ben Pfaff <email address hidden>
Acked-by: Ethan Jackson <email address hidden>
