1. 03 5月, 2012 1 次提交
    • S
      net: l2tp: unlock socket lock before returning from l2tp_ip_sendmsg · 84768edb
      Sasha Levin 提交于
      l2tp_ip_sendmsg could return without releasing socket lock, making it all the
      way to userspace, and generating the following warning:
      
      [  130.891594] ================================================
      [  130.894569] [ BUG: lock held when returning to user space! ]
      [  130.897257] 3.4.0-rc5-next-20120501-sasha #104 Tainted: G        W
      [  130.900336] ------------------------------------------------
      [  130.902996] trinity/8384 is leaving the kernel with locks still held!
      [  130.906106] 1 lock held by trinity/8384:
      [  130.907924]  #0:  (sk_lock-AF_INET){+.+.+.}, at: [<ffffffff82b9503f>] l2tp_ip_sendmsg+0x2f/0x550
      
      Introduced by commit 2f16270f ("l2tp: Fix locking in l2tp_ip.c").
      Signed-off-by: NSasha Levin <levinsasha928@gmail.com>
      Acked-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      84768edb
  2. 01 5月, 2012 9 次提交
  3. 29 4月, 2012 1 次提交
  4. 16 4月, 2012 1 次提交
  5. 14 4月, 2012 1 次提交
    • E
      udp: intoduce udp_encap_needed static_key · 447167bf
      Eric Dumazet 提交于
      Most machines dont use UDP encapsulation (L2TP)
      
      Adds a static_key so that udp_queue_rcv_skb() doesnt have to perform a
      test if L2TP never setup the encap_rcv on a socket.
      
      Idea of this patch came after Simon Horman proposal to add a hook on TCP
      as well.
      
      If static_key is not yet enabled, the fast path does a single JMP .
      
      When static_key is enabled, JMP destination is patched to reach the real
      encap_type/encap_rcv logic, possibly adding cache misses.
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Cc: Simon Horman <horms@verge.net.au>
      Cc: dev@openvswitch.org
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      447167bf
  6. 13 4月, 2012 2 次提交
  7. 02 4月, 2012 1 次提交
  8. 22 3月, 2012 1 次提交
  9. 21 3月, 2012 1 次提交
  10. 05 3月, 2012 1 次提交
  11. 16 2月, 2012 1 次提交
  12. 26 1月, 2012 1 次提交
    • J
      l2tp: l2tp_ip - fix possible oops on packet receive · 68315801
      James Chapman 提交于
      When a packet is received on an L2TP IP socket (L2TPv3 IP link
      encapsulation), the l2tpip socket's backlog_rcv function calls
      xfrm4_policy_check(). This is not necessary, since it was called
      before the skb was added to the backlog. With CONFIG_NET_NS enabled,
      xfrm4_policy_check() will oops if skb->dev is null, so this trivial
      patch removes the call.
      
      This bug has always been present, but only when CONFIG_NET_NS is
      enabled does it cause problems. Most users are probably using UDP
      encapsulation for L2TP, hence the problem has only recently
      surfaced.
      
      EIP: 0060:[<c12bb62b>] EFLAGS: 00210246 CPU: 0
      EIP is at l2tp_ip_recvmsg+0xd4/0x2a7
      EAX: 00000001 EBX: d77b5180 ECX: 00000000 EDX: 00200246
      ESI: 00000000 EDI: d63cbd30 EBP: d63cbd18 ESP: d63cbcf4
       DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
      Call Trace:
       [<c1218568>] sock_common_recvmsg+0x31/0x46
       [<c1215c92>] __sock_recvmsg_nosec+0x45/0x4d
       [<c12163a1>] __sock_recvmsg+0x31/0x3b
       [<c1216828>] sock_recvmsg+0x96/0xab
       [<c10b2693>] ? might_fault+0x47/0x81
       [<c10b2693>] ? might_fault+0x47/0x81
       [<c1167fd0>] ? _copy_from_user+0x31/0x115
       [<c121e8c8>] ? copy_from_user+0x8/0xa
       [<c121ebd6>] ? verify_iovec+0x3e/0x78
       [<c1216604>] __sys_recvmsg+0x10a/0x1aa
       [<c1216792>] ? sock_recvmsg+0x0/0xab
       [<c105a99b>] ? __lock_acquire+0xbdf/0xbee
       [<c12d5a99>] ? do_page_fault+0x193/0x375
       [<c10d1200>] ? fcheck_files+0x9b/0xca
       [<c10d1259>] ? fget_light+0x2a/0x9c
       [<c1216bbb>] sys_recvmsg+0x2b/0x43
       [<c1218145>] sys_socketcall+0x16d/0x1a5
       [<c11679f0>] ? trace_hardirqs_on_thunk+0xc/0x10
       [<c100305f>] sysenter_do_call+0x12/0x38
      Code: c6 05 8c ea a8 c1 01 e8 0c d4 d9 ff 85 f6 74 07 3e ff 86 80 00 00 00 b9 17 b6 2b c1 ba 01 00 00 00 b8 78 ed 48 c1 e8 23 f6 d9 ff <ff> 76 0c 68 28 e3 30 c1 68 2d 44 41 c1 e8 89 57 01 00 83 c4 0c
      Signed-off-by: NJames Chapman <jchapman@katalix.com>
      Acked-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      68315801
  13. 27 11月, 2011 1 次提交
  14. 09 11月, 2011 1 次提交
  15. 04 11月, 2011 1 次提交
  16. 19 10月, 2011 2 次提交
  17. 28 7月, 2011 1 次提交
    • N
      net: Audit drivers to identify those needing IFF_TX_SKB_SHARING cleared · 550fd08c
      Neil Horman 提交于
      After the last patch, We are left in a state in which only drivers calling
      ether_setup have IFF_TX_SKB_SHARING set (we assume that drivers touching real
      hardware call ether_setup for their net_devices and don't hold any state in
      their skbs.  There are a handful of drivers that violate this assumption of
      course, and need to be fixed up.  This patch identifies those drivers, and marks
      them as not being able to support the safe transmission of skbs by clearning the
      IFF_TX_SKB_SHARING flag in priv_flags
      Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
      CC: Karsten Keil <isdn@linux-pingi.de>
      CC: "David S. Miller" <davem@davemloft.net>
      CC: Jay Vosburgh <fubar@us.ibm.com>
      CC: Andy Gospodarek <andy@greyhouse.net>
      CC: Patrick McHardy <kaber@trash.net>
      CC: Krzysztof Halasa <khc@pm.waw.pl>
      CC: "John W. Linville" <linville@tuxdriver.com>
      CC: Greg Kroah-Hartman <gregkh@suse.de>
      CC: Marcel Holtmann <marcel@holtmann.org>
      CC: Johannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      550fd08c
  18. 27 7月, 2011 1 次提交
  19. 14 6月, 2011 1 次提交
  20. 06 6月, 2011 1 次提交
  21. 13 5月, 2011 1 次提交
  22. 09 5月, 2011 4 次提交
  23. 04 5月, 2011 1 次提交
  24. 29 4月, 2011 4 次提交