1. 14 Aug, 2013 4 commits
    • Hannes Frederic Sowa's avatar
      xfrm: make local error reporting more robust · 628e341f
      Hannes Frederic Sowa authored
      In xfrm4 and xfrm6 we need to take care about sockets of the other
      address family. This could happen because a 6in4 or 4in6 tunnel could
      get protected by ipsec.
      
      Because we don't want to have a run-time dependency on ipv6 when only
      using ipv4 xfrm we have to embed a pointer to the correct local_error
      function in xfrm_state_afinet and look it up when returning an error
      depending on the socket address family.
      
      Thanks to vi0ss for the great bug report:
      <https://bugzilla.kernel.org/show_bug.cgi?id=58691>
      
      v2:
      a) fix two more unsafe interpretations of skb->sk as ipv6 socket
         (xfrm6_local_dontfrag and __xfrm6_output)
      v3:
      a) add an EXPORT_SYMBOL_GPL(xfrm_local_error) to fix a link error when
         building ipv6 as a module (thanks to Steffen Klassert)
      
      Reported-by: <vi0oss@gmail.com>
      Cc: Steffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: default avatarHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      628e341f
    • 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
  2. 13 Aug, 2013 13 commits
  3. 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
  4. 10 Aug, 2013 5 commits
  5. 09 Aug, 2013 7 commits
  6. 08 Aug, 2013 3 commits
  7. 07 Aug, 2013 3 commits
  8. 05 Aug, 2013 2 commits