linux-toradex.git/net/openvswitch, branch v3.14.57

openvswitch: Zero flows on allocation.

2015-10-01T09:36:23+00:00

[ Upstream commit ae5f2fb1d51fa128a460bcfbe3c56d7ab8bf6a43 ]

When support for megaflows was introduced, OVS needed to start
installing flows with a mask applied to them. Since masking is an
expensive operation, OVS also had an optimization that would only
take the parts of the flow keys that were covered by a non-zero
mask. The values stored in the remaining pieces should not matter
because they are masked out.

While this works fine for the purposes of matching (which must always
look at the mask), serialization to netlink can be problematic. Since
the flow and the mask are serialized separately, the uninitialized
portions of the flow can be encoded with whatever values happen to be
present.

In terms of functionality, this has little effect since these fields
will be masked out by definition. However, it leaks kernel memory to
userspace, which is a potential security vulnerability. It is also
possible that other code paths could look at the masked key and get
uninitialized data, although this does not currently appear to be an
issue in practice.

This removes the mask optimization for flows that are being installed.
This was always intended to be the case as the mask optimizations were
really targetting per-packet flow operations.

Fixes: 03f0d916 ("openvswitch: Mega flow implementation")
Signed-off-by: Jesse Gross 
Acked-by: Pravin B Shelar 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

openvswitch: fix panic with multiple vlan headers

2014-10-15T06:36:41+00:00

[ Upstream commit 2ba5af42a7b59ef01f9081234d8855140738defd ]

When there are multiple vlan headers present in a received frame, the first
one is put into vlan_tci and protocol is set to ETH_P_8021Q. Anything in the
skb beyond the VLAN TPID may be still non-linear, including the inner TCI
and ethertype. While ovs_flow_extract takes care of IP and IPv6 headers, it
does nothing with ETH_P_8021Q. Later, if OVS_ACTION_ATTR_POP_VLAN is
executed, __pop_vlan_tci pulls the next vlan header into vlan_tci.

This leads to two things:

1. Part of the resulting ethernet header is in the non-linear part of the
   skb. When eth_type_trans is called later as the result of
   OVS_ACTION_ATTR_OUTPUT, kernel BUGs in __skb_pull. Also, __pop_vlan_tci
   is in fact accessing random data when it reads past the TPID.

2. network_header points into the ethernet header instead of behind it.
   mac_len is set to a wrong value (10), too.

Reported-by: Yulong Pei 
Signed-off-by: Jiri Benc 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

openvswitch: fix a possible deadlock and lockdep warning

2014-03-28T20:41:53+00:00

There are two problematic situations.

A deadlock can happen when is_percpu is false because it can get
interrupted while holding the spinlock. Then it executes
ovs_flow_stats_update() in softirq context which tries to get
the same lock.

The second sitation is that when is_percpu is true, the code
correctly disables BH but only for the local CPU, so the
following can happen when locking the remote CPU without
disabling BH:

       CPU#0                            CPU#1
  ovs_flow_stats_get()
   stats_read()
 +->spin_lock remote CPU#1        ovs_flow_stats_get()
 |                    stats_read()
 |  ...                       +-->  spin_lock remote CPU#0
 |                            |     
 |  ovs_flow_stats_update()   |     ...
 |   spin_lock local CPU#0 <--+     ovs_flow_stats_update()
 +---------------------------------- spin_lock local CPU#1

This patch disables BH for both cases fixing the deadlocks.
Acked-by: Jesse Gross 

