1. 24 2月, 2011 2 次提交
  2. 23 2月, 2011 9 次提交
  3. 22 2月, 2011 5 次提交
    • C
      p54pci: update receive dma buffers before and after processing · 0bf719df
      Christian Lamparter 提交于
      Documentation/DMA-API-HOWTO.txt states:
      
      "DMA transfers need to be synced properly in order for
      the cpu and device to see the most uptodate and correct
      copy of the DMA buffer."
      
      Cc: <stable@kernel.org>
      Signed-off-by: NChristian Lamparter <chunkeey@googlemail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      0bf719df
    • D
      fix cfg80211_wext_siwfreq lock ordering... · 4f919a3b
      Daniel J Blueman 提交于
      I previously managed to reproduce a hang while scanning wireless
      channels (reproducible with airodump-ng hopping channels); subsequent
      lockdep instrumentation revealed a lock ordering issue.
      
      Without knowing the design intent, it looks like the locks should be
      taken in reverse order; please comment.
      
      =======================================================
      [ INFO: possible circular locking dependency detected ]
      2.6.38-rc5-341cd #4
      -------------------------------------------------------
      airodump-ng/15445 is trying to acquire lock:
       (&rdev->devlist_mtx){+.+.+.}, at: [<ffffffff816b1266>]
      cfg80211_wext_siwfreq+0xc6/0x100
      
      but task is already holding lock:
       (&wdev->mtx){+.+.+.}, at: [<ffffffff816b125c>] cfg80211_wext_siwfreq+0xbc/0x100
      
      which lock already depends on the new lock.
      
      the existing dependency chain (in reverse order) is:
      
      -> #1 (&wdev->mtx){+.+.+.}:
             [<ffffffff810a79d6>] lock_acquire+0xc6/0x280
             [<ffffffff816d6bce>] mutex_lock_nested+0x6e/0x4b0
             [<ffffffff81696080>] cfg80211_netdev_notifier_call+0x430/0x5f0
             [<ffffffff8109351b>] notifier_call_chain+0x8b/0x100
             [<ffffffff810935b1>] raw_notifier_call_chain+0x11/0x20
             [<ffffffff81576d92>] call_netdevice_notifiers+0x32/0x60
             [<ffffffff815771a4>] __dev_notify_flags+0x34/0x80
             [<ffffffff81577230>] dev_change_flags+0x40/0x70
             [<ffffffff8158587c>] do_setlink+0x1fc/0x8d0
             [<ffffffff81586042>] rtnl_setlink+0xf2/0x140
             [<ffffffff81586923>] rtnetlink_rcv_msg+0x163/0x270
             [<ffffffff8159d741>] netlink_rcv_skb+0xa1/0xd0
             [<ffffffff815867b0>] rtnetlink_rcv+0x20/0x30
             [<ffffffff8159d39a>] netlink_unicast+0x2ba/0x300
             [<ffffffff8159dd57>] netlink_sendmsg+0x267/0x3e0
             [<ffffffff8155e364>] sock_sendmsg+0xe4/0x110
             [<ffffffff8155f3a3>] sys_sendmsg+0x253/0x3b0
             [<ffffffff81003192>] system_call_fastpath+0x16/0x1b
      
      -> #0 (&rdev->devlist_mtx){+.+.+.}:
             [<ffffffff810a7222>] __lock_acquire+0x1622/0x1d10
             [<ffffffff810a79d6>] lock_acquire+0xc6/0x280
             [<ffffffff816d6bce>] mutex_lock_nested+0x6e/0x4b0
             [<ffffffff816b1266>] cfg80211_wext_siwfreq+0xc6/0x100
             [<ffffffff816b2fad>] ioctl_standard_call+0x5d/0xd0
             [<ffffffff816b3223>] T.808+0x163/0x170
             [<ffffffff816b326a>] wext_handle_ioctl+0x3a/0x90
             [<ffffffff815798d2>] dev_ioctl+0x6f2/0x830
             [<ffffffff8155cf3d>] sock_ioctl+0xfd/0x290
             [<ffffffff8117dffd>] do_vfs_ioctl+0x9d/0x590
             [<ffffffff8117e53a>] sys_ioctl+0x4a/0x80
             [<ffffffff81003192>] system_call_fastpath+0x16/0x1b
      
      other info that might help us debug this:
      
      2 locks held by airodump-ng/15445:
       #0:  (rtnl_mutex){+.+.+.}, at: [<ffffffff81586782>] rtnl_lock+0x12/0x20
       #1:  (&wdev->mtx){+.+.+.}, at: [<ffffffff816b125c>]
      cfg80211_wext_siwfreq+0xbc/0x100
      
      stack backtrace:
      Pid: 15445, comm: airodump-ng Not tainted 2.6.38-rc5-341cd #4
      Call Trace:
       [<ffffffff810a3f0a>] ? print_circular_bug+0xfa/0x100
       [<ffffffff810a7222>] ? __lock_acquire+0x1622/0x1d10
       [<ffffffff810a1f99>] ? trace_hardirqs_off_caller+0x29/0xc0
       [<ffffffff810a79d6>] ? lock_acquire+0xc6/0x280
       [<ffffffff816b1266>] ? cfg80211_wext_siwfreq+0xc6/0x100
       [<ffffffff810a31d7>] ? mark_held_locks+0x67/0x90
       [<ffffffff816d6bce>] ? mutex_lock_nested+0x6e/0x4b0
       [<ffffffff816b1266>] ? cfg80211_wext_siwfreq+0xc6/0x100
       [<ffffffff810a31d7>] ? mark_held_locks+0x67/0x90
       [<ffffffff816b1266>] ? cfg80211_wext_siwfreq+0xc6/0x100
       [<ffffffff816b1266>] ? cfg80211_wext_siwfreq+0xc6/0x100
       [<ffffffff816b2fad>] ? ioctl_standard_call+0x5d/0xd0
       [<ffffffff8157818b>] ? __dev_get_by_name+0x9b/0xc0
       [<ffffffff816b2f50>] ? ioctl_standard_call+0x0/0xd0
       [<ffffffff816b3223>] ? T.808+0x163/0x170
       [<ffffffff8112ddf2>] ? might_fault+0x72/0xd0
       [<ffffffff816b326a>] ? wext_handle_ioctl+0x3a/0x90
       [<ffffffff8112de3b>] ? might_fault+0xbb/0xd0
       [<ffffffff815798d2>] ? dev_ioctl+0x6f2/0x830
       [<ffffffff810a1bae>] ? put_lock_stats+0xe/0x40
       [<ffffffff810a1c8c>] ? lock_release_holdtime+0xac/0x150
       [<ffffffff8155cf3d>] ? sock_ioctl+0xfd/0x290
       [<ffffffff8117dffd>] ? do_vfs_ioctl+0x9d/0x590
       [<ffffffff8116c8ff>] ? fget_light+0x1df/0x3c0
       [<ffffffff8117e53a>] ? sys_ioctl+0x4a/0x80
       [<ffffffff81003192>] ? system_call_fastpath+0x16/0x1b
      Signed-off-by: NDaniel J Blueman <daniel.blueman@gmail.com>
      Acked-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      4f919a3b
    • G
      rt2x00: Fix WPA TKIP Michael MIC failures. · a866a2cc
      Gertjan van Wingerde 提交于
      As reported and found by Johannes Stezenbach:
      rt2800{pci,usb} do not report the Michael MIC in RXed frames, but do check
      the Michael MIC in hardware. Therefore we have to report to mac80211 that the
      received frame does not include the Michael MIC.
      
      https://bugzilla.kernel.org/show_bug.cgi?id=16608Signed-off-by: NGertjan van Wingerde <gwingerde@gmail.com>
      Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      a866a2cc
    • N
      ath5k: Fix fast channel switching · 573cfde7
      Nick Kossifidis 提交于
      Fast channel change fixes:
      
      a) Always set OFDM timings
      b) Don't re-activate PHY
      c) Enable only NF calibration, not AGC
      
      https://bugzilla.kernel.org/show_bug.cgi?id=27382Signed-off-by: NNick Kossifidis <mickflemm@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      573cfde7
    • Y
      tcp: undo_retrans counter fixes · c24f691b
      Yuchung Cheng 提交于
      Fix a bug that undo_retrans is incorrectly decremented when undo_marker is
      not set or undo_retrans is already 0. This happens when sender receives
      more DSACK ACKs than packets retransmitted during the current
      undo phase. This may also happen when sender receives DSACK after
      the undo operation is completed or cancelled.
      
      Fix another bug that undo_retrans is incorrectly incremented when
      sender retransmits an skb and tcp_skb_pcount(skb) > 1 (TSO). This case
      is rare but not impossible.
      Signed-off-by: NYuchung Cheng <ycheng@google.com>
      Acked-by: NIlpo Järvinen <ilpo.jarvinen@helsinki.fi>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c24f691b
  4. 21 2月, 2011 1 次提交
    • E
      net: Fix more stale on-stack list_head objects. · 5f04d506
      Eric W. Biederman 提交于
      From: Eric W. Biederman <ebiederm@xmission.com>
      
      In the beginning with batching unreg_list was a list that was used only
      once in the lifetime of a network device (I think).  Now we have calls
      using the unreg_list that can happen multiple times in the life of a
      network device like dev_deactivate and dev_close that are also using the
      unreg_list.  In addition in unregister_netdevice_queue we also do a
      list_move because for devices like veth pairs it is possible that
      unregister_netdevice_queue will be called multiple times.
      
      So I think the change below to fix dev_deactivate which Eric D. missed
      will fix this problem.  Now to go test that.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5f04d506
  5. 20 2月, 2011 4 次提交
  6. 19 2月, 2011 12 次提交
  7. 18 2月, 2011 7 次提交