1. 10 Sep, 2012 2 commits
  2. 08 Sep, 2012 1 commit
    • Chema Gonzalez's avatar
      net: small bug on rxhash calculation · 68622342
      Chema Gonzalez authored
      In the current rxhash calculation function, while the
      sorting of the ports/addrs is coherent (you get the
      same rxhash for packets sharing the same 4-tuple, in
      both directions), ports and addrs are sorted
      independently. This implies packets from a connection
      between the same addresses but crossed ports hash to
      the same rxhash.
      
      For example, traffic between A=S:l and B=L:s is hashed
      (in both directions) from {L, S, {s, l}}. The same
      rxhash is obtained for packets between C=S:s and D=L:l.
      
      This patch ensures that you either swap both addrs and ports,
      or you swap none. Traffic between A and B, and traffic
      between C and D, get their rxhash from different sources
      ({L, S, {l, s}} for A<->B, and {L, S, {s, l}} for C<->D)
      
      The patch is co-written with Eric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarChema Gonzalez <chema@google.com>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      68622342
  3. 07 Sep, 2012 8 commits
  4. 05 Sep, 2012 24 commits
  5. 04 Sep, 2012 5 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
    • David S. Miller's avatar
    • Wu Fengguang's avatar
      i825xx: fix paging fault on znet_probe() · b320e972
      Wu Fengguang authored
      In znet_probe(), strncmp() may access beyond 0x100000 and
      trigger the below oops in kvm.  Fix it by limiting the loop
      under 0x100000-8. I suspect the limit could be further decreased
      to 0x100000-sizeof(struct netidblk), however no datasheet at hand..
      
      [    3.744312] BUG: unable to handle kernel paging request at 80100000
      [    3.746145] IP: [<8119d12a>] strncmp+0xc/0x20
      [    3.747446] *pde = 01d10067 *pte = 00100160
      [    3.747493] Oops: 0000 [#1] DEBUG_PAGEALLOC
      [    3.747493] Pid: 1, comm: swapper Not tainted 3.6.0-rc1-00018-g57bfc0a7 #73 Bochs Bochs
      [    3.747493] EIP: 0060:[<8119d12a>] EFLAGS: 00010206 CPU: 0
      [    3.747493] EIP is at strncmp+0xc/0x20
      [    3.747493] EAX: 800fff4e EBX: 00000006 ECX: 00000006 EDX: 814d2bb9
      [    3.747493] ESI: 80100000 EDI: 814d2bba EBP: 8e03dfa0 ESP: 8e03df98
      [    3.747493]  DS: 007b ES: 007b FS: 0000 GS: 00e0 SS: 0068
      [    3.747493] CR0: 8005003b CR2: 80100000 CR3: 016f7000 CR4: 00000690
      [    3.747493] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
      [    3.747493] DR6: ffff0ff0 DR7: 00000400
      [    3.747493] Process swapper (pid: 1, ti=8e03c000 task=8e040000 task.ti=8e03c000)
      [    3.747493] Stack:
      [    3.747493]  800fffff 00000000 8e03dfb4 816a1376 00000006 816a134a 00000000 8e03dfd0
      [    3.747493]  816819b5 816ed1c0 8e03dfe4 00000006 00000123 816ed604 8e03dfe4 81681b29
      [    3.747493]  00000000 81681a5b 00000000 00000000 8134e542 00000000 00000000 00000000
      [    3.747493] Call Trace:
      [    3.747493]  [<816a1376>] znet_probe+0x2c/0x26b
      [    3.747493]  [<816a134a>] ? dnet_driver_init+0xf/0xf
      [    3.747493]  [<816819b5>] do_one_initcall+0x6a/0x110
      [    3.747493]  [<81681b29>] kernel_init+0xce/0x14b
      Signed-off-by: default avatarFengguang Wu <fengguang.wu@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b320e972
    • Steffen Klassert's avatar
      xfrm: Workaround incompatibility of ESN and async crypto · 3b59df46
      Steffen Klassert authored
      ESN for esp is defined in RFC 4303. This RFC assumes that the
      sequence number counters are always up to date. However,
      this is not true if an async crypto algorithm is employed.
      
      If the sequence number counters are not up to date on sequence
      number check, we may incorrectly update the upper 32 bit of
      the sequence number. This leads to a DOS.
      
      We workaround this by comparing the upper sequence number,
      (used for authentication) with the upper sequence number
      computed after the async processing. We drop the packet
      if these numbers are different.
      
      To do this, we introduce a recheck function that does this
      check in the ESN case.
      Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      Acked-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3b59df46
    • 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