1. 13 Nov, 2013 5 commits
    • Johan Hedberg's avatar
      Bluetooth: Fix rejecting SMP security request in slave role · 86ca9eac
      Johan Hedberg authored
      The SMP security request is for a slave role device to request the
      master role device to initiate a pairing request. If we receive this
      command while we're in the slave role we should reject it appropriately.
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      86ca9eac
    • Seung-Woo Kim's avatar
      Bluetooth: Fix crash in l2cap_chan_send after l2cap_chan_del · 31e8ce80
      Seung-Woo Kim authored
      Removing a bond and disconnecting from a specific remote device
      can cause l2cap_chan_send() is called after l2cap_chan_del() is
      called. This causes following crash.
      
      [ 1384.972086] Unable to handle kernel NULL pointer dereference at virtual address 00000008
      [ 1384.972090] pgd = c0004000
      [ 1384.972125] [00000008] *pgd=00000000
      [ 1384.972137] Internal error: Oops: 17 [#1] PREEMPT SMP ARM
      [ 1384.972144] Modules linked in:
      [ 1384.972156] CPU: 0 PID: 841 Comm: krfcommd Not tainted 3.10.14-gdf22a71-dirty #435
      [ 1384.972162] task: df29a100 ti: df178000 task.ti: df178000
      [ 1384.972182] PC is at l2cap_create_basic_pdu+0x30/0x1ac
      [ 1384.972191] LR is at l2cap_chan_send+0x100/0x1d4
      [ 1384.972198] pc : [<c051d250>]    lr : [<c0521c78>]    psr: 40000113
      [ 1384.972198] sp : df179d40  ip : c083a010  fp : 00000008
      [ 1384.972202] r10: 00000004  r9 : 0000065a  r8 : 000003f5
      [ 1384.972206] r7 : 00000000  r6 : 00000000  r5 : df179e84  r4 : da557000
      [ 1384.972210] r3 : 00000000  r2 : 00000004  r1 : df179e84  r0 : 00000000
      [ 1384.972215] Flags: nZcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
      [ 1384.972220] Control: 10c53c7d  Table: 5c8b004a  DAC: 00000015
      [ 1384.972224] Process krfcommd (pid: 841, stack limit = 0xdf178238)
      [ 1384.972229] Stack: (0xdf179d40 to 0xdf17a000)
      [ 1384.972238] 9d40: 00000000 da557000 00000004 df179e84 00000004 000003f5 0000065a 00000000
      [ 1384.972245] 9d60: 00000008 c0521c78 df179e84 da557000 00000004 da557204 de0c6800 df179e84
      [ 1384.972253] 9d80: da557000 00000004 da557204 c0526b7c 00000004 df724000 df179e84 00000004
      [ 1384.972260] 9da0: df179db0 df29a100 c083bc48 c045481c 00000001 00000000 00000000 00000000
      [ 1384.972267] 9dc0: 00000000 df29a100 00000000 00000000 00000000 00000000 df179e10 00000000
      [ 1384.972274] 9de0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      [ 1384.972281] 9e00: 00000000 00000000 00000000 00000000 df179e4c c000ec80 c0b538c0 00000004
      [ 1384.972288] 9e20: df724000 df178000 00000000 df179e84 c0b538c0 00000000 df178000 c07f4570
      [ 1384.972295] 9e40: dcad9c00 df179e74 c07f4394 df179e60 df178000 00000000 df179e84 de247010
      [ 1384.972303] 9e60: 00000043 c0454dec 00000001 00000004 df315c00 c0530598 00000004 df315c0c
      [ 1384.972310] 9e80: ffffc32c 00000000 00000000 df179ea0 00000001 00000000 00000000 00000000
      [ 1384.972317] 9ea0: df179ebc 00000004 df315c00 c05df838 00000000 c0530810 c07d08c0 d7017303
      [ 1384.972325] 9ec0: 6ec245b9 00000000 df315c00 c0531b04 c07f3fe0 c07f4018 da67a300 df315c00
      [ 1384.972332] 9ee0: 00000000 c05334e0 df315c00 df315b80 df315c00 de0c6800 da67a300 00000000
      [ 1384.972339] 9f00: de0c684c c0533674 df204100 df315c00 df315c00 df204100 df315c00 c082b138
      [ 1384.972347] 9f20: c053385c c0533754 a0000113 df178000 00000001 c083bc48 00000000 c053385c
      [ 1384.972354] 9f40: 00000000 00000000 00000000 c05338c4 00000000 df9f0000 df9f5ee4 df179f6c
      [ 1384.972360] 9f60: df178000 c0049db4 00000000 00000000 c07f3ff8 00000000 00000000 00000000
      [ 1384.972368] 9f80: df179f80 df179f80 00000000 00000000 df179f90 df179f90 df9f5ee4 c0049cfc
      [ 1384.972374] 9fa0: 00000000 00000000 00000000 c000f168 00000000 00000000 00000000 00000000
      [ 1384.972381] 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      [ 1384.972388] 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00010000 00000600
      [ 1384.972411] [<c051d250>] (l2cap_create_basic_pdu+0x30/0x1ac) from [<c0521c78>] (l2cap_chan_send+0x100/0x1d4)
      [ 1384.972425] [<c0521c78>] (l2cap_chan_send+0x100/0x1d4) from [<c0526b7c>] (l2cap_sock_sendmsg+0xa8/0x104)
      [ 1384.972440] [<c0526b7c>] (l2cap_sock_sendmsg+0xa8/0x104) from [<c045481c>] (sock_sendmsg+0xac/0xcc)
      [ 1384.972453] [<c045481c>] (sock_sendmsg+0xac/0xcc) from [<c0454dec>] (kernel_sendmsg+0x2c/0x34)
      [ 1384.972469] [<c0454dec>] (kernel_sendmsg+0x2c/0x34) from [<c0530598>] (rfcomm_send_frame+0x58/0x7c)
      [ 1384.972481] [<c0530598>] (rfcomm_send_frame+0x58/0x7c) from [<c0530810>] (rfcomm_send_ua+0x98/0xbc)
      [ 1384.972494] [<c0530810>] (rfcomm_send_ua+0x98/0xbc) from [<c0531b04>] (rfcomm_recv_disc+0xac/0x100)
      [ 1384.972506] [<c0531b04>] (rfcomm_recv_disc+0xac/0x100) from [<c05334e0>] (rfcomm_recv_frame+0x144/0x264)
      [ 1384.972519] [<c05334e0>] (rfcomm_recv_frame+0x144/0x264) from [<c0533674>] (rfcomm_process_rx+0x74/0xfc)
      [ 1384.972531] [<c0533674>] (rfcomm_process_rx+0x74/0xfc) from [<c0533754>] (rfcomm_process_sessions+0x58/0x160)
      [ 1384.972543] [<c0533754>] (rfcomm_process_sessions+0x58/0x160) from [<c05338c4>] (rfcomm_run+0x68/0x110)
      [ 1384.972558] [<c05338c4>] (rfcomm_run+0x68/0x110) from [<c0049db4>] (kthread+0xb8/0xbc)
      [ 1384.972576] [<c0049db4>] (kthread+0xb8/0xbc) from [<c000f168>] (ret_from_fork+0x14/0x2c)
      [ 1384.972586] Code: e3100004 e1a07003 e5946000 1a000057 (e5969008)
      [ 1384.972614] ---[ end trace 6170b7ce00144e8c ]---
      Signed-off-by: default avatarSeung-Woo Kim <sw0312.kim@samsung.com>
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      31e8ce80
    • Seung-Woo Kim's avatar
      Bluetooth: Fix to set proper bdaddr_type for RFCOMM connect · 8992da09
      Seung-Woo Kim authored
      L2CAP socket validates proper bdaddr_type for connect, so this
      patch fixes to set explictly bdaddr_type for RFCOMM connect.
      Signed-off-by: default avatarSeung-Woo Kim <sw0312.kim@samsung.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      8992da09
    • Seung-Woo Kim's avatar
      Bluetooth: Fix RFCOMM bind fail for L2CAP sock · c507f138
      Seung-Woo Kim authored
      L2CAP socket bind checks its bdaddr type but RFCOMM kernel thread
      does not assign proper bdaddr type for L2CAP sock. This can cause
      that RFCOMM failure.
      Signed-off-by: default avatarSeung-Woo Kim <sw0312.kim@samsung.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      c507f138
    • Marcel Holtmann's avatar
      Bluetooth: Fix issue with RFCOMM getsockopt operation · 60c7a3c9
      Marcel Holtmann authored
      The commit 94a86df0 seem to have
      uncovered a long standing bug that did not trigger so far.
      
      BUG: unable to handle kernel paging request at 00000009dd503502
      IP: [<ffffffff815b1868>] rfcomm_sock_getsockopt+0x128/0x200
      PGD 0
      Oops: 0000 [#1] SMP
      Modules linked in: ath5k ath mac80211 cfg80211
      CPU: 2 PID: 1459 Comm: bluetoothd Not tainted 3.11.0-133163-gcebd830 #2
      Hardware name: System manufacturer System Product Name/P6T DELUXE V2, BIOS
      1202    12/22/2010
      task: ffff8803304106a0 ti: ffff88033046a000 task.ti: ffff88033046a000
      RIP: 0010:[<ffffffff815b1868>]  [<ffffffff815b1868>]
      rfcomm_sock_getsockopt+0x128/0x200
      RSP: 0018:ffff88033046bed8  EFLAGS: 00010246
      RAX: 00000009dd503502 RBX: 0000000000000003 RCX: 00007fffa2ed5548
      RDX: 0000000000000003 RSI: 0000000000000012 RDI: ffff88032fd37480
      RBP: ffff88033046bf28 R08: 00007fffa2ed554c R09: ffff88032f5707d8
      R10: 00007fffa2ed5548 R11: 0000000000000202 R12: ffff880330bbd000
      R13: 00007fffa2ed5548 R14: 0000000000000003 R15: 00007fffa2ed554c
      FS:  00007fc44cfac700(0000) GS:ffff88033fc80000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00000009dd503502 CR3: 00000003304c2000 CR4: 00000000000007e0
      Stack:
      ffff88033046bf28 ffffffff815b0f2f ffff88033046bf18 0002ffff81105ef6
      0000000600000000 ffff88032fd37480 0000000000000012 00007fffa2ed5548
      0000000000000003 00007fffa2ed554c ffff88033046bf78 ffffffff814c0380
      Call Trace:
      [<ffffffff815b0f2f>] ? rfcomm_sock_setsockopt+0x5f/0x190
      [<ffffffff814c0380>] SyS_getsockopt+0x60/0xb0
      [<ffffffff815e0852>] system_call_fastpath+0x16/0x1b
      Code: 02 00 00 00 0f 47 d0 4c 89 ef e8 74 13 cd ff 83 f8 01 19 c9 f7 d1 83 e1
      f2 e9 4b ff ff ff 0f 1f 44 00 00 49 8b 84 24 70 02 00 00 <4c> 8b 30 4c 89 c0 e8
      2d 19 cd ff 85 c0 49 89 d7 b9 f2 ff ff ff
      RIP  [<ffffffff815b1868>] rfcomm_sock_getsockopt+0x128/0x200
      RSP <ffff88033046bed8>
      CR2: 00000009dd503502
      
      It triggers in the following segment of the code:
      
      0x1313 is in rfcomm_sock_getsockopt (net/bluetooth/rfcomm/sock.c:743).
      738
      739	static int rfcomm_sock_getsockopt_old(struct socket *sock, int optname, char __user *optval, int __user *optlen)
      740	{
      741		struct sock *sk = sock->sk;
      742		struct rfcomm_conninfo cinfo;
      743		struct l2cap_conn *conn = l2cap_pi(sk)->chan->conn;
      744		int len, err = 0;
      745		u32 opt;
      746
      747		BT_DBG("sk %p", sk);
      
      The l2cap_pi(sk) is wrong here since it should have been rfcomm_pi(sk),
      but that socket of course does not contain the low-level connection
      details requested here.
      
      Tracking down the actual offending commit, it seems that this has been
      introduced when doing some L2CAP refactoring:
      
      commit 8c1d787b
      Author: Gustavo F. Padovan <padovan@profusion.mobi>
      Date:   Wed Apr 13 20:23:55 2011 -0300
      
      @@ -743,6 +743,7 @@ static int rfcomm_sock_getsockopt_old(struct socket *sock, int optname, char __u
              struct sock *sk = sock->sk;
              struct sock *l2cap_sk;
              struct rfcomm_conninfo cinfo;
      +       struct l2cap_conn *conn = l2cap_pi(sk)->chan->conn;
              int len, err = 0;
              u32 opt;
      
      @@ -787,8 +788,8 @@ static int rfcomm_sock_getsockopt_old(struct socket *sock, int optname, char __u
      
                      l2cap_sk = rfcomm_pi(sk)->dlc->session->sock->sk;
      
      -               cinfo.hci_handle = l2cap_pi(l2cap_sk)->conn->hcon->handle;
      -               memcpy(cinfo.dev_class, l2cap_pi(l2cap_sk)->conn->hcon->dev_class, 3);
      +               cinfo.hci_handle = conn->hcon->handle;
      +               memcpy(cinfo.dev_class, conn->hcon->dev_class, 3);
      
      The l2cap_sk got accidentally mixed into the sk (which is RFCOMM) and
      now causing a problem within getsocketopt() system call. To fix this,
      just re-introduce l2cap_sk and make sure the right socket is used for
      the low-level connection details.
      Reported-by: default avatarFabio Rossi <rossi.f@inwind.it>
      Reported-by: default avatarJanusz Dziedzic <janusz.dziedzic@gmail.com>
      Tested-by: default avatarJanusz Dziedzic <janusz.dziedzic@gmail.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      60c7a3c9
  2. 18 Oct, 2013 8 commits
    • Felipe Pena's avatar
      drivers: net: wireless: b43: Fix possible NULL ptr dereference · 8ce9beac
      Felipe Pena authored
      On the ternary expression the 'e' variable could be NULL dereferenced,
      when b43_nphy_get_rf_ctl_over_rev7 function returns NULL.
      Signed-off-by: default avatarFelipe Pena <felipensp@gmail.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      8ce9beac
    • Stanislaw Gruszka's avatar
      rt2800usb: slow down TX status polling · 36165fd5
      Stanislaw Gruszka authored
      Polling TX statuses too frequently has two negative effects. First is
      randomly peek CPU usage, causing overall system functioning delays.
      Second bad effect is that device is not able to fill TX statuses in
      H/W register on some workloads and we get lot of timeouts like below:
      
      ieee80211 phy4: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 7 in queue 2
      ieee80211 phy4: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 7 in queue 2
      ieee80211 phy4: rt2800usb_txdone: Warning - Got TX status for an empty queue 2, dropping
      
      This not only cause flood of messages in dmesg, but also bad throughput,
      since rate scaling algorithm can not work optimally.
      
      In the future, we should probably make polling interval be adjusted
      automatically, but for now just increase values, this make mentioned
      problems gone.
      
      Resolve:
      https://bugzilla.kernel.org/show_bug.cgi?id=62781
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarStanislaw Gruszka <sgruszka@redhat.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      36165fd5
    • Stanislaw Gruszka's avatar
      rt2x00: check if device is still available on rt2x00mac_flush() · 5671ab05
      Stanislaw Gruszka authored
      Fix random kernel panic with below messages when remove dongle.
      
      [ 2212.355447] BUG: unable to handle kernel NULL pointer dereference at 0000000000000250
      [ 2212.355527] IP: [<ffffffffa02667f2>] rt2x00usb_kick_tx_entry+0x12/0x160 [rt2x00usb]
      [ 2212.355599] PGD 0
      [ 2212.355626] Oops: 0000 [#1] SMP
      [ 2212.355664] Modules linked in: rt2800usb rt2x00usb rt2800lib crc_ccitt rt2x00lib mac80211 cfg80211 tun arc4 fuse rfcomm bnep snd_hda_codec_realtek snd_hda_intel snd_hda_codec btusb uvcvideo bluetooth snd_hwdep x86_pkg_temp_thermal snd_seq coretemp aesni_intel aes_x86_64 snd_seq_device glue_helper snd_pcm ablk_helper videobuf2_vmalloc sdhci_pci videobuf2_memops videobuf2_core sdhci videodev mmc_core serio_raw snd_page_alloc microcode i2c_i801 snd_timer hid_multitouch thinkpad_acpi lpc_ich mfd_core snd tpm_tis wmi tpm tpm_bios soundcore acpi_cpufreq i915 i2c_algo_bit drm_kms_helper drm i2c_core video [last unloaded: cfg80211]
      [ 2212.356224] CPU: 0 PID: 34 Comm: khubd Not tainted 3.12.0-rc3-wl+ #3
      [ 2212.356268] Hardware name: LENOVO 3444CUU/3444CUU, BIOS G6ET93WW (2.53 ) 02/04/2013
      [ 2212.356319] task: ffff880212f687c0 ti: ffff880212f66000 task.ti: ffff880212f66000
      [ 2212.356392] RIP: 0010:[<ffffffffa02667f2>]  [<ffffffffa02667f2>] rt2x00usb_kick_tx_entry+0x12/0x160 [rt2x00usb]
      [ 2212.356481] RSP: 0018:ffff880212f67750  EFLAGS: 00010202
      [ 2212.356519] RAX: 000000000000000c RBX: 000000000000000c RCX: 0000000000000293
      [ 2212.356568] RDX: ffff8801f4dc219a RSI: 0000000000000000 RDI: 0000000000000240
      [ 2212.356617] RBP: ffff880212f67778 R08: ffffffffa02667e0 R09: 0000000000000002
      [ 2212.356665] R10: 0001f95254ab4b40 R11: ffff880212f675be R12: ffff8801f4dc2150
      [ 2212.356712] R13: 0000000000000000 R14: ffffffffa02667e0 R15: 000000000000000d
      [ 2212.356761] FS:  0000000000000000(0000) GS:ffff88021e200000(0000) knlGS:0000000000000000
      [ 2212.356813] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [ 2212.356852] CR2: 0000000000000250 CR3: 0000000001a0c000 CR4: 00000000001407f0
      [ 2212.356899] Stack:
      [ 2212.356917]  000000000000000c ffff8801f4dc2150 0000000000000000 ffffffffa02667e0
      [ 2212.356980]  000000000000000d ffff880212f677b8 ffffffffa03a31ad ffff8801f4dc219a
      [ 2212.357038]  ffff8801f4dc2150 0000000000000000 ffff8800b93217a0 ffff8801f49bc800
      [ 2212.357099] Call Trace:
      [ 2212.357122]  [<ffffffffa02667e0>] ? rt2x00usb_interrupt_txdone+0x90/0x90 [rt2x00usb]
      [ 2212.357174]  [<ffffffffa03a31ad>] rt2x00queue_for_each_entry+0xed/0x170 [rt2x00lib]
      [ 2212.357244]  [<ffffffffa026701c>] rt2x00usb_kick_queue+0x5c/0x60 [rt2x00usb]
      [ 2212.357314]  [<ffffffffa03a3682>] rt2x00queue_flush_queue+0x62/0xa0 [rt2x00lib]
      [ 2212.357386]  [<ffffffffa03a2930>] rt2x00mac_flush+0x30/0x70 [rt2x00lib]
      [ 2212.357470]  [<ffffffffa04edded>] ieee80211_flush_queues+0xbd/0x140 [mac80211]
      [ 2212.357555]  [<ffffffffa0502e52>] ieee80211_set_disassoc+0x2d2/0x3d0 [mac80211]
      [ 2212.357645]  [<ffffffffa0506da3>] ieee80211_mgd_deauth+0x1d3/0x240 [mac80211]
      [ 2212.357718]  [<ffffffff8108b17c>] ? try_to_wake_up+0xec/0x290
      [ 2212.357788]  [<ffffffffa04dbd18>] ieee80211_deauth+0x18/0x20 [mac80211]
      [ 2212.357872]  [<ffffffffa0418ddc>] cfg80211_mlme_deauth+0x9c/0x140 [cfg80211]
      [ 2212.357913]  [<ffffffffa041907c>] cfg80211_mlme_down+0x5c/0x60 [cfg80211]
      [ 2212.357962]  [<ffffffffa041cd18>] cfg80211_disconnect+0x188/0x1a0 [cfg80211]
      [ 2212.358014]  [<ffffffffa04013bc>] ? __cfg80211_stop_sched_scan+0x1c/0x130 [cfg80211]
      [ 2212.358067]  [<ffffffffa03f8954>] cfg80211_leave+0xc4/0xe0 [cfg80211]
      [ 2212.358124]  [<ffffffffa03f8d1b>] cfg80211_netdev_notifier_call+0x3ab/0x5e0 [cfg80211]
      [ 2212.358177]  [<ffffffff815140f8>] ? inetdev_event+0x38/0x510
      [ 2212.358217]  [<ffffffff81085a94>] ? __wake_up+0x44/0x50
      [ 2212.358254]  [<ffffffff8155995c>] notifier_call_chain+0x4c/0x70
      [ 2212.358293]  [<ffffffff81081156>] raw_notifier_call_chain+0x16/0x20
      [ 2212.358361]  [<ffffffff814b6dd5>] call_netdevice_notifiers_info+0x35/0x60
      [ 2212.358429]  [<ffffffff814b6ec9>] __dev_close_many+0x49/0xd0
      [ 2212.358487]  [<ffffffff814b7028>] dev_close_many+0x88/0x100
      [ 2212.358546]  [<ffffffff814b8150>] rollback_registered_many+0xb0/0x220
      [ 2212.358612]  [<ffffffff814b8319>] unregister_netdevice_many+0x19/0x60
      [ 2212.358694]  [<ffffffffa04d8eb2>] ieee80211_remove_interfaces+0x112/0x190 [mac80211]
      [ 2212.358791]  [<ffffffffa04c585f>] ieee80211_unregister_hw+0x4f/0x100 [mac80211]
      [ 2212.361994]  [<ffffffffa03a1221>] rt2x00lib_remove_dev+0x161/0x1a0 [rt2x00lib]
      [ 2212.365240]  [<ffffffffa0266e2e>] rt2x00usb_disconnect+0x2e/0x70 [rt2x00usb]
      [ 2212.368470]  [<ffffffff81419ce4>] usb_unbind_interface+0x64/0x1c0
      [ 2212.371734]  [<ffffffff813b446f>] __device_release_driver+0x7f/0xf0
      [ 2212.374999]  [<ffffffff813b4503>] device_release_driver+0x23/0x30
      [ 2212.378131]  [<ffffffff813b3c98>] bus_remove_device+0x108/0x180
      [ 2212.381358]  [<ffffffff813b0565>] device_del+0x135/0x1d0
      [ 2212.384454]  [<ffffffff81417760>] usb_disable_device+0xb0/0x270
      [ 2212.387451]  [<ffffffff8140d9cd>] usb_disconnect+0xad/0x1d0
      [ 2212.390294]  [<ffffffff8140f6cd>] hub_thread+0x63d/0x1660
      [ 2212.393034]  [<ffffffff8107c860>] ? wake_up_atomic_t+0x30/0x30
      [ 2212.395728]  [<ffffffff8140f090>] ? hub_port_debounce+0x130/0x130
      [ 2212.398412]  [<ffffffff8107baa0>] kthread+0xc0/0xd0
      [ 2212.401058]  [<ffffffff8107b9e0>] ? insert_kthread_work+0x40/0x40
      [ 2212.403639]  [<ffffffff8155de3c>] ret_from_fork+0x7c/0xb0
      [ 2212.406193]  [<ffffffff8107b9e0>] ? insert_kthread_work+0x40/0x40
      [ 2212.408732] Code: 24 58 08 00 00 bf 80 00 00 00 e8 3a c3 e0 e0 5b 41 5c 5d c3 0f 1f 44 00 00 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 41 55 41 54 53 <48> 8b 47 10 48 89 fb 4c 8b 6f 28 4c 8b 20 49 8b 04 24 4c 8b 30
      [ 2212.414671] RIP  [<ffffffffa02667f2>] rt2x00usb_kick_tx_entry+0x12/0x160 [rt2x00usb]
      [ 2212.417646]  RSP <ffff880212f67750>
      [ 2212.420547] CR2: 0000000000000250
      [ 2212.441024] ---[ end trace 5442918f33832bce ]---
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarStanislaw Gruszka <stf_xl@wp.pl>
      Acked-by: default avatarHelmut Schaa <helmut.schaa@googlemail.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      5671ab05
    • Stanislaw Gruszka's avatar
      rt2400pci: fix RSSI read · 2bf127a5
      Stanislaw Gruszka authored
      RSSI value is provided on word3 not on word2.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarStanislaw Gruszka <stf_xl@wp.pl>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      2bf127a5
    • Felix Fietkau's avatar
      ath5k: fix regression in tx status processing · 7ede612f
      Felix Fietkau authored
      The regression was introduced in the following commit:
      
      0967e01e
      "ath5k: make use of the new rate control API"
      
      ath5k_tx_frame_completed saves the intended per-rate retry counts before
      they are cleared by ieee80211_tx_info_clear_status, however at this
      point the information in info->status.rates is incomplete.
      
      This causes significant throughput degradation and excessive packet loss
      on links where high bit rates don't work properly.
      
      Move the copy from bf->rates a few lines up to ensure that the saved
      retry counts are updated, and that they are really cleared in
      info->status.rates after the call to ieee80211_tx_info_clear_status.
      
      Cc: stable@vger.kernel.org # 3.10+
      Cc: Thomas Huehn <thomas@net.t-labs.tu-berlin.de>
      Cc: Benjamin Vahl <bvahl@net.t-labs.tu-berlin.de>
      Reported-by: default avatarBen West <ben@gowasabi.net>
      Signed-off-by: default avatarFelix Fietkau <nbd@openwrt.org>
      Acked-by: default avatarThomas Huehn <thomas@net.t-labs.tu-berlin.de>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      7ede612f
    • John W. Linville's avatar
    • John W. Linville's avatar
    • Emmanuel Grumbach's avatar
      iwlwifi: dvm: don't override mac80211's queue setting · f6b12952
      Emmanuel Grumbach authored
      Since we set IEEE80211_HW_QUEUE_CONTROL, we can let
      mac80211 do the queue assignement and don't need to
      override its decisions.
      While reassiging the same values is harmless of course,
      it triggered  a WARNING when iwlwifi and mac80211 came
      to different conclusions. This happened when mac80211 set
      IEEE80211_TX_CTL_SEND_AFTER_DTIM, but didn't route the
      packet to the cab_queue because no stations were asleep.
      
      iwlwifi should not override mac80211's decicions for
      offchannel packets and packets to  be sent after DTIM,
      but it should override mac80211's decision for AMPDUs
      since we have a special queue for them. So for AMPDU,
      we still override info->hw_queue by the AMPDU queue.
      
      This avoids:
      ------------[ cut here ]------------
      WARNING: CPU: 0 PID: 2531 at drivers/net/wireless/iwlwifi/dvm/tx.c:456 iwlagn_tx_skb+0x6c5/0x883()
      Modules linked in:
      CPU: 0 PID: 2531 Comm: hostapd Not tainted 3.12.0-rc5+ #1
      Hardware name:                  /D53427RKE, BIOS RKPPT10H.86A.0017.2013.0425.1251 04/25/2013
       0000000000000000 0000000000000009 ffffffff8189aa62 0000000000000000
       ffffffff8105a4f2 ffff880058339a48 ffffffff815f8a04 0000000000000000
       ffff8800560097b0 0000000000000208 0000000000000000 ffff8800561a9e5e
      Call Trace:
       [<ffffffff8189aa62>] ? dump_stack+0x41/0x51
       [<ffffffff8105a4f2>] ? warn_slowpath_common+0x78/0x90
       [<ffffffff815f8a04>] ? iwlagn_tx_skb+0x6c5/0x883
       [<ffffffff815f8a04>] ? iwlagn_tx_skb+0x6c5/0x883
       [<ffffffff818a0040>] ? put_cred+0x15/0x15
       [<ffffffff815f6db4>] ? iwlagn_mac_tx+0x19/0x2f
       [<ffffffff8186cc45>] ? __ieee80211_tx+0x226/0x29b
       [<ffffffff8186e6bd>] ? ieee80211_tx+0xa6/0xb5
       [<ffffffff8186e98b>] ? ieee80211_monitor_start_xmit+0x1e9/0x204
       [<ffffffff8171ce5f>] ? dev_hard_start_xmit+0x271/0x3ec
       [<ffffffff817351ac>] ? sch_direct_xmit+0x66/0x164
       [<ffffffff8171d1bf>] ? dev_queue_xmit+0x1e5/0x3c8
       [<ffffffff817fac5a>] ? packet_sendmsg+0xac5/0xb3d
       [<ffffffff81709a09>] ? sock_sendmsg+0x37/0x52
       [<ffffffff810f9e0c>] ? __do_fault+0x338/0x36b
       [<ffffffff81713820>] ? verify_iovec+0x44/0x94
       [<ffffffff81709e63>] ? ___sys_sendmsg+0x1f1/0x283
       [<ffffffff81140a73>] ? __inode_wait_for_writeback+0x67/0xae
       [<ffffffff8111735e>] ? __cache_free.isra.46+0x178/0x187
       [<ffffffff811173b1>] ? kmem_cache_free+0x44/0x84
       [<ffffffff81132c22>] ? dentry_kill+0x13d/0x149
       [<ffffffff81132f6f>] ? dput+0xe5/0xef
       [<ffffffff81136e04>] ? fget_light+0x2e/0x7c
       [<ffffffff8170ae62>] ? __sys_sendmsg+0x39/0x57
       [<ffffffff818a7e39>] ? system_call_fastpath+0x16/0x1b
      ---[ end trace 1b3eb79359c1d1e6 ]---
      Reported-by: default avatarSander Eikelenboom <linux@eikelenboom.it>
      Reviewed-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      f6b12952
  3. 17 Oct, 2013 1 commit
    • Johannes Berg's avatar
      mac80211: disable WMM with invalid parameters · 095d81ce
      Johannes Berg authored
      Some APs (notably a Sitecom WL-153 v1 with firmware 1.45) are sending
      invalid WMM parameters setting AIFSN, ECWmin and ECWmax to zero. The
      spec mandates that the value of AIFSN is at least 2, and some cards
      (e.g. Intel with the iwldvm driver) can't transmit when the invalid
      QoS parameters are actually uploaded to the firmware.
      
      Since there's little chance of being able to guess the values that
      the AP actually meant, disable WMM if such an invalid case is found.
      Since ECWmin/ECWmax are allowed to be zero, only verify AIFSN >= 2
      and ECWmin <= ECWmax.
      Reviewed-by: default avatarEliad Peller <eliad@wizery.com>
      Reported-by: default avatarAntonio Quartulli <antonio@meshcoding.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      095d81ce
  4. 15 Oct, 2013 2 commits
  5. 14 Oct, 2013 5 commits
  6. 11 Oct, 2013 3 commits
  7. 10 Oct, 2013 3 commits
  8. 09 Oct, 2013 2 commits
  9. 07 Oct, 2013 3 commits
  10. 02 Oct, 2013 6 commits
  11. 30 Sep, 2013 2 commits