1. 15 Aug, 2013 9 commits
  2. 14 Aug, 2013 6 commits
    • Jesse Gross's avatar
      openvswitch: Reset tunnel key between input and output. · 36bf5cc6
      Jesse Gross authored
      It doesn't make sense to output a tunnel packet using the same
      parameters that it was received with since that will generally
      just result in the packet going back to us. As a result, userspace
      assumes that the tunnel key is cleared when transitioning through
      the switch. In the majority of cases this doesn't matter since a
      packet is either going to a tunnel port (in which the key is
      overwritten with new values) or to a non-tunnel port (in which
      case the key is ignored). However, it's theoreticaly possible that
      userspace could rely on the documented behavior, so this corrects
      it.
      Signed-off-by: default avatarJesse Gross <jesse@nicira.com>
      36bf5cc6
    • Pravin B Shelar's avatar
      openvswitch: Use correct type while allocating flex array. · 42415c90
      Pravin B Shelar authored
      Flex array is used to allocate hash buckets which is type struct
      hlist_head, but we use `struct hlist_head *` to calculate
      array size.  Since hlist_head is of size pointer it works fine.
      
      Following patch use correct type.
      Signed-off-by: default avatarPravin B Shelar <pshelar@nicira.com>
      Signed-off-by: default avatarJesse Gross <jesse@nicira.com>
      42415c90
    • Jesse Gross's avatar
      openvswitch: Fix bad merge resolution. · 30444e98
      Jesse Gross authored
      git silently included an extra hunk in vport_cmd_set() during
      automatic merging. This code is unreachable so it does not actually
      introduce a problem but it is clearly incorrect.
      Signed-off-by: default avatarJesse Gross <jesse@nicira.com>
      30444e98
    • Weiping Pan's avatar
      tun: compare with 0 instead of total_len · d9bf5f13
      Weiping Pan authored
      Since we set "len = total_len" in the beginning of tun_get_user(),
      so we should compare the new len with 0, instead of total_len,
      or the if statement always returns false.
      Signed-off-by: default avatarWeiping Pan <wpan@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d9bf5f13
    • Asbjoern Sloth Toennesen's avatar
      rtnetlink: rtnl_bridge_getlink: Call nlmsg_find_attr() with ifinfomsg header · 3e805ad2
      Asbjoern Sloth Toennesen authored
      Fix the iproute2 command `bridge vlan show`, after switching from
      rtgenmsg to ifinfomsg.
      
      Let's start with a little history:
      
      Feb 20:   Vlad Yasevich got his VLAN-aware bridge patchset included in
                the 3.9 merge window.
                In the kernel commit 6cbdceeb, he added attribute support to
                bridge GETLINK requests sent with rtgenmsg.
      
      Mar 6th:  Vlad got this iproute2 reference implementation of the bridge
                vlan netlink interface accepted (iproute2 9eff0e5c)
      
      Apr 25th: iproute2 switched from using rtgenmsg to ifinfomsg (63338dca)
                http://patchwork.ozlabs.org/patch/239602/
                http://marc.info/?t=136680900700007
      
      Apr 28th: Linus released 3.9
      
      Apr 30th: Stephen released iproute2 3.9.0
      
      The `bridge vlan show` command haven't been working since the switch to
      ifinfomsg, or in a released version of iproute2. Since the kernel side
      only supports rtgenmsg, which iproute2 switched away from just prior to
      the iproute2 3.9.0 release.
      
      I haven't been able to find any documentation, about neither rtgenmsg
      nor ifinfomsg, and in which situation to use which, but kernel commit
      88c5b5ce seams to suggest that ifinfomsg should be used.
      
      Fixing this in kernel will break compatibility, but I doubt that anybody
      have been using it due to this bug in the user space reference
      implementation, at least not without noticing this bug. That said the
      functionality is still fully functional in 3.9, when reversing iproute2
      commit 63338dca.
      
      This could also be fixed in iproute2, but thats an ugly patch that would
      reintroduce rtgenmsg in iproute2, and from searching in netdev it seams
      like rtgenmsg usage is discouraged. I'm assuming that the only reason
      that Vlad implemented the kernel side to use rtgenmsg, was because
      iproute2 was using it at the time.
      Signed-off-by: default avatarAsbjoern Sloth Toennesen <ast@fiberby.net>
      Reviewed-by: default avatarVlad Yasevich <vyasevich@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3e805ad2
    • Alexey Brodkin's avatar
      ethernet/arc/arc_emac - fix NAPI "work > weight" warning · 9cff866e
      Alexey Brodkin authored
      Initially I improperly set a boundary for maximum number of input
      packets to process on NAPI poll ("work") so it might be more than
      expected amount ("weight").
      
      This was really harmless but seeing WARN_ON_ONCE on every device boot is
      not nice. So trivial fix ("<" instead of "<=") is here.
      Signed-off-by: default avatarAlexey Brodkin <abrodkin@synopsys.com>
      
      Cc: Vineet Gupta <vgupta@synopsys.com>
      Cc: Mischa Jonker <mjonker@synopsys.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Grant Likely <grant.likely@linaro.org>
      Cc: Rob Herring <rob.herring@calxeda.com>
      Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9cff866e
  3. 13 Aug, 2013 13 commits
  4. 12 Aug, 2013 3 commits
    • dingtianhong's avatar
      tipc: avoid possible deadlock while enable and disable bearer · d4cca39d
      dingtianhong authored
      We met lockdep warning when enable and disable the bearer for commands such as:
      
      tipc-config -netid=1234 -addr=1.1.3 -be=eth:eth0
      tipc-config -netid=1234 -addr=1.1.3 -bd=eth:eth0
      
      ---------------------------------------------------
      
      [  327.693595] ======================================================
      [  327.693994] [ INFO: possible circular locking dependency detected ]
      [  327.694519] 3.11.0-rc3-wwd-default #4 Tainted: G           O
      [  327.694882] -------------------------------------------------------
      [  327.695385] tipc-config/5825 is trying to acquire lock:
      [  327.695754]  (((timer))#2){+.-...}, at: [<ffffffff8105be80>] del_timer_sync+0x0/0xd0
      [  327.696018]
      [  327.696018] but task is already holding lock:
      [  327.696018]  (&(&b_ptr->lock)->rlock){+.-...}, at: [<ffffffffa02be58d>] bearer_disable+  0xdd/0x120 [tipc]
      [  327.696018]
      [  327.696018] which lock already depends on the new lock.
      [  327.696018]
      [  327.696018]
      [  327.696018] the existing dependency chain (in reverse order) is:
      [  327.696018]
      [  327.696018] -> #1 (&(&b_ptr->lock)->rlock){+.-...}:
      [  327.696018]        [<ffffffff810b3b4d>] validate_chain+0x6dd/0x870
      [  327.696018]        [<ffffffff810b40bb>] __lock_acquire+0x3db/0x670
      [  327.696018]        [<ffffffff810b4453>] lock_acquire+0x103/0x130
      [  327.696018]        [<ffffffff814d65b1>] _raw_spin_lock_bh+0x41/0x80
      [  327.696018]        [<ffffffffa02c5d48>] disc_timeout+0x18/0xd0 [tipc]
      [  327.696018]        [<ffffffff8105b92a>] call_timer_fn+0xda/0x1e0
      [  327.696018]        [<ffffffff8105bcd7>] run_timer_softirq+0x2a7/0x2d0
      [  327.696018]        [<ffffffff8105379a>] __do_softirq+0x16a/0x2e0
      [  327.696018]        [<ffffffff81053a35>] irq_exit+0xd5/0xe0
      [  327.696018]        [<ffffffff81033005>] smp_apic_timer_interrupt+0x45/0x60
      [  327.696018]        [<ffffffff814df4af>] apic_timer_interrupt+0x6f/0x80
      [  327.696018]        [<ffffffff8100b70e>] arch_cpu_idle+0x1e/0x30
      [  327.696018]        [<ffffffff810a039d>] cpu_idle_loop+0x1fd/0x280
      [  327.696018]        [<ffffffff810a043e>] cpu_startup_entry+0x1e/0x20
      [  327.696018]        [<ffffffff81031589>] start_secondary+0x89/0x90
      [  327.696018]
      [  327.696018] -> #0 (((timer))#2){+.-...}:
      [  327.696018]        [<ffffffff810b33fe>] check_prev_add+0x43e/0x4b0
      [  327.696018]        [<ffffffff810b3b4d>] validate_chain+0x6dd/0x870
      [  327.696018]        [<ffffffff810b40bb>] __lock_acquire+0x3db/0x670
      [  327.696018]        [<ffffffff810b4453>] lock_acquire+0x103/0x130
      [  327.696018]        [<ffffffff8105bebd>] del_timer_sync+0x3d/0xd0
      [  327.696018]        [<ffffffffa02c5855>] tipc_disc_delete+0x15/0x30 [tipc]
      [  327.696018]        [<ffffffffa02be59f>] bearer_disable+0xef/0x120 [tipc]
      [  327.696018]        [<ffffffffa02be74f>] tipc_disable_bearer+0x2f/0x60 [tipc]
      [  327.696018]        [<ffffffffa02bfb32>] tipc_cfg_do_cmd+0x2e2/0x550 [tipc]
      [  327.696018]        [<ffffffffa02c8c79>] handle_cmd+0x49/0xe0 [tipc]
      [  327.696018]        [<ffffffff8143e898>] genl_family_rcv_msg+0x268/0x340
      [  327.696018]        [<ffffffff8143ed30>] genl_rcv_msg+0x70/0xd0
      [  327.696018]        [<ffffffff8143d4c9>] netlink_rcv_skb+0x89/0xb0
      [  327.696018]        [<ffffffff8143e617>] genl_rcv+0x27/0x40
      [  327.696018]        [<ffffffff8143d21e>] netlink_unicast+0x15e/0x1b0
      [  327.696018]        [<ffffffff8143ddcf>] netlink_sendmsg+0x22f/0x400
      [  327.696018]        [<ffffffff813f7836>] __sock_sendmsg+0x66/0x80
      [  327.696018]        [<ffffffff813f7957>] sock_aio_write+0x107/0x120
      [  327.696018]        [<ffffffff8117f76d>] do_sync_write+0x7d/0xc0
      [  327.696018]        [<ffffffff8117fc56>] vfs_write+0x186/0x190
      [  327.696018]        [<ffffffff811803e0>] SyS_write+0x60/0xb0
      [  327.696018]        [<ffffffff814de852>] system_call_fastpath+0x16/0x1b
      [  327.696018]
      [  327.696018] other info that might help us debug this:
      [  327.696018]
      [  327.696018]  Possible unsafe locking scenario:
      [  327.696018]
      [  327.696018]        CPU0                    CPU1
      [  327.696018]        ----                    ----
      [  327.696018]   lock(&(&b_ptr->lock)->rlock);
      [  327.696018]                                lock(((timer))#2);
      [  327.696018]                                lock(&(&b_ptr->lock)->rlock);
      [  327.696018]   lock(((timer))#2);
      [  327.696018]
      [  327.696018]  *** DEADLOCK ***
      [  327.696018]
      [  327.696018] 5 locks held by tipc-config/5825:
      [  327.696018]  #0:  (cb_lock){++++++}, at: [<ffffffff8143e608>] genl_rcv+0x18/0x40
      [  327.696018]  #1:  (genl_mutex){+.+.+.}, at: [<ffffffff8143ed66>] genl_rcv_msg+0xa6/0xd0
      [  327.696018]  #2:  (config_mutex){+.+.+.}, at: [<ffffffffa02bf889>] tipc_cfg_do_cmd+0x39/ 0x550 [tipc]
      [  327.696018]  #3:  (tipc_net_lock){++.-..}, at: [<ffffffffa02be738>] tipc_disable_bearer+ 0x18/0x60 [tipc]
      [  327.696018]  #4:  (&(&b_ptr->lock)->rlock){+.-...}, at: [<ffffffffa02be58d>]             bearer_disable+0xdd/0x120 [tipc]
      [  327.696018]
      [  327.696018] stack backtrace:
      [  327.696018] CPU: 2 PID: 5825 Comm: tipc-config Tainted: G           O 3.11.0-rc3-wwd-    default #4
      [  327.696018] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
      [  327.696018]  00000000ffffffff ffff880037fa77a8 ffffffff814d03dd 0000000000000000
      [  327.696018]  ffff880037fa7808 ffff880037fa77e8 ffffffff810b1c4f 0000000037fa77e8
      [  327.696018]  ffff880037fa7808 ffff880037e4db40 0000000000000000 ffff880037e4e318
      [  327.696018] Call Trace:
      [  327.696018]  [<ffffffff814d03dd>] dump_stack+0x4d/0xa0
      [  327.696018]  [<ffffffff810b1c4f>] print_circular_bug+0x10f/0x120
      [  327.696018]  [<ffffffff810b33fe>] check_prev_add+0x43e/0x4b0
      [  327.696018]  [<ffffffff810b3b4d>] validate_chain+0x6dd/0x870
      [  327.696018]  [<ffffffff81087a28>] ? sched_clock_cpu+0xd8/0x110
      [  327.696018]  [<ffffffff810b40bb>] __lock_acquire+0x3db/0x670
      [  327.696018]  [<ffffffff810b4453>] lock_acquire+0x103/0x130
      [  327.696018]  [<ffffffff8105be80>] ? try_to_del_timer_sync+0x70/0x70
      [  327.696018]  [<ffffffff8105bebd>] del_timer_sync+0x3d/0xd0
      [  327.696018]  [<ffffffff8105be80>] ? try_to_del_timer_sync+0x70/0x70
      [  327.696018]  [<ffffffffa02c5855>] tipc_disc_delete+0x15/0x30 [tipc]
      [  327.696018]  [<ffffffffa02be59f>] bearer_disable+0xef/0x120 [tipc]
      [  327.696018]  [<ffffffffa02be74f>] tipc_disable_bearer+0x2f/0x60 [tipc]
      [  327.696018]  [<ffffffffa02bfb32>] tipc_cfg_do_cmd+0x2e2/0x550 [tipc]
      [  327.696018]  [<ffffffff81218783>] ? security_capable+0x13/0x20
      [  327.696018]  [<ffffffffa02c8c79>] handle_cmd+0x49/0xe0 [tipc]
      [  327.696018]  [<ffffffff8143e898>] genl_family_rcv_msg+0x268/0x340
      [  327.696018]  [<ffffffff8143ed30>] genl_rcv_msg+0x70/0xd0
      [  327.696018]  [<ffffffff8143ecc0>] ? genl_lock+0x20/0x20
      [  327.696018]  [<ffffffff8143d4c9>] netlink_rcv_skb+0x89/0xb0
      [  327.696018]  [<ffffffff8143e608>] ? genl_rcv+0x18/0x40
      [  327.696018]  [<ffffffff8143e617>] genl_rcv+0x27/0x40
      [  327.696018]  [<ffffffff8143d21e>] netlink_unicast+0x15e/0x1b0
      [  327.696018]  [<ffffffff81289d7c>] ? memcpy_fromiovec+0x6c/0x90
      [  327.696018]  [<ffffffff8143ddcf>] netlink_sendmsg+0x22f/0x400
      [  327.696018]  [<ffffffff813f7836>] __sock_sendmsg+0x66/0x80
      [  327.696018]  [<ffffffff813f7957>] sock_aio_write+0x107/0x120
      [  327.696018]  [<ffffffff813fe29c>] ? release_sock+0x8c/0xa0
      [  327.696018]  [<ffffffff8117f76d>] do_sync_write+0x7d/0xc0
      [  327.696018]  [<ffffffff8117fa24>] ? rw_verify_area+0x54/0x100
      [  327.696018]  [<ffffffff8117fc56>] vfs_write+0x186/0x190
      [  327.696018]  [<ffffffff811803e0>] SyS_write+0x60/0xb0
      [  327.696018]  [<ffffffff814de852>] system_call_fastpath+0x16/0x1b
      
      -----------------------------------------------------------------------
      
      The problem is that the tipc_link_delete() will cancel the timer disc_timeout() when
      the b_ptr->lock is hold, but the disc_timeout() still call b_ptr->lock to finish the
      work, so the dead lock occurs.
      
      We should unlock the b_ptr->lock when del the disc_timeout().
      
      Remove link_timeout() still met the same problem, the patch:
      
      http://article.gmane.org/gmane.network.tipc.general/4380
      
      fix the problem, so no need to send patch for fix link_timeout() deadlock warming.
      Signed-off-by: default avatarWang Weidong <wangweidong1@huawei.com>
      Signed-off-by: default avatarDing Tianhong <dingtianhong@huawei.com>
      Acked-by: default avatarYing Xue <ying.xue@windriver.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d4cca39d
    • Stephane Grosjean's avatar
      can: pcan_usb: fix wrong memcpy() bytes length · 3c322a56
      Stephane Grosjean authored
      Fix possibly wrong memcpy() bytes length since some CAN records received from
      PCAN-USB could define a DLC field in range [9..15].
      In that case, the real DLC value MUST be used to move forward the record pointer
      but, only 8 bytes max. MUST be copied into the data field of the struct
      can_frame object of the skb given to the network core.
      
      Cc: linux-stable <stable@vger.kernel.org>
      Signed-off-by: default avatarStephane Grosjean <s.grosjean@peak-system.com>
      Signed-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3c322a56
    • Eric Dumazet's avatar
      macvtap: fix two races · 29d79196
      Eric Dumazet authored
      Since commit ac4e4af1 ("macvtap: Consistently use rcu functions"),
      Thomas gets two different warnings :
      
      BUG: using smp_processor_id() in preemptible [00000000] code: vhost-45891/45892
      caller is macvtap_do_read+0x45c/0x600 [macvtap]
      CPU: 1 PID: 45892 Comm: vhost-45891 Not tainted 3.11.0-bisecttest #13
      Call Trace:
      ([<00000000001126ee>] show_trace+0x126/0x144)
       [<00000000001127d2>] show_stack+0xc6/0xd4
       [<000000000068bcec>] dump_stack+0x74/0xd8
       [<0000000000481066>] debug_smp_processor_id+0xf6/0x114
       [<000003ff802e9a18>] macvtap_do_read+0x45c/0x600 [macvtap]
       [<000003ff802e9c1c>] macvtap_recvmsg+0x60/0x88 [macvtap]
       [<000003ff80318c5e>] handle_rx+0x5b2/0x800 [vhost_net]
       [<000003ff8028f77c>] vhost_worker+0x15c/0x1c4 [vhost]
       [<000000000015f3ac>] kthread+0xd8/0xe4
       [<00000000006934a6>] kernel_thread_starter+0x6/0xc
       [<00000000006934a0>] kernel_thread_starter+0x0/0xc
      
      And
      
      BUG: using smp_processor_id() in preemptible [00000000] code: vhost-45897/45898
      caller is macvlan_start_xmit+0x10a/0x1b4 [macvlan]
      CPU: 1 PID: 45898 Comm: vhost-45897 Not tainted 3.11.0-bisecttest #16
      Call Trace:
      ([<00000000001126ee>] show_trace+0x126/0x144)
       [<00000000001127d2>] show_stack+0xc6/0xd4
       [<000000000068bdb8>] dump_stack+0x74/0xd4
       [<0000000000481132>] debug_smp_processor_id+0xf6/0x114
       [<000003ff802b72ca>] macvlan_start_xmit+0x10a/0x1b4 [macvlan]
       [<000003ff802ea69a>] macvtap_get_user+0x982/0xbc4 [macvtap]
       [<000003ff802ea92a>] macvtap_sendmsg+0x4e/0x60 [macvtap]
       [<000003ff8031947c>] handle_tx+0x494/0x5ec [vhost_net]
       [<000003ff8028f77c>] vhost_worker+0x15c/0x1c4 [vhost]
       [<000000000015f3ac>] kthread+0xd8/0xe4
       [<000000000069356e>] kernel_thread_starter+0x6/0xc
       [<0000000000693568>] kernel_thread_starter+0x0/0xc
      2 locks held by vhost-45897/45898:
       #0:  (&vq->mutex){+.+.+.}, at: [<000003ff8031903c>] handle_tx+0x54/0x5ec [vhost_net]
       #1:  (rcu_read_lock){.+.+..}, at: [<000003ff802ea53c>] macvtap_get_user+0x824/0xbc4 [macvtap]
      
      In the first case, macvtap_put_user() calls macvlan_count_rx()
      in a preempt-able context, and this is not allowed.
      
      In the second case, macvtap_get_user() calls
      macvlan_start_xmit() with BH enabled, and this is not allowed.
      Reported-by: default avatarThomas Huth <thuth@linux.vnet.ibm.com>
      Bisected-by: default avatarThomas Huth <thuth@linux.vnet.ibm.com>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Tested-by: default avatarThomas Huth <thuth@linux.vnet.ibm.com>
      Cc: Vlad Yasevich <vyasevic@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      29d79196
  5. 10 Aug, 2013 5 commits
  6. 09 Aug, 2013 4 commits