1. 27 Mar, 2013 4 commits
  2. 25 Mar, 2013 2 commits
  3. 24 Mar, 2013 2 commits
    • Ben Greear's avatar
      mac80211: Don't restart sta-timer if not associated. · 370bd005
      Ben Greear authored
      I found another crash when deleting lots of virtual stations
      in a congested environment.  I think the problem is that
      the ieee80211_mlme_notify_scan_completed could call
      ieee80211_restart_sta_timer for a stopped interface
      that was about to be deleted.
      
      With the following patch I am unable to reproduce the
      crash.
      Signed-off-by: default avatarBen Greear <greearb@candelatech.com>
      [move check, also make the same change in mesh]
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      370bd005
    • Johannes Berg's avatar
      cfg80211: always check for scan end on P2P device · f9f47529
      Johannes Berg authored
      If a P2P device wdev is removed while it has a scan, then the
      scan completion might crash later as it is already freed by
      that time. To avoid the crash always check the scan completion
      when the P2P device is being removed for some reason. If the
      driver already canceled it, don't want and free it, otherwise
      warn and leak it to avoid later crashes.
      
      In order to do this, locking needs to be changed away from the
      rdev mutex (which can't always be guaranteed). For now, use
      the sched_scan_mtx instead, I'll rename it to just scan_mtx in
      a later patch.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      f9f47529
  4. 20 Mar, 2013 5 commits
  5. 18 Mar, 2013 9 commits
  6. 15 Mar, 2013 1 commit
    • Ming Lei's avatar
      Bluetooth: Add support for Dell[QCA 0cf3:0036] · d66629c1
      Ming Lei authored
      Add support for the AR9462 chip
      
      T:  Bus=03 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#=  3 Spd=12   MxCh= 0
      D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
      P:  Vendor=0cf3 ProdID=0036 Rev= 0.02
      C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
      A:  FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=01
      I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=1ms
      E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
      I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
      I:  If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
      I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
      I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
      I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
      
      Cc: <stable@vger.kernel.org>
      Cc: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
      Signed-off-by: default avatarMing Lei <ming.lei@canonical.com>
      Signed-off-by: default avatarGustavo Padovan <gustavo.padovan@collabora.co.uk>
      d66629c1
  7. 14 Mar, 2013 1 commit
    • Vinicius Costa Gomes's avatar
      Bluetooth: Fix not closing SCO sockets in the BT_CONNECT2 state · eb20ff9c
      Vinicius Costa Gomes authored
      With deferred setup for SCO, it is possible that userspace closes the
      socket when it is in the BT_CONNECT2 state, after the Connect Request is
      received but before the Accept Synchonous Connection is sent.
      
      If this happens the following crash was observed, when the connection is
      terminated:
      
      [  +0.000003] hci_sync_conn_complete_evt: hci0 status 0x10
      [  +0.000005] sco_connect_cfm: hcon ffff88003d1bd800 bdaddr 40:98:4e:32:d7:39 status 16
      [  +0.000003] sco_conn_del: hcon ffff88003d1bd800 conn ffff88003cc8e300, err 110
      [  +0.000015] BUG: unable to handle kernel NULL pointer dereference at 0000000000000199
      [  +0.000906] IP: [<ffffffff810620dd>] __lock_acquire+0xed/0xe82
      [  +0.000000] PGD 3d21f067 PUD 3d291067 PMD 0
      [  +0.000000] Oops: 0002 [#1] SMP
      [  +0.000000] Modules linked in: rfcomm bnep btusb bluetooth
      [  +0.000000] CPU 0
      [  +0.000000] Pid: 1481, comm: kworker/u:2H Not tainted 3.9.0-rc1-25019-gad82cdd1 #1 Bochs Bochs
      [  +0.000000] RIP: 0010:[<ffffffff810620dd>]  [<ffffffff810620dd>] __lock_acquire+0xed/0xe82
      [  +0.000000] RSP: 0018:ffff88003c3c19d8  EFLAGS: 00010002
      [  +0.000000] RAX: 0000000000000001 RBX: 0000000000000246 RCX: 0000000000000000
      [  +0.000000] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff88003d1be868
      [  +0.000000] RBP: ffff88003c3c1a98 R08: 0000000000000002 R09: 0000000000000000
      [  +0.000000] R10: ffff88003d1be868 R11: ffff88003e20b000 R12: 0000000000000002
      [  +0.000000] R13: ffff88003aaa8000 R14: 000000000000006e R15: ffff88003d1be850
      [  +0.000000] FS:  0000000000000000(0000) GS:ffff88003e200000(0000) knlGS:0000000000000000
      [  +0.000000] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      [  +0.000000] CR2: 0000000000000199 CR3: 000000003c1cb000 CR4: 00000000000006b0
      [  +0.000000] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [  +0.000000] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      [  +0.000000] Process kworker/u:2H (pid: 1481, threadinfo ffff88003c3c0000, task ffff88003aaa8000)
      [  +0.000000] Stack:
      [  +0.000000]  ffffffff81b16342 0000000000000000 0000000000000000 ffff88003d1be868
      [  +0.000000]  ffffffff00000000 00018c0c7863e367 000000003c3c1a28 ffffffff8101efbd
      [  +0.000000]  0000000000000000 ffff88003e3d2400 ffff88003c3c1a38 ffffffff81007c7a
      [  +0.000000] Call Trace:
      [  +0.000000]  [<ffffffff8101efbd>] ? kvm_clock_read+0x34/0x3b
      [  +0.000000]  [<ffffffff81007c7a>] ? paravirt_sched_clock+0x9/0xd
      [  +0.000000]  [<ffffffff81007fd4>] ? sched_clock+0x9/0xb
      [  +0.000000]  [<ffffffff8104fd7a>] ? sched_clock_local+0x12/0x75
      [  +0.000000]  [<ffffffff810632d1>] lock_acquire+0x93/0xb1
      [  +0.000000]  [<ffffffffa0022339>] ? spin_lock+0x9/0xb [bluetooth]
      [  +0.000000]  [<ffffffff8105f3d8>] ? lock_release_holdtime.part.22+0x4e/0x55
      [  +0.000000]  [<ffffffff814f6038>] _raw_spin_lock+0x40/0x74
      [  +0.000000]  [<ffffffffa0022339>] ? spin_lock+0x9/0xb [bluetooth]
      [  +0.000000]  [<ffffffff814f6936>] ? _raw_spin_unlock+0x23/0x36
      [  +0.000000]  [<ffffffffa0022339>] spin_lock+0x9/0xb [bluetooth]
      [  +0.000000]  [<ffffffffa00230cc>] sco_conn_del+0x76/0xbb [bluetooth]
      [  +0.000000]  [<ffffffffa002391d>] sco_connect_cfm+0x2da/0x2e9 [bluetooth]
      [  +0.000000]  [<ffffffffa000862a>] hci_proto_connect_cfm+0x38/0x65 [bluetooth]
      [  +0.000000]  [<ffffffffa0008d30>] hci_sync_conn_complete_evt.isra.79+0x11a/0x13e [bluetooth]
      [  +0.000000]  [<ffffffffa000cd96>] hci_event_packet+0x153b/0x239d [bluetooth]
      [  +0.000000]  [<ffffffff814f68ff>] ? _raw_spin_unlock_irqrestore+0x48/0x5c
      [  +0.000000]  [<ffffffffa00025f6>] hci_rx_work+0xf3/0x2e3 [bluetooth]
      [  +0.000000]  [<ffffffff8103efed>] process_one_work+0x1dc/0x30b
      [  +0.000000]  [<ffffffff8103ef83>] ? process_one_work+0x172/0x30b
      [  +0.000000]  [<ffffffff8103e07f>] ? spin_lock_irq+0x9/0xb
      [  +0.000000]  [<ffffffff8103fc8d>] worker_thread+0x123/0x1d2
      [  +0.000000]  [<ffffffff8103fb6a>] ? manage_workers+0x240/0x240
      [  +0.000000]  [<ffffffff81044211>] kthread+0x9d/0xa5
      [  +0.000000]  [<ffffffff81044174>] ? __kthread_parkme+0x60/0x60
      [  +0.000000]  [<ffffffff814f75bc>] ret_from_fork+0x7c/0xb0
      [  +0.000000]  [<ffffffff81044174>] ? __kthread_parkme+0x60/0x60
      [  +0.000000] Code: d7 44 89 8d 50 ff ff ff 4c 89 95 58 ff ff ff e8 44 fc ff ff 44 8b 8d 50 ff ff ff 48 85 c0 4c 8b 95 58 ff ff ff 0f 84 7a 04 00 00 <f0> ff 80 98 01 00 00 83 3d 25 41 a7 00 00 45 8b b5 e8 05 00 00
      [  +0.000000] RIP  [<ffffffff810620dd>] __lock_acquire+0xed/0xe82
      [  +0.000000]  RSP <ffff88003c3c19d8>
      [  +0.000000] CR2: 0000000000000199
      [  +0.000000] ---[ end trace e73cd3b52352dd34 ]---
      
      Cc: stable@vger.kernel.org [3.8]
      Signed-off-by: default avatarVinicius Costa Gomes <vinicius.gomes@openbossa.org>
      Tested-by: default avatarFrederic Dalleau <frederic.dalleau@intel.com>
      Signed-off-by: default avatarGustavo Padovan <gustavo.padovan@collabora.co.uk>
      eb20ff9c
  8. 13 Mar, 2013 3 commits
  9. 11 Mar, 2013 3 commits
    • Sunguk Lee's avatar
      Bluetooth: Device 0cf3:3008 should map AR 3012 · 94a32d10
      Sunguk Lee authored
      T:  Bus=01 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#=  3 Spd=12   MxCh= 0
      D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
      P:  Vendor=0cf3 ProdID=3008 Rev= 0.01
      S:  Manufacturer=Atheros Communications
      S:  Product=Bluetooth USB Host Controller
      S:  SerialNumber=Alaska Day 2006
      C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
      I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=1ms
      E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
      I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
      I:  If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
      I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
      I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
      I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
      Signed-off-by: default avatarSunguk Lee <d3m3vilurr@gmail.com>
      Signed-off-by: default avatarGustavo Padovan <gustavo.padovan@collabora.co.uk>
      94a32d10
    • John W. Linville's avatar
      Merge tag 'nfc-fixes-3.9-1' of git://git.kernel.org/pub/scm/linux/kernel/git/sameo/nfc-fixes · de121989
      John W. Linville authored
      Samuel Ortiz <sameo@linux.intel.com> says:
      
      This is the first NFC pull request for 3.9 fixes
      
      With this one we have:
      
      - A fix for properly decreasing socket ack log.
      - A timer and works cleanup upon NFC device removal.
      - A monitoroing socket cleanup round from llcp_socket_release.
      - A proper error report to pending sockets upon NFC device removal.
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      de121989
    • Johannes Berg's avatar
      mac80211: fix crash with P2P Device returning action frames · 07e5a5f5
      Johannes Berg authored
      If a P2P Device interface receives an unhandled action
      frame, we attempt to return it. This crashes because it
      doesn't have a channel context. Fix the crash by using
      status->band and properly mark the return frame as an
      off-channel frame.
      Reported-by: default avatarIlan Peer <ilan.peer@intel.com>
      Reviewed-by: default avatarIlan Peer <ilan.peer@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      07e5a5f5
  10. 08 Mar, 2013 6 commits
  11. 07 Mar, 2013 2 commits
  12. 06 Mar, 2013 2 commits
    • Johannes Berg's avatar
      mac80211: always synchronize_net() during station removal · 27a737ff
      Johannes Berg authored
      If there are keys left during station removal, then a
      synchronize_net() will be done (for each key, I have a
      patch to address this for 3.10), otherwise it won't be
      done at all which causes issues because the station
      could be used for TX while it's being removed from the
      driver -- that might confuse the driver.
      
      Fix this by always doing synchronize_net() if no key
      was present any more.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      27a737ff
    • David S. Miller's avatar
      Merge branch 'for-davem' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless · 930df2df
      David S. Miller authored
      John W. Linville says:
      
      ====================
      This time just passing along a big batch of fixes from Johannes...
      
      For the mac80211 bits:
      
      "Here I have fixes from Ben Greear for stray work items when deleting
      interfaces, another idle handling fix from Felix, a fix from Marco ro a
      mesh PS buffering crash and I have a fix for the VHT MCS calculation in
      association request frames and more nl80211 feature advertising removal
      as well as a workaround to increase the dump size if the SKB overhead is
      too large. For 3.10 I already have a complete fix queued, but that also
      requires (simple) userspace changes."
      
      And for the iwlwifi bits:
      
      "The patches from Dor fix a bunch of calibration issues in the new MVM
      driver, and Emmanuel has a number of fixes there as well. Also, we
      decided to disable 8k A-MSDU by default, so that's in there. My own
      patches are addressing an issue we found with the new devices but that
      seems to also exist on older ones, the DMA writeback the devices do can
      be delayed and cause issues. The fix is unfortunately relatively large
      and depends on two other changes (to not be hugely conflicting), but I
      think it's still worth it at this point."
      
      As Johannes says, it is a bit large.  But I hope it is still early
      enough in the cycle to make that worthwhile.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      930df2df