linux-stable.git/drivers/net/wireless, branch linux-2.6.29.y Linux kernel stable tree iwlwifi: update key flags at time key is set 2009-06-15T16:40:11+00:00 Reinette Chatre reinette.chatre@intel.com 2009-04-30T20:56:31+00:00 485e8e39a85e8178978252cd17f218e6787851ee commit 299f5462087f3bc2141e6bc83ba7e2b15d8a07d2 upstream. We need to be symmetrical in what is done when key is set and cleared. This is important wrt the key flags as they are used during key clearing and if they are not set when the key is set the key cannot be cleared completely. This addresses the many occurences of the WARN found in iwl_set_tkip_dynamic_key_info() and tracked in http://www.kerneloops.org/searchweek.php?search=iwl_set_dynamic_key If calling iwl_set_tkip_dynamic_key_info()/iwl_remove_dynamic_key() pair a few times in a row will cause that we run out of key space. This is because the index stored in the key flags is used by iwl_remove_dynamic_key() to decide if it should remove the key. Unfortunately the key flags, and hence the key index is currently only set at the time the key is written to the device (in iwl_update_tkip_key()) and _not_ in iwl_set_tkip_dynamic_key_info(). Fix this by setting flags in iwl_set_tkip_dynamic_key_info(). Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit 299f5462087f3bc2141e6bc83ba7e2b15d8a07d2 upstream.

We need to be symmetrical in what is done when key is set and cleared.
This is important wrt the key flags as they are used during key
clearing and if they are not set when the key is set the key cannot be
cleared completely.

This addresses the many occurences of the WARN found in
iwl_set_tkip_dynamic_key_info() and tracked in
http://www.kerneloops.org/searchweek.php?search=iwl_set_dynamic_key

If calling iwl_set_tkip_dynamic_key_info()/iwl_remove_dynamic_key()
pair a few times in a row will cause that we run out of key space.
This is because the index stored in the key flags is used by
iwl_remove_dynamic_key() to decide if it should remove the key.
Unfortunately the key flags, and hence the key index is currently only
set at the time the key is written to the device (in
iwl_update_tkip_key()) and _not_ in iwl_set_tkip_dynamic_key_info().
Fix this by setting flags in iwl_set_tkip_dynamic_key_info().

Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
ath9k: Fix FIF_BCN_PRBRESP_PROMISC handling 2009-05-08T22:45:12+00:00 Luis R. Rodriguez lrodriguez@Atheros.com 2009-05-06T00:04:11+00:00 25ffea68860d3ffd7837a8bcf8f75875b3ec4d4b This is a port of commit 91ed19f5f66a7fe544f0ec385e981f43491d1d5a for 2.6.29. Without this after scanning your device will set the association ID to something bogus and what is being reported is multicast/broadcast frame are not being received. For details see this bug report: https://bugzilla.redhat.com/show_bug.cgi?id=498502 >From the original commit: So that a new created IBSS network doesn't break on the first scan. It seems to Sujith and me that this stupid code unnecessary, too. So remove it... Reported-by: David Woodhouse <dwmw2@infradead.org> Tested-by: David Woodhouse <dwmw2@infradead.org> Signed-off-by: Alina Friedrichsen <x-alina@gmx.net> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Jouni Malinen <Jouni.Malinen@atheros.com> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
This is a port of commit
91ed19f5f66a7fe544f0ec385e981f43491d1d5a
for 2.6.29.

Without this after scanning your device will set
the association ID to something bogus and what is
being reported is multicast/broadcast frame are not
being received. For details see this bug report:

https://bugzilla.redhat.com/show_bug.cgi?id=498502

>From the original commit:

So that a new created IBSS network
doesn't break on the first scan.

It seems to Sujith and me that this
stupid code unnecessary, too.

So remove it...

