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

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

openvswitch: Fix ovs_dp_cmd_msg_size()

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

commit 43d4be9cb55f3bac5253e9289996fd9d735531db (openvswitch: Allow user space
to announce ability to accept unaligned Netlink messages) introduced
OVS_DP_ATTR_USER_FEATURES netlink attribute in datapath responses,
but the attribute size was not taken into account in ovs_dp_cmd_msg_size().

Signed-off-by: Daniele Di Proietto 
Signed-off-by: Jesse Gross

openvswitch: Fix kernel panic on ovs_flow_free

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

Both mega flow mask's reference counter and per flow table mask list
should only be accessed when holding ovs_mutex() lock. However
this is not true with ovs_flow_table_flush(). The patch fixes this bug.

Reported-by: Joe Stringer 
Signed-off-by: Andy Zhou 
Signed-off-by: Jesse Gross