=================================
[ INFO: inconsistent lock state ]
3.14.0-rc8-00007-g632b06a #1 Tainted: G          I
---------------------------------
inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
swapper/0/0 [HC0[0]:SC1[5]:HE1:SE0] takes:
(&(&cpu_stats->lock)->rlock){+.?...}, at: [] ovs_flow_stats_update+0x51/0xd0 [openvswitch]
{SOFTIRQ-ON-W} state was registered at:
[] __lock_acquire+0x68f/0x1c40
[] lock_acquire+0xa2/0x1d0
[] _raw_spin_lock+0x3e/0x80
[] ovs_flow_stats_get+0xc4/0x1e0 [openvswitch]
[] ovs_flow_cmd_fill_info+0x185/0x360 [openvswitch]
[] ovs_flow_cmd_build_info.constprop.27+0x55/0x90 [openvswitch]
[] ovs_flow_cmd_new_or_set+0x4dd/0x570 [openvswitch]
[] genl_family_rcv_msg+0x1cd/0x3f0
[] genl_rcv_msg+0x8e/0xd0
[] netlink_rcv_skb+0xa9/0xc0
[] genl_rcv+0x28/0x40
[] netlink_unicast+0x100/0x1e0
[] netlink_sendmsg+0x347/0x770
[] sock_sendmsg+0x9c/0xe0
[] ___sys_sendmsg+0x3a9/0x3c0
[] __sys_sendmsg+0x51/0x90
[] SyS_sendmsg+0x12/0x20
[] system_call_fastpath+0x16/0x1b
irq event stamp: 1740726
hardirqs last  enabled at (1740726): [] ip6_finish_output2+0x4f0/0x840
hardirqs last disabled at (1740725): [] ip6_finish_output2+0x4ab/0x840
softirqs last  enabled at (1740674): [] _local_bh_enable+0x22/0x50
softirqs last disabled at (1740675): [] irq_exit+0xc5/0xd0

other info that might help us debug this:
 Possible unsafe locking scenario:

       CPU0
       ----
  lock(&(&cpu_stats->lock)->rlock);
  
    lock(&(&cpu_stats->lock)->rlock);

 *** DEADLOCK ***

5 locks held by swapper/0/0:
 #0:  (((&ifa->dad_timer))){+.-...}, at: [] call_timer_fn+0x5/0x320
 #1:  (rcu_read_lock){.+.+..}, at: [] mld_sendpack+0x5/0x4a0
 #2:  (rcu_read_lock_bh){.+....}, at: [] ip6_finish_output2+0x59/0x840
 #3:  (rcu_read_lock_bh){.+....}, at: [] __dev_queue_xmit+0x5/0x9b0
 #4:  (rcu_read_lock){.+.+..}, at: [] internal_dev_xmit+0x5/0x110 [openvswitch]

stack backtrace:
CPU: 0 PID: 0 Comm: swapper/0 Tainted: G          I  3.14.0-rc8-00007-g632b06a #1
Hardware name:                  /DX58SO, BIOS SOX5810J.86A.5599.2012.0529.2218 05/29/2012
 0000000000000000 0fcf20709903df0c ffff88042d603808 ffffffff817cfe3c
 ffffffff81c134c0 ffff88042d603858 ffffffff817cb6da 0000000000000005
 ffffffff00000001 ffff880400000000 0000000000000006 ffffffff81c134c0
Call Trace:
   [] dump_stack+0x4d/0x66
 [] print_usage_bug+0x1f4/0x205
 [] ? check_usage_backwards+0x180/0x180
 [] mark_lock+0x223/0x2b0
 [] __lock_acquire+0x623/0x1c40
 [] ? __lock_is_held+0x57/0x80
 [] ? masked_flow_lookup+0x236/0x250 [openvswitch]
 [] lock_acquire+0xa2/0x1d0
 [] ? ovs_flow_stats_update+0x51/0xd0 [openvswitch]
 [] _raw_spin_lock+0x3e/0x80
 [] ? ovs_flow_stats_update+0x51/0xd0 [openvswitch]
 [] ovs_flow_stats_update+0x51/0xd0 [openvswitch]
 [] ovs_dp_process_received_packet+0x84/0x120 [openvswitch]
 [] ? __lock_acquire+0x347/0x1c40
 [] ovs_vport_receive+0x2a/0x30 [openvswitch]
 [] internal_dev_xmit+0x68/0x110 [openvswitch]
 [] ? internal_dev_xmit+0x5/0x110 [openvswitch]
 [] dev_hard_start_xmit+0x2e6/0x8b0
 [] __dev_queue_xmit+0x417/0x9b0
 [] ? __dev_queue_xmit+0x5/0x9b0
 [] ? ip6_finish_output2+0x4f0/0x840
 [] dev_queue_xmit+0x10/0x20
 [] ip6_finish_output2+0x551/0x840
 [] ? ip6_finish_output+0x9a/0x220
 [] ip6_finish_output+0x9a/0x220
 [] ip6_output+0x4f/0x1f0
 [] mld_sendpack+0x1d9/0x4a0
 [] mld_send_initial_cr.part.32+0x88/0xa0
 [] ? addrconf_dad_completed+0x220/0x220
 [] ipv6_mc_dad_complete+0x31/0x50
 [] addrconf_dad_completed+0x147/0x220
 [] ? addrconf_dad_completed+0x220/0x220
 [] addrconf_dad_timer+0x19f/0x1c0
 [] call_timer_fn+0x99/0x320
 [] ? call_timer_fn+0x5/0x320
 [] ? addrconf_dad_completed+0x220/0x220
 [] run_timer_softirq+0x254/0x3b0
 [] __do_softirq+0x12d/0x480

