.33 patches

6 files changed, 167 insertions, 59 deletions

diff --git a/queue-2.6.33/b43-fix-beacon-problem-in-ad-hoc-mode.patch b/queue-2.6.33/b43-fix-beacon-problem-in-ad-hoc-mode.patch
new file mode 100644
index 0000000..9d28871
--- /dev/null
+++ b/queue-2.6.33/b43-fix-beacon-problem-in-ad-hoc-mode.patch
@@ -0,0 +1,33 @@
+From 8c23516fbb209ccf8f8c36268311c721faff29ee Mon Sep 17 00:00:00 2001
+From: Manual Munz <freifunk@somakoma.de>
+Date: Sun, 18 Sep 2011 18:24:03 -0500
+Subject: b43: Fix beacon problem in ad-hoc mode
+
+From: Manual Munz <freifunk@somakoma.de>
+
+commit 8c23516fbb209ccf8f8c36268311c721faff29ee upstream.
+
+In ad-hoc mode, driver b43 does not issue beacons.
+
+Signed-off-by: Manual Munz <freifunk@somakoma.de>
+Tested-by: Larry Finger <Larry.Finger@lwfinger.net>
+Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
+Signed-off-by: John W. Linville <linville@tuxdriver.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/net/wireless/b43/main.c |    3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/net/wireless/b43/main.c
++++ b/drivers/net/wireless/b43/main.c
+@@ -1526,7 +1526,8 @@ static void handle_irq_beacon(struct b43
+ 	u32 cmd, beacon0_valid, beacon1_valid;
+ 
+ 	if (!b43_is_mode(wl, NL80211_IFTYPE_AP) &&
+-	    !b43_is_mode(wl, NL80211_IFTYPE_MESH_POINT))
++	    !b43_is_mode(wl, NL80211_IFTYPE_MESH_POINT) &&
++	    !b43_is_mode(wl, NL80211_IFTYPE_ADHOC))
+ 		return;
+ 
+ 	/* This is the bottom half of the asynchronous beacon update. */
diff --git a/queue-2.6.33/cifs-fix-possible-memory-corruption-in-cifsfindnext.patch b/queue-2.6.33/cifs-fix-possible-memory-corruption-in-cifsfindnext.patch
new file mode 100644
index 0000000..21abc31
--- /dev/null
+++ b/queue-2.6.33/cifs-fix-possible-memory-corruption-in-cifsfindnext.patch
@@ -0,0 +1,43 @@
+From 9438fabb73eb48055b58b89fc51e0bc4db22fabd Mon Sep 17 00:00:00 2001
+From: Jeff Layton <jlayton@redhat.com>
+Date: Tue, 23 Aug 2011 07:21:28 -0400
+Subject: cifs: fix possible memory corruption in CIFSFindNext
+
+From: Jeff Layton <jlayton@redhat.com>
+
+commit 9438fabb73eb48055b58b89fc51e0bc4db22fabd upstream.
+
+The name_len variable in CIFSFindNext is a signed int that gets set to
+the resume_name_len in the cifs_search_info. The resume_name_len however
+is unsigned and for some infolevels is populated directly from a 32 bit
+value sent by the server.
+
+If the server sends a very large value for this, then that value could
+look negative when converted to a signed int. That would make that
+value pass the PATH_MAX check later in CIFSFindNext. The name_len would
+then be used as a length value for a memcpy. It would then be treated
+as unsigned again, and the memcpy scribbles over a ton of memory.
+
+Fix this by making the name_len an unsigned value in CIFSFindNext.
+
+Reported-by: Darren Lavender <dcl@hppine99.gbr.hp.com>
+Signed-off-by: Jeff Layton <jlayton@redhat.com>
+Signed-off-by: Steve French <sfrench@us.ibm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ fs/cifs/cifssmb.c |    3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/fs/cifs/cifssmb.c
++++ b/fs/cifs/cifssmb.c
+@@ -3596,7 +3596,8 @@ int CIFSFindNext(const int xid, struct c
+ 	T2_FNEXT_RSP_PARMS *parms;
+ 	char *response_data;
+ 	int rc = 0;
+-	int bytes_returned, name_len;
++	int bytes_returned;
++	unsigned int name_len;
+ 	__u16 params, byte_count;
+ 
+ 	cFYI(1, ("In FindNext"));
diff --git a/queue-2.6.33/mm-sync-vmalloc-address-space-page-tables-in-alloc_vm_area.patch b/queue-2.6.33/mm-sync-vmalloc-address-space-page-tables-in-alloc_vm_area.patch
deleted file mode 100644
index 26a6654..0000000
--- a/queue-2.6.33/mm-sync-vmalloc-address-space-page-tables-in-alloc_vm_area.patch
+++ /dev/null
@@ -1,58 +0,0 @@
-From 461ae488ecb125b140d7ea29ceeedbcce9327003 Mon Sep 17 00:00:00 2001
-From: David Vrabel <david.vrabel@citrix.com>
-Date: Wed, 14 Sep 2011 16:22:02 -0700
-Subject: mm: sync vmalloc address space page tables in alloc_vm_area()
-
-From: David Vrabel <david.vrabel@citrix.com>
-
-commit 461ae488ecb125b140d7ea29ceeedbcce9327003 upstream.
-
-Xen backend drivers (e.g., blkback and netback) would sometimes fail to
-map grant pages into the vmalloc address space allocated with
-alloc_vm_area().  The GNTTABOP_map_grant_ref would fail because Xen could
-not find the page (in the L2 table) containing the PTEs it needed to
-update.
-
-(XEN) mm.c:3846:d0 Could not find L1 PTE for address fbb42000
-
-netback and blkback were making the hypercall from a kernel thread where
-task->active_mm != &init_mm and alloc_vm_area() was only updating the page
-tables for init_mm.  The usual method of deferring the update to the page
-tables of other processes (i.e., after taking a fault) doesn't work as a
-fault cannot occur during the hypercall.
-
-This would work on some systems depending on what else was using vmalloc.
-
-Fix this by reverting ef691947d8a3 ("vmalloc: remove vmalloc_sync_all()
-from alloc_vm_area()") and add a comment to explain why it's needed.
-
-Signed-off-by: David Vrabel <david.vrabel@citrix.com>
-Cc: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
-Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
-Cc: Ian Campbell <Ian.Campbell@citrix.com>
-Cc: Keir Fraser <keir.xen@gmail.com>
-Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
-Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
----
- mm/vmalloc.c |    8 ++++++++
- 1 file changed, 8 insertions(+)
-
---- a/mm/vmalloc.c
-+++ b/mm/vmalloc.c
-@@ -2049,6 +2049,14 @@ struct vm_struct *alloc_vm_area(size_t s
- 	   mappings */
- 	vmalloc_sync_all();
- 
-+	/*
-+	 * If the allocated address space is passed to a hypercall
-+	 * before being used then we cannot rely on a page fault to
-+	 * trigger an update of the page tables.  So sync all the page
-+	 * tables here.
-+	 */
-+	vmalloc_sync_all();
-+
- 	return area;
- }
- EXPORT_SYMBOL_GPL(alloc_vm_area);
diff --git a/queue-2.6.33/rtl2800usb-fix-incorrect-storage-of-mac-address-on.patch b/queue-2.6.33/rtl2800usb-fix-incorrect-storage-of-mac-address-on.patch
new file mode 100644
index 0000000..27f72dc
--- /dev/null
+++ b/queue-2.6.33/rtl2800usb-fix-incorrect-storage-of-mac-address-on.patch
@@ -0,0 +1,48 @@
+From daabead1c32f331edcfb255fd973411c667977e8 Mon Sep 17 00:00:00 2001
+From: Larry Finger <Larry.Finger@lwfinger.net>
+Date: Wed, 14 Sep 2011 16:50:23 -0500
+Subject: rtl2800usb: Fix incorrect storage of MAC address on
+ big-endian platforms
+
+From: Larry Finger <Larry.Finger@lwfinger.net>
+
+commit daabead1c32f331edcfb255fd973411c667977e8 upstream.
+
+The eeprom data is stored in little-endian order in the rt2x00 library.
+As it was converted to cpu order in the read routines, the data need to
+be converted to LE on a big-endian platform.
+
+Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
+Signed-off-by: John W. Linville <linville@tuxdriver.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/net/wireless/rt2x00/rt2800lib.c |   17 +++++++++--------
+ 1 file changed, 9 insertions(+), 8 deletions(-)
+
+--- a/drivers/net/wireless/rt2x00/rt2800lib.c
++++ b/drivers/net/wireless/rt2x00/rt2800lib.c
+@@ -1694,14 +1694,15 @@ static void rt2800_efuse_read(struct rt2
+ 	rt2800_regbusy_read(rt2x00dev, EFUSE_CTRL, EFUSE_CTRL_KICK, &reg);
+ 
+ 	/* Apparently the data is read from end to start */
+-	rt2800_register_read_lock(rt2x00dev, EFUSE_DATA3,
+-					(u32 *)&rt2x00dev->eeprom[i]);
+-	rt2800_register_read_lock(rt2x00dev, EFUSE_DATA2,
+-					(u32 *)&rt2x00dev->eeprom[i + 2]);
+-	rt2800_register_read_lock(rt2x00dev, EFUSE_DATA1,
+-					(u32 *)&rt2x00dev->eeprom[i + 4]);
+-	rt2800_register_read_lock(rt2x00dev, EFUSE_DATA0,
+-					(u32 *)&rt2x00dev->eeprom[i + 6]);
++	rt2800_register_read_lock(rt2x00dev, EFUSE_DATA3, &reg);
++	/* The returned value is in CPU order, but eeprom is le */
++	rt2x00dev->eeprom[i] = cpu_to_le32(reg);
++	rt2800_register_read_lock(rt2x00dev, EFUSE_DATA2, &reg);
++	*(u32 *)&rt2x00dev->eeprom[i + 2] = cpu_to_le32(reg);
++	rt2800_register_read_lock(rt2x00dev, EFUSE_DATA1, &reg);
++	*(u32 *)&rt2x00dev->eeprom[i + 4] = cpu_to_le32(reg);
++	rt2800_register_read_lock(rt2x00dev, EFUSE_DATA0, &reg);
++	*(u32 *)&rt2x00dev->eeprom[i + 6] = cpu_to_le32(reg);
+ 
+ 	mutex_unlock(&rt2x00dev->csr_mutex);
+ }
diff --git a/queue-2.6.33/series b/queue-2.6.33/series
index d5b6396..eaab303 100644
--- a/queue-2.6.33/series
+++ b/queue-2.6.33/series
@@ -24,5 +24,8 @@ qla2xxx-correct-inadvertent-loop-state-transitions-during-port-update-handling.p
 e1000-fix-driver-to-be-used-on-pa-risc-c8000-workstations.patch
 asoc-fix-reporting-of-partial-jack-updates.patch
 alsa-hda-cirrus-fix-surround-speaker-volume-control-name.patch
-mm-sync-vmalloc-address-space-page-tables-in-alloc_vm_area.patch
 drm-radeon-kms-fix-typo-in-r100_blit_copy.patch
+cifs-fix-possible-memory-corruption-in-cifsfindnext.patch
+b43-fix-beacon-problem-in-ad-hoc-mode.patch
+wireless-reset-beacon_found-while-updating-regulatory.patch
+rtl2800usb-fix-incorrect-storage-of-mac-address-on.patch
diff --git a/queue-2.6.33/wireless-reset-beacon_found-while-updating-regulatory.patch b/queue-2.6.33/wireless-reset-beacon_found-while-updating-regulatory.patch
new file mode 100644
index 0000000..8efb2ee
--- /dev/null
+++ b/queue-2.6.33/wireless-reset-beacon_found-while-updating-regulatory.patch
@@ -0,0 +1,39 @@
+From aa3d7eef398dd4f29045e9889b817d5161afe03e Mon Sep 17 00:00:00 2001
+From: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
+Date: Wed, 14 Sep 2011 14:28:17 +0530
+Subject: wireless: Reset beacon_found while updating regulatory
+
+From: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
+
+commit aa3d7eef398dd4f29045e9889b817d5161afe03e upstream.
+
+During the association, the regulatory is updated by country IE
+that reaps the previously found beacons. The impact is that
+after a STA disconnects *or* when for any reason a regulatory
+domain change happens the beacon hint flag is not cleared
+therefore preventing future beacon hints to be learned.
+This is important as a regulatory domain change or a restore
+of regulatory settings would set back the passive scan and no-ibss
+flags on the channel. This is the right place to do this given that
+it covers any regulatory domain change.
+
+Reviewed-by: Luis R. Rodriguez <mcgrof@gmail.com>
+Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
+Acked-by: Luis R. Rodriguez <mcgrof@qca.qualcomm.com>
+Signed-off-by: John W. Linville <linville@tuxdriver.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ net/wireless/reg.c |    1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/net/wireless/reg.c
++++ b/net/wireless/reg.c
+@@ -998,6 +998,7 @@ static void handle_channel(struct wiphy
+ 		return;
+ 	}
+ 
++	chan->beacon_found = false;
+ 	chan->flags = flags | bw_flags | map_regdom_flags(reg_rule->flags);
+ 	chan->max_antenna_gain = min(chan->orig_mag,
+ 		(int) MBI_TO_DBI(power_rule->max_antenna_gain));