Reported-by: David Woodhouse <dwmw2@infradead.org>
Tested-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: Alina Friedrichsen <x-alina@gmx.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Jouni Malinen <Jouni.Malinen@atheros.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
rndis_wlan: fix initialization order for workqueue&workers 2009-05-08T22:45:11+00:00 Jussi Kivilinna jussi.kivilinna@mbnet.fi 2009-04-22T07:59:37+00:00 76e6da3c9e11f2d009a4c519993f29fcd32ae388 commit e805e4d0b53506dff4255a2792483f094e7fcd2c upstream. rndis_wext_link_change() might be called from rndis_command() at initialization stage and priv->workqueue/priv->work have not been initialized yet. This causes invalid opcode at rndis_wext_bind on some brands of bcm4320. Fix by initializing workqueue/workers in rndis_wext_bind() before rndis_command is used. This bug has existed since 2.6.25, reported at: http://bugzilla.kernel.org/show_bug.cgi?id=12794 Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit e805e4d0b53506dff4255a2792483f094e7fcd2c upstream.

rndis_wext_link_change() might be called from rndis_command() at
initialization stage and priv->workqueue/priv->work have not been
initialized yet. This causes invalid opcode at rndis_wext_bind on
some brands of bcm4320.

Fix by initializing workqueue/workers in rndis_wext_bind() before
rndis_command is used.

This bug has existed since 2.6.25, reported at:
	http://bugzilla.kernel.org/show_bug.cgi?id=12794

Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
ath5k: fix buffer overrun in rate debug code 2009-05-08T22:45:09+00:00 Bob Copeland me@bobcopeland.com 2009-04-28T02:12:43+00:00 f8c890f0bc401fd581a27062fcb989ef19893318 commit b7fcb5c4a4c27da2f6d86cb03d18687e537442cf upstream. char bname[5] is too small for the string "X GHz" when the null terminator is taken into account. Thus, turning on rate debugging can crash unless we have lucky stack alignment. Cc: stable@kernel.org Reported-by: Paride Legovini <legovini@spiro.fisica.unipd.it> Signed-off-by: Bob Copeland <me@bobcopeland.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit b7fcb5c4a4c27da2f6d86cb03d18687e537442cf upstream.

char bname[5] is too small for the string "X GHz" when the null
terminator is taken into account.  Thus, turning on rate debugging
can crash unless we have lucky stack alignment.

Cc: stable@kernel.org
Reported-by: Paride Legovini <legovini@spiro.fisica.unipd.it>
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
b43: Refresh RX poison on buffer recycling 2009-05-08T22:44:58+00:00 Michael Buesch mb@bu3sch.de 2009-04-24T16:05:29+00:00 60f9c3b02c5adfa2bfb1061642e5086df61d4d6a upstream commit: cf68636a9773aa97915497fe54fa4a51e3f08f3a The RX buffer poison needs to be refreshed, if we recycle an RX buffer, because it might be (partially) overwritten by some DMA operations. Cc: stable@kernel.org Cc: Francesco Gringoli <francesco.gringoli@ing.unibs.it> Signed-off-by: Michael Buesch <mb@bu3sch.de> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Chris Wright <chrisw@sous-sol.org> 
upstream commit: cf68636a9773aa97915497fe54fa4a51e3f08f3a

The RX buffer poison needs to be refreshed, if we recycle an RX buffer,
because it might be (partially) overwritten by some DMA operations.

Cc: stable@kernel.org
Cc: Francesco Gringoli <francesco.gringoli@ing.unibs.it>
Signed-off-by: Michael Buesch <mb@bu3sch.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
b43: Poison RX buffers 2009-05-08T22:44:58+00:00 Michael Buesch mb@bu3sch.de 2009-04-24T16:05:31+00:00 46da7a503eaadb0daf7a56c4f8ced1a3d4e57ec2 upstream commit: ec9a1d8c13e36440eda0f3c79b8149080e3ab5ba This patch adds poisoning and sanity checking to the RX DMA buffers. This is used for protection against buggy hardware/firmware that raises RX interrupts without doing an actual DMA transfer. This mechanism protects against rare "bad packets" (due to uninitialized skb data) and rare kernel crashes due to uninitialized RX headers. The poison is selected to not match on valid frames and to be cheap for checking. The poison check mechanism _might_ trigger incorrectly, if we are voluntarily receiving frames with bad PLCP headers. However, this is nonfatal, because the chance of such a match is basically zero and in case it happens it just results in dropping the packet. Bad-PLCP RX defaults to off, and you should leave it off unless you want to listen to the latest news broadcasted by your microwave oven. This patch also moves the initialization of the RX-header "length" field in front of the mapping of the DMA buffer. The CPU should not touch the buffer after we mapped it. Cc: stable@kernel.org Reported-by: Francesco Gringoli <francesco.gringoli@ing.unibs.it> Signed-off-by: Michael Buesch <mb@bu3sch.de> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Chris Wright <chrisw@sous-sol.org> 
upstream commit: ec9a1d8c13e36440eda0f3c79b8149080e3ab5ba

