1. 20 Mar, 2013 3 commits
    • Tom Parkin's avatar
      l2tp: close sessions in ip socket destroy callback · 93606317
      Tom Parkin authored
      
      
      l2tp_core hooks UDP's .destroy handler to gain advance warning of a tunnel
      socket being closed from userspace.  We need to do the same thing for
      IP-encapsulation sockets.
      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>
      93606317
    • Tom Parkin's avatar
      l2tp: export l2tp_tunnel_closeall · e34f4c70
      Tom Parkin authored
      
      
      l2tp_core internally uses l2tp_tunnel_closeall to close all sessions in a
      tunnel when a UDP-encapsulation socket is destroyed.  We need to do something
      similar for IP-encapsulation sockets.
      
      Export l2tp_tunnel_closeall as a GPL symbol to enable l2tp_ip and l2tp_ip6 to
      call it from their .destroy handlers.
      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>
      e34f4c70
    • Tom Parkin's avatar
      l2tp: add udp encap socket destroy handler · 9980d001
      Tom Parkin authored
      
      
      L2TP sessions hold a reference to the tunnel socket to prevent it going away
      while sessions are still active.  However, since tunnel destruction is handled
      by the sock sk_destruct callback there is a catch-22: a tunnel with sessions
      cannot be deleted since each session holds a reference to the tunnel socket.
      If userspace closes a managed tunnel socket, or dies, the tunnel will persist
      and it will be neccessary to individually delete the sessions using netlink
      commands.  This is ugly.
      
      To prevent this occuring, this patch leverages the udp encapsulation socket
      destroy callback to gain early notification when the tunnel socket is closed.
      This allows us to safely close the sessions running in the tunnel, dropping
      the tunnel socket references in the process.  The tunnel socket is then
      destroyed as normal, and the tunnel resources deallocated in sk_destruct.
      
      While we're at it, ensure that l2tp_tunnel_closeall correctly drops session
      references to allow the sessions to be deleted rather than leaking.
      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>
      9980d001
  2. 01 Mar, 2013 1 commit
    • Guillaume Nault's avatar
      l2tp: Restore socket refcount when sendmsg succeeds · 8b82547e
      Guillaume Nault authored
      
      
      The sendmsg() syscall handler for PPPoL2TP doesn't decrease the socket
      reference counter after successful transmissions. Any successful
      sendmsg() call from userspace will then increase the reference counter
      forever, thus preventing the kernel's session and tunnel data from
      being freed later on.
      
      The problem only happens when writing directly on L2TP sockets.
      PPP sockets attached to L2TP are unaffected as the PPP subsystem
      uses pppol2tp_xmit() which symmetrically increase/decrease reference
      counters.
      
      This patch adds the missing call to sock_put() before returning from
      pppol2tp_sendmsg().
      Signed-off-by: default avatarGuillaume Nault <g.nault@alphalink.fr>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8b82547e
  3. 28 Feb, 2013 1 commit
    • Sasha Levin's avatar
      hlist: drop the node parameter from iterators · b67bfe0d
      Sasha Levin authored
      
      
      I'm not sure why, but the hlist for each entry iterators were conceived
      
              list_for_each_entry(pos, head, member)
      
      The hlist ones were greedy and wanted an extra parameter:
      
              hlist_for_each_entry(tpos, pos, head, member)
      
      Why did they need an extra pos parameter? I'm not quite sure. Not only
      they don't really need it, it also prevents the iterator from looking
      exactly like the list iterator, which is unfortunate.
      
      Besides the semantic patch, there was some manual work required:
      
       - Fix up the actual hlist iterators in linux/list.h
       - Fix up the declaration of other iterators based on the hlist ones.
       - A very small amount of places were using the 'node' parameter, this
       was modified to use 'obj->member' instead.
       - Coccinelle didn't handle the hlist_for_each_entry_safe iterator
       properly, so those had to be fixed up manually.
      
      The semantic patch which is mostly the work of Peter Senna Tschudin is here:
      
      @@
      iterator name hlist_for_each_entry, hlist_for_each_entry_continue, hlist_for_each_entry_from, hlist_for_each_entry_rcu, hlist_for_each_entry_rcu_bh, hlist_for_each_entry_continue_rcu_bh, for_each_busy_worker, ax25_uid_for_each, ax25_for_each, inet_bind_bucket_for_each, sctp_for_each_hentry, sk_for_each, sk_for_each_rcu, sk_for_each_from, sk_for_each_safe, sk_for_each_bound, hlist_for_each_entry_safe, hlist_for_each_entry_continue_rcu, nr_neigh_for_each, nr_neigh_for_each_safe, nr_node_for_each, nr_node_for_each_safe, for_each_gfn_indirect_valid_sp, for_each_gfn_sp, for_each_host;
      
      type T;
      expression a,c,d,e;
      identifier b;
      statement S;
      @@
      
      -T b;
          <+... when != b
      (
      hlist_for_each_entry(a,
      - b,
      c, d) S
      |
      hlist_for_each_entry_continue(a,
      - b,
      c) S
      |
      hlist_for_each_entry_from(a,
      - b,
      c) S
      |
      hlist_for_each_entry_rcu(a,
      - b,
      c, d) S
      |
      hlist_for_each_entry_rcu_bh(a,
      - b,
      c, d) S
      |
      hlist_for_each_entry_continue_rcu_bh(a,
      - b,
      c) S
      |
      for_each_busy_worker(a, c,
      - b,
      d) S
      |
      ax25_uid_for_each(a,
      - b,
      c) S
      |
      ax25_for_each(a,
      - b,
      c) S
      |
      inet_bind_bucket_for_each(a,
      - b,
      c) S
      |
      sctp_for_each_hentry(a,
      - b,
      c) S
      |
      sk_for_each(a,
      - b,
      c) S
      |
      sk_for_each_rcu(a,
      - b,
      c) S
      |
      sk_for_each_from
      -(a, b)
      +(a)
      S
      + sk_for_each_from(a) S
      |
      sk_for_each_safe(a,
      - b,
      c, d) S
      |
      sk_for_each_bound(a,
      - b,
      c) S
      |
      hlist_for_each_entry_safe(a,
      - b,
      c, d, e) S
      |
      hlist_for_each_entry_continue_rcu(a,
      - b,
      c) S
      |
      nr_neigh_for_each(a,
      - b,
      c) S
      |
      nr_neigh_for_each_safe(a,
      - b,
      c, d) S
      |
      nr_node_for_each(a,
      - b,
      c) S
      |
      nr_node_for_each_safe(a,
      - b,
      c, d) S
      |
      - for_each_gfn_sp(a, c, d, b) S
      + for_each_gfn_sp(a, c, d) S
      |
      - for_each_gfn_indirect_valid_sp(a, c, d, b) S
      + for_each_gfn_indirect_valid_sp(a, c, d) S
      |
      for_each_host(a,
      - b,
      c) S
      |
      for_each_host_safe(a,
      - b,
      c, d) S
      |
      for_each_mesh_entry(a,
      - b,
      c, d) S
      )
          ...+>
      
      [akpm@linux-foundation.org: drop bogus change from net/ipv4/raw.c]
      [akpm@linux-foundation.org: drop bogus hunk from net/ipv6/raw.c]
      [akpm@linux-foundation.org: checkpatch fixes]
      [akpm@linux-foundation.org: fix warnings]
      [akpm@linux-foudnation.org: redo intrusive kvm changes]
      Tested-by: default avatarPeter Senna Tschudin <peter.senna@gmail.com>
      Acked-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      Cc: Wu Fengguang <fengguang.wu@intel.com>
      Cc: Marcelo Tosatti <mtosatti@redhat.com>
      Cc: Gleb Natapov <gleb@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      b67bfe0d
  4. 18 Feb, 2013 2 commits
  5. 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
  6. 05 Feb, 2013 5 commits
  7. 31 Jan, 2013 2 commits
  8. 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
  9. 11 Jan, 2013 1 commit
  10. 03 Nov, 2012 1 commit
    • Tom Parkin's avatar
      l2tp: fix oops in l2tp_eth_create() error path · 78933636
      Tom Parkin authored
      
      
      When creating an L2TPv3 Ethernet session, if register_netdev() should fail for
      any reason (for example, automatic naming for "l2tpeth%d" interfaces hits the
      32k-interface limit), the netdev is freed in the error path.  However, the
      l2tp_eth_sess structure's dev pointer is left uncleared, and this results in
      l2tp_eth_delete() then attempting to unregister the same netdev later in the
      session teardown.  This results in an oops.
      
      To avoid this, clear the session dev pointer in the error path.
      Signed-off-by: default avatarTom Parkin <tparkin@katalix.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      78933636
  11. 26 Oct, 2012 1 commit
  12. 27 Sep, 2012 1 commit
  13. 21 Sep, 2012 1 commit
    • Amerigo Wang's avatar
      l2tp: fix compile error when CONFIG_IPV6=m and CONFIG_L2TP=y · fc181625
      Amerigo Wang authored
      
      
      When CONFIG_IPV6=m and CONFIG_L2TP=y, I got the following compile error:
      
        LD      init/built-in.o
      net/built-in.o: In function `l2tp_xmit_core':
      l2tp_core.c:(.text+0x147781): undefined reference to `inet6_csk_xmit'
      net/built-in.o: In function `l2tp_tunnel_create':
      (.text+0x149067): undefined reference to `udpv6_encap_enable'
      net/built-in.o: In function `l2tp_ip6_recvmsg':
      l2tp_ip6.c:(.text+0x14e991): undefined reference to `ipv6_recv_error'
      net/built-in.o: In function `l2tp_ip6_sendmsg':
      l2tp_ip6.c:(.text+0x14ec64): undefined reference to `fl6_sock_lookup'
      l2tp_ip6.c:(.text+0x14ed6b): undefined reference to `datagram_send_ctl'
      l2tp_ip6.c:(.text+0x14eda0): undefined reference to `fl6_sock_lookup'
      l2tp_ip6.c:(.text+0x14ede5): undefined reference to `fl6_merge_options'
      l2tp_ip6.c:(.text+0x14edf4): undefined reference to `ipv6_fixup_options'
      l2tp_ip6.c:(.text+0x14ee5d): undefined reference to `fl6_update_dst'
      l2tp_ip6.c:(.text+0x14eea3): undefined reference to `ip6_dst_lookup_flow'
      l2tp_ip6.c:(.text+0x14eee7): undefined reference to `ip6_dst_hoplimit'
      l2tp_ip6.c:(.text+0x14ef8b): undefined reference to `ip6_append_data'
      l2tp_ip6.c:(.text+0x14ef9d): undefined reference to `ip6_flush_pending_frames'
      l2tp_ip6.c:(.text+0x14efe2): undefined reference to `ip6_push_pending_frames'
      net/built-in.o: In function `l2tp_ip6_destroy_sock':
      l2tp_ip6.c:(.text+0x14f090): undefined reference to `ip6_flush_pending_frames'
      l2tp_ip6.c:(.text+0x14f0a0): undefined reference to `inet6_destroy_sock'
      net/built-in.o: In function `l2tp_ip6_connect':
      l2tp_ip6.c:(.text+0x14f14d): undefined reference to `ip6_datagram_connect'
      net/built-in.o: In function `l2tp_ip6_bind':
      l2tp_ip6.c:(.text+0x14f4fe): undefined reference to `ipv6_chk_addr'
      net/built-in.o: In function `l2tp_ip6_init':
      l2tp_ip6.c:(.init.text+0x73fa): undefined reference to `inet6_add_protocol'
      l2tp_ip6.c:(.init.text+0x740c): undefined reference to `inet6_register_protosw'
      net/built-in.o: In function `l2tp_ip6_exit':
      l2tp_ip6.c:(.exit.text+0x1954): undefined reference to `inet6_unregister_protosw'
      l2tp_ip6.c:(.exit.text+0x1965): undefined reference to `inet6_del_protocol'
      net/built-in.o:(.rodata+0xf2d0): undefined reference to `inet6_release'
      net/built-in.o:(.rodata+0xf2d8): undefined reference to `inet6_bind'
      net/built-in.o:(.rodata+0xf308): undefined reference to `inet6_ioctl'
      net/built-in.o:(.data+0x1af40): undefined reference to `ipv6_setsockopt'
      net/built-in.o:(.data+0x1af48): undefined reference to `ipv6_getsockopt'
      net/built-in.o:(.data+0x1af50): undefined reference to `compat_ipv6_setsockopt'
      net/built-in.o:(.data+0x1af58): undefined reference to `compat_ipv6_getsockopt'
      make: *** [vmlinux] Error 1
      
      This is due to l2tp uses symbols from IPV6, so when IPV6
      is a module, l2tp is not allowed to be builtin.
      
      Cc: David Miller <davem@davemloft.net>
      Signed-off-by: default avatarCong Wang <amwang@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fc181625
  14. 10 Sep, 2012 1 commit
  15. 05 Sep, 2012 1 commit
    • Eric Dumazet's avatar
      net: qdisc busylock needs lockdep annotations · 23d3b8bf
      Eric Dumazet authored
      
      
      It seems we need to provide ability for stacked devices
      to use specific lock_class_key for sch->busylock
      
      We could instead default l2tpeth tx_queue_len to 0 (no qdisc), but
      a user might use a qdisc anyway.
      
      (So same fixes are probably needed on non LLTX stacked drivers)
      
      Noticed while stressing L2TPV3 setup :
      
      ======================================================
       [ INFO: possible circular locking dependency detected ]
       3.6.0-rc3+ #788 Not tainted
       -------------------------------------------------------
       netperf/4660 is trying to acquire lock:
        (l2tpsock){+.-...}, at: [<ffffffffa0208db2>] l2tp_xmit_skb+0x172/0xa50 [l2tp_core]
      
       but task is already holding lock:
        (&(&sch->busylock)->rlock){+.-...}, at: [<ffffffff81596595>] dev_queue_xmit+0xd75/0xe00
      
       which lock already depends on the new lock.
      
       the existing dependency chain (in reverse order) is:
      
       -> #1 (&(&sch->busylock)->rlock){+.-...}:
              [<ffffffff810a5df0>] lock_acquire+0x90/0x200
              [<ffffffff817499fc>] _raw_spin_lock_irqsave+0x4c/0x60
              [<ffffffff81074872>] __wake_up+0x32/0x70
              [<ffffffff8136d39e>] tty_wakeup+0x3e/0x80
              [<ffffffff81378fb3>] pty_write+0x73/0x80
              [<ffffffff8136cb4c>] tty_put_char+0x3c/0x40
              [<ffffffff813722b2>] process_echoes+0x142/0x330
              [<ffffffff813742ab>] n_tty_receive_buf+0x8fb/0x1230
              [<ffffffff813777b2>] flush_to_ldisc+0x142/0x1c0
              [<ffffffff81062818>] process_one_work+0x198/0x760
              [<ffffffff81063236>] worker_thread+0x186/0x4b0
              [<ffffffff810694d3>] kthread+0x93/0xa0
              [<ffffffff81753e24>] kernel_thread_helper+0x4/0x10
      
       -> #0 (l2tpsock){+.-...}:
              [<ffffffff810a5288>] __lock_acquire+0x1628/0x1b10
              [<ffffffff810a5df0>] lock_acquire+0x90/0x200
              [<ffffffff817498c1>] _raw_spin_lock+0x41/0x50
              [<ffffffffa0208db2>] l2tp_xmit_skb+0x172/0xa50 [l2tp_core]
              [<ffffffffa021a802>] l2tp_eth_dev_xmit+0x32/0x60 [l2tp_eth]
              [<ffffffff815952b2>] dev_hard_start_xmit+0x502/0xa70
              [<ffffffff815b63ce>] sch_direct_xmit+0xfe/0x290
              [<ffffffff81595a05>] dev_queue_xmit+0x1e5/0xe00
              [<ffffffff815d9d60>] ip_finish_output+0x3d0/0x890
              [<ffffffff815db019>] ip_output+0x59/0xf0
              [<ffffffff815da36d>] ip_local_out+0x2d/0xa0
              [<ffffffff815da5a3>] ip_queue_xmit+0x1c3/0x680
              [<ffffffff815f4192>] tcp_transmit_skb+0x402/0xa60
              [<ffffffff815f4a94>] tcp_write_xmit+0x1f4/0xa30
              [<ffffffff815f5300>] tcp_push_one+0x30/0x40
              [<ffffffff815e6672>] tcp_sendmsg+0xe82/0x1040
              [<ffffffff81614495>] inet_sendmsg+0x125/0x230
              [<ffffffff81576cdc>] sock_sendmsg+0xdc/0xf0
              [<ffffffff81579ece>] sys_sendto+0xfe/0x130
              [<ffffffff81752c92>] system_call_fastpath+0x16/0x1b
        Possible unsafe locking scenario:
      
              CPU0                    CPU1
              ----                    ----
         lock(&(&sch->busylock)->rlock);
                                      lock(l2tpsock);
                                      lock(&(&sch->busylock)->rlock);
         lock(l2tpsock);
      
        *** DEADLOCK ***
      
       5 locks held by netperf/4660:
        #0:  (sk_lock-AF_INET){+.+.+.}, at: [<ffffffff815e581c>] tcp_sendmsg+0x2c/0x1040
        #1:  (rcu_read_lock){.+.+..}, at: [<ffffffff815da3e0>] ip_queue_xmit+0x0/0x680
        #2:  (rcu_read_lock_bh){.+....}, at: [<ffffffff815d9ac5>] ip_finish_output+0x135/0x890
        #3:  (rcu_read_lock_bh){.+....}, at: [<ffffffff81595820>] dev_queue_xmit+0x0/0xe00
        #4:  (&(&sch->busylock)->rlock){+.-...}, at: [<ffffffff81596595>] dev_queue_xmit+0xd75/0xe00
      
       stack backtrace:
       Pid: 4660, comm: netperf Not tainted 3.6.0-rc3+ #788
       Call Trace:
        [<ffffffff8173dbf8>] print_circular_bug+0x1fb/0x20c
        [<ffffffff810a5288>] __lock_acquire+0x1628/0x1b10
        [<ffffffff810a334b>] ? check_usage+0x9b/0x4d0
        [<ffffffff810a3f44>] ? __lock_acquire+0x2e4/0x1b10
        [<ffffffff810a5df0>] lock_acquire+0x90/0x200
        [<ffffffffa0208db2>] ? l2tp_xmit_skb+0x172/0xa50 [l2tp_core]
        [<ffffffff817498c1>] _raw_spin_lock+0x41/0x50
        [<ffffffffa0208db2>] ? l2tp_xmit_skb+0x172/0xa50 [l2tp_core]
        [<ffffffffa0208db2>] l2tp_xmit_skb+0x172/0xa50 [l2tp_core]
        [<ffffffffa021a802>] l2tp_eth_dev_xmit+0x32/0x60 [l2tp_eth]
        [<ffffffff815952b2>] dev_hard_start_xmit+0x502/0xa70
        [<ffffffff81594e0e>] ? dev_hard_start_xmit+0x5e/0xa70
        [<ffffffff81595961>] ? dev_queue_xmit+0x141/0xe00
        [<ffffffff815b63ce>] sch_direct_xmit+0xfe/0x290
        [<ffffffff81595a05>] dev_queue_xmit+0x1e5/0xe00
        [<ffffffff81595820>] ? dev_hard_start_xmit+0xa70/0xa70
        [<ffffffff815d9d60>] ip_finish_output+0x3d0/0x890
        [<ffffffff815d9ac5>] ? ip_finish_output+0x135/0x890
        [<ffffffff815db019>] ip_output+0x59/0xf0
        [<ffffffff815da36d>] ip_local_out+0x2d/0xa0
        [<ffffffff815da5a3>] ip_queue_xmit+0x1c3/0x680
        [<ffffffff815da3e0>] ? ip_local_out+0xa0/0xa0
        [<ffffffff815f4192>] tcp_transmit_skb+0x402/0xa60
        [<ffffffff815fa25e>] ? tcp_md5_do_lookup+0x18e/0x1a0
        [<ffffffff815f4a94>] tcp_write_xmit+0x1f4/0xa30
        [<ffffffff815f5300>] tcp_push_one+0x30/0x40
        [<ffffffff815e6672>] tcp_sendmsg+0xe82/0x1040
        [<ffffffff81614495>] inet_sendmsg+0x125/0x230
        [<ffffffff81614370>] ? inet_create+0x6b0/0x6b0
        [<ffffffff8157e6e2>] ? sock_update_classid+0xc2/0x3b0
        [<ffffffff8157e750>] ? sock_update_classid+0x130/0x3b0
        [<ffffffff81576cdc>] sock_sendmsg+0xdc/0xf0
        [<ffffffff81162579>] ? fget_light+0x3f9/0x4f0
        [<ffffffff81579ece>] sys_sendto+0xfe/0x130
        [<ffffffff810a69ad>] ? trace_hardirqs_on+0xd/0x10
        [<ffffffff8174a0b0>] ? _raw_spin_unlock_irq+0x30/0x50
        [<ffffffff810757e3>] ? finish_task_switch+0x83/0xf0
        [<ffffffff810757a6>] ? finish_task_switch+0x46/0xf0
        [<ffffffff81752cb7>] ? sysret_check+0x1b/0x56
        [<ffffffff81752c92>] system_call_fastpath+0x16/0x1b
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      23d3b8bf
  16. 04 Sep, 2012 2 commits
    • Eric Dumazet's avatar
      l2tp: fix a typo in l2tp_eth_dev_recv() · c0cc88a7
      Eric Dumazet authored
      
      
      While investigating l2tp bug, I hit a bug in eth_type_trans(),
      because not enough bytes were pulled in skb head.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c0cc88a7
    • 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
  17. 30 Aug, 2012 1 commit
  18. 16 Aug, 2012 1 commit
  19. 29 Jun, 2012 2 commits
  20. 26 Jun, 2012 1 commit
    • Eric Dumazet's avatar
      net: l2tp_eth: use LLTX to avoid LOCKDEP splats · a2842a1e
      Eric Dumazet authored
      
      
      Denys Fedoryshchenko reported a LOCKDEP issue with l2tp code.
      
      [ 8683.927442] ======================================================
      [ 8683.927555] [ INFO: possible circular locking dependency detected ]
      [ 8683.927672] 3.4.1-build-0061 #14 Not tainted
      [ 8683.927782] -------------------------------------------------------
      [ 8683.927895] swapper/0/0 is trying to acquire lock:
      [ 8683.928007]  (slock-AF_INET){+.-...}, at: [<e0fc73ec>]
      l2tp_xmit_skb+0x173/0x47e [l2tp_core]
      [ 8683.928121]
      [ 8683.928121] but task is already holding lock:
      [ 8683.928121]  (_xmit_ETHER#2){+.-...}, at: [<c02f062d>]
      sch_direct_xmit+0x36/0x119
      [ 8683.928121]
      [ 8683.928121] which lock already depends on the new lock.
      [ 8683.928121]
      [ 8683.928121]
      [ 8683.928121] the existing dependency chain (in reverse order) is:
      [ 8683.928121]
      [ 8683.928121] -> #1 (_xmit_ETHER#2){+.-...}:
      [ 8683.928121]        [<c015a561>] lock_acquire+0x71/0x85
      [ 8683.928121]        [<c034da2d>] _raw_spin_lock+0x33/0x40
      [ 8683.928121]        [<c0304e0c>] ip_send_reply+0xf2/0x1ce
      [ 8683.928121]        [<c0317dbc>] tcp_v4_send_reset+0x153/0x16f
      [ 8683.928121]        [<c0317f4a>] tcp_v4_do_rcv+0x172/0x194
      [ 8683.928121]        [<c031929b>] tcp_v4_rcv+0x387/0x5a0
      [ 8683.928121]        [<c03001d0>] ip_local_deliver_finish+0x13a/0x1e9
      [ 8683.928121]        [<c0300645>] NF_HOOK.clone.11+0x46/0x4d
      [ 8683.928121]        [<c030075b>] ip_local_deliver+0x41/0x45
      [ 8683.928121]        [<c03005dd>] ip_rcv_finish+0x31a/0x33c
      [ 8683.928121]        [<c0300645>] NF_HOOK.clone.11+0x46/0x4d
      [ 8683.928121]        [<c0300960>] ip_rcv+0x201/0x23d
      [ 8683.928121]        [<c02de91b>] __netif_receive_skb+0x329/0x378
      [ 8683.928121]        [<c02deae8>] netif_receive_skb+0x4e/0x7d
      [ 8683.928121]        [<e08d5ef3>] rtl8139_poll+0x243/0x33d [8139too]
      [ 8683.928121]        [<c02df103>] net_rx_action+0x90/0x15d
      [ 8683.928121]        [<c012b2b5>] __do_softirq+0x7b/0x118
      [ 8683.928121]
      [ 8683.928121] -> #0 (slock-AF_INET){+.-...}:
      [ 8683.928121]        [<c0159f1b>] __lock_acquire+0x9a3/0xc27
      [ 8683.928121]        [<c015a561>] lock_acquire+0x71/0x85
      [ 8683.928121]        [<c034da2d>] _raw_spin_lock+0x33/0x40
      [ 8683.928121]        [<e0fc73ec>] l2tp_xmit_skb+0x173/0x47e
      [l2tp_core]
      [ 8683.928121]        [<e0fe31fb>] l2tp_eth_dev_xmit+0x1a/0x2f
      [l2tp_eth]
      [ 8683.928121]        [<c02e01e7>] dev_hard_start_xmit+0x333/0x3f2
      [ 8683.928121]        [<c02f064c>] sch_direct_xmit+0x55/0x119
      [ 8683.928121]        [<c02e0528>] dev_queue_xmit+0x282/0x418
      [ 8683.928121]        [<c031f4fb>] NF_HOOK.clone.19+0x45/0x4c
      [ 8683.928121]        [<c031f524>] arp_xmit+0x22/0x24
      [ 8683.928121]        [<c031f567>] arp_send+0x41/0x48
      [ 8683.928121]        [<c031fa7d>] arp_process+0x289/0x491
      [ 8683.928121]        [<c031f4fb>] NF_HOOK.clone.19+0x45/0x4c
      [ 8683.928121]        [<c031f7a0>] arp_rcv+0xb1/0xc3
      [ 8683.928121]        [<c02de91b>] __netif_receive_skb+0x329/0x378
      [ 8683.928121]        [<c02de9d3>] process_backlog+0x69/0x130
      [ 8683.928121]        [<c02df103>] net_rx_action+0x90/0x15d
      [ 8683.928121]        [<c012b2b5>] __do_softirq+0x7b/0x118
      [ 8683.928121]
      [ 8683.928121] other info that might help us debug this:
      [ 8683.928121]
      [ 8683.928121]  Possible unsafe locking scenario:
      [ 8683.928121]
      [ 8683.928121]        CPU0                    CPU1
      [ 8683.928121]        ----                    ----
      [ 8683.928121]   lock(_xmit_ETHER#2);
      [ 8683.928121]                                lock(slock-AF_INET);
      [ 8683.928121]                                lock(_xmit_ETHER#2);
      [ 8683.928121]   lock(slock-AF_INET);
      [ 8683.928121]
      [ 8683.928121]  *** DEADLOCK ***
      [ 8683.928121]
      [ 8683.928121] 3 locks held by swapper/0/0:
      [ 8683.928121]  #0:  (rcu_read_lock){.+.+..}, at: [<c02dbc10>]
      rcu_lock_acquire+0x0/0x30
      [ 8683.928121]  #1:  (rcu_read_lock_bh){.+....}, at: [<c02dbc10>]
      rcu_lock_acquire+0x0/0x30
      [ 8683.928121]  #2:  (_xmit_ETHER#2){+.-...}, at: [<c02f062d>]
      sch_direct_xmit+0x36/0x119
      [ 8683.928121]
      [ 8683.928121] stack backtrace:
      [ 8683.928121] Pid: 0, comm: swapper/0 Not tainted 3.4.1-build-0061 #14
      [ 8683.928121] Call Trace:
      [ 8683.928121]  [<c034bdd2>] ? printk+0x18/0x1a
      [ 8683.928121]  [<c0158904>] print_circular_bug+0x1ac/0x1b6
      [ 8683.928121]  [<c0159f1b>] __lock_acquire+0x9a3/0xc27
      [ 8683.928121]  [<c015a561>] lock_acquire+0x71/0x85
      [ 8683.928121]  [<e0fc73ec>] ? l2tp_xmit_skb+0x173/0x47e [l2tp_core]
      [ 8683.928121]  [<c034da2d>] _raw_spin_lock+0x33/0x40
      [ 8683.928121]  [<e0fc73ec>] ? l2tp_xmit_skb+0x173/0x47e [l2tp_core]
      [ 8683.928121]  [<e0fc73ec>] l2tp_xmit_skb+0x173/0x47e [l2tp_core]
      [ 8683.928121]  [<e0fe31fb>] l2tp_eth_dev_xmit+0x1a/0x2f [l2tp_eth]
      [ 8683.928121]  [<c02e01e7>] dev_hard_start_xmit+0x333/0x3f2
      [ 8683.928121]  [<c02f064c>] sch_direct_xmit+0x55/0x119
      [ 8683.928121]  [<c02e0528>] dev_queue_xmit+0x282/0x418
      [ 8683.928121]  [<c02e02a6>] ? dev_hard_start_xmit+0x3f2/0x3f2
      [ 8683.928121]  [<c031f4fb>] NF_HOOK.clone.19+0x45/0x4c
      [ 8683.928121]  [<c031f524>] arp_xmit+0x22/0x24
      [ 8683.928121]  [<c02e02a6>] ? dev_hard_start_xmit+0x3f2/0x3f2
      [ 8683.928121]  [<c031f567>] arp_send+0x41/0x48
      [ 8683.928121]  [<c031fa7d>] arp_process+0x289/0x491
      [ 8683.928121]  [<c031f7f4>] ? __neigh_lookup.clone.20+0x42/0x42
      [ 8683.928121]  [<c031f4fb>] NF_HOOK.clone.19+0x45/0x4c
      [ 8683.928121]  [<c031f7a0>] arp_rcv+0xb1/0xc3
      [ 8683.928121]  [<c031f7f4>] ? __neigh_lookup.clone.20+0x42/0x42
      [ 8683.928121]  [<c02de91b>] __netif_receive_skb+0x329/0x378
      [ 8683.928121]  [<c02de9d3>] process_backlog+0x69/0x130
      [ 8683.928121]  [<c02df103>] net_rx_action+0x90/0x15d
      [ 8683.928121]  [<c012b2b5>] __do_softirq+0x7b/0x118
      [ 8683.928121]  [<c012b23a>] ? local_bh_enable+0xd/0xd
      [ 8683.928121]  <IRQ>  [<c012b4d0>] ? irq_exit+0x41/0x91
      [ 8683.928121]  [<c0103c6f>] ? do_IRQ+0x79/0x8d
      [ 8683.928121]  [<c0157ea1>] ? trace_hardirqs_off_caller+0x2e/0x86
      [ 8683.928121]  [<c034ef6e>] ? common_interrupt+0x2e/0x34
      [ 8683.928121]  [<c0108a33>] ? default_idle+0x23/0x38
      [ 8683.928121]  [<c01091a8>] ? cpu_idle+0x55/0x6f
      [ 8683.928121]  [<c033df25>] ? rest_init+0xa1/0xa7
      [ 8683.928121]  [<c033de84>] ? __read_lock_failed+0x14/0x14
      [ 8683.928121]  [<c0498745>] ? start_kernel+0x303/0x30a
      [ 8683.928121]  [<c0498209>] ? repair_env_string+0x51/0x51
      [ 8683.928121]  [<c04980a8>] ? i386_start_kernel+0xa8/0xaf
      
      It appears that like most virtual devices, l2tp should be converted to
      LLTX mode.
      
      This patch takes care of statistics using atomic_long in both RX and TX
      paths, and fix a bug in l2tp_eth_dev_recv(), which was caching skb->data
      before a pskb_may_pull() call.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarDenys Fedoryshchenko <denys@visp.net.lb>
      Cc: James Chapman <jchapman@katalix.com>
      Cc: Hong zhi guo <honkiko@gmail.com>
      Cc: Francois Romieu <romieu@fr.zoreil.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a2842a1e
  21. 25 Jun, 2012 1 commit
  22. 08 Jun, 2012 1 commit
  23. 07 Jun, 2012 1 commit
  24. 04 Jun, 2012 1 commit
    • Joe Perches's avatar
      net: Remove casts to same type · e3192690
      Joe Perches authored
      
      
      Adding casts of objects to the same type is unnecessary
      and confusing for a human reader.
      
      For example, this cast:
      
      	int y;
      	int *p = (int *)&y;
      
      I used the coccinelle script below to find and remove these
      unnecessary casts.  I manually removed the conversions this
      script produces of casts with __force and __user.
      
      @@
      type T;
      T *p;
      @@
      
      -	(T *)p
      +	p
      Signed-off-by: default avatarJoe Perches <joe@perches.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e3192690
  25. 30 May, 2012 1 commit
    • Neil Horman's avatar
      genetlink: Build a generic netlink family module alias · e9412c37
      Neil Horman authored
      
      
      Generic netlink searches for -type- formatted aliases when requesting a module to
      fulfill a protocol request (i.e. net-pf-16-proto-16-type-<x>, where x is a type
      value).  However generic netlink protocols have no well defined type numbers,
      they have string names.  Modify genl_ctrl_getfamily to request an alias in the
      format net-pf-16-proto-16-family-<x> instead, where x is a generic string, and
      add a macro that builds on the previously added MODULE_ALIAS_NET_PF_PROTO_NAME
      macro to allow modules to specifify those generic strings.
      
      Note, l2tp previously hacked together an net-pf-16-proto-16-type-l2tp alias
      using the MODULE_ALIAS macro, with these updates we can convert that to use the
      PROTO_NAME macro.
      Signed-off-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      CC: Eric Dumazet <eric.dumazet@gmail.com>
      CC: James Chapman <jchapman@katalix.com>
      CC: David Miller <davem@davemloft.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e9412c37
  26. 29 May, 2012 1 commit
    • James Chapman's avatar
      l2tp: fix oops in L2TP IP sockets for connect() AF_UNSPEC case · c51ce497
      James Chapman authored
      
      
      An application may call connect() to disconnect a socket using an
      address with family AF_UNSPEC. The L2TP IP sockets were not handling
      this case when the socket is not bound and an attempt to connect()
      using AF_UNSPEC in such cases would result in an oops. This patch
      addresses the problem by protecting the sk_prot->disconnect() call
      against trying to unhash the socket before it is bound.
      
      The L2TP IPv4 and IPv6 sockets have the same problem. Both are fixed
      by this patch.
      
      The patch also adds more checks that the sockaddr supplied to bind()
      and connect() calls is valid.
      
       RIP: 0010:[<ffffffff82e133b0>]  [<ffffffff82e133b0>] inet_unhash+0x50/0xd0
       RSP: 0018:ffff88001989be28  EFLAGS: 00010293
       Stack:
        ffff8800407a8000 0000000000000000 ffff88001989be78 ffffffff82e3a249
        ffffffff82e3a050 ffff88001989bec8 ffff88001989be88 ffff8800407a8000
        0000000000000010 ffff88001989bec8 ffff88001989bea8 ffffffff82e42639
       Call Trace:
       [<ffffffff82e3a249>] udp_disconnect+0x1f9/0x290
       [<ffffffff82e42639>] inet_dgram_connect+0x29/0x80
       [<ffffffff82d012fc>] sys_connect+0x9c/0x100
      Reported-by: default avatarSasha Levin <levinsasha928@gmail.com>
      Signed-off-by: default avatarJames Chapman <jchapman@katalix.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c51ce497
  27. 17 May, 2012 1 commit
  28. 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
  29. 03 May, 2012 1 commit
    • Sasha Levin's avatar
      net: l2tp: unlock socket lock before returning from l2tp_ip_sendmsg · 84768edb
      Sasha Levin authored
      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: default avatarSasha Levin <levinsasha928@gmail.com>
      Acked-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      84768edb