1. 29 4月, 2010 7 次提交
    • B
      sfc: Wait at most 10ms for the MC to finish reading out MAC statistics · aabc5649
      Ben Hutchings 提交于
      The original code would wait indefinitely if MAC stats DMA failed.
      Signed-off-by: NBen Hutchings <bhutchings@solarflare.com>
      Cc: stable@kernel.org
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      aabc5649
    • V
      sctp: Fix oops when sending queued ASCONF chunks · c0786693
      Vlad Yasevich 提交于
      When we finish processing ASCONF_ACK chunk, we try to send
      the next queued ASCONF.  This action runs the sctp state
      machine recursively and it's not prepared to do so.
      
      kernel BUG at kernel/timer.c:790!
      invalid opcode: 0000 [#1] SMP
      last sysfs file: /sys/module/ipv6/initstate
      Modules linked in: sha256_generic sctp libcrc32c ipv6 dm_multipath
      uinput 8139too i2c_piix4 8139cp mii i2c_core pcspkr virtio_net joydev
      floppy virtio_blk virtio_pci [last unloaded: scsi_wait_scan]
      
      Pid: 0, comm: swapper Not tainted 2.6.34-rc4 #15 /Bochs
      EIP: 0060:[<c044a2ef>] EFLAGS: 00010286 CPU: 0
      EIP is at add_timer+0xd/0x1b
      EAX: cecbab14 EBX: 000000f0 ECX: c0957b1c EDX: 03595cf4
      ESI: cecba800 EDI: cf276f00 EBP: c0957aa0 ESP: c0957aa0
       DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
      Process swapper (pid: 0, ti=c0956000 task=c0988ba0 task.ti=c0956000)
      Stack:
       c0957ae0 d1851214 c0ab62e4 c0ab5f26 0500ffff 00000004 00000005 00000004
      <0> 00000000 d18694fd 00000004 1666b892 cecba800 cecba800 c0957b14
      00000004
      <0> c0957b94 d1851b11 ceda8b00 cecba800 cf276f00 00000001 c0957b14
      000000d0
      Call Trace:
       [<d1851214>] ? sctp_side_effects+0x607/0xdfc [sctp]
       [<d1851b11>] ? sctp_do_sm+0x108/0x159 [sctp]
       [<d1863386>] ? sctp_pname+0x0/0x1d [sctp]
       [<d1861a56>] ? sctp_primitive_ASCONF+0x36/0x3b [sctp]
       [<d185657c>] ? sctp_process_asconf_ack+0x2a4/0x2d3 [sctp]
       [<d184e35c>] ? sctp_sf_do_asconf_ack+0x1dd/0x2b4 [sctp]
       [<d1851ac1>] ? sctp_do_sm+0xb8/0x159 [sctp]
       [<d1863334>] ? sctp_cname+0x0/0x52 [sctp]
       [<d1854377>] ? sctp_assoc_bh_rcv+0xac/0xe1 [sctp]
       [<d1858f0f>] ? sctp_inq_push+0x2d/0x30 [sctp]
       [<d186329d>] ? sctp_rcv+0x797/0x82e [sctp]
      Tested-by: NWei Yongjun <yjwei@cn.fujitsu.com>
      Signed-off-by: NYuansong Qiao <ysqiao@research.ait.ie>
      Signed-off-by: NShuaijun Zhang <szhang@research.ait.ie>
      Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c0786693
    • W
      sctp: fix to calc the INIT/INIT-ACK chunk length correctly is set · a8170c35
      Wei Yongjun 提交于
      When calculating the INIT/INIT-ACK chunk length, we should not
      only account the length of parameters, but also the parameters
      zero padding length, such as AUTH HMACS parameter and CHUNKS
      parameter. Without the parameters zero padding length we may get
      following oops.
      
      skb_over_panic: text:ce2068d2 len:130 put:6 head:cac3fe00 data:cac3fe00 tail:0xcac3fe82 end:0xcac3fe80 dev:<NULL>
      ------------[ cut here ]------------
      kernel BUG at net/core/skbuff.c:127!
      invalid opcode: 0000 [#2] SMP
      last sysfs file: /sys/module/aes_generic/initstate
      Modules linked in: authenc ......
      
      Pid: 4102, comm: sctp_darn Tainted: G      D    2.6.34-rc2 #6
      EIP: 0060:[<c0607630>] EFLAGS: 00010282 CPU: 0
      EIP is at skb_over_panic+0x37/0x3e
      EAX: 00000078 EBX: c07c024b ECX: c07c02b9 EDX: cb607b78
      ESI: 00000000 EDI: cac3fe7a EBP: 00000002 ESP: cb607b74
       DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
      Process sctp_darn (pid: 4102, ti=cb607000 task=cabdc990 task.ti=cb607000)
      Stack:
       c07c02b9 ce2068d2 00000082 00000006 cac3fe00 cac3fe00 cac3fe82 cac3fe80
      <0> c07c024b cac3fe7c cac3fe7a c0608dec ca986e80 ce2068d2 00000006 0000007a
      <0> cb8120ca ca986e80 cb812000 00000003 cb8120c4 ce208a25 cb8120ca cadd9400
      Call Trace:
       [<ce2068d2>] ? sctp_addto_chunk+0x45/0x85 [sctp]
       [<c0608dec>] ? skb_put+0x2e/0x32
       [<ce2068d2>] ? sctp_addto_chunk+0x45/0x85 [sctp]
       [<ce208a25>] ? sctp_make_init+0x279/0x28c [sctp]
       [<c0686a92>] ? apic_timer_interrupt+0x2a/0x30
       [<ce1fdc0b>] ? sctp_sf_do_prm_asoc+0x2b/0x7b [sctp]
       [<ce202823>] ? sctp_do_sm+0xa0/0x14a [sctp]
       [<ce2133b9>] ? sctp_pname+0x0/0x14 [sctp]
       [<ce211d72>] ? sctp_primitive_ASSOCIATE+0x2b/0x31 [sctp]
       [<ce20f3cf>] ? sctp_sendmsg+0x7a0/0x9eb [sctp]
       [<c064eb1e>] ? inet_sendmsg+0x3b/0x43
       [<c04244b7>] ? task_tick_fair+0x2d/0xd9
       [<c06031e1>] ? sock_sendmsg+0xa7/0xc1
       [<c0416afe>] ? smp_apic_timer_interrupt+0x6b/0x75
       [<c0425123>] ? dequeue_task_fair+0x34/0x19b
       [<c0446abb>] ? sched_clock_local+0x17/0x11e
       [<c052ea87>] ? _copy_from_user+0x2b/0x10c
       [<c060ab3a>] ? verify_iovec+0x3c/0x6a
       [<c06035ca>] ? sys_sendmsg+0x186/0x1e2
       [<c042176b>] ? __wake_up_common+0x34/0x5b
       [<c04240c2>] ? __wake_up+0x2c/0x3b
       [<c057e35c>] ? tty_wakeup+0x43/0x47
       [<c04430f2>] ? remove_wait_queue+0x16/0x24
       [<c0580c94>] ? n_tty_read+0x5b8/0x65e
       [<c042be02>] ? default_wake_function+0x0/0x8
       [<c0604e0e>] ? sys_socketcall+0x17f/0x1cd
       [<c040264c>] ? sysenter_do_call+0x12/0x22
      Code: 0f 45 de 53 ff b0 98 00 00 00 ff b0 94 ......
      EIP: [<c0607630>] skb_over_panic+0x37/0x3e SS:ESP 0068:cb607b74
      
      To reproduce:
      
      # modprobe sctp
      # echo 1 > /proc/sys/net/sctp/addip_enable
      # echo 1 > /proc/sys/net/sctp/auth_enable
      # sctp_test -H 3ffe:501:ffff:100:20c:29ff:fe4d:f37e -P 800 -l
      # sctp_darn -H 3ffe:501:ffff:100:20c:29ff:fe4d:f37e -P 900 -h 192.168.0.21 -p 800 -I -s -t
      sctp_darn ready to send...
      3ffe:501:ffff:100:20c:29ff:fe4d:f37e:900-192.168.0.21:800 Interactive mode> bindx-add=192.168.0.21
      3ffe:501:ffff:100:20c:29ff:fe4d:f37e:900-192.168.0.21:800 Interactive mode> bindx-add=192.168.1.21
      3ffe:501:ffff:100:20c:29ff:fe4d:f37e:900-192.168.0.21:800 Interactive mode> snd=10
      
      ------------------------------------------------------------------
      eth0 has addresses: 3ffe:501:ffff:100:20c:29ff:fe4d:f37e and 192.168.0.21
      eth1 has addresses: 192.168.1.21
      ------------------------------------------------------------------
      Reported-by: NGeorge Cheimonidis <gchimon@gmail.com>
      Signed-off-by: NWei Yongjun <yjwei@cn.fujitsu.com>
      Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a8170c35
    • V
      sctp: per_cpu variables should be in bh_disabled section · 81419d86
      Vlad Yasevich 提交于
      Since the change of the atomics to percpu variables, we now
      have to disable BH in process context when touching percpu variables.
      Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      81419d86
    • V
      sctp: fix potential reference of a freed pointer · 0c42749c
      Vlad Yasevich 提交于
      When sctp attempts to update an assocition, it removes any
      addresses that were not in the updated INITs.  However, the loop
      may attempt to refrence a transport with address after removing it.
      Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0c42749c
    • W
      sctp: avoid irq lock inversion while call sk->sk_data_ready() · 561b1733
      Wei Yongjun 提交于
      sk->sk_data_ready() of sctp socket can be called from both BH and non-BH
      contexts, but the default sk->sk_data_ready(), sock_def_readable(), can
      not be used in this case. Therefore, we have to make a new function
      sctp_data_ready() to grab sk->sk_data_ready() with BH disabling.
      
      =========================================================
      [ INFO: possible irq lock inversion dependency detected ]
      2.6.33-rc6 #129
      ---------------------------------------------------------
      sctp_darn/1517 just changed the state of lock:
       (clock-AF_INET){++.?..}, at: [<c06aab60>] sock_def_readable+0x20/0x80
      but this lock took another, SOFTIRQ-unsafe lock in the past:
       (slock-AF_INET){+.-...}
      
      and interrupts could create inverse lock ordering between them.
      
      other info that might help us debug this:
      1 lock held by sctp_darn/1517:
       #0:  (sk_lock-AF_INET){+.+.+.}, at: [<cdfe363d>] sctp_sendmsg+0x23d/0xc00 [sctp]
      Signed-off-by: NWei Yongjun <yjwei@cn.fujitsu.com>
      Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      561b1733
    • D
      Revert "tcp: bind() fix when many ports are bound" · 8d238b25
      David S. Miller 提交于
      This reverts two commits:
      
      fda48a0d
      tcp: bind() fix when many ports are bound
      
      and a follow-on fix for it:
      
      6443bb1f
      ipv6: Fix inet6_csk_bind_conflict()
      
      It causes problems with binding listening sockets when time-wait
      sockets from a previous instance still are alive.
      
      It's too late to keep fiddling with this so late in the -rc
      series, and we'll deal with it in net-next-2.6 instead.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8d238b25
  2. 28 4月, 2010 13 次提交
  3. 27 4月, 2010 5 次提交
  4. 26 4月, 2010 1 次提交
  5. 25 4月, 2010 1 次提交
  6. 24 4月, 2010 2 次提交
    • A
      gianfar: Fix potential oops during OF address translation · 7ce97d4f
      Anton Vorontsov 提交于
      gianfar driver may pass NULL pointer to the of_translate_address(),
      which may lead to a kernel oops. Fix this by using of_iomap(), which
      is also much simpler and shorter.
      Signed-off-by: NAnton Vorontsov <avorontsov@mvista.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7ce97d4f
    • A
      fsl_pq_mdio: Fix kernel oops during OF address translation · 3b1fd3e5
      Anton Vorontsov 提交于
      Old P1020RDB device trees were not specifing tbipa address for
      MDIO nodes, which is now causing this kernel oops:
      
       ...
       eth2: TX BD ring size for Q[6]: 256
       eth2: TX BD ring size for Q[7]: 256
       Unable to handle kernel paging request for data at address 0x00000000
       Faulting instruction address: 0xc0015504
       Oops: Kernel access of bad area, sig: 11 [#1]
       ...
       NIP [c0015504] memcpy+0x3c/0x9c
       LR [c000a9f8] __of_translate_address+0xfc/0x21c
       Call Trace:
       [df839e00] [c000a94c] __of_translate_address+0x50/0x21c (unreliable)
       [df839e50] [c01a33e8] get_gfar_tbipa+0xb0/0xe0
       ...
      
      The old device trees are buggy, though having a dead ethernet is
      better than a dead kernel, so fix the issue by using of_iomap().
      
      Also, a somewhat similar issue exist in the probe() routine, though
      there the oops is only a possibility. Nonetheless, fix it too.
      Signed-off-by: NAnton Vorontsov <avorontsov@mvista.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3b1fd3e5
  7. 23 4月, 2010 3 次提交
  8. 22 4月, 2010 8 次提交