This patch adds poisoning and sanity checking to the RX DMA buffers.
This is used for protection against buggy hardware/firmware that raises
RX interrupts without doing an actual DMA transfer.

This mechanism protects against rare "bad packets" (due to uninitialized skb data)
and rare kernel crashes due to uninitialized RX headers.

The poison is selected to not match on valid frames and to be cheap for checking.

The poison check mechanism _might_ trigger incorrectly, if we are voluntarily
receiving frames with bad PLCP headers. However, this is nonfatal, because the
chance of such a match is basically zero and in case it happens it just results
in dropping the packet.
Bad-PLCP RX defaults to off, and you should leave it off unless you want to listen
to the latest news broadcasted by your microwave oven.

This patch also moves the initialization of the RX-header "length" field in front of
the mapping of the DMA buffer. The CPU should not touch the buffer after we mapped it.

Cc: stable@kernel.org
Reported-by: Francesco Gringoli <francesco.gringoli@ing.unibs.it>
Signed-off-by: Michael Buesch <mb@bu3sch.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
rt2x00: Fix SLAB corruption during rmmod 2009-04-27T17:36:52+00:00 Gertjan van Wingerde gwingerde@gmail.com 2009-04-01T19:18:11+00:00 f8629efabc754f5c0003ce38c28b26db7ca89244 At rmmod stage, the code path is the following one : rt2x00lib_remove_dev   ->  rt2x00lib_uninitialize()         -> rt2x00rfkill_unregister()              -> rfkill_unregister()         -> rt2x00rfkill_free()              -> rfkill_free() The problem is that rfkill_free should not be called after rfkill_register otherwise put_device(&rfkill->dev) will be called 2 times. This patch fixes this by only calling rt2x00rfkill_free() when rt2x00rfkill_register() hasn't been called or has failed. This patch is for 2.6.29 only. The code in question has completely disappeared in 2.6.30 and does not contain this bug. Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com> Tested-by: Arnaud Patard <apatard@mandriva.com> Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: Chris Wright <chrisw@sous-sol.org> 
At rmmod stage, the code path is the following one :

rt2x00lib_remove_dev
  ->  rt2x00lib_uninitialize()
        -> rt2x00rfkill_unregister()
             -> rfkill_unregister()
        -> rt2x00rfkill_free()
             -> rfkill_free()

The problem is that rfkill_free should not be called after rfkill_register
otherwise put_device(&rfkill->dev) will be called 2 times. This patch
fixes this by only calling rt2x00rfkill_free() when rt2x00rfkill_register()
hasn't been called or has failed.

