Skip to content

L
linux
Switch branch/tag
  1. 12 May, 2010 1 commit
    • Johannes Berg's avatar
      mac80211: don't process work item with wrong frame · b8d92c9c
      Johannes Berg authored 
      When we process a frame, we currently just match it
to the work struct by the MAC addresses, and not by
the work type. This means that we can end up doing
the work for an association request item when (for
whatever reason) we receive another frame type, for
example a probe response. Processing the wrong type
of frame will lead to completely invalid data being
processed, and will lead to various problems like
thinking the association was successful even if the
AP never sent an assocation response.

Fix this by making each processing function check
that it is invoked for the right work struct type
only and continue processing otherwise (and drop
frames that we didn't expect).

This bug was uncovered during the debugging for
https://bugzilla.kernel.org/show_bug.cgi?id=15862
but doesn't seem to be the cause for any of the
various problems reported there.
Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      b8d92c9c
  3. 10 May, 2010 1 commit
  5. 07 May, 2010 2 commits
    • Reinette Chatre's avatar
      mac80211: remove association work when processing deauth request · 79733a86
      Reinette Chatre authored 
      In https://bugzilla.kernel.org/show_bug.cgi?id=15794 a user encountered the
following:

[18967.469098] wlan0: authenticated
[18967.472527] wlan0: associate with 00:1c:10:b8:e3:ea (try 1)
[18967.472585] wlan0: deauthenticating from 00:1c:10:b8:e3:ea by local choice (reason=3)
[18967.672057] wlan0: associate with 00:1c:10:b8:e3:ea (try 2)
[18967.872357] wlan0: associate with 00:1c:10:b8:e3:ea (try 3)
[18968.072960] wlan0: association with 00:1c:10:b8:e3:ea timed out
[18968.076890] ------------[ cut here ]------------
[18968.076898] WARNING: at net/wireless/mlme.c:341 cfg80211_send_assoc_timeout+0xa8/0x140()
[18968.076900] Hardware name: GX628
[18968.076924] Pid: 1408, comm: phy0 Not tainted 2.6.34-rc4-00082-g250541fc-dirty #3
[18968.076926] Call Trace:
[18968.076931]  [<ffffffff8103459e>] ?  warn_slowpath_common+0x6e/0xb0
[18968.076934]  [<ffffffff8157c2d8>] ?  cfg80211_send_assoc_timeout+0xa8/0x140
[18968.076937]  [<ffffffff8103ff8b>] ? mod_timer+0x10b/0x180
[18968.076940]  [<ffffffff8158f0fc>] ?  ieee80211_assoc_done+0xbc/0xc0
[18968.076943]  [<ffffffff81590d53>] ?  ieee80211_work_work+0x553/0x11c0
[18968.076945]  [<ffffffff8102d931>] ? finish_task_switch+0x41/0xb0
[18968.076948]  [<ffffffff81590800>] ?  ieee80211_work_work+0x0/0x11c0
[18968.076951]  [<ffffffff810476fb>] ? worker_thread+0x13b/0x210
[18968.076954]  [<ffffffff8104b6b0>] ?  autoremove_wake_function+0x0/0x30
[18968.076956]  [<ffffffff810475c0>] ? worker_thread+0x0/0x210
[18968.076959]  [<ffffffff8104b21e>] ? kthread+0x8e/0xa0
[18968.076962]  [<ffffffff810031f4>] ?  kernel_thread_helper+0x4/0x10
[18968.076964]  [<ffffffff8104b190>] ? kthread+0x0/0xa0
[18968.076966]  [<ffffffff810031f0>] ?  kernel_thread_helper+0x0/0x10
[18968.076968] ---[ end trace 8aa6265f4b1adfe0 ]---

As explained by Johannes Berg <johannes@sipsolutions.net>:

We authenticate successfully, and then userspace requests association.
Then we start that process, but the AP doesn't respond. While we're
still waiting for an AP response, userspace asks for a deauth. We do
the deauth, but don't abort the association work. Then once the
association work times out we tell cfg80211, but it no longer wants
to know since for all it is concerned we accepted the deauth that
also kills the association attempt.

Fix this by, upon receipt of deauth request, removing the association work
and continuing to send the deauth.

Unfortunately the user reporting the issue is not able to reproduce this
problem anymore and cannot verify this fix. This seems like a well understood
issue though and I thus present the patch.
Bug-identified-by: default avatarJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: default avatarReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      79733a86
    • Christian Lamparter's avatar
      ar9170: wait for asynchronous firmware loading · 160b8242
      Christian Lamparter authored 
      This patch fixes a regression introduced by the following patch:
"ar9170: load firmware asynchronously"

When we kick off a firmware loading request and then unbind,
or disconnect the usb device right away, we get into trouble:

> ------------[ cut here ]------------
> WARNING: at lib/kref.c:44 kref_get+0x1c/0x20()
> Hardware name: 18666GU
> Modules linked in: ar9170usb [...]
> Pid: 6588, comm: firmware/ar9170 Not tainted 2.6.34-rc5-wl #43
> Call Trace:
> [<c102b05e>] ? warn_slowpath_common+0x6e/0xb0
> [<c117c93c>] ? kref_get+0x1c/0x20
> [<c102b0b3>] ? warn_slowpath_null+0x13/0x20
> [<c117c93c>] ? kref_get+0x1c/0x20
> [<c117bb2f>] ? kobject_get+0xf/0x20
> [<c124d630>] ? get_device+0x10/0x20
> [<c124e5a0>] ? device_add+0x60/0x530
> [<c117b8b5>] ? kobject_init+0x25/0xa0
> [<c12569f9>] ? _request_firmware+0x139/0x3e0
> [<c1256cc0>] ? request_firmware_work_func+0x20/0x70
> [<c1256ca0>] ? request_firmware_work_func+0x0/0x70
> [<c103ff24>] ? kthread+0x74/0x80
> [<c103feb0>] ? kthread+0x0/0x80
> [<c1003136>] ? kernel_thread_helper+0x6/0x10
>---[ end trace 2d50bd818f64a1b7 ]---
- followed by a random Oops -

Avoid that by waiting for the firmware loading to finish
(whether successfully or not) before the unbind in
ar9170_usb_disconnect.
Reported-by: default avatarJohannes Berg <johannes@sipsolutions.net>
Bug-fixed-by: default avatarJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: default avatarChristian Lamparter <chunkeey@googlemail.com>
Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      160b8242
  7. 30 Apr, 2010 1 commit
  9. 26 Apr, 2010 1 commit
  11. 19 Apr, 2010 2 commits
  13. 16 Apr, 2010 2 commits
  15. 09 Apr, 2010 1 commit
  17. 08 Apr, 2010 1 commit
  19. 06 Apr, 2010 3 commits
  21. 02 Apr, 2010 3 commits
    • Zhu Yi's avatar
      iwlwifi: avoid Tx queue memory allocation in interface down · de0f60ea
      Zhu Yi authored 
      We used to free all the Tx queues memory when interface is brought
down and reallocate them again in interface up. This requires
order-4 allocation for txq->cmd[]. In situations like s2ram, this
usually leads to allocation failure in the memory subsystem. The
patch fixed this problem by allocating the Tx queues memory only at
the first time. Later iwl_down/iwl_up only initialize but don't
free and reallocate them. The memory is freed at the device removal
time. BTW, we have already done this for the Rx queue.

This fixed bug https://bugzilla.kernel.org/show_bug.cgi?id=15551Signed-off-by: default avatarZhu Yi <yi.zhu@intel.com>
Acked-by: default avatarWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: default avatarReinette Chatre <reinette.chatre@intel.com>
      de0f60ea
    • Shanyu Zhao's avatar
      iwlwifi: use consistent table for tx data collect · 04f2dec1
      Shanyu Zhao authored 
      When collecting tx data for non-aggregation packets in rate scaling, if
the tx data matches "other table", it still uses current table to update
the stats and calculate average throughput in function rs_collect_tx_data().
This can mess up the rate scaling data structure and cause a kernel panic
in a BUG_ON statement in rs_rate_scale_perform().

To fix this bug, we pass table pointer instead of window pointer (pointed
to by table pointer) to function rs_collect_tx_data() so that the table
being used is consistent.
Signed-off-by: default avatarShanyu Zhao <shanyu.zhao@intel.com>
Signed-off-by: default avatarHenry Zhang <hongx.c.zhang@intel.com>
Signed-off-by: default avatarReinette Chatre <reinette.chatre@intel.com>
      04f2dec1
    • Zhu Yi's avatar
      iwlwifi: fix DMA allocation warnings · dd487449
      Zhu Yi authored 
      Below warning is triggered sometimes at module removal time when
CONFIG_DMA_API_DEBUG is enabled. This should be caused by we didn't
unmap pending commands (enqueued, but no complete notification
received) for the Tx command queue.

[ 1583.107469] ------------[ cut here ]------------
[ 1583.107539] WARNING: at lib/dma-debug.c:688
dma_debug_device_change+0x13c/0x180()
[ 1583.107617] Hardware name: ...
[ 1583.107664] pci 0000:04:00.0: DMA-API: device driver has pending DMA
allocations while released from device [count=1]
[ 1583.107713] Modules linked in: ...
[ 1583.111661] Pid: 16970, comm: modprobe Tainted: G        W
2.6.34-rc1-wl #33
[ 1583.111727] Call Trace:
[ 1583.111779]  [<c02a281c>] ? dma_debug_device_change+0x13c/0x180
[ 1583.111833]  [<c02a281c>] ? dma_debug_device_change+0x13c/0x180
[ 1583.111908]  [<c0138e11>] warn_slowpath_common+0x71/0xd0
[ 1583.111963]  [<c02a281c>] ? dma_debug_device_change+0x13c/0x180
[ 1583.112016]  [<c0138ebb>] warn_slowpath_fmt+0x2b/0x30
[ 1583.112086]  [<c02a281c>] dma_debug_device_change+0x13c/0x180
[ 1583.112142]  [<c03e6c33>] notifier_call_chain+0x53/0x90
[ 1583.112198]  [<c03e1ebe>] ? down_read+0x6e/0x90
[ 1583.112271]  [<c015b229>] __blocking_notifier_call_chain+0x49/0x70
[ 1583.112326]  [<c015b26f>] blocking_notifier_call_chain+0x1f/0x30
[ 1583.112380]  [<c031931c>] __device_release_driver+0x8c/0xa0
[ 1583.112451]  [<c03193bf>] driver_detach+0x8f/0xa0
[ 1583.112538]  [<c0318382>] bus_remove_driver+0x82/0x100
[ 1583.112595]  [<c0319ad9>] driver_unregister+0x49/0x80
[ 1583.112671]  [<c024feb2>] ? sysfs_remove_file+0x12/0x20
[ 1583.112727]  [<c02aa292>] pci_unregister_driver+0x32/0x80
[ 1583.112791]  [<fc13a3c1>] iwl_exit+0x12/0x19 [iwlagn]
[ 1583.112848]  [<c017940a>] sys_delete_module+0x15a/0x210
[ 1583.112870]  [<c015a5db>] ? up_read+0x1b/0x30
[ 1583.112893]  [<c029600c>] ? trace_hardirqs_off_thunk+0xc/0x10
[ 1583.112924]  [<c0295ffc>] ? trace_hardirqs_on_thunk+0xc/0x10
[ 1583.112947]  [<c03e6a1f>] ? do_page_fault+0x1ff/0x3c0
[ 1583.112978]  [<c03e36f6>] ? restore_all_notrace+0x0/0x18
[ 1583.113002]  [<c016aa70>] ? trace_hardirqs_on_caller+0x20/0x190
[ 1583.113025]  [<c0102d58>] sysenter_do_call+0x12/0x38
[ 1583.113054] ---[ end trace fc23e059cc4c2ced ]---
Signed-off-by: default avatarZhu Yi <yi.zhu@intel.com>
Signed-off-by: default avatarReinette Chatre <reinette.chatre@intel.com>
      dd487449
  23. 30 Mar, 2010 15 commits
  25. 16 Mar, 2010 3 commits
    • Adel Gadllah's avatar
      iwlwifi: Silence tfds_in_queue message · c8406ea8
      Adel Gadllah authored 
      Commit a239a8b4 introduced a
noisy message, that fills up the log very fast.

The error seems not to be fatal (the connection is stable and
performance is ok), so make it IWL_DEBUG_TX rather than IWL_ERR.
Signed-off-by: default avatarAdel Gadllah <adel.gadllah@gmail.com>
Cc: stable@kernel.org
Acked-by: default avatarReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      c8406ea8
    • Felix Fietkau's avatar
      ath9k: fix BUG_ON triggered by PAE frames · 4fdec031
      Felix Fietkau authored 
      When I initially stumbled upon sequence number problems with PAE frames
in ath9k, I submitted a patch to remove all special cases for PAE
frames and let them go through the normal transmit path.
Out of concern about crypto incompatibility issues, this change was
merged instead:

commit 6c8afef5
Author: Sujith <Sujith.Manoharan@atheros.com>
Date:   Tue Feb 9 10:07:00 2010 +0530

    ath9k: Fix sequence numbers for PAE frames

After a lot of testing, I'm able to reliably trigger a driver crash on
rekeying with current versions with this change in place.
It seems that the driver does not support sending out regular MPDUs with
the same TID while an A-MPDU session is active.
This leads to duplicate entries in the TID Tx buffer, which hits the
following BUG_ON in ath_tx_addto_baw():

    index  = ATH_BA_INDEX(tid->seq_start, bf->bf_seqno);
    cindex = (tid->baw_head + index) & (ATH_TID_MAX_BUFS - 1);

    BUG_ON(tid->tx_buf[cindex] != NULL);

I believe until we actually have a reproducible case of an
incompatibility with another AP using no PAE special cases, we should
simply get rid of this mess.

This patch completely fixes my crash issues in STA mode and makes it
stay connected without throughput drops or connectivity issues even
when the AP is configured to a very short group rekey interval.
Signed-off-by: default avatarFelix Fietkau <nbd@openwrt.org>
Cc: stable@kernel.org
Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      4fdec031
    • Grazvydas Ignotas's avatar
      wl1251: fix potential crash · 3f60ebc9
      Grazvydas Ignotas authored 
      In case debugfs does not init for some reason (or is disabled
on older kernels) driver does not allocate stats.fw_stats
structure, but tries to clear it later and trips on a NULL
pointer:

Unable to handle kernel NULL pointer dereference at virtual address
00000000
PC is at __memzero+0x24/0x80
Backtrace:
[<bf0ddb88>] (wl1251_debugfs_reset+0x0/0x30 [wl1251])
[<bf0d6a2c>] (wl1251_op_stop+0x0/0x12c [wl1251])
[<bf0bc228>] (ieee80211_stop_device+0x0/0x74 [mac80211])
[<bf0b0d10>] (ieee80211_stop+0x0/0x4ac [mac80211])
[<c02deeac>] (dev_close+0x0/0xb4)
[<c02deac0>] (dev_change_flags+0x0/0x184)
[<c031f478>] (devinet_ioctl+0x0/0x704)
[<c0320720>] (inet_ioctl+0x0/0x100)

Add a NULL pointer check to fix this.
Signed-off-by: default avatarGrazvydas Ignotas <notasas@gmail.com>
Acked-by: default avatarKalle Valo <kalle.valo@iki.fi>
Cc: stable@kernel.org
Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      3f60ebc9
  27. 10 Mar, 2010 4 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7