1. 08 Feb, 2013 1 commit
    • Eric Dumazet's avatar
      l2tp: dont play with skb->truesize · 87c084a9
      Eric Dumazet authored
      
      
      Andrew Savchenko reported a DNS failure and we diagnosed that
      some UDP sockets were unable to send more packets because their
      sk_wmem_alloc was corrupted after a while (tx_queue column in
      following trace)
      
      $ cat /proc/net/udp
        sl  local_address rem_address   st tx_queue rx_queue tr tm->when retrnsmt   uid  timeout inode ref pointer drops
      ...
        459: 00000000:0270 00000000:0000 07 00000000:00000000 00:00000000 00000000     0        0 4507 2 ffff88003d612380 0
        466: 00000000:0277 00000000:0000 07 00000000:00000000 00:00000000 00000000     0        0 4802 2 ffff88003d613180 0
        470: 076A070A:007B 00000000:0000 07 FFFF4600:00000000 00:00000000 00000000   123        0 5552 2 ffff880039974380 0
        470: 010213AC:007B 00000000:0000 07 00000000:00000000 00:00000000 00000000     0        0 4986 2 ffff88003dbd3180 0
        470: 010013AC:007B 00000000:0000 07 00000000:00000000 00:00000000 00000000     0        0 4985 2 ffff88003dbd2e00 0
        470: 00FCA8C0:007B 00000000:0000 07 FFFFFB00:00000000 00:00000000 00000000     0        0 4984 2 ffff88003dbd2a80 0
      ...
      
      Playing with skb->truesize is tricky, especially when
      skb is attached to a socket, as we can fool memory charging.
      
      Just remove this code, its not worth trying to be ultra
      precise in xmit path.
      Reported-by: default avatarAndrew Savchenko <bircoph@gmail.com>
      Tested-by: default avatarAndrew Savchenko <bircoph@gmail.com>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: James Chapman <jchapman@katalix.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      87c084a9
  2. 29 Jan, 2013 1 commit
    • Tom Parkin's avatar
      l2tp: prevent l2tp_tunnel_delete racing with userspace close · 80d84ef3
      Tom Parkin authored
      
      
      If a tunnel socket is created by userspace, l2tp hooks the socket destructor
      in order to clean up resources if userspace closes the socket or crashes.  It
      also caches a pointer to the struct sock for use in the data path and in the
      netlink interface.
      
      While it is safe to use the cached sock pointer in the data path, where the
      skb references keep the socket alive, it is not safe to use it elsewhere as
      such access introduces a race with userspace closing the socket.  In
      particular, l2tp_tunnel_delete is prone to oopsing if a multithreaded
      userspace application closes a socket at the same time as sending a netlink
      delete command for the tunnel.
      
      This patch fixes this oops by forcing l2tp_tunnel_delete to explicitly look up
      a tunnel socket held by userspace using sockfd_lookup().
      Signed-off-by: default avatarTom Parkin <tparkin@katalix.com>
      Signed-off-by: default avatarJames Chapman <jchapman@katalix.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      80d84ef3
  3. 04 Sep, 2012 1 commit
    • Eric Dumazet's avatar
      l2tp: fix a lockdep splat · 37159ef2
      Eric Dumazet authored
      
      
      Fixes following lockdep splat :
      
      [ 1614.734896] =============================================
      [ 1614.734898] [ INFO: possible recursive locking detected ]
      [ 1614.734901] 3.6.0-rc3+ #782 Not tainted
      [ 1614.734903] ---------------------------------------------
      [ 1614.734905] swapper/11/0 is trying to acquire lock:
      [ 1614.734907]  (slock-AF_INET){+.-...}, at: [<ffffffffa0209d72>] l2tp_xmit_skb+0x172/0xa50 [l2tp_core]
      [ 1614.734920]
      [ 1614.734920] but task is already holding lock:
      [ 1614.734922]  (slock-AF_INET){+.-...}, at: [<ffffffff815fce23>] tcp_v4_err+0x163/0x6b0
      [ 1614.734932]
      [ 1614.734932] other info that might help us debug this:
      [ 1614.734935]  Possible unsafe locking scenario:
      [ 1614.734935]
      [ 1614.734937]        CPU0
      [ 1614.734938]        ----
      [ 1614.734940]   lock(slock-AF_INET);
      [ 1614.734943]   lock(slock-AF_INET);
      [ 1614.734946]
      [ 1614.734946]  *** DEADLOCK ***
      [ 1614.734946]
      [ 1614.734949]  May be due to missing lock nesting notation
      [ 1614.734949]
      [ 1614.734952] 7 locks held by swapper/11/0:
      [ 1614.734954]  #0:  (rcu_read_lock){.+.+..}, at: [<ffffffff81592801>] __netif_receive_skb+0x251/0xd00
      [ 1614.734964]  #1:  (rcu_read_lock){.+.+..}, at: [<ffffffff815d319c>] ip_local_deliver_finish+0x4c/0x4e0
      [ 1614.734972]  #2:  (rcu_read_lock){.+.+..}, at: [<ffffffff8160d116>] icmp_socket_deliver+0x46/0x230
      [ 1614.734982]  #3:  (slock-AF_INET){+.-...}, at: [<ffffffff815fce23>] tcp_v4_err+0x163/0x6b0
      [ 1614.734989]  #4:  (rcu_read_lock){.+.+..}, at: [<ffffffff815da240>] ip_queue_xmit+0x0/0x680
      [ 1614.734997]  #5:  (rcu_read_lock_bh){.+....}, at: [<ffffffff815d9925>] ip_finish_output+0x135/0x890
      [ 1614.735004]  #6:  (rcu_read_lock_bh){.+....}, at: [<ffffffff81595680>] dev_queue_xmit+0x0/0xe00
      [ 1614.735012]
      [ 1614.735012] stack backtrace:
      [ 1614.735016] Pid: 0, comm: swapper/11 Not tainted 3.6.0-rc3+ #782
      [ 1614.735018] Call Trace:
      [ 1614.735020]  <IRQ>  [<ffffffff810a50ac>] __lock_acquire+0x144c/0x1b10
      [ 1614.735033]  [<ffffffff810a334b>] ? check_usage+0x9b/0x4d0
      [ 1614.735037]  [<ffffffff810a6762>] ? mark_held_locks+0x82/0x130
      [ 1614.735042]  [<ffffffff810a5df0>] lock_acquire+0x90/0x200
      [ 1614.735047]  [<ffffffffa0209d72>] ? l2tp_xmit_skb+0x172/0xa50 [l2tp_core]
      [ 1614.735051]  [<ffffffff810a69ad>] ? trace_hardirqs_on+0xd/0x10
      [ 1614.735060]  [<ffffffff81749b31>] _raw_spin_lock+0x41/0x50
      [ 1614.735065]  [<ffffffffa0209d72>] ? l2tp_xmit_skb+0x172/0xa50 [l2tp_core]
      [ 1614.735069]  [<ffffffffa0209d72>] l2tp_xmit_skb+0x172/0xa50 [l2tp_core]
      [ 1614.735075]  [<ffffffffa014f7f2>] l2tp_eth_dev_xmit+0x32/0x60 [l2tp_eth]
      [ 1614.735079]  [<ffffffff81595112>] dev_hard_start_xmit+0x502/0xa70
      [ 1614.735083]  [<ffffffff81594c6e>] ? dev_hard_start_xmit+0x5e/0xa70
      [ 1614.735087]  [<ffffffff815957c1>] ? dev_queue_xmit+0x141/0xe00
      [ 1614.735093]  [<ffffffff815b622e>] sch_direct_xmit+0xfe/0x290
      [ 1614.735098]  [<ffffffff81595865>] dev_queue_xmit+0x1e5/0xe00
      [ 1614.735102]  [<ffffffff81595680>] ? dev_hard_start_xmit+0xa70/0xa70
      [ 1614.735106]  [<ffffffff815b4daa>] ? eth_header+0x3a/0xf0
      [ 1614.735111]  [<ffffffff8161d33e>] ? fib_get_table+0x2e/0x280
      [ 1614.735117]  [<ffffffff8160a7e2>] arp_xmit+0x22/0x60
      [ 1614.735121]  [<ffffffff8160a863>] arp_send+0x43/0x50
      [ 1614.735125]  [<ffffffff8160b82f>] arp_solicit+0x18f/0x450
      [ 1614.735132]  [<ffffffff8159d9da>] neigh_probe+0x4a/0x70
      [ 1614.735137]  [<ffffffff815a191a>] __neigh_event_send+0xea/0x300
      [ 1614.735141]  [<ffffffff815a1c93>] neigh_resolve_output+0x163/0x260
      [ 1614.735146]  [<ffffffff815d9cf5>] ip_finish_output+0x505/0x890
      [ 1614.735150]  [<ffffffff815d9925>] ? ip_finish_output+0x135/0x890
      [ 1614.735154]  [<ffffffff815dae79>] ip_output+0x59/0xf0
      [ 1614.735158]  [<ffffffff815da1cd>] ip_local_out+0x2d/0xa0
      [ 1614.735162]  [<ffffffff815da403>] ip_queue_xmit+0x1c3/0x680
      [ 1614.735165]  [<ffffffff815da240>] ? ip_local_out+0xa0/0xa0
      [ 1614.735172]  [<ffffffff815f4402>] tcp_transmit_skb+0x402/0xa60
      [ 1614.735177]  [<ffffffff815f5a11>] tcp_retransmit_skb+0x1a1/0x620
      [ 1614.735181]  [<ffffffff815f7e93>] tcp_retransmit_timer+0x393/0x960
      [ 1614.735185]  [<ffffffff815fce23>] ? tcp_v4_err+0x163/0x6b0
      [ 1614.735189]  [<ffffffff815fd317>] tcp_v4_err+0x657/0x6b0
      [ 1614.735194]  [<ffffffff8160d116>] ? icmp_socket_deliver+0x46/0x230
      [ 1614.735199]  [<ffffffff8160d19e>] icmp_socket_deliver+0xce/0x230
      [ 1614.735203]  [<ffffffff8160d116>] ? icmp_socket_deliver+0x46/0x230
      [ 1614.735208]  [<ffffffff8160d464>] icmp_unreach+0xe4/0x2c0
      [ 1614.735213]  [<ffffffff8160e520>] icmp_rcv+0x350/0x4a0
      [ 1614.735217]  [<ffffffff815d3285>] ip_local_deliver_finish+0x135/0x4e0
      [ 1614.735221]  [<ffffffff815d319c>] ? ip_local_deliver_finish+0x4c/0x4e0
      [ 1614.735225]  [<ffffffff815d3ffa>] ip_local_deliver+0x4a/0x90
      [ 1614.735229]  [<ffffffff815d37b7>] ip_rcv_finish+0x187/0x730
      [ 1614.735233]  [<ffffffff815d425d>] ip_rcv+0x21d/0x300
      [ 1614.735237]  [<ffffffff81592a1b>] __netif_receive_skb+0x46b/0xd00
      [ 1614.735241]  [<ffffffff81592801>] ? __netif_receive_skb+0x251/0xd00
      [ 1614.735245]  [<ffffffff81593368>] process_backlog+0xb8/0x180
      [ 1614.735249]  [<ffffffff81593cf9>] net_rx_action+0x159/0x330
      [ 1614.735257]  [<ffffffff810491f0>] __do_softirq+0xd0/0x3e0
      [ 1614.735264]  [<ffffffff8109ed24>] ? tick_program_event+0x24/0x30
      [ 1614.735270]  [<ffffffff8175419c>] call_softirq+0x1c/0x30
      [ 1614.735278]  [<ffffffff8100425d>] do_softirq+0x8d/0xc0
      [ 1614.735282]  [<ffffffff8104983e>] irq_exit+0xae/0xe0
      [ 1614.735287]  [<ffffffff8175494e>] smp_apic_timer_interrupt+0x6e/0x99
      [ 1614.735291]  [<ffffffff81753a1c>] apic_timer_interrupt+0x6c/0x80
      [ 1614.735293]  <EOI>  [<ffffffff810a14ad>] ? trace_hardirqs_off+0xd/0x10
      [ 1614.735306]  [<ffffffff81336f85>] ? intel_idle+0xf5/0x150
      [ 1614.735310]  [<ffffffff81336f7e>] ? intel_idle+0xee/0x150
      [ 1614.735317]  [<ffffffff814e6ea9>] cpuidle_enter+0x19/0x20
      [ 1614.735321]  [<ffffffff814e7538>] cpuidle_idle_call+0xa8/0x630
      [ 1614.735327]  [<ffffffff8100c1ba>] cpu_idle+0x8a/0xe0
      [ 1614.735333]  [<ffffffff8173762e>] start_secondary+0x220/0x222
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      37159ef2
  4. 30 Aug, 2012 1 commit
  5. 29 Jun, 2012 1 commit
  6. 17 May, 2012 1 commit
  7. 11 May, 2012 2 commits
    • James Chapman's avatar
      l2tp: fix data packet sequence number handling · d301e325
      James Chapman authored
      
      
      If enabled, L2TP data packets have sequence numbers which a receiver
      can use to drop out of sequence frames or try to reorder them. The
      first frame has sequence number 0, but the L2TP code currently expects
      it to be 1. This results in the first data frame being handled as out
      of sequence.
      
      This one-line patch fixes the problem.
      Signed-off-by: default avatarJames Chapman <jchapman@katalix.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d301e325
    • James Chapman's avatar
      l2tp: fix reorder timeout recovery · 38d40b3f
      James Chapman authored
      
      
      When L2TP data packet reordering is enabled, packets are held in a
      queue while waiting for out-of-sequence packets. If a packet gets
      lost, packets will be held until the reorder timeout expires, when we
      are supposed to then advance to the sequence number of the next packet
      but we don't currently do so. As a result, the data channel is stuck
      because we are waiting for a packet that will never arrive - all
      packets age out and none are passed.
      
      The fix is to add a flag to the session context, which is set when the
      reorder timeout expires and tells the receive code to reset the next
      expected sequence number to that of the next packet in the queue.
      
      Tested in a production L2TP network with Starent and Nortel L2TP gear.
      Signed-off-by: default avatarJames Chapman <jchapman@katalix.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      38d40b3f
  8. 01 May, 2012 3 commits
  9. 30 Apr, 2012 1 commit
  10. 29 Apr, 2012 1 commit
  11. 13 Apr, 2012 1 commit
    • Eric Dumazet's avatar
      udp: intoduce udp_encap_needed static_key · 447167bf
      Eric Dumazet authored
      
      
      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: default avatarEric Dumazet <eric.dumazet@gmail.com>
      Cc: Simon Horman <horms@verge.net.au>
      Cc: dev@openvswitch.org
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      447167bf
  12. 26 Nov, 2011 1 commit
  13. 08 Nov, 2011 1 commit
  14. 03 Nov, 2011 1 commit
  15. 19 Oct, 2011 1 commit
  16. 26 Jul, 2011 1 commit
  17. 12 May, 2011 1 commit
  18. 08 May, 2011 2 commits
    • David S. Miller's avatar
      inet: Pass flowi to ->queue_xmit(). · d9d8da80
      David S. Miller authored
      
      
      This allows us to acquire the exact route keying information from the
      protocol, however that might be managed.
      
      It handles all of the possibilities, from the simplest case of storing
      the key in inet->cork.fl to the more complex setup SCTP has where
      individual transports determine the flow.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d9d8da80
    • David S. Miller's avatar
      l2tp: Fix locking in l2tp_core.c · 6af88da1
      David S. Miller authored
      
      
      l2tp_xmit_skb() must take the socket lock.  It makes use of ip_queue_xmit()
      which expects to execute in a socket atomic context.
      
      Since we execute this function in software interrupts, we cannot use the
      usual lock_sock()/release_sock() sequence, instead we have to use
      bh_lock_sock() and see if a user has the socket locked, and if so drop
      the packet.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6af88da1
  19. 25 Oct, 2010 1 commit
    • Stephen Rothwell's avatar
      l2tp: static functions should not be exported · e341b2dd
      Stephen Rothwell authored
      
      
      Causes these build failures on PowerPC:
      
      net/l2tp/l2tp_core.c:1228: error: __ksymtab_l2tp_tunnel_closeall causes a section type conflict
      net/l2tp/l2tp_core.c:1228: error: __ksymtab_l2tp_tunnel_closeall causes a section type conflict
      net/l2tp/l2tp_core.c:1006: error: __ksymtab_l2tp_xmit_core causes a section type conflict
      net/l2tp/l2tp_core.c:1006: error: __ksymtab_l2tp_xmit_core causes a section type conflict
      net/l2tp/l2tp_core.c:847: error: __ksymtab_l2tp_udp_recv_core causes a section type conflict
      net/l2tp/l2tp_core.c:847: error: __ksymtab_l2tp_udp_recv_core causes a section type conflict
      Signed-off-by: default avatarStephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e341b2dd
  20. 24 Oct, 2010 1 commit
  21. 23 Apr, 2010 1 commit
  22. 16 Apr, 2010 1 commit
  23. 04 Apr, 2010 1 commit
  24. 03 Apr, 2010 6 commits