This patch is for 2.6.29 only. The code in question has completely disappeared
in 2.6.30 and does not contain this bug.

Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Tested-by: Arnaud Patard <apatard@mandriva.com>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
ath5k: warn and correct rate for unknown hw rate indexes 2009-04-02T20:55:17+00:00 Bob Copeland me@bobcopeland.com 2009-03-28T01:45:04+00:00 db257505aa751f739531fee3a3f16a45ddb0eaca upstream commit: b726604706ad88d8b28bc487e45e710f58cc19ee ath5k sets up a mapping table from the hardware rate index to the rate index used by mac80211; however, we have seen some received frames with incorrect rate indexes. Such frames normally get dropped with a warning in __ieee80211_rx(), but it doesn't include enough information to track down the error. This patch adds a warning to hw_to_driver_rix for any lookups that result in a rate index of -1, then returns a valid rate so the frame can be processed. Changes-licensed-under: 3-Clause-BSD Signed-off-by: Bob Copeland <me@bobcopeland.com> Cc: stable@kernel.org Signed-off-by: John W. Linville <linville@tuxdriver.com> [chrisw: add db5b4f7ae3901fdc48c5b988fc2a5e0cb4ec1870 to backport] Signed-off-by: Chris Wright <chrisw@sous-sol.org> 
upstream commit: b726604706ad88d8b28bc487e45e710f58cc19ee

ath5k sets up a mapping table from the hardware rate index to
the rate index used by mac80211; however, we have seen some
received frames with incorrect rate indexes.  Such frames
normally get dropped with a warning in __ieee80211_rx(),
but it doesn't include enough information to track down the
error.

This patch adds a warning to hw_to_driver_rix for any lookups
that result in a rate index of -1, then returns a valid rate so
the frame can be processed.

Changes-licensed-under: 3-Clause-BSD

Signed-off-by: Bob Copeland <me@bobcopeland.com>
Cc: stable@kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>
[chrisw: add db5b4f7ae3901fdc48c5b988fc2a5e0cb4ec1870 to backport]
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
ath5k: disable MIB interrupts 2009-04-02T20:55:17+00:00 Bob Copeland me@bobcopeland.com 2009-03-28T01:45:12+00:00 7b2b76da5c570166c04a44c9646963089b67e4ef upstream commit: 9ca9fb8aa8422595956af9681518cdb8b167055e The MIB interrupt fires whenever counters overflow; however without support for automatic noise immunity, we can sometimes get an interrupt storm. The get_stats() callback reads the counters anyway so we can disable the interrupt for now until ANI is implemented. This fixes the issue reported in http://bugzilla.kernel.org/show_bug.cgi?id=12647. Changes-licensed-under: 3-Clause-BSD Cc: stable@kernel.org Signed-off-by: Bob Copeland <me@bobcopeland.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Chris Wright <chrisw@sous-sol.org> 
upstream commit: 9ca9fb8aa8422595956af9681518cdb8b167055e

The MIB interrupt fires whenever counters overflow; however without
support for automatic noise immunity, we can sometimes get an interrupt
storm.  The get_stats() callback reads the counters anyway so we can
disable the interrupt for now until ANI is implemented.  This fixes
the issue reported in http://bugzilla.kernel.org/show_bug.cgi?id=12647.

Changes-licensed-under: 3-Clause-BSD

Cc: stable@kernel.org
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
b43: fix b43_plcp_get_bitrate_idx_ofdm return type 2009-04-02T20:55:16+00:00 Lorenzo Nava navalorenx@gmail.com 2009-03-28T01:45:06+00:00 bf2d225b466496ff6704288bbd79fe744b399811 upstream commit: a3c0b87c4f21911fb7185902dd13f0e3cd7f33f7 This patch fixes the return type of b43_plcp_get_bitrate_idx_ofdm. If the plcp contains an error, the function return value is 255 instead of -1, and the packet was not dropped. This causes a warning in __ieee80211_rx function because rate idx is out of range. Cc: stable@kernel.org Signed-off-by: Lorenzo Nava <navalorenx@gmail.com> Signed-off-by: Michael Buesch <mb@bu3sch.de> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Chris Wright <chrisw@sous-sol.org> 
upstream commit: a3c0b87c4f21911fb7185902dd13f0e3cd7f33f7

This patch fixes the return type of b43_plcp_get_bitrate_idx_ofdm. If
the plcp contains an error, the function return value is 255 instead
of -1, and the packet was not dropped. This causes a warning in
__ieee80211_rx function because rate idx is out of range.

Cc: stable@kernel.org
Signed-off-by: Lorenzo Nava <navalorenx@gmail.com>
Signed-off-by: Michael Buesch <mb@bu3sch.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>