1. 29 Feb, 2012 3 commits
  2. 23 Feb, 2012 2 commits
  3. 21 Feb, 2012 5 commits
  4. 15 Feb, 2012 17 commits
    • Pavel Roskin's avatar
      ath9k: stop on rates with idx -1 in ath9k rate control's .tx_status · 2504a642
      Pavel Roskin authored
      Rate control algorithms are supposed to stop processing when they
      encounter a rate with the index -1.  Checking for rate->count not being
      zero is not enough.
      
      Allowing a rate with negative index leads to memory corruption in
      ath_debug_stat_rc().
      
      One consequence of the bug is discussed at
      https://bugzilla.redhat.com/show_bug.cgi?id=768639Signed-off-by: default avatarPavel Roskin <proski@gnu.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      2504a642
    • Amitkumar Karwar's avatar
      mwifiex: clear previous security setting during association · 6670f15b
      Amitkumar Karwar authored
      Driver maintains different flags for WEP, WPA, WPA2 security modes.
      Appropriate flag is set using security information provided in
      connect request. mwifiex_is_network_compatible() routine uses them
      to check if driver's setting is compatible with AP. Association is
      aborted if the routine fails.
      
      For some corner cases, it is observed that association is failed
      even for valid security information based on association history.
      This patch fixes the problem by clearing previous security setting
      during each association.
      
      We should set WEP key provided in connect request as default tx key.
      This missing change is also added here.
      Signed-off-by: default avatarAmitkumar Karwar <akarwar@marvell.com>
      Signed-off-by: default avatarBing Zhao <bzhao@marvell.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      6670f15b
    • Felix Fietkau's avatar
      mac80211: do not call rate control .tx_status before .rate_init · 216c57b2
      Felix Fietkau authored
      Most rate control implementations assume .get_rate and .tx_status are only
      called once the per-station data has been fully initialized.
      minstrel_ht crashes if this assumption is violated.
      Signed-off-by: default avatarFelix Fietkau <nbd@openwrt.org>
      Tested-by: default avatarArend van Spriel <arend@broadcom.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      216c57b2
    • Johannes Berg's avatar
      mac80211: call rate control only after init · 4b5a433a
      Johannes Berg authored
      There are situations where we don't have the
      necessary rate control information yet for
      station entries, e.g. when associating. This
      currently doesn't really happen due to the
      dummy station handling; explicitly disabling
      rate control when it's not initialised will
      allow us to remove dummy stations.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      4b5a433a
    • Ulisses Furquim's avatar
      Bluetooth: Fix possible use after free in delete path · 24d2b8c0
      Ulisses Furquim authored
      We need to use the _sync() version for cancelling the info and security
      timer in the L2CAP connection delete path. Otherwise the delayed work
      handler might run after the connection object is freed.
      Signed-off-by: default avatarUlisses Furquim <ulisses@profusion.mobi>
      Acked-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      24d2b8c0
    • Ulisses Furquim's avatar
      Bluetooth: Remove usage of __cancel_delayed_work() · 6de32750
      Ulisses Furquim authored
      __cancel_delayed_work() is being used in some paths where we cannot
      sleep waiting for the delayed work to finish. However, that function
      might return while the timer is running and the work will be queued
      again. Replace the calls with safer cancel_delayed_work() version
      which spins until the timer handler finishes on other CPUs and
      cancels the delayed work.
      Signed-off-by: default avatarUlisses Furquim <ulisses@profusion.mobi>
      Acked-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      6de32750
    • Manoj Iyer's avatar
      Bluetooth: btusb: Add vendor specific ID (0a5c 21f3) for BCM20702A0 · 403f048a
      Manoj Iyer authored
      T: Bus=01 Lev=02 Prnt=02 Port=03 Cnt=03 Dev#= 5 Spd=12 MxCh= 0
      D: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
      P: Vendor=0a5c ProdID=21f3 Rev=01.12
      S: Manufacturer=Broadcom Corp
      S: Product=BCM20702A0
      S: SerialNumber=74DE2B344A7B
      C: #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=0mA
      I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
      I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
      I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
      I: If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none)
      Signed-off-by: default avatarManoj Iyer <manoj.iyer@canonical.com>
      Tested-by: default avatarDennis Chua <dennis.chua@canonical.com>
      Acked-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      403f048a
    • Johan Hedberg's avatar
      Bluetooth: Add missing QUIRK_NO_RESET test to hci_dev_do_close · ca0d6c7e
      Johan Hedberg authored
      We should only perform a reset in hci_dev_do_close if the
      HCI_QUIRK_NO_RESET flag is set (since in such a case a reset will not be
      performed when initializing the device).
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      Acked-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      ca0d6c7e
    • Octavian Purdila's avatar
      Bluetooth: Fix RFCOMM session reference counting issue · cf33e77b
      Octavian Purdila authored
      There is an imbalance in the rfcomm_session_hold / rfcomm_session_put
      operations which causes the following crash:
      
      [  685.010159] BUG: unable to handle kernel paging request at 6b6b6b6b
      [  685.010169] IP: [<c149d76d>] rfcomm_process_dlcs+0x1b/0x15e
      [  685.010181] *pdpt = 000000002d665001 *pde = 0000000000000000
      [  685.010191] Oops: 0000 [#1] PREEMPT SMP
      [  685.010247]
      [  685.010255] Pid: 947, comm: krfcommd Tainted: G         C  3.0.16-mid8-dirty #44
      [  685.010266] EIP: 0060:[<c149d76d>] EFLAGS: 00010246 CPU: 1
      [  685.010274] EIP is at rfcomm_process_dlcs+0x1b/0x15e
      [  685.010281] EAX: e79f551c EBX: 6b6b6b6b ECX: 00000007 EDX: e79f40b4
      [  685.010288] ESI: e79f4060 EDI: ed4e1f70 EBP: ed4e1f68 ESP: ed4e1f50
      [  685.010295]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
      [  685.010303] Process krfcommd (pid: 947, ti=ed4e0000 task=ed43e5e0 task.ti=ed4e0000)
      [  685.010308] Stack:
      [  685.010312]  ed4e1f68 c149eb53 e5925150 e79f4060 ed500000 ed4e1f70 ed4e1f80 c149ec10
      [  685.010331]  00000000 ed43e5e0 00000000 ed4e1f90 ed4e1f9c c149ec87 0000bf54 00000000
      [  685.010348]  00000000 ee03bf54 c149ec37 ed4e1fe4 c104fe01 00000000 00000000 00000000
      [  685.010367] Call Trace:
      [  685.010376]  [<c149eb53>] ? rfcomm_process_rx+0x6e/0x74
      [  685.010387]  [<c149ec10>] rfcomm_process_sessions+0xb7/0xde
      [  685.010398]  [<c149ec87>] rfcomm_run+0x50/0x6d
      [  685.010409]  [<c149ec37>] ? rfcomm_process_sessions+0xde/0xde
      [  685.010419]  [<c104fe01>] kthread+0x63/0x68
      [  685.010431]  [<c104fd9e>] ? __init_kthread_worker+0x42/0x42
      [  685.010442]  [<c14dae82>] kernel_thread_helper+0x6/0xd
      
      This issue has been brought up earlier here:
      
      https://lkml.org/lkml/2011/5/21/127
      
      The issue appears to be the rfcomm_session_put in rfcomm_recv_ua. This
      operation doesn't seem be to required as for the non-initiator case we
      have the rfcomm_process_rx doing an explicit put and in the initiator
      case the last dlc_unlink will drive the reference counter to 0.
      
      There have been several attempts to fix these issue:
      
      6c2718da Bluetooth: Do not call rfcomm_session_put() for RFCOMM UA on closed socket
      683d949a Bluetooth: Never deallocate a session when some DLC points to it
      
      but AFAICS they do not fix the issue just make it harder to reproduce.
      Signed-off-by: default avatarOctavian Purdila <octavian.purdila@intel.com>
      Signed-off-by: default avatarGopala Krishna Murala <gopala.krishna.murala@intel.com>
      Acked-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      cf33e77b
    • Andre Guedes's avatar
      Bluetooth: Fix potential deadlock · a51cd2be
      Andre Guedes authored
      We don't need to use the _sync variant in hci_conn_hold and
      hci_conn_put to cancel conn->disc_work delayed work. This way
      we avoid potential deadlocks like this one reported by lockdep.
      
      ======================================================
      [ INFO: possible circular locking dependency detected ]
      3.2.0+ #1 Not tainted
      -------------------------------------------------------
      kworker/u:1/17 is trying to acquire lock:
       (&hdev->lock){+.+.+.}, at: [<ffffffffa0041155>] hci_conn_timeout+0x62/0x158 [bluetooth]
      
      but task is already holding lock:
       ((&(&conn->disc_work)->work)){+.+...}, at: [<ffffffff81035751>] process_one_work+0x11a/0x2bf
      
      which lock already depends on the new lock.
      
      the existing dependency chain (in reverse order) is:
      
      -> #2 ((&(&conn->disc_work)->work)){+.+...}:
             [<ffffffff81057444>] lock_acquire+0x8a/0xa7
             [<ffffffff81034ed1>] wait_on_work+0x3d/0xaa
             [<ffffffff81035b54>] __cancel_work_timer+0xac/0xef
             [<ffffffff81035ba4>] cancel_delayed_work_sync+0xd/0xf
             [<ffffffffa00554b0>] smp_chan_create+0xde/0xe6 [bluetooth]
             [<ffffffffa0056160>] smp_conn_security+0xa3/0x12d [bluetooth]
             [<ffffffffa0053640>] l2cap_connect_cfm+0x237/0x2e8 [bluetooth]
             [<ffffffffa004239c>] hci_proto_connect_cfm+0x2d/0x6f [bluetooth]
             [<ffffffffa0046ea5>] hci_event_packet+0x29d1/0x2d60 [bluetooth]
             [<ffffffffa003dde3>] hci_rx_work+0xd0/0x2e1 [bluetooth]
             [<ffffffff810357af>] process_one_work+0x178/0x2bf
             [<ffffffff81036178>] worker_thread+0xce/0x152
             [<ffffffff81039a03>] kthread+0x95/0x9d
             [<ffffffff812e7754>] kernel_thread_helper+0x4/0x10
      
      -> #1 (slock-AF_BLUETOOTH-BTPROTO_L2CAP){+.+...}:
             [<ffffffff81057444>] lock_acquire+0x8a/0xa7
             [<ffffffff812e553a>] _raw_spin_lock_bh+0x36/0x6a
             [<ffffffff81244d56>] lock_sock_nested+0x24/0x7f
             [<ffffffffa004d96f>] lock_sock+0xb/0xd [bluetooth]
             [<ffffffffa0052906>] l2cap_chan_connect+0xa9/0x26f [bluetooth]
             [<ffffffffa00545f8>] l2cap_sock_connect+0xb3/0xff [bluetooth]
             [<ffffffff81243b48>] sys_connect+0x69/0x8a
             [<ffffffff812e6579>] system_call_fastpath+0x16/0x1b
      
      -> #0 (&hdev->lock){+.+.+.}:
             [<ffffffff81056d06>] __lock_acquire+0xa80/0xd74
             [<ffffffff81057444>] lock_acquire+0x8a/0xa7
             [<ffffffff812e3870>] __mutex_lock_common+0x48/0x38e
             [<ffffffff812e3c75>] mutex_lock_nested+0x2a/0x31
             [<ffffffffa0041155>] hci_conn_timeout+0x62/0x158 [bluetooth]
             [<ffffffff810357af>] process_one_work+0x178/0x2bf
             [<ffffffff81036178>] worker_thread+0xce/0x152
             [<ffffffff81039a03>] kthread+0x95/0x9d
             [<ffffffff812e7754>] kernel_thread_helper+0x4/0x10
      
      other info that might help us debug this:
      
      Chain exists of:
        &hdev->lock --> slock-AF_BLUETOOTH-BTPROTO_L2CAP --> (&(&conn->disc_work)->work)
      
       Possible unsafe locking scenario:
      
             CPU0                    CPU1
             ----                    ----
        lock((&(&conn->disc_work)->work));
                                     lock(slock-AF_BLUETOOTH-BTPROTO_L2CAP);
                                     lock((&(&conn->disc_work)->work));
        lock(&hdev->lock);
      
       *** DEADLOCK ***
      
      2 locks held by kworker/u:1/17:
       #0:  (hdev->name){.+.+.+}, at: [<ffffffff81035751>] process_one_work+0x11a/0x2bf
       #1:  ((&(&conn->disc_work)->work)){+.+...}, at: [<ffffffff81035751>] process_one_work+0x11a/0x2bf
      
      stack backtrace:
      Pid: 17, comm: kworker/u:1 Not tainted 3.2.0+ #1
      Call Trace:
       [<ffffffff812e06c6>] print_circular_bug+0x1f8/0x209
       [<ffffffff81056d06>] __lock_acquire+0xa80/0xd74
       [<ffffffff81021ef2>] ? arch_local_irq_restore+0x6/0xd
       [<ffffffff81022bc7>] ? vprintk+0x3f9/0x41e
       [<ffffffff81057444>] lock_acquire+0x8a/0xa7
       [<ffffffffa0041155>] ? hci_conn_timeout+0x62/0x158 [bluetooth]
       [<ffffffff812e3870>] __mutex_lock_common+0x48/0x38e
       [<ffffffffa0041155>] ? hci_conn_timeout+0x62/0x158 [bluetooth]
       [<ffffffff81190fd6>] ? __dynamic_pr_debug+0x6d/0x6f
       [<ffffffffa0041155>] ? hci_conn_timeout+0x62/0x158 [bluetooth]
       [<ffffffff8105320f>] ? trace_hardirqs_off+0xd/0xf
       [<ffffffff812e3c75>] mutex_lock_nested+0x2a/0x31
       [<ffffffffa0041155>] hci_conn_timeout+0x62/0x158 [bluetooth]
       [<ffffffff810357af>] process_one_work+0x178/0x2bf
       [<ffffffff81035751>] ? process_one_work+0x11a/0x2bf
       [<ffffffff81055af3>] ? lock_acquired+0x1d0/0x1df
       [<ffffffffa00410f3>] ? hci_acl_disconn+0x65/0x65 [bluetooth]
       [<ffffffff81036178>] worker_thread+0xce/0x152
       [<ffffffff810407ed>] ? finish_task_switch+0x45/0xc5
       [<ffffffff810360aa>] ? manage_workers.isra.25+0x16a/0x16a
       [<ffffffff81039a03>] kthread+0x95/0x9d
       [<ffffffff812e7754>] kernel_thread_helper+0x4/0x10
       [<ffffffff812e5db4>] ? retint_restore_args+0x13/0x13
       [<ffffffff8103996e>] ? __init_kthread_worker+0x55/0x55
       [<ffffffff812e7750>] ? gs_change+0x13/0x13
      Signed-off-by: default avatarAndre Guedes <andre.guedes@openbossa.org>
      Signed-off-by: default avatarVinicius Costa Gomes <vinicius.gomes@openbossa.org>
      Reviewed-by: default avatarUlisses Furquim <ulisses@profusion.mobi>
      Acked-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      a51cd2be
    • Octavian Purdila's avatar
      Bluetooth: silence lockdep warning · b5a30dda
      Octavian Purdila authored
      Since bluetooth uses multiple protocols types, to avoid lockdep
      warnings, we need to use different lockdep classes (one for each
      protocol type).
      
      This is already done in bt_sock_create but it misses a couple of cases
      when new connections are created. This patch corrects that to fix the
      following warning:
      
      <4>[ 1864.732366] =======================================================
      <4>[ 1864.733030] [ INFO: possible circular locking dependency detected ]
      <4>[ 1864.733544] 3.0.16-mid3-00007-gc9a0f62 #3
      <4>[ 1864.733883] -------------------------------------------------------
      <4>[ 1864.734408] t.android.btclc/4204 is trying to acquire lock:
      <4>[ 1864.734869]  (rfcomm_mutex){+.+.+.}, at: [<c14970ea>] rfcomm_dlc_close+0x15/0x30
      <4>[ 1864.735541]
      <4>[ 1864.735549] but task is already holding lock:
      <4>[ 1864.736045]  (sk_lock-AF_BLUETOOTH){+.+.+.}, at: [<c1498bf7>] lock_sock+0xa/0xc
      <4>[ 1864.736732]
      <4>[ 1864.736740] which lock already depends on the new lock.
      <4>[ 1864.736750]
      <4>[ 1864.737428]
      <4>[ 1864.737437] the existing dependency chain (in reverse order) is:
      <4>[ 1864.738016]
      <4>[ 1864.738023] -> #1 (sk_lock-AF_BLUETOOTH){+.+.+.}:
      <4>[ 1864.738549]        [<c1062273>] lock_acquire+0x104/0x140
      <4>[ 1864.738977]        [<c13d35c1>] lock_sock_nested+0x58/0x68
      <4>[ 1864.739411]        [<c1493c33>] l2cap_sock_sendmsg+0x3e/0x76
      <4>[ 1864.739858]        [<c13d06c3>] __sock_sendmsg+0x50/0x59
      <4>[ 1864.740279]        [<c13d0ea2>] sock_sendmsg+0x94/0xa8
      <4>[ 1864.740687]        [<c13d0ede>] kernel_sendmsg+0x28/0x37
      <4>[ 1864.741106]        [<c14969ca>] rfcomm_send_frame+0x30/0x38
      <4>[ 1864.741542]        [<c1496a2a>] rfcomm_send_ua+0x58/0x5a
      <4>[ 1864.741959]        [<c1498447>] rfcomm_run+0x441/0xb52
      <4>[ 1864.742365]        [<c104f095>] kthread+0x63/0x68
      <4>[ 1864.742742]        [<c14d5182>] kernel_thread_helper+0x6/0xd
      <4>[ 1864.743187]
      <4>[ 1864.743193] -> #0 (rfcomm_mutex){+.+.+.}:
      <4>[ 1864.743667]        [<c1061ada>] __lock_acquire+0x988/0xc00
      <4>[ 1864.744100]        [<c1062273>] lock_acquire+0x104/0x140
      <4>[ 1864.744519]        [<c14d2c70>] __mutex_lock_common+0x3b/0x33f
      <4>[ 1864.744975]        [<c14d303e>] mutex_lock_nested+0x2d/0x36
      <4>[ 1864.745412]        [<c14970ea>] rfcomm_dlc_close+0x15/0x30
      <4>[ 1864.745842]        [<c14990d9>] __rfcomm_sock_close+0x5f/0x6b
      <4>[ 1864.746288]        [<c1499114>] rfcomm_sock_shutdown+0x2f/0x62
      <4>[ 1864.746737]        [<c13d275d>] sys_socketcall+0x1db/0x422
      <4>[ 1864.747165]        [<c14d42f0>] syscall_call+0x7/0xb
      Signed-off-by: default avatarOctavian Purdila <octavian.purdila@intel.com>
      Acked-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      b5a30dda
    • Vinicius Costa Gomes's avatar
      Bluetooth: Fix using an absolute timeout on hci_conn_put() · 33166063
      Vinicius Costa Gomes authored
      queue_delayed_work() expects a relative time for when that work
      should be scheduled.
      Signed-off-by: default avatarVinicius Costa Gomes <vinicius.gomes@openbossa.org>
      Acked-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      33166063
    • Andrzej Kaczmarek's avatar
      Bluetooth: l2cap_set_timer needs jiffies as timeout value · 6e1da683
      Andrzej Kaczmarek authored
      After moving L2CAP timers to workqueues l2cap_set_timer expects timeout
      value to be specified in jiffies but constants defined in miliseconds
      are used. This makes timeouts unreliable when CONFIG_HZ is not set to
      1000.
      
      __set_chan_timer macro still uses jiffies as input to avoid multiple
      conversions from/to jiffies for sk_sndtimeo value which is already
      specified in jiffies.
      Signed-off-by: default avatarAndrzej Kaczmarek <andrzej.kaczmarek@tieto.com>
      Ackec-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      6e1da683
    • Andrzej Kaczmarek's avatar
      Bluetooth: Fix sk_sndtimeo initialization for L2CAP socket · a6375255
      Andrzej Kaczmarek authored
      sk_sndtime value should be specified in jiffies thus initial value
      needs to be converted from miliseconds. Otherwise this timeout is
      unreliable when CONFIG_HZ is not set to 1000.
      Signed-off-by: default avatarAndrzej Kaczmarek <andrzej.kaczmarek@tieto.com>
      Acked-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      a6375255
    • Johan Hedberg's avatar
      Bluetooth: Remove bogus inline declaration from l2cap_chan_connect · 4aa832c2
      Johan Hedberg authored
      As reported by Dan Carpenter this function causes a Sparse warning and
      shouldn't be declared inline:
      
      include/net/bluetooth/l2cap.h:837:30 error: marked inline, but without a
      definition"
      Reported-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      Acked-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      4aa832c2
    • Daniel Wagner's avatar
      Bluetooth: Don't mark non xfer isoc endpoint URBs with URB_ISO_ASAP · 19ad9e94
      Daniel Wagner authored
      [ 2096.384084] btusb_send_frame:684: hci0
      [ 2096.384087] usb 3-1: BOGUS urb flags, 2 --> 0
      [ 2096.384091] Bluetooth: hci0 urb ffff8801b61d3a80 submission failed (22)
      
      According the documentation in usb_submit_urb() URB_ISO_ASAP
      flag is only allowed for endpoints of type USB_ENDPOINT_XFER_ISOC.
      
      This reverts commit b8aabfc9.
      Signed-off-by: default avatarDaniel Wagner <daniel.wagner@bmw-carit.de>
      Acked-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      Acked-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      19ad9e94
    • Peter Hurley's avatar
      Bluetooth: Fix l2cap conn failures for ssp devices · 18daf164
      Peter Hurley authored
      Commit 33060542 fixed l2cap conn establishment for non-ssp remote
      devices by not setting HCI_CONN_ENCRYPT_PEND every time conn security
      is tested (which was always returning failure on any subsequent
      security checks).
      
      However, this broke l2cap conn establishment for ssp remote devices
      when an ACL link was already established at SDP-level security. This
      fix ensures that encryption must be pending whenever authentication
      is also pending.
      Signed-off-by: default avatarPeter Hurley <peter@hurleysoftware.com>
      Tested-by: default avatarDaniel Wagner <daniel.wagner@bmw-carit.de>
      Acked-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      18daf164
  5. 09 Feb, 2012 2 commits
    • Simon Graham's avatar
      rtlwifi: Modify rtl_pci_init to return 0 on success · c27111e5
      Simon Graham authored
      Fixes problem where caller would think routine succeeded when it failed
      leading to divide by zero panic.
      Signed-off-by: default avatarSimon Graham <simon.graham@virtualcomputer.com>
      Acked-by: default avatarLarry Finger <Larry.Finger@lwfinger.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      c27111e5
    • Mohammed Shafi Shajakhan's avatar
      mac80211: Fix a rwlock bad magic bug · b57e6b56
      Mohammed Shafi Shajakhan authored
      read_lock(&tpt_trig->trig.leddev_list_lock) is accessed via the path
      ieee80211_open (->) ieee80211_do_open (->) ieee80211_mod_tpt_led_trig
      (->) ieee80211_start_tpt_led_trig (->) tpt_trig_timer before initializing
      it.
      the intilization of this read/write lock happens via the path
      ieee80211_led_init (->) led_trigger_register, but we are doing
      'ieee80211_led_init'  after 'ieeee80211_if_add' where we
      register netdev_ops.
      so we access leddev_list_lock before initializing it and causes the
      following bug in chrome laptops with AR928X cards with the following
      script
      
      while true
      do
      sudo modprobe -v ath9k
      sleep 3
      sudo modprobe -r ath9k
      sleep 3
      done
      
      	BUG: rwlock bad magic on CPU#1, wpa_supplicant/358, f5b9eccc
      	Pid: 358, comm: wpa_supplicant Not tainted 3.0.13 #1
      	Call Trace:
      
      	[<8137b9df>] rwlock_bug+0x3d/0x47
      	[<81179830>] do_raw_read_lock+0x19/0x29
      	[<8137f063>] _raw_read_lock+0xd/0xf
      	[<f9081957>] tpt_trig_timer+0xc3/0x145 [mac80211]
      	[<f9081f3a>] ieee80211_mod_tpt_led_trig+0x152/0x174 [mac80211]
      	[<f9076a3f>] ieee80211_do_open+0x11e/0x42e [mac80211]
      	[<f9075390>] ? ieee80211_check_concurrent_iface+0x26/0x13c [mac80211]
      	[<f9076d97>] ieee80211_open+0x48/0x4c [mac80211]
      	[<812dbed8>] __dev_open+0x82/0xab
      	[<812dc0c9>] __dev_change_flags+0x9c/0x113
      	[<812dc1ae>] dev_change_flags+0x18/0x44
      	[<8132144f>] devinet_ioctl+0x243/0x51a
      	[<81321ba9>] inet_ioctl+0x93/0xac
      	[<812cc951>] sock_ioctl+0x1c6/0x1ea
      	[<812cc78b>] ? might_fault+0x20/0x20
      	[<810b1ebb>] do_vfs_ioctl+0x46e/0x4a2
      	[<810a6ebb>] ? fget_light+0x2f/0x70
      	[<812ce549>] ? sys_recvmsg+0x3e/0x48
      	[<810b1f35>] sys_ioctl+0x46/0x69
      	[<8137fa77>] sysenter_do_call+0x12/0x2
      
      Cc: <stable@vger.kernel.org>
      Cc: Gary Morain <gmorain@google.com>
      Cc: Paul Stewart <pstew@google.com>
      Cc: Abhijit Pradhan <abhijit@qca.qualcomm.com>
      Cc: Vasanthakumar Thiagarajan <vthiagar@qca.qualcomm.com>
      Cc: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
      Acked-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Tested-by: default avatarMohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
      Signed-off-by: default avatarMohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      b57e6b56
  6. 07 Feb, 2012 1 commit
  7. 06 Feb, 2012 4 commits
  8. 03 Feb, 2012 3 commits
    • Mohammed Shafi Shajakhan's avatar
      ath9k: Fix kernel panic during driver initilization · 07445f68
      Mohammed Shafi Shajakhan authored
      all works need to be initialized before ieee80211_register_hw
      to prevent mac80211 call backs such as drv_start, drv_config
      getting started. otherwise we would queue/cancel works before
      initializing them and it leads to kernel panic.
      this issue can be recreated with the following script
      in Chrome laptops with AR928X cards, with background scan
      running (or) Network manager is running
      
      while true
      do
      sudo modprobe -v ath9k
      sleep 3
      sudo modprobe -r ath9k
      sleep 3
      done
      
      	 EIP: [<81040a47>] __cancel_work_timer+0xb8/0xe1 SS:ESP 0068:f6be9d70
      	 ---[ end trace 4f86d6139a9900ef ]---
      	 Registered led device: ath9k-phy0
      	 ieee80211 phy0: Atheros AR9280 Rev:2 mem=0xf88a0000,
      	 irq=16
      	 Kernel panic - not syncing: Fatal exception
      	 Pid: 456, comm: wpa_supplicant Tainted: G      D
      	 3.0.13 #1
      	Call Trace:
      	 [<81379e21>] panic+0x53/0x14a
      	 [<81004a30>] oops_end+0x73/0x81
      	 [<81004b53>] die+0x4c/0x55
      	 [<81002710>] do_trap+0x7c/0x83
      	 [<81002855>] ? do_bounds+0x58/0x58
      	 [<810028cc>] do_invalid_op+0x77/0x81
      	 [<81040a47>] ? __cancel_work_timer+0xb8/0xe1
      	 [<810489ec>] ? sched_clock_cpu+0x81/0x11f
      	 [<8103f809>] ? wait_on_work+0xe2/0xf7
      	 [<8137f807>] error_code+0x67/0x6c
      	 [<810300d8>] ? wait_consider_task+0x4ba/0x84c
      	 [<81040a47>] ? __cancel_work_timer+0xb8/0xe1
      	 [<810380c9>] ? try_to_del_timer_sync+0x5f/0x67
      	 [<81040a91>] cancel_work_sync+0xf/0x11
      	 [<f88d7b7c>] ath_set_channel+0x62/0x25c [ath9k]
      	 [<f88d67d1>] ? ath9k_tx_last_beacon+0x26a/0x85c [ath9k]
      	 [<f88d8899>] ath_radio_disable+0x3f1/0x68e [ath9k]
      	 [<f90d0edb>] ieee80211_hw_config+0x111/0x116 [mac80211]
      	 [<f90dd95c>] __ieee80211_recalc_idle+0x919/0xa37 [mac80211]
      	 [<f90dda76>] __ieee80211_recalc_idle+0xa33/0xa37 [mac80211]
      	 [<812dbed8>] __dev_open+0x82/0xab
      
      Cc: <stable@vger.kernel.org>
      Cc: Gary Morain <gmorain@google.com>
      Cc: Paul Stewart <pstew@google.com>
      Cc: Vasanthakumar Thiagarajan <vthiagar@qca.qualcomm.com>
      Tested-by: default avatarMohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
      Signed-off-by: default avatarRajkumar Manoharan <rmanohar@qca.qualcomm.com>
      Signed-off-by: default avatarMohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      07445f68
    • Amitkumar Karwar's avatar
      mwifiex: handle association failure case correctly · b7097eb7
      Amitkumar Karwar authored
      Currently even if association is failed "iw link" shows some
      information about connected BSS and "Tx timeout" error is seen in
      dmesg log.
      
      This patch fixes below issues in the code to handle assoc failure
      case correctly.
      1) "status" variable in mwifiex_wait_queue_complete() is not
      correctly updated. Hence driver doesn't inform cfg80211 stack
      about association failure.
      2) During association network queues are stopped but carrier is
      not cleared, which gives Tx timeout error in failure case
      Signed-off-by: default avatarAmitkumar Karwar <akarwar@marvell.com>
      Signed-off-by: default avatarBing Zhao <bzhao@marvell.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      b7097eb7
    • John W. Linville's avatar
      ath9k: use WARN_ON_ONCE in ath_rc_get_highest_rix · 8149415e
      John W. Linville authored
      The device seems to survive the issue, so no need to flood the logs
      about it...
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      8149415e
  9. 01 Feb, 2012 3 commits