1. 08 Sep, 2010 2 commits
  2. 07 Sep, 2010 11 commits
  3. 03 Sep, 2010 4 commits
  4. 02 Sep, 2010 6 commits
  5. 01 Sep, 2010 9 commits
  6. 31 Aug, 2010 5 commits
    • Luis R. Rodriguez's avatar
      ath9k_hw: fix parsing of HT40 5 GHz CTLs · 90487974
      Luis R. Rodriguez authored
      
      
      The 5 GHz CTL indexes were not being read for all hardware
      devices due to the masking out through the CTL_MODE_M mask
      being one bit too short. Without this the calibrated regulatory
      maximum values were not being picked up when devices operate
      on 5 GHz in HT40 mode. The final output power used for Atheros
      devices is the minimum between the calibrated CTL values and
      what CRDA provides.
      
      Cc: stable@kernel.org [2.6.27+]
      Signed-off-by: default avatarLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      90487974
    • Luis R. Rodriguez's avatar
      ath9k_hw: Fix EEPROM uncompress block reading on AR9003 · 803288e6
      Luis R. Rodriguez authored
      
      
      The EEPROM is compressed on AR9003, upon decompression
      the wrong upper limit was being used for the block which
      prevented the 5 GHz CTL indexes from being used, which are
      stored towards the end of the EEPROM block. This fix allows
      the actual intended regulatory limits to be used on AR9003
      hardware.
      
      Cc: stable@kernel.org [2.6.36+]
      Signed-off-by: default avatarLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      803288e6
    • John W. Linville's avatar
      wireless: register wiphy rfkill w/o holding cfg80211_mutex · c3d34d5d
      John W. Linville authored
      Otherwise lockdep complains...
      
      https://bugzilla.kernel.org/show_bug.cgi?id=17311
      
      
      
      [ INFO: possible circular locking dependency detected ]
      2.6.36-rc2-git4 #12
      -------------------------------------------------------
      kworker/0:3/3630 is trying to acquire lock:
       (rtnl_mutex){+.+.+.}, at: [<ffffffff813396c7>] rtnl_lock+0x12/0x14
      
      but task is already holding lock:
       (rfkill_global_mutex){+.+.+.}, at: [<ffffffffa014b129>]
      rfkill_switch_all+0x24/0x49 [rfkill]
      
      which lock already depends on the new lock.
      
      the existing dependency chain (in reverse order) is:
      
      -> #2 (rfkill_global_mutex){+.+.+.}:
             [<ffffffff81079ad7>] lock_acquire+0x120/0x15b
             [<ffffffff813ae869>] __mutex_lock_common+0x54/0x52e
             [<ffffffff813aede9>] mutex_lock_nested+0x34/0x39
             [<ffffffffa014b4ab>] rfkill_register+0x2b/0x29c [rfkill]
             [<ffffffffa0185ba0>] wiphy_register+0x1ae/0x270 [cfg80211]
             [<ffffffffa0206f01>] ieee80211_register_hw+0x1b4/0x3cf [mac80211]
             [<ffffffffa0292e98>] iwl_ucode_callback+0x9e9/0xae3 [iwlagn]
             [<ffffffff812d3e9d>] request_firmware_work_func+0x54/0x6f
             [<ffffffff81065d15>] kthread+0x8c/0x94
             [<ffffffff8100ac24>] kernel_thread_helper+0x4/0x10
      
      -> #1 (cfg80211_mutex){+.+.+.}:
             [<ffffffff81079ad7>] lock_acquire+0x120/0x15b
             [<ffffffff813ae869>] __mutex_lock_common+0x54/0x52e
             [<ffffffff813aede9>] mutex_lock_nested+0x34/0x39
             [<ffffffffa018605e>] cfg80211_get_dev_from_ifindex+0x1b/0x7c [cfg80211]
             [<ffffffffa0189f36>] cfg80211_wext_giwscan+0x58/0x990 [cfg80211]
             [<ffffffff8139a3ce>] ioctl_standard_iw_point+0x1a8/0x272
             [<ffffffff8139a529>] ioctl_standard_call+0x91/0xa7
             [<ffffffff8139a687>] T.723+0xbd/0x12c
             [<ffffffff8139a727>] wext_handle_ioctl+0x31/0x6d
             [<ffffffff8133014e>] dev_ioctl+0x63d/0x67a
             [<ffffffff8131afd9>] sock_ioctl+0x48/0x21d
             [<ffffffff81102abd>] do_vfs_ioctl+0x4ba/0x509
             [<ffffffff81102b5d>] sys_ioctl+0x51/0x74
             [<ffffffff81009e02>] system_call_fastpath+0x16/0x1b
      
      -> #0 (rtnl_mutex){+.+.+.}:
             [<ffffffff810796b0>] __lock_acquire+0xa93/0xd9a
             [<ffffffff81079ad7>] lock_acquire+0x120/0x15b
             [<ffffffff813ae869>] __mutex_lock_common+0x54/0x52e
             [<ffffffff813aede9>] mutex_lock_nested+0x34/0x39
             [<ffffffff813396c7>] rtnl_lock+0x12/0x14
             [<ffffffffa0185cb5>] cfg80211_rfkill_set_block+0x1a/0x7b [cfg80211]
             [<ffffffffa014aed0>] rfkill_set_block+0x80/0xd5 [rfkill]
             [<ffffffffa014b07e>] __rfkill_switch_all+0x3f/0x6f [rfkill]
             [<ffffffffa014b13d>] rfkill_switch_all+0x38/0x49 [rfkill]
             [<ffffffffa014b821>] rfkill_op_handler+0x105/0x136 [rfkill]
             [<ffffffff81060708>] process_one_work+0x248/0x403
             [<ffffffff81062620>] worker_thread+0x139/0x214
             [<ffffffff81065d15>] kthread+0x8c/0x94
             [<ffffffff8100ac24>] kernel_thread_helper+0x4/0x10
      
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      Acked-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      c3d34d5d
    • David S. Miller's avatar
      netlink: Make NETLINK_USERSOCK work again. · b963ea89
      David S. Miller authored
      
      
      Once we started enforcing the a nl_table[] entry exist for
      a protocol, NETLINK_USERSOCK stopped working.  Add a dummy
      table entry so that it works again.
      
      Reported-by: default avatarThomas Voegtle <tv@lio96.de>
      Tested-by: default avatarThomas Voegtle <tv@lio96.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b963ea89
    • David S. Miller's avatar
      irda: Correctly clean up self->ias_obj on irda_bind() failure. · 628e300c
      David S. Miller authored
      
      
      If irda_open_tsap() fails, the irda_bind() code tries to destroy
      the ->ias_obj object by hand, but does so wrongly.
      
      In particular, it fails to a) release the hashbin attached to the
      object and b) reset the self->ias_obj pointer to NULL.
      
      Fix both problems by using irias_delete_object() and explicitly
      setting self->ias_obj to NULL, just as irda_release() does.
      
      Reported-by: default avatarTavis Ormandy <taviso@cmpxchg8b.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      628e300c
  7. 30 Aug, 2010 3 commits
    • Johannes Berg's avatar
      wireless extensions: fix kernel heap content leak · 42da2f94
      Johannes Berg authored
      
      
      Wireless extensions have an unfortunate, undocumented
      requirement which requires drivers to always fill
      iwp->length when returning a successful status. When
      a driver doesn't do this, it leads to a kernel heap
      content leak when userspace offers a larger buffer
      than would have been necessary.
      
      Arguably, this is a driver bug, as it should, if it
      returns 0, fill iwp->length, even if it separately
      indicated that the buffer contents was not valid.
      
      However, we can also at least avoid the memory content
      leak if the driver doesn't do this by setting the iwp
      length to max_tokens, which then reflects how big the
      buffer is that the driver may fill, regardless of how
      big the userspace buffer is.
      
      To illustrate the point, this patch also fixes a
      corresponding cfg80211 bug (since this requirement
      isn't documented nor was ever pointed out by anyone
      during code review, I don't trust all drivers nor
      all cfg80211 handlers to implement it correctly).
      
      Cc: stable@kernel.org [all the way back]
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      42da2f94
    • John W. Linville's avatar
      9ef80804
    • Johannes Berg's avatar
      mac80211: delete work timer · 071249b1
      Johannes Berg authored
      
      
      The new workqueue changes helped me find this bug
      that's been lingering since the changes to the work
      processing in mac80211 -- the work timer is never
      deleted properly. Do that to avoid having it fire
      after all data structures have been freed. It can't
      be re-armed because all it will do, if running, is
      schedule the work, but that gets flushed later and
      won't have anything to do since all work items are
      gone by now (by way of interface removal).
      
      Cc: stable@kernel.org [2.6.34+]
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      071249b1