1. 09 10月, 2013 2 次提交
    • E
      ipv6: make lookups simpler and faster · efe4208f
      Eric Dumazet 提交于
      TCP listener refactoring, part 4 :
      
      To speed up inet lookups, we moved IPv4 addresses from inet to struct
      sock_common
      
      Now is time to do the same for IPv6, because it permits us to have fast
      lookups for all kind of sockets, including upcoming SYN_RECV.
      
      Getting IPv6 addresses in TCP lookups currently requires two extra cache
      lines, plus a dereference (and memory stall).
      
      inet6_sk(sk) does the dereference of inet_sk(__sk)->pinet6
      
      This patch is way bigger than its IPv4 counter part, because for IPv4,
      we could add aliases (inet_daddr, inet_rcv_saddr), while on IPv6,
      it's not doable easily.
      
      inet6_sk(sk)->daddr becomes sk->sk_v6_daddr
      inet6_sk(sk)->rcv_saddr becomes sk->sk_v6_rcv_saddr
      
      And timewait socket also have tw->tw_v6_daddr & tw->tw_v6_rcv_saddr
      at the same offset.
      
      We get rid of INET6_TW_MATCH() as INET6_MATCH() is now the generic
      macro.
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      efe4208f
    • D
      l2tp: Fix build warning with ipv6 disabled. · 8d8a51e2
      David S. Miller 提交于
      net/l2tp/l2tp_core.c: In function ‘l2tp_verify_udp_checksum’:
      net/l2tp/l2tp_core.c:499:22: warning: unused variable ‘tunnel’ [-Wunused-variable]
      
      Create a helper "l2tp_tunnel()" to facilitate this, and as a side
      effect get rid of a bunch of unnecessary void pointer casts.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8d8a51e2
  2. 03 10月, 2013 1 次提交
    • F
      l2tp: fix kernel panic when using IPv4-mapped IPv6 addresses · e18503f4
      François Cachereul 提交于
      IPv4 mapped addresses cause kernel panic.
      The patch juste check whether the IPv6 address is an IPv4 mapped
      address. If so, use IPv4 API instead of IPv6.
      
      [  940.026915] general protection fault: 0000 [#1]
      [  940.026915] Modules linked in: l2tp_ppp l2tp_netlink l2tp_core pppox ppp_generic slhc loop psmouse
      [  940.026915] CPU: 0 PID: 3184 Comm: memcheck-amd64- Not tainted 3.11.0+ #1
      [  940.026915] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
      [  940.026915] task: ffff880007130e20 ti: ffff88000737e000 task.ti: ffff88000737e000
      [  940.026915] RIP: 0010:[<ffffffff81333780>]  [<ffffffff81333780>] ip6_xmit+0x276/0x326
      [  940.026915] RSP: 0018:ffff88000737fd28  EFLAGS: 00010286
      [  940.026915] RAX: c748521a75ceff48 RBX: ffff880000c30800 RCX: 0000000000000000
      [  940.026915] RDX: ffff88000075cc4e RSI: 0000000000000028 RDI: ffff8800060e5a40
      [  940.026915] RBP: ffff8800060e5a40 R08: 0000000000000000 R09: ffff88000075cc90
      [  940.026915] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88000737fda0
      [  940.026915] R13: 0000000000000000 R14: 0000000000002000 R15: ffff880005d3b580
      [  940.026915] FS:  00007f163dc5e800(0000) GS:ffffffff81623000(0000) knlGS:0000000000000000
      [  940.026915] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  940.026915] CR2: 00000004032dc940 CR3: 0000000005c25000 CR4: 00000000000006f0
      [  940.026915] Stack:
      [  940.026915]  ffff88000075cc4e ffffffff81694e90 ffff880000c30b38 0000000000000020
      [  940.026915]  11000000523c4bac ffff88000737fdb4 0000000000000000 ffff880000c30800
      [  940.026915]  ffff880005d3b580 ffff880000c30b38 ffff8800060e5a40 0000000000000020
      [  940.026915] Call Trace:
      [  940.026915]  [<ffffffff81356cc3>] ? inet6_csk_xmit+0xa4/0xc4
      [  940.026915]  [<ffffffffa0038535>] ? l2tp_xmit_skb+0x503/0x55a [l2tp_core]
      [  940.026915]  [<ffffffff812b8d3b>] ? pskb_expand_head+0x161/0x214
      [  940.026915]  [<ffffffffa003e91d>] ? pppol2tp_xmit+0xf2/0x143 [l2tp_ppp]
      [  940.026915]  [<ffffffffa00292e0>] ? ppp_channel_push+0x36/0x8b [ppp_generic]
      [  940.026915]  [<ffffffffa00293fe>] ? ppp_write+0xaf/0xc5 [ppp_generic]
      [  940.026915]  [<ffffffff8110ead4>] ? vfs_write+0xa2/0x106
      [  940.026915]  [<ffffffff8110edd6>] ? SyS_write+0x56/0x8a
      [  940.026915]  [<ffffffff81378ac0>] ? system_call_fastpath+0x16/0x1b
      [  940.026915] Code: 00 49 8b 8f d8 00 00 00 66 83 7c 11 02 00 74 60 49
      8b 47 58 48 83 e0 fe 48 8b 80 18 01 00 00 48 85 c0 74 13 48 8b 80 78 02
      00 00 <48> ff 40 28 41 8b 57 68 48 01 50 30 48 8b 54 24 08 49 c7 c1 51
      [  940.026915] RIP  [<ffffffff81333780>] ip6_xmit+0x276/0x326
      [  940.026915]  RSP <ffff88000737fd28>
      [  940.057945] ---[ end trace be8aba9a61c8b7f3 ]---
      [  940.058583] Kernel panic - not syncing: Fatal exception in interrupt
      Signed-off-by: NFrançois CACHEREUL <f.cachereul@alphalink.fr>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e18503f4
  3. 03 7月, 2013 3 次提交
  4. 23 3月, 2013 1 次提交
  5. 21 3月, 2013 9 次提交
  6. 28 2月, 2013 1 次提交
    • S
      hlist: drop the node parameter from iterators · b67bfe0d
      Sasha Levin 提交于
      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: NPeter Senna Tschudin <peter.senna@gmail.com>
      Acked-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Signed-off-by: NSasha 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: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      b67bfe0d
  7. 08 2月, 2013 1 次提交
    • E
      l2tp: dont play with skb->truesize · 87c084a9
      Eric Dumazet 提交于
      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: NAndrew Savchenko <bircoph@gmail.com>
      Tested-by: NAndrew Savchenko <bircoph@gmail.com>
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc: James Chapman <jchapman@katalix.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      87c084a9
  8. 06 2月, 2013 3 次提交
  9. 30 1月, 2013 1 次提交
    • T
      l2tp: prevent l2tp_tunnel_delete racing with userspace close · 80d84ef3
      Tom Parkin 提交于
      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: NTom Parkin <tparkin@katalix.com>
      Signed-off-by: NJames Chapman <jchapman@katalix.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      80d84ef3
  10. 05 9月, 2012 1 次提交
    • E
      l2tp: fix a lockdep splat · 37159ef2
      Eric Dumazet 提交于
      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: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      37159ef2
  11. 31 8月, 2012 1 次提交
  12. 29 6月, 2012 1 次提交
  13. 17 5月, 2012 1 次提交
  14. 11 5月, 2012 2 次提交
    • J
      l2tp: fix data packet sequence number handling · d301e325
      James Chapman 提交于
      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: NJames Chapman <jchapman@katalix.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d301e325
    • J
      l2tp: fix reorder timeout recovery · 38d40b3f
      James Chapman 提交于
      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: NJames Chapman <jchapman@katalix.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      38d40b3f
  15. 01 5月, 2012 4 次提交
  16. 29 4月, 2012 1 次提交
  17. 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
  18. 27 11月, 2011 1 次提交
  19. 09 11月, 2011 1 次提交
  20. 04 11月, 2011 1 次提交
  21. 19 10月, 2011 1 次提交
  22. 27 7月, 2011 1 次提交
  23. 13 5月, 2011 1 次提交