1. 12 10月, 2010 1 次提交
  2. 08 10月, 2010 2 次提交
  3. 07 10月, 2010 4 次提交
  4. 06 10月, 2010 8 次提交
  5. 29 9月, 2010 1 次提交
  6. 28 9月, 2010 1 次提交
  7. 21 9月, 2010 1 次提交
  8. 17 9月, 2010 3 次提交
  9. 15 9月, 2010 2 次提交
  10. 01 9月, 2010 2 次提交
    • J
      wireless: register wiphy rfkill w/o holding cfg80211_mutex · c3d34d5d
      John W. Linville 提交于
      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: NJohn W. Linville <linville@tuxdriver.com>
      Acked-by: NJohannes Berg <johannes@sipsolutions.net>
      c3d34d5d
    • J
      net/wireless: Remove double test · 36539107
      Julia Lawall 提交于
      The same expression is tested twice and the result is the same each time.
      
      The sematic match that finds this problem is as follows:
      (http://coccinelle.lip6.fr/)
      
      // <smpl>
      @expression@
      expression E;
      @@
      
      (
      * E
        || ... || E
      |
      * E
        && ... && E
      )
      // </smpl>
      Signed-off-by: NJulia Lawall <julia@diku.dk>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      36539107
  11. 31 8月, 2010 1 次提交
    • J
      wireless extensions: fix kernel heap content leak · 42da2f94
      Johannes Berg 提交于
      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: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      42da2f94
  12. 28 8月, 2010 2 次提交
  13. 26 8月, 2010 1 次提交
    • J
      nl80211: fix missing nesting · 74b70a4e
      Johannes Berg 提交于
      commit 95a6ccbb46c70cff376684c752831c014c87029d
      Author: Johannes Berg <johannes.berg@intel.com>
      Date:   Thu Aug 12 15:38:38 2010 +0200
      
          cfg80211/mac80211: extensible frame processing
      
      introduced a netlink bug that caused parsing errors
      in userspace because it forgot to close a nesting,
      which would advertise a nesting length of zero to
      userspace, which then completely threw off parsing
      and led to
      
      	Illegal nla->nla_type == 0
      
      being printed by libnl.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      74b70a4e
  14. 25 8月, 2010 2 次提交
  15. 17 8月, 2010 4 次提交
  16. 10 8月, 2010 1 次提交
  17. 29 7月, 2010 2 次提交
  18. 28 7月, 2010 1 次提交
    • J
      wireless: Convert wiphy_debug macro to function · 073730d7
      Joe Perches 提交于
      Save a few bytes of text
      
      (allyesconfig)
      $ size drivers/net/wireless/built-in.o*
         text	   data	    bss	    dec	    hex	filename
      3924568	 100548	 871056	4896172	 4ab5ac	drivers/net/wireless/built-in.o.new
      3926520	 100548	 871464	4898532	 4abee4	drivers/net/wireless/built-in.o.old
      
      $ size net/wireless/core.o*
         text	   data	    bss	    dec	    hex	filename
        12843	    216	   3768	  16827	   41bb	net/wireless/core.o.new
        12328	    216	   3656	  16200	   3f48	net/wireless/core.o
      Signed-off-by: NJoe Perches <joe@perches.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      073730d7
  19. 27 7月, 2010 1 次提交