1. 29 4月, 2010 2 次提交
    • 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 9 次提交
  9. 21 4月, 2010 4 次提交
    • D
      net: Fix an RCU warning in dev_pick_tx() · 05d17608
      David Howells 提交于
      Fix the following RCU warning in dev_pick_tx():
      
      ===================================================
      [ INFO: suspicious rcu_dereference_check() usage. ]
      ---------------------------------------------------
      net/core/dev.c:1993 invoked rcu_dereference_check() without protection!
      
      other info that might help us debug this:
      
      rcu_scheduler_active = 1, debug_locks = 0
      2 locks held by swapper/0:
       #0:  (&idev->mc_ifc_timer){+.-...}, at: [<ffffffff81039e65>] run_timer_softirq+0x17b/0x278
       #1:  (rcu_read_lock_bh){.+....}, at: [<ffffffff812ea3eb>] dev_queue_xmit+0x14e/0x4dc
      
      stack backtrace:
      Pid: 0, comm: swapper Not tainted 2.6.34-rc5-cachefs #4
      Call Trace:
       <IRQ>  [<ffffffff810516c4>] lockdep_rcu_dereference+0xaa/0xb2
       [<ffffffff812ea4f6>] dev_queue_xmit+0x259/0x4dc
       [<ffffffff812ea3eb>] ? dev_queue_xmit+0x14e/0x4dc
       [<ffffffff81052324>] ? trace_hardirqs_on+0xd/0xf
       [<ffffffff81035362>] ? local_bh_enable_ip+0xbc/0xc1
       [<ffffffff812f0954>] neigh_resolve_output+0x24b/0x27c
       [<ffffffff8134f673>] ip6_output_finish+0x7c/0xb4
       [<ffffffff81350c34>] ip6_output2+0x256/0x261
       [<ffffffff81052324>] ? trace_hardirqs_on+0xd/0xf
       [<ffffffff813517fb>] ip6_output+0xbbc/0xbcb
       [<ffffffff8135bc5d>] ? fib6_force_start_gc+0x2b/0x2d
       [<ffffffff81368acb>] mld_sendpack+0x273/0x39d
       [<ffffffff81368858>] ? mld_sendpack+0x0/0x39d
       [<ffffffff81052099>] ? mark_held_locks+0x52/0x70
       [<ffffffff813692fc>] mld_ifc_timer_expire+0x24f/0x288
       [<ffffffff81039ed6>] run_timer_softirq+0x1ec/0x278
       [<ffffffff81039e65>] ? run_timer_softirq+0x17b/0x278
       [<ffffffff813690ad>] ? mld_ifc_timer_expire+0x0/0x288
       [<ffffffff81035531>] ? __do_softirq+0x69/0x140
       [<ffffffff8103556a>] __do_softirq+0xa2/0x140
       [<ffffffff81002e0c>] call_softirq+0x1c/0x28
       [<ffffffff81004b54>] do_softirq+0x38/0x80
       [<ffffffff81034f06>] irq_exit+0x45/0x47
       [<ffffffff810177c3>] smp_apic_timer_interrupt+0x88/0x96
       [<ffffffff810028d3>] apic_timer_interrupt+0x13/0x20
       <EOI>  [<ffffffff810488dd>] ? __atomic_notifier_call_chain+0x0/0x86
       [<ffffffff810096bf>] ? mwait_idle+0x6e/0x78
       [<ffffffff810096b6>] ? mwait_idle+0x65/0x78
       [<ffffffff810011cb>] cpu_idle+0x4d/0x83
       [<ffffffff81380b05>] rest_init+0xb9/0xc0
       [<ffffffff81380a4c>] ? rest_init+0x0/0xc0
       [<ffffffff8168dcf0>] start_kernel+0x392/0x39d
       [<ffffffff8168d2a3>] x86_64_start_reservations+0xb3/0xb7
       [<ffffffff8168d38b>] x86_64_start_kernel+0xe4/0xeb
      
      An rcu_dereference() should be an rcu_dereference_bh().
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Acked-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      05d17608
    • D
      e04997b1
    • H
      ipv6: Fix tcp_v6_send_response transport header setting. · 6651ffc8
      Herbert Xu 提交于
      My recent patch to remove the open-coded checksum sequence in
      tcp_v6_send_response broke it as we did not set the transport
      header pointer on the new packet.
      
      Actually, there is code there trying to set the transport
      header properly, but it sets it for the wrong skb ('skb'
      instead of 'buff').
      
      This bug was introduced by commit
      a8fdf2b3 ("ipv6: Fix
      tcp_v6_send_response(): it didn't set skb transport header")
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6651ffc8
    • E
      bridge: add a missing ntohs() · 8eabf95c
      Eric Dumazet 提交于
      grec_nsrcs is in network order, we should convert to host horder in
      br_multicast_igmp3_report()
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Acked-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8eabf95c