Signed-off-by: Flavio Leitner 
Signed-off-by: David S. Miller

core, nfqueue, openvswitch: Orphan frags in skb_zerocopy and handle errors

2014-03-27T19:29:38+00:00

skb_zerocopy can copy elements of the frags array between skbs, but it doesn't
orphan them. Also, it doesn't handle errors, so this patch takes care of that
as well, and modify the callers accordingly. skb_tx_error() is also added to
the callers so they will signal the failed delivery towards the creator of the
skb.

Signed-off-by: Zoltan Kiss 
Signed-off-by: David S. Miller

openvswitch: Correctly report flow used times for first 5 minutes after boot.

2014-03-20T17:45:21+00:00

The kernel starts out its "jiffies" timer as 5 minutes below zero, as
shown in include/linux/jiffies.h:

  /*
   * Have the 32 bit jiffies value wrap 5 minutes after boot
   * so jiffies wrap bugs show up earlier.
   */
  #define INITIAL_JIFFIES ((unsigned long)(unsigned int) (-300*HZ))

The loop in ovs_flow_stats_get() starts out with 'used' set to 0, then
takes any "later" time.  This means that for the first five minutes after
boot, flows will always be reported as never used, since 0 is greater than
any time already seen.

Signed-off-by: Ben Pfaff 
Acked-by: Pravin B Shelar 
Signed-off-by: Jesse Gross

openvswitch: Fix race.

2014-02-16T01:42:29+00:00

ovs_vport_cmd_dump() did rcu_read_lock() only after getting the
datapath, which could have been deleted in between.  Resolved by
taking rcu_read_lock() before the get_dp() call.

Signed-off-by: Jarno Rajahalme 
Signed-off-by: Pravin B Shelar

openvswitch: Read tcp flags only then the tranport header is present.

2014-02-16T01:37:45+00:00

Only the first IP fragment can have a TCP header, check for this.

Signed-off-by: Jarno Rajahalme 
Signed-off-by: Jesse Gross

ovs: fix dp check in ovs_dp_reset_user_features

2014-02-16T01:24:19+00:00

This fixes crash when userspace does "ovs-dpctl add-dp dev" where dev is
existing non-dp netdevice.

Introduced by:
commit 44da5ae5fbea4686f667dc854e5ea16814e44c59
"openvswitch: Drop user features if old user space attempted to create datapath"

Signed-off-by: Jiri Pirko 
Signed-off-by: Jesse Gross

openvswitch: Suppress error messages on megaflow updates

2014-02-05T06:32:38+00:00

With subfacets, we'd expect megaflow updates message to carry
the original micro flow. If not, EINVAL is returned and kernel
logs an error message.  Now that the user space subfacet layer is
removed, it is expected that flow updates can arrive with a
micro flow other than the original. Change the return code to
EEXIST and remove the kernel error log message.

Reported-by: Ben Pfaff 
Signed-off-by: Andy Zhou 
Signed-off-by: Jesse Gross

openvswitch: Fix ovs_flow_free() ovs-lock assert.

2014-02-05T06:21:45+00:00

ovs_flow_free() is not called under ovs-lock during packet
execute path (ovs_packet_cmd_execute()). Since packet execute
does not touch flow->mask, there is no need to take that
lock either. So move assert in case where flow->mask is checked.

Found by code inspection.

Signed-off-by: Pravin B Shelar 
Signed-off-by: Jesse Gross