[01/42] MAINTAINERS: stable: Update address

[01/42] MAINTAINERS: stable: Update address

[Greg KH]

3.1-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Joe Perches <joe@perches.com>

commit bc7a2f3abc636d7cab84258a48e77b08fb5fd3d6 upstream.

The old address hasn't worked since the great intrusion of August 2011.

Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 MAINTAINERS |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6129,7 +6129,7 @@ F:	arch/alpha/kernel/srm_env.c
 
 STABLE BRANCH
 M:	Greg Kroah-Hartman <greg@kroah.com>
-L:	stable@kernel.org
+L:	stable@vger.kernel.org
 S:	Maintained
 
 STAGING SUBSYSTEM

[02/42] Documentation: Update stable address

[Greg KH]

3.1-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Joe Perches <joe@perches.com>

commit 2eb7f204db51969ea558802a6601d79c2fb273b9 upstream.

The Japanese/Korean/Chinese versions still need updating.

Also, the stable kernel 2.6.x.y descriptions are out of date
and should be updated as well.

Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 Documentation/HOWTO                         |    4 ++--
 Documentation/development-process/5.Posting |    8 ++++----
 2 files changed, 6 insertions(+), 6 deletions(-)

--- a/Documentation/HOWTO
+++ b/Documentation/HOWTO
@@ -275,8 +275,8 @@ versions.
 If no 2.6.x.y kernel is available, then the highest numbered 2.6.x
 kernel is the current stable kernel.
 
-2.6.x.y are maintained by the "stable" team <stable@kernel.org>, and are
-released as needs dictate.  The normal release period is approximately 
+2.6.x.y are maintained by the "stable" team <stable@vger.kernel.org>, and
+are released as needs dictate.  The normal release period is approximately
 two weeks, but it can be longer if there are no pressing problems.  A
 security-related problem, instead, can cause a release to happen almost
 instantly.
--- a/Documentation/development-process/5.Posting
+++ b/Documentation/development-process/5.Posting
@@ -271,10 +271,10 @@ copies should go to:
    the linux-kernel list.
 
  - If you are fixing a bug, think about whether the fix should go into the
-   next stable update.  If so, stable@kernel.org should get a copy of the
-   patch.  Also add a "Cc: stable@kernel.org" to the tags within the patch
-   itself; that will cause the stable team to get a notification when your
-   fix goes into the mainline.
+   next stable update.  If so, stable@vger.kernel.org should get a copy of
+   the patch.  Also add a "Cc: stable@vger.kernel.org" to the tags within
+   the patch itself; that will cause the stable team to get a notification
+   when your fix goes into the mainline.
 
 When selecting recipients for a patch, it is good to have an idea of who
 you think will eventually accept the patch and get it merged.  While it

[03/42] firmware: Fix an oops on reading fw_priv->fw in sysfs loading file

[Greg KH]

3.1-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Neil Horman <nhorman@tuxdriver.com>

commit eea915bb0d1358755f151eaefb8208a2d5f3e10c upstream.

This oops was reported recently:
firmware_loading_store+0xf9/0x17b
dev_attr_store+0x20/0x22
sysfs_write_file+0x101/0x134
vfs_write+0xac/0xf3
sys_write+0x4a/0x6e
system_call_fastpath+0x16/0x1b

The complete backtrace was unfortunately not captured, but details can be found
here:
https://bugzilla.redhat.com/show_bug.cgi?id=769920

The cause is fairly clear.

Its caused by the fact that firmware_loading_store has a case 0 in its
switch statement that reads and writes the fw_priv->fw poniter without the
protection of the fw_lock mutex.  since there is a window between the time that
_request_firmware sets fw_priv->fw to NULL and the time the corresponding sysfs
file is unregistered, its possible for a user space application to race in, and
write a zero to the loading file, causing a NULL dereference in
firmware_loading_store.  Fix it by extending the protection of the fw_lock mutex
to cover all of the firware_loading_store function.

Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/base/firmware_class.c |   14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -226,13 +226,13 @@ static ssize_t firmware_loading_store(st
 	int loading = simple_strtol(buf, NULL, 10);
 	int i;
 
+	mutex_lock(&fw_lock);
+
+	if (!fw_priv->fw)
+		goto out;
+
 	switch (loading) {
 	case 1:
-		mutex_lock(&fw_lock);
-		if (!fw_priv->fw) {
-			mutex_unlock(&fw_lock);
-			break;
-		}
 		firmware_free_data(fw_priv->fw);
 		memset(fw_priv->fw, 0, sizeof(struct firmware));
 		/* If the pages are not owned by 'struct firmware' */
@@ -243,7 +243,6 @@ static ssize_t firmware_loading_store(st
 		fw_priv->page_array_size = 0;
 		fw_priv->nr_pages = 0;
 		set_bit(FW_STATUS_LOADING, &fw_priv->status);
-		mutex_unlock(&fw_lock);
 		break;
 	case 0:
 		if (test_bit(FW_STATUS_LOADING, &fw_priv->status)) {
@@ -274,7 +273,8 @@ static ssize_t firmware_loading_store(st
 		fw_load_abort(fw_priv);
 		break;
 	}
-
+out:
+	mutex_unlock(&fw_lock);
 	return count;
 }
 

[04/42] rt2800usb: Move ID out of unknown

[Greg KH]

3.1-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Larry Finger <Larry.Finger@lwfinger.net>

commit 3f81f8f1524ccca24df1029b0cf825ecef5e5cdc upstream.

Testing on the openSUSE wireless forum has shown that a Linksys
WUSB54GC v3 with USB ID 1737:0077 works with rt2800usb when the ID is
written to /sys/.../new_id. This ID can therefore be moved out of UNKNOWN.

Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/net/wireless/rt2x00/rt2800usb.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/net/wireless/rt2x00/rt2800usb.c
+++ b/drivers/net/wireless/rt2x00/rt2800usb.c
@@ -970,6 +970,7 @@ static struct usb_device_id rt2800usb_de
 	{ USB_DEVICE(0x13b1, 0x0031) },
 	{ USB_DEVICE(0x1737, 0x0070) },
 	{ USB_DEVICE(0x1737, 0x0071) },
+	{ USB_DEVICE(0x1737, 0x0077) },
 	/* Logitec */
 	{ USB_DEVICE(0x0789, 0x0162) },
 	{ USB_DEVICE(0x0789, 0x0163) },
@@ -1165,7 +1166,6 @@ static struct usb_device_id rt2800usb_de
 	{ USB_DEVICE(0x1740, 0x0605) },
 	{ USB_DEVICE(0x1740, 0x0615) },
 	/* Linksys */
-	{ USB_DEVICE(0x1737, 0x0077) },
 	{ USB_DEVICE(0x1737, 0x0078) },
 	/* Logitec */
 	{ USB_DEVICE(0x0789, 0x0168) },

[05/42] offb: Fix setting of the pseudo-palette for >8bpp

[Greg KH]

3.1-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Benjamin Herrenschmidt <benh@kernel.crashing.org>

commit 1bb0b7d21584b3f878e2bc880db62351ddee5185 upstream.

When using a >8bpp framebuffer, offb advertises truecolor, not directcolor,
and doesn't touch the color map even if it has a corresponding access method
for the real hardware.

Thus it needs to set the pseudo-palette with all 3 components of the color,
like other truecolor framebuffers, not with copies of the color index like
a directcolor framebuffer would do.

This went unnoticed for a long time because it's pretty hard to get offb
to kick in with anything but 8bpp (old BootX under MacOS will do that and
qemu does it).

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/video/offb.c |   44 ++++++++++++++++++++------------------------
 1 file changed, 20 insertions(+), 24 deletions(-)

--- a/drivers/video/offb.c
+++ b/drivers/video/offb.c
@@ -100,36 +100,32 @@ static int offb_setcolreg(u_int regno, u
 			  u_int transp, struct fb_info *info)
 {
 	struct offb_par *par = (struct offb_par *) info->par;
-	int i, depth;
-	u32 *pal = info->pseudo_palette;
 
-	depth = info->var.bits_per_pixel;
-	if (depth == 16)
-		depth = (info->var.green.length == 5) ? 15 : 16;
+	if (info->fix.visual == FB_VISUAL_TRUECOLOR) {
+		u32 *pal = info->pseudo_palette;
+		u32 cr = red >> (16 - info->var.red.length);
+		u32 cg = green >> (16 - info->var.green.length);
+		u32 cb = blue >> (16 - info->var.blue.length);
+		u32 value;
 
-	if (regno > 255 ||
-	    (depth == 16 && regno > 63) ||
-	    (depth == 15 && regno > 31))
-		return 1;
+		if (regno >= 16)
+			return -EINVAL;
 
-	if (regno < 16) {
-		switch (depth) {
-		case 15:
-			pal[regno] = (regno << 10) | (regno << 5) | regno;
-			break;
-		case 16:
-			pal[regno] = (regno << 11) | (regno << 5) | regno;
-			break;
-		case 24:
-			pal[regno] = (regno << 16) | (regno << 8) | regno;
-			break;
-		case 32:
-			i = (regno << 8) | regno;
-			pal[regno] = (i << 16) | i;
-			break;
+		value = (cr << info->var.red.offset) |
+			(cg << info->var.green.offset) |
+			(cb << info->var.blue.offset);
+		if (info->var.transp.length > 0) {
+			u32 mask = (1 << info->var.transp.length) - 1;
+			mask <<= info->var.transp.offset;
+			value |= mask;
 		}
+		pal[regno] = value;
+		return 0;
 	}
 
+	if (regno > 255)
+		return -EINVAL;
+
 	red >>= 8;
 	green >>= 8;
 	blue >>= 8;

[06/42] offb: Fix bug in calculating requested vram size

[Greg KH]

3.1-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Benjamin Herrenschmidt <benh@kernel.crashing.org>

commit c055fe0797b7bd8f6f21a13598a55a16d5c13ae7 upstream.

We used to try to request 8 times more vram than needed, which would
fail if the card has a too small BAR (observed with qemu & kvm).

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/video/offb.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/video/offb.c
+++ b/drivers/video/offb.c
@@ -377,7 +377,7 @@ static void __init offb_init_fb(const ch
 				int pitch, unsigned long address,
 				int foreign_endian, struct device_node *dp)
 {
-	unsigned long res_size = pitch * height * (depth + 7) / 8;
+	unsigned long res_size = pitch * height;
 	struct offb_par *par = &default_par;
 	unsigned long res_start = address;
 	struct fb_fix_screeninfo *fix;

[07/42] wl12xx: Validate FEM index from ini file and FW

[Greg KH]

3.1-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Pontus Fuchs <pontus.fuchs@gmail.com>

commit 2131d3c2f99b081806fdae7662c92fe6acda52af upstream.

Check for out of bound FEM index to prevent reading beyond ini
memory end.

Signed-off-by: Pontus Fuchs <pontus.fuchs@gmail.com>
Reviewed-by: Luciano Coelho <coelho@ti.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/net/wireless/wl12xx/cmd.c |   22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

--- a/drivers/net/wireless/wl12xx/cmd.c
+++ b/drivers/net/wireless/wl12xx/cmd.c
@@ -120,6 +120,11 @@ int wl1271_cmd_general_parms(struct wl12
 	if (!wl->nvs)
 		return -ENODEV;
 
+	if (gp->tx_bip_fem_manufacturer >= WL1271_INI_FEM_MODULE_COUNT) {
+		wl1271_warning("FEM index from INI out of bounds");
+		return -EINVAL;
+	}
+
 	gen_parms = kzalloc(sizeof(*gen_parms), GFP_KERNEL);
 	if (!gen_parms)
 		return -ENOMEM;
@@ -148,6 +153,12 @@ int wl1271_cmd_general_parms(struct wl12
 	gp->tx_bip_fem_manufacturer =
 		gen_parms->general_params.tx_bip_fem_manufacturer;
 
+	if (gp->tx_bip_fem_manufacturer >= WL1271_INI_FEM_MODULE_COUNT) {
+		wl1271_warning("FEM index from FW out of bounds");
+		ret = -EINVAL;
+		goto out;
+	}
+
 	wl1271_debug(DEBUG_CMD, "FEM autodetect: %s, manufacturer: %d\n",
 		     answer ? "auto" : "manual", gp->tx_bip_fem_manufacturer);
 
@@ -167,6 +178,11 @@ int wl128x_cmd_general_parms(struct wl12
 	if (!wl->nvs)
 		return -ENODEV;
 
+	if (gp->tx_bip_fem_manufacturer >= WL1271_INI_FEM_MODULE_COUNT) {
+		wl1271_warning("FEM index from ini out of bounds");
+		return -EINVAL;
+	}
+
 	gen_parms = kzalloc(sizeof(*gen_parms), GFP_KERNEL);
 	if (!gen_parms)
 		return -ENOMEM;
@@ -191,6 +207,12 @@ int wl128x_cmd_general_parms(struct wl12
 	gp->tx_bip_fem_manufacturer =
 		gen_parms->general_params.tx_bip_fem_manufacturer;
 
+	if (gp->tx_bip_fem_manufacturer >= WL1271_INI_FEM_MODULE_COUNT) {
+		wl1271_warning("FEM index from FW out of bounds");
+		ret = -EINVAL;
+		goto out;
+	}
+
 	wl1271_debug(DEBUG_CMD, "FEM autodetect: %s, manufacturer: %d\n",
 		     answer ? "auto" : "manual", gp->tx_bip_fem_manufacturer);
 

[08/42] wl12xx: Check buffer bound when processing nvs data

[Greg KH]

3.1-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Pontus Fuchs <pontus.fuchs@gmail.com>

commit f6efe96edd9c41c624c8f4ddbc4930c1a2d8f1e1 upstream.

An nvs with malformed contents could cause the processing of the
calibration data to read beyond the end of the buffer. Prevent this
from happening by adding bound checking.

Signed-off-by: Pontus Fuchs <pontus.fuchs@gmail.com>
Reviewed-by: Luciano Coelho <coelho@ti.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/net/wireless/wl12xx/boot.c |   14 ++++++++++++++
 1 file changed, 14 insertions(+)

--- a/drivers/net/wireless/wl12xx/boot.c
+++ b/drivers/net/wireless/wl12xx/boot.c
@@ -358,6 +358,9 @@ static int wl1271_boot_upload_nvs(struct
 		nvs_ptr += 3;
 
 		for (i = 0; i < burst_len; i++) {
+			if (nvs_ptr + 3 >= (u8 *) wl->nvs + nvs_len)
+				goto out_badnvs;
+
 			val = (nvs_ptr[0] | (nvs_ptr[1] << 8)
 			       | (nvs_ptr[2] << 16) | (nvs_ptr[3] << 24));
 
@@ -369,6 +372,9 @@ static int wl1271_boot_upload_nvs(struct
 			nvs_ptr += 4;
 			dest_addr += 4;
 		}
+
+		if (nvs_ptr >= (u8 *) wl->nvs + nvs_len)
+			goto out_badnvs;
 	}
 
 	/*
@@ -380,6 +386,10 @@ static int wl1271_boot_upload_nvs(struct
 	 */
 	nvs_ptr = (u8 *)wl->nvs +
 			ALIGN(nvs_ptr - (u8 *)wl->nvs + 7, 4);
+
+	if (nvs_ptr >= (u8 *) wl->nvs + nvs_len)
+		goto out_badnvs;
+
 	nvs_len -= nvs_ptr - (u8 *)wl->nvs;
 
 	/* Now we must set the partition correctly */
@@ -395,6 +405,10 @@ static int wl1271_boot_upload_nvs(struct
 
 	kfree(nvs_aligned);
 	return 0;
+
+out_badnvs:
+	wl1271_error("nvs data is malformed");
+	return -EILSEQ;
 }
 
 static void wl1271_boot_enable_interrupts(struct wl1271 *wl)

[09/42] wl12xx: Restore testmode ABI

[Greg KH]

3.1-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Pontus Fuchs <pontus.fuchs@gmail.com>

commit 3f1764945eaac532c20ab1f23afa352a40f797b2 upstream.

Commit 80900d0140a7648587982c8f299830e900e49165 accidently broke
the ABI for testmode commands. Restore the ABI again.

Signed-off-by: Pontus Fuchs <pontus.fuchs@gmail.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/net/wireless/wl12xx/testmode.c |    1 +
 1 file changed, 1 insertion(+)

--- a/drivers/net/wireless/wl12xx/testmode.c
+++ b/drivers/net/wireless/wl12xx/testmode.c
@@ -36,6 +36,7 @@ enum wl1271_tm_commands {
 	WL1271_TM_CMD_TEST,
 	WL1271_TM_CMD_INTERROGATE,
 	WL1271_TM_CMD_CONFIGURE,
+	WL1271_TM_CMD_NVS_PUSH,		/* Not in use. Keep to not break ABI */
 	WL1271_TM_CMD_SET_PLT_MODE,
 	WL1271_TM_CMD_RECOVER,
 

[10/42] powerpc/time: Handle wrapping of decrementer

[Greg KH]

3.1-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Anton Blanchard <anton@samba.org>

commit 37fb9a0231ee43d42d069863bdfd567fca2b61af upstream.

When re-enabling interrupts we have code to handle edge sensitive
decrementers by resetting the decrementer to 1 whenever it is negative.
If interrupts were disabled long enough that the decrementer wrapped to
positive we do nothing. This means interrupts can be delayed for a long
time until it finally goes negative again.

While we hope interrupts are never be disabled long enough for the
decrementer to go positive, we have a very good test team that can
drive any kernel into the ground. The softlockup data we get back
from these fails could be seconds in the future, completely missing
the cause of the lockup.

We already keep track of the timebase of the next event so use that
to work out if we should trigger a decrementer exception.

Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 arch/powerpc/include/asm/time.h |    2 ++
 arch/powerpc/kernel/irq.c       |   15 ++++++---------
 arch/powerpc/kernel/time.c      |    9 +++++++++
 3 files changed, 17 insertions(+), 9 deletions(-)

--- a/arch/powerpc/include/asm/time.h
+++ b/arch/powerpc/include/asm/time.h
@@ -219,5 +219,7 @@ DECLARE_PER_CPU(struct cpu_usage, cpu_us
 extern void secondary_cpu_time_init(void);
 extern void iSeries_time_init_early(void);
 
+extern void decrementer_check_overflow(void);
+
 #endif /* __KERNEL__ */
 #endif /* __POWERPC_TIME_H */
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -164,16 +164,13 @@ notrace void arch_local_irq_restore(unsi
 	 */
 	local_paca->hard_enabled = en;
 
-#ifndef CONFIG_BOOKE
-	/* On server, re-trigger the decrementer if it went negative since
-	 * some processors only trigger on edge transitions of the sign bit.
-	 *
-	 * BookE has a level sensitive decrementer (latches in TSR) so we
-	 * don't need that
+	/*
+	 * Trigger the decrementer if we have a pending event. Some processors
+	 * only trigger on edge transitions of the sign bit. We might also
+	 * have disabled interrupts long enough that the decrementer wrapped
+	 * to positive.
 	 */
-	if ((int)mfspr(SPRN_DEC) < 0)
-		mtspr(SPRN_DEC, 1);
-#endif /* CONFIG_BOOKE */
+	decrementer_check_overflow();
 
 	/*
 	 * Force the delivery of pending soft-disabled interrupts on PS3.
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@ -889,6 +889,15 @@ static void __init clocksource_init(void
 	       clock->name, clock->mult, clock->shift);
 }
 
+void decrementer_check_overflow(void)
+{
+	u64 now = get_tb_or_rtc();
+	struct decrementer_clock *decrementer = &__get_cpu_var(decrementers);
+
+	if (now >= decrementer->next_tb)
+		set_dec(1);
+}
+
 static int decrementer_set_next_event(unsigned long evt,
 				      struct clock_event_device *dev)
 {

[11/42] powerpc: Fix unpaired probe_hcall_entry and probe_hcall_exit

[Greg KH]

3.1-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Li Zhong <zhong@linux.vnet.ibm.com>

commit e4f387d8db3ba3c2dae4d8bdfe7bb5f4fe1bcb0d upstream.

Unpaired calling of probe_hcall_entry and probe_hcall_exit might happen
as following, which could cause incorrect preempt count.

__trace_hcall_entry => trace_hcall_entry -> probe_hcall_entry =>
get_cpu_var => preempt_disable

__trace_hcall_exit => trace_hcall_exit -> probe_hcall_exit =>
put_cpu_var => preempt_enable

where:
A => B and A -> B means A calls B, but
=> means A will call B through function name, and B will definitely be
called.
-> means A will call B through function pointer, so B might not be
called if the function pointer is not set.

So error happens when only one of probe_hcall_entry and probe_hcall_exit
get called during a hcall.

This patch tries to move the preempt count operations from
probe_hcall_entry and probe_hcall_exit to its callers.

Reported-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
Tested-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 arch/powerpc/platforms/pseries/hvCall_inst.c |    4 +---
 arch/powerpc/platforms/pseries/lpar.c        |    2 ++
 2 files changed, 3 insertions(+), 3 deletions(-)

--- a/arch/powerpc/platforms/pseries/hvCall_inst.c
+++ b/arch/powerpc/platforms/pseries/hvCall_inst.c
@@ -109,7 +109,7 @@ static void probe_hcall_entry(void *igno
 	if (opcode > MAX_HCALL_OPCODE)
 		return;
 
-	h = &get_cpu_var(hcall_stats)[opcode / 4];
+	h = &__get_cpu_var(hcall_stats)[opcode / 4];
 	h->tb_start = mftb();
 	h->purr_start = mfspr(SPRN_PURR);
 }
@@ -126,8 +126,6 @@ static void probe_hcall_exit(void *ignor
 	h->num_calls++;
 	h->tb_total += mftb() - h->tb_start;
 	h->purr_total += mfspr(SPRN_PURR) - h->purr_start;
-
-	put_cpu_var(hcall_stats);
 }
 
 static int __init hcall_inst_init(void)
--- a/arch/powerpc/platforms/pseries/lpar.c
+++ b/arch/powerpc/platforms/pseries/lpar.c
@@ -553,6 +553,7 @@ void __trace_hcall_entry(unsigned long o
 		goto out;
 
 	(*depth)++;
+	preempt_disable();
 	trace_hcall_entry(opcode, args);
 	(*depth)--;
 
@@ -575,6 +576,7 @@ void __trace_hcall_exit(long opcode, uns
 
 	(*depth)++;
 	trace_hcall_exit(opcode, retval, retbuf);
+	preempt_enable();
 	(*depth)--;
 
 out:

[12/42] asix: new device id

[Greg KH]

3.1-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Aurelien Jacobs <aurel@gnuage.org>

commit e8303a3b2196272c3eb994d0fd1a189a958a2bdd upstream.

Adds the device id needed for the USB Ethernet Adapter delivered by
ASUS with their Zenbook.

Signed-off-by: Aurelien Jacobs <aurel@gnuage.org>
Acked-by: Grant Grundler <grundler@chromium.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/net/usb/asix.c |    4 ++++
 1 file changed, 4 insertions(+)

--- a/drivers/net/usb/asix.c
+++ b/drivers/net/usb/asix.c
@@ -1560,6 +1560,10 @@ static const struct usb_device_id	produc
 	// ASIX 88772a
 	USB_DEVICE(0x0db0, 0xa877),
 	.driver_info = (unsigned long) &ax88772_info,
+}, {
+	// Asus USB Ethernet Adapter
+	USB_DEVICE (0x0b95, 0x7e2b),
+	.driver_info = (unsigned long) &ax88772_info,
 },
 	{ },		// END
 };

[13/42] IB/qib: Fix a possible data corruption when receiving packets

[Greg KH]

3.1-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Ram Vepa <ram.vepa@qlogic.com>

commit eddfb675256f49d14e8c5763098afe3eb2c93701 upstream.

Prevent a receive data corruption by ensuring that the write to update
the rcvhdrheadn register to generate an interrupt is at the very end
of the receive processing.

Signed-off-by: Ramkrishna Vepa <ram.vepa@qlogic.com>
Signed-off-by: Mike Marciniszyn <mike.marciniszyn@qlogic.com>
Signed-off-by: Roland Dreier <roland@purestorage.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/infiniband/hw/qib/qib_iba6120.c |    4 +++-
 drivers/infiniband/hw/qib/qib_iba7220.c |    4 +++-
 drivers/infiniband/hw/qib/qib_iba7322.c |    6 ++++--
 3 files changed, 10 insertions(+), 4 deletions(-)

--- a/drivers/infiniband/hw/qib/qib_iba6120.c
+++ b/drivers/infiniband/hw/qib/qib_iba6120.c
@@ -2076,9 +2076,11 @@ static void qib_6120_config_ctxts(struct
 static void qib_update_6120_usrhead(struct qib_ctxtdata *rcd, u64 hd,
 				    u32 updegr, u32 egrhd, u32 npkts)
 {
-	qib_write_ureg(rcd->dd, ur_rcvhdrhead, hd, rcd->ctxt);
 	if (updegr)
 		qib_write_ureg(rcd->dd, ur_rcvegrindexhead, egrhd, rcd->ctxt);
+	mmiowb();
+	qib_write_ureg(rcd->dd, ur_rcvhdrhead, hd, rcd->ctxt);
+	mmiowb();
 }
 
 static u32 qib_6120_hdrqempty(struct qib_ctxtdata *rcd)
--- a/drivers/infiniband/hw/qib/qib_iba7220.c
+++ b/drivers/infiniband/hw/qib/qib_iba7220.c
@@ -2724,9 +2724,11 @@ static int qib_7220_set_loopback(struct
 static void qib_update_7220_usrhead(struct qib_ctxtdata *rcd, u64 hd,
 				    u32 updegr, u32 egrhd, u32 npkts)
 {
-	qib_write_ureg(rcd->dd, ur_rcvhdrhead, hd, rcd->ctxt);
 	if (updegr)
 		qib_write_ureg(rcd->dd, ur_rcvegrindexhead, egrhd, rcd->ctxt);
+	mmiowb();
+	qib_write_ureg(rcd->dd, ur_rcvhdrhead, hd, rcd->ctxt);
+	mmiowb();
 }
 
 static u32 qib_7220_hdrqempty(struct qib_ctxtdata *rcd)
--- a/drivers/infiniband/hw/qib/qib_iba7322.c
+++ b/drivers/infiniband/hw/qib/qib_iba7322.c
@@ -4084,10 +4084,12 @@ static void qib_update_7322_usrhead(stru
 	 */
 	if (hd >> IBA7322_HDRHEAD_PKTINT_SHIFT)
 		adjust_rcv_timeout(rcd, npkts);
-	qib_write_ureg(rcd->dd, ur_rcvhdrhead, hd, rcd->ctxt);
-	qib_write_ureg(rcd->dd, ur_rcvhdrhead, hd, rcd->ctxt);
 	if (updegr)
 		qib_write_ureg(rcd->dd, ur_rcvegrindexhead, egrhd, rcd->ctxt);
+	mmiowb();
+	qib_write_ureg(rcd->dd, ur_rcvhdrhead, hd, rcd->ctxt);
+	qib_write_ureg(rcd->dd, ur_rcvhdrhead, hd, rcd->ctxt);
+	mmiowb();
 }
 
 static u32 qib_7322_hdrqempty(struct qib_ctxtdata *rcd)

[14/42] perf: Fix parsing of __print_flags() in TP_printk()

[Greg KH]

3.1-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Steven Rostedt <srostedt@redhat.com>

commit 49908a1b25d448d68fd26faca260e1850201575f upstream.

A update is made to the sched:sched_switch event that adds some
logic to the first parameter of the __print_flags() that shows the
state of tasks. This change cause perf to fail parsing the flags.

A simple fix is needed to have the parser be able to process ops
within the argument.

Reported-by: Andrew Vagin <avagin@openvz.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 tools/perf/util/trace-event-parse.c |    2 ++
 1 file changed, 2 insertions(+)

--- a/tools/perf/util/trace-event-parse.c
+++ b/tools/perf/util/trace-event-parse.c
@@ -1582,6 +1582,8 @@ process_symbols(struct event *event, str
 	field = malloc_or_die(sizeof(*field));
 
 	type = process_arg(event, field, &token);
+	while (type == EVENT_OP)
+		type = process_op(event, field, &token);
 	if (test_type_token(type, token, EVENT_DELIM, ","))
 		goto out_free;
 

[15/42] reiserfs: Fix quota mount option parsing

[Greg KH]

3.1-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Jan Kara <jack@suse.cz>

commit a06d789b424190e9f59da391681f908486db2554 upstream.

When jqfmt mount option is not specified on remount, we mistakenly clear
s_jquota_fmt value stored in superblock. Fix the problem.

CC: reiserfs-devel@vger.kernel.org
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 fs/reiserfs/super.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/fs/reiserfs/super.c
+++ b/fs/reiserfs/super.c
@@ -1164,7 +1164,8 @@ static void handle_quota_files(struct su
 			kfree(REISERFS_SB(s)->s_qf_names[i]);
 		REISERFS_SB(s)->s_qf_names[i] = qf_names[i];
 	}
-	REISERFS_SB(s)->s_jquota_fmt = *qfmt;
+	if (*qfmt)
+		REISERFS_SB(s)->s_jquota_fmt = *qfmt;
 }
 #endif
 

[16/42] reiserfs: Force inode evictions before umount to avoid crash

[Greg KH]

3.1-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Jeff Mahoney <jeffm@suse.com>

commit a9e36da655e54545c3289b2a0700b5c443de0edd upstream.

This patch fixes a crash in reiserfs_delete_xattrs during umount.

When shrink_dcache_for_umount clears the dcache from
generic_shutdown_super, delayed evictions are forced to disk. If an
evicted inode has extended attributes associated with it, it will
need to walk the xattr tree to locate and remove them.

But since shrink_dcache_for_umount will BUG if it encounters active
dentries, the xattr tree must be released before it's called or it will
crash during every umount.

This patch forces the evictions to occur before generic_shutdown_super
by calling shrink_dcache_sb first. The additional evictions caused
by the removal of each associated xattr file and dir will be automatically
handled as they're added to the LRU list.

CC: reiserfs-devel@vger.kernel.org
Signed-off-by: Jeff Mahoney <jeffm@suse.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 fs/reiserfs/super.c |   24 ++++++++++++++----------
 1 file changed, 14 insertions(+), 10 deletions(-)

--- a/fs/reiserfs/super.c
+++ b/fs/reiserfs/super.c
@@ -453,16 +453,20 @@ int remove_save_link(struct inode *inode
 static void reiserfs_kill_sb(struct super_block *s)
 {
 	if (REISERFS_SB(s)) {
-		if (REISERFS_SB(s)->xattr_root) {
-			d_invalidate(REISERFS_SB(s)->xattr_root);
-			dput(REISERFS_SB(s)->xattr_root);
-			REISERFS_SB(s)->xattr_root = NULL;
-		}
-		if (REISERFS_SB(s)->priv_root) {
-			d_invalidate(REISERFS_SB(s)->priv_root);
-			dput(REISERFS_SB(s)->priv_root);
-			REISERFS_SB(s)->priv_root = NULL;
-		}
+		/*
+		 * Force any pending inode evictions to occur now. Any
+		 * inodes to be removed that have extended attributes
+		 * associated with them need to clean them up before
+		 * we can release the extended attribute root dentries.
+		 * shrink_dcache_for_umount will BUG if we don't release
+		 * those before it's called so ->put_super is too late.
+		 */
+		shrink_dcache_sb(s);
+
+		dput(REISERFS_SB(s)->xattr_root);
+		REISERFS_SB(s)->xattr_root = NULL;
+		dput(REISERFS_SB(s)->priv_root);
+		REISERFS_SB(s)->priv_root = NULL;
 	}
 
 	kill_block_super(s);

[17/42] ext3: Dont warn from writepage when readonly inode is spotted after error

[Greg KH]

3.1-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Jan Kara <jack@suse.cz>

commit 33c104d415e92a51aaf638dc3d93920cfa601e5c upstream.

WARN_ON_ONCE(IS_RDONLY(inode)) tends to trip when filesystem hits error and is
remounted read-only. This unnecessarily scares users (well, they should be
scared because of filesystem error, but the stack trace distracts them from the
right source of their fear ;-). We could as well just remove the WARN_ON but
it's not hard to fix it to not trip on filesystem with errors and not use more
cycles in the common case so that's what we do.

Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 fs/ext3/inode.c |   24 +++++++++++++++++++++---
 1 file changed, 21 insertions(+), 3 deletions(-)

--- a/fs/ext3/inode.c
+++ b/fs/ext3/inode.c
@@ -1617,7 +1617,13 @@ static int ext3_ordered_writepage(struct
 	int err;
 
 	J_ASSERT(PageLocked(page));
-	WARN_ON_ONCE(IS_RDONLY(inode));
+	/*
+	 * We don't want to warn for emergency remount. The condition is
+	 * ordered to avoid dereferencing inode->i_sb in non-error case to
+	 * avoid slow-downs.
+	 */
+	WARN_ON_ONCE(IS_RDONLY(inode) &&
+		     !(EXT3_SB(inode->i_sb)->s_mount_state & EXT3_ERROR_FS));
 
 	/*
 	 * We give up here if we're reentered, because it might be for a
@@ -1692,7 +1698,13 @@ static int ext3_writeback_writepage(stru
 	int err;
 
 	J_ASSERT(PageLocked(page));
-	WARN_ON_ONCE(IS_RDONLY(inode));
+	/*
+	 * We don't want to warn for emergency remount. The condition is
+	 * ordered to avoid dereferencing inode->i_sb in non-error case to
+	 * avoid slow-downs.
+	 */
+	WARN_ON_ONCE(IS_RDONLY(inode) &&
+		     !(EXT3_SB(inode->i_sb)->s_mount_state & EXT3_ERROR_FS));
 
 	if (ext3_journal_current_handle())
 		goto out_fail;
@@ -1735,7 +1747,13 @@ static int ext3_journalled_writepage(str
 	int err;
 
 	J_ASSERT(PageLocked(page));
-	WARN_ON_ONCE(IS_RDONLY(inode));
+	/*
+	 * We don't want to warn for emergency remount. The condition is
+	 * ordered to avoid dereferencing inode->i_sb in non-error case to
+	 * avoid slow-downs.
+	 */
+	WARN_ON_ONCE(IS_RDONLY(inode) &&
+		     !(EXT3_SB(inode->i_sb)->s_mount_state & EXT3_ERROR_FS));
 
 	if (ext3_journal_current_handle())
 		goto no_write;

[18/42] USB: update documentation for usbmon

[Greg KH]

3.1-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Alan Stern <stern@rowland.harvard.edu>

commit d8cae98cddd286e38db1724dda1b0e7b467f9237 upstream.

The documentation for usbmon is out of date; the usbfs "devices" file
now exists in /sys/kernel/debug/usb rather than /proc/bus/usb.  This
patch (as1505) updates the documentation accordingly, and also
mentions that the necessary information can be found by running lsusb.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
CC: Pete Zaitcev <zaitcev@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 Documentation/usb/usbmon.txt |   14 +++++++++-----
 1 file changed, 9 insertions(+), 5 deletions(-)

--- a/Documentation/usb/usbmon.txt
+++ b/Documentation/usb/usbmon.txt
@@ -47,10 +47,11 @@ This allows to filter away annoying devi
 
 2. Find which bus connects to the desired device
 
-Run "cat /proc/bus/usb/devices", and find the T-line which corresponds to
-the device. Usually you do it by looking for the vendor string. If you have
-many similar devices, unplug one and compare two /proc/bus/usb/devices outputs.
-The T-line will have a bus number. Example:
+Run "cat /sys/kernel/debug/usb/devices", and find the T-line which corresponds
+to the device. Usually you do it by looking for the vendor string. If you have
+many similar devices, unplug one and compare the two
+/sys/kernel/debug/usb/devices outputs. The T-line will have a bus number.
+Example:
 
 T:  Bus=03 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=12  MxCh= 0
 D:  Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
@@ -58,7 +59,10 @@ P:  Vendor=0557 ProdID=2004 Rev= 1.00
 S:  Manufacturer=ATEN
 S:  Product=UC100KM V2.00
 
-Bus=03 means it's bus 3.
+"Bus=03" means it's bus 3. Alternatively, you can look at the output from
+"lsusb" and get the bus number from the appropriate line. Example:
+
+Bus 003 Device 002: ID 0557:2004 ATEN UC100KM V2.00
 
 3. Start 'cat'
 

[19/42] atmel_serial: fix spinlock lockup in RS485 code

[Greg KH]

3.1-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Claudio Scordino <claudio@evidence.eu.com>

commit dbf1115d3f8c7052788aa4e6e46abd27f3b3eeba upstream.

Patch to fix a spinlock lockup in the driver that sometimes happens when the
tasklet starts.

Signed-off-by: Claudio Scordino <claudio@evidence.eu.com>
Signed-off-by: Dave Bender <codehero@gmail.com>
Tested-by: Dave Bender <codehero@gmail.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Acked-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/tty/serial/atmel_serial.c |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

--- a/drivers/tty/serial/atmel_serial.c
+++ b/drivers/tty/serial/atmel_serial.c
@@ -199,8 +199,9 @@ void atmel_config_rs485(struct uart_port
 {
 	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
 	unsigned int mode;
+	unsigned long flags;
 
-	spin_lock(&port->lock);
+	spin_lock_irqsave(&port->lock, flags);
 
 	/* Disable interrupts */
 	UART_PUT_IDR(port, atmel_port->tx_done_mask);
@@ -231,7 +232,7 @@ void atmel_config_rs485(struct uart_port
 	/* Enable interrupts */
 	UART_PUT_IER(port, atmel_port->tx_done_mask);
 
-	spin_unlock(&port->lock);
+	spin_unlock_irqrestore(&port->lock, flags);
 
 }
 

[20/42] cgroup: fix to allow mounting a hierarchy by name

[Greg KH]

3.1-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Li Zefan <lizf@cn.fujitsu.com>

commit 0d19ea866562e46989412a0676412fa0983c9ce7 upstream.

If we mount a hierarchy with a specified name, the name is unique,
and we can use it to mount the hierarchy without specifying its
set of subsystem names. This feature is documented is
Documentation/cgroups/cgroups.txt section 2.3

Here's an example:

	# mount -t cgroup -o cpuset,name=myhier xxx /cgroup1
	# mount -t cgroup -o name=myhier xxx /cgroup2

But it was broken by commit 32a8cf235e2f192eb002755076994525cdbaa35a
(cgroup: make the mount options parsing more accurate)

This fixes the regression.

Signed-off-by: Li Zefan <lizf@cn.fujitsu.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 kernel/cgroup.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -1175,10 +1175,10 @@ static int parse_cgroupfs_options(char *
 
 	/*
 	 * If the 'all' option was specified select all the subsystems,
-	 * otherwise 'all, 'none' and a subsystem name options were not
-	 * specified, let's default to 'all'
+	 * otherwise if 'none', 'name=' and a subsystem name options
+	 * were not specified, let's default to 'all'
 	 */
-	if (all_ss || (!all_ss && !one_ss && !opts->none)) {
+	if (all_ss || (!one_ss && !opts->none && !opts->name)) {
 		for (i = 0; i < CGROUP_SUBSYS_COUNT; i++) {
 			struct cgroup_subsys *ss = subsys[i];
 			if (ss == NULL)

[21/42] udf: Fix deadlock when converting file from in-ICB one to normal one

[Greg KH]

3.1-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Jan Kara <jack@suse.cz>

commit d2eb8c359309ec45d6bf5b147303ab8e13be86ea upstream.

During BKL removal in 2.6.38, conversion of files from in-ICB format to normal
format got broken. We call ->writepage with i_data_sem held but udf_get_block()
also acquires i_data_sem thus creating A-A deadlock.

We fix the problem by dropping i_data_sem before calling ->writepage() which is
safe since i_mutex still protects us against any changes in the file. Also fix
pagelock - i_data_sem lock inversion in udf_expand_file_adinicb() by dropping
i_data_sem before calling find_or_create_page().

Reported-by: Matthias Matiak <netzpython@mail-on.us>
Tested-by: Matthias Matiak <netzpython@mail-on.us>
Reviewed-by: Namjae Jeon <linkinjeon@gmail.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 fs/udf/file.c  |    6 +++---
 fs/udf/inode.c |   21 ++++++++++++++++++---
 2 files changed, 21 insertions(+), 6 deletions(-)

--- a/fs/udf/file.c
+++ b/fs/udf/file.c
@@ -125,7 +125,6 @@ static ssize_t udf_file_aio_write(struct
 			err = udf_expand_file_adinicb(inode);
 			if (err) {
 				udf_debug("udf_expand_adinicb: err=%d\n", err);
-				up_write(&iinfo->i_data_sem);
 				return err;
 			}
 		} else {
@@ -133,9 +132,10 @@ static ssize_t udf_file_aio_write(struct
 				iinfo->i_lenAlloc = pos + count;
 			else
 				iinfo->i_lenAlloc = inode->i_size;
+			up_write(&iinfo->i_data_sem);
 		}
-	}
-	up_write(&iinfo->i_data_sem);
+	} else
+		up_write(&iinfo->i_data_sem);
 
 	retval = generic_file_aio_write(iocb, iov, nr_segs, ppos);
 	if (retval > 0)
--- a/fs/udf/inode.c
+++ b/fs/udf/inode.c
@@ -145,6 +145,12 @@ const struct address_space_operations ud
 	.bmap		= udf_bmap,
 };
 
+/*
+ * Expand file stored in ICB to a normal one-block-file
+ *
+ * This function requires i_data_sem for writing and releases it.
+ * This function requires i_mutex held
+ */
 int udf_expand_file_adinicb(struct inode *inode)
 {
 	struct page *page;
@@ -163,9 +169,15 @@ int udf_expand_file_adinicb(struct inode
 			iinfo->i_alloc_type = ICBTAG_FLAG_AD_LONG;
 		/* from now on we have normal address_space methods */
 		inode->i_data.a_ops = &udf_aops;
+		up_write(&iinfo->i_data_sem);
 		mark_inode_dirty(inode);
 		return 0;
 	}
+	/*
+	 * Release i_data_sem so that we can lock a page - page lock ranks
+	 * above i_data_sem. i_mutex still protects us against file changes.
+	 */
+	up_write(&iinfo->i_data_sem);
 
 	page = find_or_create_page(inode->i_mapping, 0, GFP_NOFS);
 	if (!page)
@@ -181,6 +193,7 @@ int udf_expand_file_adinicb(struct inode
 		SetPageUptodate(page);
 		kunmap(page);
 	}
+	down_write(&iinfo->i_data_sem);
 	memset(iinfo->i_ext.i_data + iinfo->i_lenEAttr, 0x00,
 	       iinfo->i_lenAlloc);
 	iinfo->i_lenAlloc = 0;
@@ -190,17 +203,20 @@ int udf_expand_file_adinicb(struct inode
 		iinfo->i_alloc_type = ICBTAG_FLAG_AD_LONG;
 	/* from now on we have normal address_space methods */
 	inode->i_data.a_ops = &udf_aops;
+	up_write(&iinfo->i_data_sem);
 	err = inode->i_data.a_ops->writepage(page, &udf_wbc);
 	if (err) {
 		/* Restore everything back so that we don't lose data... */
 		lock_page(page);
 		kaddr = kmap(page);
+		down_write(&iinfo->i_data_sem);
 		memcpy(iinfo->i_ext.i_data + iinfo->i_lenEAttr, kaddr,
 		       inode->i_size);
 		kunmap(page);
 		unlock_page(page);
 		iinfo->i_alloc_type = ICBTAG_FLAG_AD_IN_ICB;
 		inode->i_data.a_ops = &udf_adinicb_aops;
+		up_write(&iinfo->i_data_sem);
 	}
 	page_cache_release(page);
 	mark_inode_dirty(inode);
@@ -1105,10 +1121,9 @@ int udf_setsize(struct inode *inode, lof
 			if (bsize <
 			    (udf_file_entry_alloc_offset(inode) + newsize)) {
 				err = udf_expand_file_adinicb(inode);
-				if (err) {
-					up_write(&iinfo->i_data_sem);
+				if (err)
 					return err;
-				}
+				down_write(&iinfo->i_data_sem);
 			} else
 				iinfo->i_lenAlloc = newsize;
 		}

[22/42] drivers/usb/class/cdc-acm.c: clear dangling pointer

[Greg KH]

3.1-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Julia Lawall <julia@diku.dk>

commit e7c8e8605d0bafc705ff27f9da98a1668427cc0f upstream.

On some failures, the country_code field of an acm structure is freed
without freeing the acm structure itself.  Elsewhere, operations including
memcpy and kfree are performed on the country_code field.  The patch sets
the country_code field to NULL when it is freed, and likewise sets the
country_code_size field to 0.

Signed-off-by: Julia Lawall <julia@diku.dk>
Acked-by: Oliver Neukum <oneukum@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/usb/class/cdc-acm.c |    4 ++++
 1 file changed, 4 insertions(+)

--- a/drivers/usb/class/cdc-acm.c
+++ b/drivers/usb/class/cdc-acm.c
@@ -1183,6 +1183,8 @@ made_compressed_probe:
 		i = device_create_file(&intf->dev, &dev_attr_wCountryCodes);
 		if (i < 0) {
 			kfree(acm->country_codes);
+			acm->country_codes = NULL;
+			acm->country_code_size = 0;
 			goto skip_countries;
 		}
 
@@ -1191,6 +1193,8 @@ made_compressed_probe:
 		if (i < 0) {
 			device_remove_file(&intf->dev, &dev_attr_wCountryCodes);
 			kfree(acm->country_codes);
+			acm->country_codes = NULL;
+			acm->country_code_size = 0;
 			goto skip_countries;
 		}
 	}

[23/42] USB: isight: fix kernel bug when loading firmware

[Greg KH]

3.1-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Greg Kroah-Hartman <gregkh@suse.de>

commit 59bf5cf94f0fa3b08fb1258b52649077b7d0914d upstream.

We were sending data on the stack when uploading firmware, which causes
some machines fits, and is not allowed.  Fix this by using the buffer we
already had around for this very purpose.

Reported-by: Wouter M. Koolen <wmkoolen@cwi.nl>
Tested-by: Wouter M. Koolen <wmkoolen@cwi.nl>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/usb/misc/isight_firmware.c |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

--- a/drivers/usb/misc/isight_firmware.c
+++ b/drivers/usb/misc/isight_firmware.c
@@ -55,8 +55,9 @@ static int isight_firmware_load(struct u
 
 	ptr = firmware->data;
 
+	buf[0] = 0x01;
 	if (usb_control_msg
-	    (dev, usb_sndctrlpipe(dev, 0), 0xa0, 0x40, 0xe600, 0, "\1", 1,
+	    (dev, usb_sndctrlpipe(dev, 0), 0xa0, 0x40, 0xe600, 0, buf, 1,
 	     300) != 1) {
 		printk(KERN_ERR
 		       "Failed to initialise isight firmware loader\n");
@@ -100,8 +101,9 @@ static int isight_firmware_load(struct u
 		}
 	}
 
+	buf[0] = 0x00;
 	if (usb_control_msg
-	    (dev, usb_sndctrlpipe(dev, 0), 0xa0, 0x40, 0xe600, 0, "\0", 1,
+	    (dev, usb_sndctrlpipe(dev, 0), 0xa0, 0x40, 0xe600, 0, buf, 1,
 	     300) != 1) {
 		printk(KERN_ERR "isight firmware loading completion failed\n");
 		ret = -ENODEV;

[24/42] usb: usb-storage doesnt support dynamic id currently, the patch disables the feature to fix an oops

[Greg KH]

3.1-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Huajun Li <huajun.li.lee@gmail.com>

commit 1a3a026ba1b6bbfe0b7f79ab38cf991d691e7c9a upstream.

Echo vendor and product number of a non usb-storage device to
usb-storage driver's new_id, then plug in the device to host and you
will find following oops msg, the root cause is usb_stor_probe1()
refers invalid id entry if giving a dynamic id, so just disable the
feature.

[ 3105.018012] general protection fault: 0000 [#1] SMP DEBUG_PAGEALLOC
[ 3105.018062] CPU 0
[ 3105.018075] Modules linked in: usb_storage usb_libusual bluetooth
dm_crypt binfmt_misc snd_hda_codec_analog snd_hda_intel snd_hda_codec
snd_hwdep hp_wmi ppdev sparse_keymap snd_pcm snd_seq_midi snd_rawmidi
snd_seq_midi_event snd_seq snd_timer snd_seq_device psmouse snd
serio_raw tpm_infineon soundcore i915 snd_page_alloc tpm_tis
parport_pc tpm tpm_bios drm_kms_helper drm i2c_algo_bit video lp
parport usbhid hid sg sr_mod sd_mod ehci_hcd uhci_hcd usbcore e1000e
usb_common floppy
[ 3105.018408]
[ 3105.018419] Pid: 189, comm: khubd Tainted: G          I  3.2.0-rc7+
#29 Hewlett-Packard HP Compaq dc7800p Convertible Minitower/0AACh
[ 3105.018481] RIP: 0010:[<ffffffffa045830d>]  [<ffffffffa045830d>]
usb_stor_probe1+0x2fd/0xc20 [usb_storage]
[ 3105.018536] RSP: 0018:ffff880056a3d830  EFLAGS: 00010286
[ 3105.018562] RAX: ffff880065f4e648 RBX: ffff88006bb28000 RCX: 0000000000000000
[ 3105.018597] RDX: ffff88006f23c7b0 RSI: 0000000000000001 RDI: 0000000000000206
[ 3105.018632] RBP: ffff880056a3d900 R08: 0000000000000000 R09: ffff880067365000
[ 3105.018665] R10: 00000000000002ac R11: 0000000000000010 R12: ffff6000b41a7340
[ 3105.018698] R13: ffff880065f4ef60 R14: ffff88006bb28b88 R15: ffff88006f23d270
[ 3105.018733] FS:  0000000000000000(0000) GS:ffff88007a200000(0000)
knlGS:0000000000000000
[ 3105.018773] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 3105.018801] CR2: 00007fc99c8c4650 CR3: 0000000001e05000 CR4: 00000000000006f0
[ 3105.018835] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 3105.018870] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 3105.018906] Process khubd (pid: 189, threadinfo ffff880056a3c000,
task ffff88005677a400)
[ 3105.018945] Stack:
[ 3105.018959]  0000000000000000 0000000000000000 ffff880056a3d8d0
0000000000000002
[ 3105.019011]  0000000000000000 ffff880056a3d918 ffff880000000000
0000000000000002
[ 3105.019058]  ffff880056a3d8d0 0000000000000012 ffff880056a3d8d0
0000000000000006
[ 3105.019105] Call Trace:
[ 3105.019128]  [<ffffffffa0458cd4>] storage_probe+0xa4/0xe0 [usb_storage]
[ 3105.019173]  [<ffffffffa0097822>] usb_probe_interface+0x172/0x330 [usbcore]
[ 3105.019211]  [<ffffffff815fda67>] driver_probe_device+0x257/0x3b0
[ 3105.019243]  [<ffffffff815fdd43>] __device_attach+0x73/0x90
[ 3105.019272]  [<ffffffff815fdcd0>] ? __driver_attach+0x110/0x110
[ 3105.019303]  [<ffffffff815fb93c>] bus_for_each_drv+0x9c/0xf0
[ 3105.019334]  [<ffffffff815fd6c7>] device_attach+0xf7/0x120
[ 3105.019364]  [<ffffffff815fc905>] bus_probe_device+0x45/0x80
[ 3105.019396]  [<ffffffff815f98a6>] device_add+0x876/0x990
[ 3105.019434]  [<ffffffffa0094e42>] usb_set_configuration+0x822/0x9e0 [usbcore]
[ 3105.019479]  [<ffffffffa00a3492>] generic_probe+0x62/0xf0 [usbcore]
[ 3105.019518]  [<ffffffffa0097a46>] usb_probe_device+0x66/0xb0 [usbcore]
[ 3105.019555]  [<ffffffff815fda67>] driver_probe_device+0x257/0x3b0
[ 3105.019589]  [<ffffffff815fdd43>] __device_attach+0x73/0x90
[ 3105.019617]  [<ffffffff815fdcd0>] ? __driver_attach+0x110/0x110
[ 3105.019648]  [<ffffffff815fb93c>] bus_for_each_drv+0x9c/0xf0
[ 3105.019680]  [<ffffffff815fd6c7>] device_attach+0xf7/0x120
[ 3105.019709]  [<ffffffff815fc905>] bus_probe_device+0x45/0x80
[ 3105.021040] usb usb6: usb auto-resume
[ 3105.021045] usb usb6: wakeup_rh
[ 3105.024849]  [<ffffffff815f98a6>] device_add+0x876/0x990
[ 3105.025086]  [<ffffffffa0088987>] usb_new_device+0x1e7/0x2b0 [usbcore]
[ 3105.025086]  [<ffffffffa008a4d7>] hub_thread+0xb27/0x1ec0 [usbcore]
[ 3105.025086]  [<ffffffff810d5200>] ? wake_up_bit+0x50/0x50
[ 3105.025086]  [<ffffffffa00899b0>] ? usb_remote_wakeup+0xa0/0xa0 [usbcore]
[ 3105.025086]  [<ffffffff810d49b8>] kthread+0xd8/0xf0
[ 3105.025086]  [<ffffffff81939884>] kernel_thread_helper+0x4/0x10
[ 3105.025086]  [<ffffffff8192a8c0>] ? _raw_spin_unlock_irq+0x50/0x80
[ 3105.025086]  [<ffffffff8192b1b4>] ? retint_restore_args+0x13/0x13
[ 3105.025086]  [<ffffffff810d48e0>] ? __init_kthread_worker+0x80/0x80
[ 3105.025086]  [<ffffffff81939880>] ? gs_change+0x13/0x13
[ 3105.025086] Code: 00 48 83 05 cd ad 00 00 01 48 83 05 cd ad 00 00
01 4c 8b ab 30 0c 00 00 48 8b 50 08 48 83 c0 30 48 89 45 a0 4c 89 a3
40 0c 00 00 <41> 0f b6 44 24 10 48 89 55 a8 3c ff 0f 84 b8 04 00 00 48
83 05
[ 3105.025086] RIP  [<ffffffffa045830d>] usb_stor_probe1+0x2fd/0xc20
[usb_storage]
[ 3105.025086]  RSP <ffff880056a3d830>
[ 3105.060037] hub 6-0:1.0: hub_resume
[ 3105.062616] usb usb5: usb auto-resume
[ 3105.064317] ehci_hcd 0000:00:1d.7: resume root hub
[ 3105.094809] ---[ end trace a7919e7f17c0a727 ]---
[ 3105.130069] hub 5-0:1.0: hub_resume
[ 3105.132131] usb usb4: usb auto-resume
[ 3105.132136] usb usb4: wakeup_rh
[ 3105.180059] hub 4-0:1.0: hub_resume
[ 3106.290052] usb usb6: suspend_rh (auto-stop)
[ 3106.290077] usb usb4: suspend_rh (auto-stop)

Signed-off-by: Huajun Li <huajun.li.lee@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/usb/storage/usb.c |    1 +
 1 file changed, 1 insertion(+)

--- a/drivers/usb/storage/usb.c
+++ b/drivers/usb/storage/usb.c
@@ -1073,6 +1073,7 @@ static struct usb_driver usb_storage_dri
 	.id_table =	usb_storage_usb_ids,
 	.supports_autosuspend = 1,
 	.soft_unbind =	1,
+	.no_dynamic_id = 1,
 };
 
 static int __init usb_stor_init(void)

[25/42] USB: add quirk for another camera

[Greg KH]

3.1-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Oliver Neukum <oliver@neukum.org>

commit 35284b3d2f68a8a3703745e629999469f78386b5 upstream.

The Guillemot Webcam Hercules Dualpix Exchange camera
has been reported with a second ID.

Signed-off-by: Oliver Neukum <oneukum@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/usb/core/quirks.c |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -117,9 +117,12 @@ static const struct usb_device_id usb_qu
 	{ USB_DEVICE(0x06a3, 0x0006), .driver_info =
 			USB_QUIRK_CONFIG_INTF_STRINGS },
 
-	/* Guillemot Webcam Hercules Dualpix Exchange*/
+	/* Guillemot Webcam Hercules Dualpix Exchange (2nd ID) */
 	{ USB_DEVICE(0x06f8, 0x0804), .driver_info = USB_QUIRK_RESET_RESUME },
 
+	/* Guillemot Webcam Hercules Dualpix Exchange*/
+	{ USB_DEVICE(0x06f8, 0x3005), .driver_info = USB_QUIRK_RESET_RESUME },
+
 	/* M-Systems Flash Disk Pioneers */
 	{ USB_DEVICE(0x08ec, 0x1000), .driver_info = USB_QUIRK_RESET_RESUME },
 

[26/42] usb: musb: fix pm_runtime mismatch

[Greg KH]

3.1-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Felipe Contreras <felipe.contreras@gmail.com>

commit 772aed45b604c5ff171f0f12c12392d868333f79 upstream.

In musb_init_controller() there's a pm_runtime_put(), but there's no
pm_runtime_get(), which creates a mismatch that causes the driver to
sleep when it shouldn't.

This was introduced in 7acc619[1], but it wasn't triggered in my setup
until 18a2689[2] was merged to Linus' branch at point df0914[3]. IOW;
when PM is working as it was supposed to.

However, it seems most of the time this is used in a way that keeps the
counter above 0, so nobody noticed. Also, it seems to depend on the
configuration used in versions before 3.1, but not later (or in it).

I found the problem by loading isp1704_charger before any usb gadgets:
http://article.gmane.org/gmane.linux.kernel/1226122

All versions after 2.6.39 are affected.

[1] usb: musb: Idle path retention and offmode support for OMAP3
[2] OMAP2+: musb: hwmod adaptation for musb registration
[3] Merge branch 'omap-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6

Cc: Hema HK <hemahk@ti.com>
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>

---
 drivers/usb/musb/musb_core.c |    2 --
 1 file changed, 2 deletions(-)

--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -2013,8 +2013,6 @@ musb_init_controller(struct device *dev,
 	if (status < 0)
 		goto fail3;
 
-	pm_runtime_put(musb->controller);
-
 	status = musb_init_debugfs(musb);
 	if (status < 0)
 		goto fail4;

[27/42] USB: omninet: fix write_room

[Greg KH]

3.1-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Johan Hovold <jhovold@gmail.com>

commit 694c6301e515bad574af74b6552134c4d9dcb334 upstream.

Fix regression introduced by commit 507ca9bc047666 ([PATCH] USB: add
ability for usb-serial drivers to determine if their write urb is
currently being used.) which inverted the logic in write_room so that it
returns zero when the write urb is actually free.

Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/usb/serial/omninet.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/usb/serial/omninet.c
+++ b/drivers/usb/serial/omninet.c
@@ -315,7 +315,7 @@ static int omninet_write_room(struct tty
 	int room = 0; /* Default: no room */
 
 	/* FIXME: no consistent locking for write_urb_busy */
-	if (wport->write_urb_busy)
+	if (!wport->write_urb_busy)
 		room = wport->bulk_out_size - OMNINET_HEADERLEN;
 
 	dbg("%s - returns %d", __func__, room);

[28/42] USB: Add USB-ID for Multiplex RC serial adapter to cp210x.c

[Greg KH]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1085 bytes --]

3.1-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Malte Schröder <maltesch@gmx.de>

commit 08e87d0d773dc9ca5faf4c3306e238ed0ea129b0 upstream.

Hi, below patch adds the USB-ID of the serial adapters sold by
Multiplex RC (www.multiplex-rc.de).

Signed-off-by: Malte Schröder <maltesch@gmx.de>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/usb/serial/cp210x.c |    1 +
 1 file changed, 1 insertion(+)

--- a/drivers/usb/serial/cp210x.c
+++ b/drivers/usb/serial/cp210x.c
@@ -92,6 +92,7 @@ static const struct usb_device_id id_tab
 	{ USB_DEVICE(0x10C4, 0x818B) }, /* AVIT Research USB to TTL */
 	{ USB_DEVICE(0x10C4, 0x819F) }, /* MJS USB Toslink Switcher */
 	{ USB_DEVICE(0x10C4, 0x81A6) }, /* ThinkOptics WavIt */
+	{ USB_DEVICE(0x10C4, 0x81A9) }, /* Multiplex RC Interface */
 	{ USB_DEVICE(0x10C4, 0x81AC) }, /* MSD Dash Hawk */
 	{ USB_DEVICE(0x10C4, 0x81AD) }, /* INSYS USB Modem */
 	{ USB_DEVICE(0x10C4, 0x81C8) }, /* Lipowsky Industrie Elektronik GmbH, Baby-JTAG */

[29/42] usb: fix number of mapped SG DMA entries

[Greg KH]

3.1-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Clemens Ladisch <clemens@ladisch.de>

commit bc677d5b64644c399cd3db6a905453e611f402ab upstream.

Add a new field num_mapped_sgs to struct urb so that we have a place to
store the number of mapped entries and can also retain the original
value of entries in num_sgs.  Previously, usb_hcd_map_urb_for_dma()
would overwrite this with the number of mapped entries, which would
break dma_unmap_sg() because it requires the original number of entries.

This fixes warnings like the following when using USB storage devices:
 ------------[ cut here ]------------
 WARNING: at lib/dma-debug.c:902 check_unmap+0x4e4/0x695()
 ehci_hcd 0000:00:12.2: DMA-API: device driver frees DMA sg list with different entry count [map count=4] [unmap count=1]
 Modules linked in: ohci_hcd ehci_hcd
 Pid: 0, comm: kworker/0:1 Not tainted 3.2.0-rc2+ #319
 Call Trace:
  <IRQ>  [<ffffffff81036d3b>] warn_slowpath_common+0x80/0x98
  [<ffffffff81036de7>] warn_slowpath_fmt+0x41/0x43
  [<ffffffff811fa5ae>] check_unmap+0x4e4/0x695
  [<ffffffff8105e92c>] ? trace_hardirqs_off+0xd/0xf
  [<ffffffff8147208b>] ? _raw_spin_unlock_irqrestore+0x33/0x50
  [<ffffffff811fa84a>] debug_dma_unmap_sg+0xeb/0x117
  [<ffffffff8137b02f>] usb_hcd_unmap_urb_for_dma+0x71/0x188
  [<ffffffff8137b166>] unmap_urb_for_dma+0x20/0x22
  [<ffffffff8137b1c5>] usb_hcd_giveback_urb+0x5d/0xc0
  [<ffffffffa0000d02>] ehci_urb_done+0xf7/0x10c [ehci_hcd]
  [<ffffffffa0001140>] qh_completions+0x429/0x4bd [ehci_hcd]
  [<ffffffffa000340a>] ehci_work+0x95/0x9c0 [ehci_hcd]
  ...
 ---[ end trace f29ac88a5a48c580 ]---
 Mapped at:
  [<ffffffff811faac4>] debug_dma_map_sg+0x45/0x139
  [<ffffffff8137bc0b>] usb_hcd_map_urb_for_dma+0x22e/0x478
  [<ffffffff8137c494>] usb_hcd_submit_urb+0x63f/0x6fa
  [<ffffffff8137d01c>] usb_submit_urb+0x2c7/0x2de
  [<ffffffff8137dcd4>] usb_sg_wait+0x55/0x161

Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/usb/core/hcd.c       |    5 ++---
 drivers/usb/host/ehci-q.c    |    2 +-
 drivers/usb/host/uhci-q.c    |    2 +-
 drivers/usb/host/whci/qset.c |    4 ++--
 drivers/usb/host/xhci-ring.c |    4 ++--
 include/linux/usb.h          |    1 +
 6 files changed, 9 insertions(+), 9 deletions(-)

--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -1398,11 +1398,10 @@ int usb_hcd_map_urb_for_dma(struct usb_h
 					ret = -EAGAIN;
 				else
 					urb->transfer_flags |= URB_DMA_MAP_SG;
-				if (n != urb->num_sgs) {
-					urb->num_sgs = n;
+				urb->num_mapped_sgs = n;
+				if (n != urb->num_sgs)
 					urb->transfer_flags |=
 							URB_DMA_SG_COMBINED;
-				}
 			} else if (urb->sg) {
 				struct scatterlist *sg = urb->sg;
 				urb->transfer_dma = dma_map_page(
--- a/drivers/usb/host/ehci-q.c
+++ b/drivers/usb/host/ehci-q.c
@@ -649,7 +649,7 @@ qh_urb_transaction (
 	/*
 	 * data transfer stage:  buffer setup
 	 */
-	i = urb->num_sgs;
+	i = urb->num_mapped_sgs;
 	if (len > 0 && i > 0) {
 		sg = urb->sg;
 		buf = sg_dma_address(sg);
--- a/drivers/usb/host/uhci-q.c
+++ b/drivers/usb/host/uhci-q.c
@@ -943,7 +943,7 @@ static int uhci_submit_common(struct uhc
 	if (usb_pipein(urb->pipe))
 		status |= TD_CTRL_SPD;
 
-	i = urb->num_sgs;
+	i = urb->num_mapped_sgs;
 	if (len > 0 && i > 0) {
 		sg = urb->sg;
 		data = sg_dma_address(sg);
--- a/drivers/usb/host/whci/qset.c
+++ b/drivers/usb/host/whci/qset.c
@@ -443,7 +443,7 @@ static int qset_add_urb_sg(struct whc *w
 
 	remaining = urb->transfer_buffer_length;
 
-	for_each_sg(urb->sg, sg, urb->num_sgs, i) {
+	for_each_sg(urb->sg, sg, urb->num_mapped_sgs, i) {
 		dma_addr_t dma_addr;
 		size_t dma_remaining;
 		dma_addr_t sp, ep;
@@ -561,7 +561,7 @@ static int qset_add_urb_sg_linearize(str
 
 	remaining = urb->transfer_buffer_length;
 
-	for_each_sg(urb->sg, sg, urb->num_sgs, i) {
+	for_each_sg(urb->sg, sg, urb->num_mapped_sgs, i) {
 		size_t len;
 		size_t sg_remaining;
 		void *orig;
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -2562,7 +2562,7 @@ static unsigned int count_sg_trbs_needed
 	struct scatterlist *sg;
 
 	sg = NULL;
-	num_sgs = urb->num_sgs;
+	num_sgs = urb->num_mapped_sgs;
 	temp = urb->transfer_buffer_length;
 
 	xhci_dbg(xhci, "count sg list trbs: \n");
@@ -2746,7 +2746,7 @@ static int queue_bulk_sg_tx(struct xhci_
 		return -EINVAL;
 
 	num_trbs = count_sg_trbs_needed(xhci, urb);
-	num_sgs = urb->num_sgs;
+	num_sgs = urb->num_mapped_sgs;
 	total_packet_count = roundup(urb->transfer_buffer_length,
 			le16_to_cpu(urb->ep->desc.wMaxPacketSize));
 
--- a/include/linux/usb.h
+++ b/include/linux/usb.h
@@ -1202,6 +1202,7 @@ struct urb {
 	void *transfer_buffer;		/* (in) associated data buffer */
 	dma_addr_t transfer_dma;	/* (in) dma addr for transfer_buffer */
 	struct scatterlist *sg;		/* (in) scatter gather buffer list */
+	int num_mapped_sgs;		/* (internal) mapped sg entries */
 	int num_sgs;			/* (in) number of entries in the sg list */
 	u32 transfer_buffer_length;	/* (in) data buffer length */
 	u32 actual_length;		/* (return) actual transfer length */

[30/42] xhci: Properly handle COMP_2ND_BW_ERR

[Greg KH]

3.1-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Hans de Goede <hdegoede@redhat.com>

commit 71d85724bdd947a3b42a88d08af79f290a1a767b upstream.

I encountered a result of COMP_2ND_BW_ERR while improving how the pwc
webcam driver handles not having the full usb1 bandwidth available to
itself.

I created the following test setup, a NEC xhci controller with a
single TT USB 2 hub plugged into it, with a usb keyboard and a pwc webcam
plugged into the usb2 hub. This caused the following to show up in dmesg
when trying to stream from the pwc camera at its highest alt setting:

xhci_hcd 0000:01:00.0: ERROR: unexpected command completion code 0x23.
usb 6-2.1: Not enough bandwidth for altsetting 9

And usb_set_interface returned -EINVAL, which caused my pwc code to not
do the right thing as it expected -ENOSPC.

This patch makes the xhci driver properly handle COMP_2ND_BW_ERR and makes
usb_set_interface return -ENOSPC as expected.

This should be backported to stable kernels as old as 2.6.32.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/usb/host/xhci.c |    1 +
 drivers/usb/host/xhci.h |    1 -
 2 files changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -1568,6 +1568,7 @@ static int xhci_configure_endpoint_resul
 		/* FIXME: can we allocate more resources for the HC? */
 		break;
 	case COMP_BW_ERR:
+	case COMP_2ND_BW_ERR:
 		dev_warn(&udev->dev, "Not enough bandwidth "
 				"for new device state.\n");
 		ret = -ENOSPC;
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -900,7 +900,6 @@ struct xhci_transfer_event {
 /* Invalid Stream ID Error */
 #define COMP_STRID_ERR	34
 /* Secondary Bandwidth Error - may be returned by a Configure Endpoint cmd */
-/* FIXME - check for this */
 #define COMP_2ND_BW_ERR	35
 /* Split Transaction Error */
 #define	COMP_SPLIT_ERR	36

[31/42] USB: option: add id for 3G dongle Model VT1000 of Viettel

[Greg KH]

3.1-stable review patch.  If anyone has any objections, please let me know.

------------------

From: VU Tuan Duc <DucVT@viettel.com.vn>

commit 5b061623355d8f69327a24838b0aa05e435ae5d5 upstream.

Add VendorID/ProductID for USB 3G dongle Model VT1000 of Viettel.

Signed-off-by: VU Tuan Duc <ducvt@viettel.com.vn>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/usb/serial/option.c |    5 +++++
 1 file changed, 5 insertions(+)

--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -472,6 +472,10 @@ static void option_instat_callback(struc
 #define YUGA_PRODUCT_CLU528			0x260D
 #define YUGA_PRODUCT_CLU526			0x260F
 
+/* Viettel products */
+#define VIETTEL_VENDOR_ID			0x2262
+#define VIETTEL_PRODUCT_VT1000			0x0002
+
 /* some devices interfaces need special handling due to a number of reasons */
 enum option_blacklist_reason {
 		OPTION_BLACKLIST_NONE = 0,
@@ -1173,6 +1177,7 @@ static const struct usb_device_id option
 	{ USB_DEVICE(YUGA_VENDOR_ID, YUGA_PRODUCT_CLU516) },
 	{ USB_DEVICE(YUGA_VENDOR_ID, YUGA_PRODUCT_CLU528) },
 	{ USB_DEVICE(YUGA_VENDOR_ID, YUGA_PRODUCT_CLU526) },
+	{ USB_DEVICE_AND_INTERFACE_INFO(VIETTEL_VENDOR_ID, VIETTEL_PRODUCT_VT1000, 0xff, 0xff, 0xff) },
 	{ } /* Terminating entry */
 };
 MODULE_DEVICE_TABLE(usb, option_ids);

[32/42] usb: option: add ZD Incorporated HSPA modem

[Greg KH]

3.1-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Janne Snabb <snabb@epipe.com>

commit 3c8c9316710b83e906e425024153bf0929887b59 upstream.

Add support for Chinese Noname HSPA USB modem which is apparently
manufactured by a company called ZD Incorporated (based on texts in the
Windows drivers).

This product is available at least from Dealextreme (SKU 80032) and
possibly in India with name Olive V-MW250. It is based on Qualcomm
MSM6280 chip.

I needed to also add "options usb-storage quirks=0685:7000:i" in modprobe
configuration because udevd or the kernel keeps poking the embedded
fake-cd-rom which fails and causes the device to reset. There might be
a better way to accomplish the same. usb_modeswitch is not needed with
this device.

Signed-off-by: Janne Snabb <snabb@epipe.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/usb/serial/option.c |    5 +++++
 1 file changed, 5 insertions(+)

--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -476,6 +476,10 @@ static void option_instat_callback(struc
 #define VIETTEL_VENDOR_ID			0x2262
 #define VIETTEL_PRODUCT_VT1000			0x0002
 
+/* ZD Incorporated */
+#define ZD_VENDOR_ID				0x0685
+#define ZD_PRODUCT_7000				0x7000
+
 /* some devices interfaces need special handling due to a number of reasons */
 enum option_blacklist_reason {
 		OPTION_BLACKLIST_NONE = 0,
@@ -1178,6 +1182,7 @@ static const struct usb_device_id option
 	{ USB_DEVICE(YUGA_VENDOR_ID, YUGA_PRODUCT_CLU528) },
 	{ USB_DEVICE(YUGA_VENDOR_ID, YUGA_PRODUCT_CLU526) },
 	{ USB_DEVICE_AND_INTERFACE_INFO(VIETTEL_VENDOR_ID, VIETTEL_PRODUCT_VT1000, 0xff, 0xff, 0xff) },
+	{ USB_DEVICE_AND_INTERFACE_INFO(ZD_VENDOR_ID, ZD_PRODUCT_7000, 0xff, 0xff, 0xff) },
 	{ } /* Terminating entry */
 };
 MODULE_DEVICE_TABLE(usb, option_ids);

[33/42] usb: ch9: fix up MaxStreams helper

[Greg KH]

3.1-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Felipe Balbi <balbi@ti.com>

commit 18b7ede5f7ee2092aedcb578d3ac30bd5d4fc23c upstream.

[ removed the dwc3 portion of the patch as it didn't apply to
older kernels - gregkh]

According to USB 3.0 Specification Table 9-22, if
bmAttributes [4:0] are set to zero, it means "no
streams supported", but the way this helper was
defined on Linux, we will *always* have one stream
which might cause several problems.

For example on DWC3, we would tell the controller
endpoint has streams enabled and yet start transfers
with Stream ID set to 0, which would goof up the host
side.

While doing that, convert the macro to an inline
function due to the different checks we now need.

Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/usb/host/xhci.c |    3 +--
 include/linux/usb/ch9.h |   20 +++++++++++++++++++-
 2 files changed, 20 insertions(+), 3 deletions(-)

--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -2183,8 +2183,7 @@ static int xhci_calculate_streams_and_bi
 		if (ret < 0)
 			return ret;
 
-		max_streams = USB_SS_MAX_STREAMS(
-				eps[i]->ss_ep_comp.bmAttributes);
+		max_streams = usb_ss_max_streams(&eps[i]->ss_ep_comp);
 		if (max_streams < (*num_streams - 1)) {
 			xhci_dbg(xhci, "Ep 0x%x only supports %u stream IDs.\n",
 					eps[i]->desc.bEndpointAddress,
--- a/include/linux/usb/ch9.h
+++ b/include/linux/usb/ch9.h
@@ -583,8 +583,26 @@ struct usb_ss_ep_comp_descriptor {
 } __attribute__ ((packed));
 
 #define USB_DT_SS_EP_COMP_SIZE		6
+
 /* Bits 4:0 of bmAttributes if this is a bulk endpoint */
-#define USB_SS_MAX_STREAMS(p)		(1 << ((p) & 0x1f))
+static inline int
+usb_ss_max_streams(const struct usb_ss_ep_comp_descriptor *comp)
+{
+	int		max_streams;
+
+	if (!comp)
+		return 0;
+
+	max_streams = comp->bmAttributes & 0x1f;
+
+	if (!max_streams)
+		return 0;
+
+	max_streams = 1 << max_streams;
+
+	return max_streams;
+}
+
 /* Bits 1:0 of bmAttributes if this is an isoc endpoint */
 #define USB_SS_MULT(p)			(1 + ((p) & 0x3))
 

[34/42] OHCI: final fix for NVIDIA problems (I hope)

[Greg KH]

3.1-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Alan Stern <stern@rowland.harvard.edu>

commit c61875977458637226ab093a35d200f2d5789787 upstream.

Problems with NVIDIA's OHCI host controllers persist.  After looking
carefully through the spec, I finally realized that when a controller
is reset it then automatically goes into a SUSPEND state in which it
is completely quiescent (no DMA and no IRQs) and from which it will
not awaken until the system puts it into the OPERATIONAL state.

Therefore there's no need to worry about controllers being in the
RESET state for extended periods, or remaining in the OPERATIONAL
state during system shutdown.  The proper action for device
initialization is to put the controller into the RESET state (if it's
not there already) and then to issue a software reset.  Similarly, the
proper action for device shutdown is simply to do a software reset.

This patch (as1499) implements such an approach.  It simplifies
initialization and shutdown, and allows the NVIDIA shutdown-quirk code
to be removed.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Andre "Osku" Schmidt <andre.osku.schmidt@googlemail.com>
Tested-by: Arno Augustin <Arno.Augustin@web.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/usb/host/ohci-hcd.c   |   15 ++++-------
 drivers/usb/host/ohci-pci.c   |   26 --------------------
 drivers/usb/host/ohci.h       |    1 
 drivers/usb/host/pci-quirks.c |   54 ++++++++++++++++++------------------------
 4 files changed, 30 insertions(+), 66 deletions(-)

--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -389,17 +389,14 @@ ohci_shutdown (struct usb_hcd *hcd)
 	struct ohci_hcd *ohci;
 
 	ohci = hcd_to_ohci (hcd);
-	ohci_writel (ohci, OHCI_INTR_MIE, &ohci->regs->intrdisable);
-	ohci->hc_control = ohci_readl(ohci, &ohci->regs->control);
+	ohci_writel(ohci, (u32) ~0, &ohci->regs->intrdisable);
 
-	/* If the SHUTDOWN quirk is set, don't put the controller in RESET */
-	ohci->hc_control &= (ohci->flags & OHCI_QUIRK_SHUTDOWN ?
-			OHCI_CTRL_RWC | OHCI_CTRL_HCFS :
-			OHCI_CTRL_RWC);
-	ohci_writel(ohci, ohci->hc_control, &ohci->regs->control);
+	/* Software reset, after which the controller goes into SUSPEND */
+	ohci_writel(ohci, OHCI_HCR, &ohci->regs->cmdstatus);
+	ohci_readl(ohci, &ohci->regs->cmdstatus);	/* flush the writes */
+	udelay(10);
 
-	/* flush the writes */
-	(void) ohci_readl (ohci, &ohci->regs->control);
+	ohci_writel(ohci, ohci->fminterval, &ohci->regs->fminterval);
 }
 
 static int check_ed(struct ohci_hcd *ohci, struct ed *ed)
--- a/drivers/usb/host/ohci-pci.c
+++ b/drivers/usb/host/ohci-pci.c
@@ -175,28 +175,6 @@ static int ohci_quirk_amd700(struct usb_
 	return 0;
 }
 
-/* nVidia controllers continue to drive Reset signalling on the bus
- * even after system shutdown, wasting power.  This flag tells the
- * shutdown routine to leave the controller OPERATIONAL instead of RESET.
- */
-static int ohci_quirk_nvidia_shutdown(struct usb_hcd *hcd)
-{
-	struct pci_dev *pdev = to_pci_dev(hcd->self.controller);
-	struct ohci_hcd	*ohci = hcd_to_ohci(hcd);
-
-	/* Evidently nVidia fixed their later hardware; this is a guess at
-	 * the changeover point.
-	 */
-#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP51_USB		0x026d
-
-	if (pdev->device < PCI_DEVICE_ID_NVIDIA_NFORCE_MCP51_USB) {
-		ohci->flags |= OHCI_QUIRK_SHUTDOWN;
-		ohci_dbg(ohci, "enabled nVidia shutdown quirk\n");
-	}
-
-	return 0;
-}
-
 static void sb800_prefetch(struct ohci_hcd *ohci, int on)
 {
 	struct pci_dev *pdev;
@@ -260,10 +238,6 @@ static const struct pci_device_id ohci_p
 		PCI_DEVICE(PCI_VENDOR_ID_ATI, 0x4399),
 		.driver_data = (unsigned long)ohci_quirk_amd700,
 	},
-	{
-		PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, PCI_ANY_ID),
-		.driver_data = (unsigned long) ohci_quirk_nvidia_shutdown,
-	},
 
 	/* FIXME for some of the early AMD 760 southbridges, OHCI
 	 * won't work at all.  blacklist them.
--- a/drivers/usb/host/ohci.h
+++ b/drivers/usb/host/ohci.h
@@ -403,7 +403,6 @@ struct ohci_hcd {
 #define	OHCI_QUIRK_HUB_POWER	0x100			/* distrust firmware power/oc setup */
 #define	OHCI_QUIRK_AMD_PLL	0x200			/* AMD PLL quirk*/
 #define	OHCI_QUIRK_AMD_PREFETCH	0x400			/* pre-fetch for ISO transfer */
-#define	OHCI_QUIRK_SHUTDOWN	0x800			/* nVidia power bug */
 	// there are also chip quirks/bugs in init logic
 
 	struct work_struct	nec_work;	/* Worker for NEC quirk */
--- a/drivers/usb/host/pci-quirks.c
+++ b/drivers/usb/host/pci-quirks.c
@@ -36,6 +36,7 @@
 #define OHCI_INTRENABLE		0x10
 #define OHCI_INTRDISABLE	0x14
 #define OHCI_FMINTERVAL		0x34
+#define OHCI_HCFS		(3 << 6)	/* hc functional state */
 #define OHCI_HCR		(1 << 0)	/* host controller reset */
 #define OHCI_OCR		(1 << 3)	/* ownership change request */
 #define OHCI_CTRL_RWC		(1 << 9)	/* remote wakeup connected */
@@ -465,6 +466,8 @@ static void __devinit quirk_usb_handoff_
 {
 	void __iomem *base;
 	u32 control;
+	u32 fminterval;
+	int cnt;
 
 	if (!mmio_resource_enabled(pdev, 0))
 		return;
@@ -497,41 +500,32 @@ static void __devinit quirk_usb_handoff_
 	}
 #endif
 
-	/* reset controller, preserving RWC (and possibly IR) */
-	writel(control & OHCI_CTRL_MASK, base + OHCI_CONTROL);
-	readl(base + OHCI_CONTROL);
-
-	/* Some NVIDIA controllers stop working if kept in RESET for too long */
-	if (pdev->vendor == PCI_VENDOR_ID_NVIDIA) {
-		u32 fminterval;
-		int cnt;
+	/* disable interrupts */
+	writel((u32) ~0, base + OHCI_INTRDISABLE);
 
-		/* drive reset for at least 50 ms (7.1.7.5) */
-		msleep(50);
-
-		/* software reset of the controller, preserving HcFmInterval */
-		fminterval = readl(base + OHCI_FMINTERVAL);
-		writel(OHCI_HCR, base + OHCI_CMDSTATUS);
-
-		/* reset requires max 10 us delay */
-		for (cnt = 30; cnt > 0; --cnt) {	/* ... allow extra time */
-			if ((readl(base + OHCI_CMDSTATUS) & OHCI_HCR) == 0)
-				break;
-			udelay(1);
-		}
-		writel(fminterval, base + OHCI_FMINTERVAL);
+	/* Reset the USB bus, if the controller isn't already in RESET */
+	if (control & OHCI_HCFS) {
+		/* Go into RESET, preserving RWC (and possibly IR) */
+		writel(control & OHCI_CTRL_MASK, base + OHCI_CONTROL);
+		readl(base + OHCI_CONTROL);
 
-		/* Now we're in the SUSPEND state with all devices reset
-		 * and wakeups and interrupts disabled
-		 */
+		/* drive bus reset for at least 50 ms (7.1.7.5) */
+		msleep(50);
 	}
 
-	/*
-	 * disable interrupts
-	 */
-	writel(~(u32)0, base + OHCI_INTRDISABLE);
-	writel(~(u32)0, base + OHCI_INTRSTATUS);
+	/* software reset of the controller, preserving HcFmInterval */
+	fminterval = readl(base + OHCI_FMINTERVAL);
+	writel(OHCI_HCR, base + OHCI_CMDSTATUS);
+
+	/* reset requires max 10 us delay */
+	for (cnt = 30; cnt > 0; --cnt) {	/* ... allow extra time */
+		if ((readl(base + OHCI_CMDSTATUS) & OHCI_HCR) == 0)
+			break;
+		udelay(1);
+	}
+	writel(fminterval, base + OHCI_FMINTERVAL);
 
+	/* Now the controller is safely in SUSPEND and nothing can wake it up */
 	iounmap(base);
 }
 

[35/42] igmp: Avoid zero delay when receiving odd mixture of IGMP queries

[Greg KH]

3.1-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Ben Hutchings <ben@decadent.org.uk>

commit a8c1f65c79cbbb2f7da782d4c9d15639a9b94b27 upstream.

Commit 5b7c84066733c5dfb0e4016d939757b38de189e4 ('ipv4: correct IGMP
behavior on v3 query during v2-compatibility mode') added yet another
case for query parsing, which can result in max_delay = 0.  Substitute
a value of 1, as in the usual v3 case.

Reported-by: Simon McVittie <smcv@debian.org>
References: http://bugs.debian.org/654876
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>

---
 net/ipv4/igmp.c |    2 ++
 1 file changed, 2 insertions(+)

--- a/net/ipv4/igmp.c
+++ b/net/ipv4/igmp.c
@@ -875,6 +875,8 @@ static void igmp_heard_query(struct in_d
 		 * to be intended in a v3 query.
 		 */
 		max_delay = IGMPV3_MRC(ih3->code)*(HZ/IGMP_TIMER_SCALE);
+		if (!max_delay)
+			max_delay = 1;	/* can't mod w/ 0 */
 	} else { /* v3 */
 		if (!pskb_may_pull(skb, sizeof(struct igmpv3_query)))
 			return;

[36/42] asix: fix infinite loop in rx_fixup()

[Greg KH]

3.1-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Aurelien Jacobs <aurel@gnuage.org>

commit 6c15d74defd38e7e7f8805392578b7a1d508097e upstream.

At this point if skb->len happens to be 2, the subsequant skb_pull(skb, 4)
call won't work and the skb->len won't be decreased and won't ever reach 0,
resulting in an infinite loop.

With an ASIX 88772 under heavy load, without this patch, rx_fixup() reaches
an infinite loop in less than a minute. With this patch applied,
no infinite loop even after hours of heavy load.

Signed-off-by: Aurelien Jacobs <aurel@gnuage.org>
Cc: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
Signed-off-by: David S. Miller <davem@davemloft.net>

---
 drivers/net/usb/asix.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/net/usb/asix.c
+++ b/drivers/net/usb/asix.c
@@ -371,7 +371,7 @@ static int asix_rx_fixup(struct usbnet *
 
 		skb_pull(skb, (size + 1) & 0xfffe);
 
-		if (skb->len == 0)
+		if (skb->len < sizeof(header))
 			break;
 
 		head = (u8 *) skb->data;

[37/42] bonding: fix error handling if slave is busy (v2)

[Greg KH]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1834 bytes --]

3.1-stable review patch.  If anyone has any objections, please let me know.

------------------

From: stephen hemminger <shemminger@vyatta.com>

commit f7d9821a6a9c83450ac35e76d3709e32fd38b76f upstream.

If slave device already has a receive handler registered, then the
error unwind of bonding device enslave function is broken.

The following will leave a pointer to freed memory in the slave
device list, causing a later kernel panic.
# modprobe dummy
# ip li add dummy0-1 link dummy0 type macvlan
# modprobe bonding
# echo +dummy0 >/sys/class/net/bond0/bonding/slaves

The fix is to detach the slave (which removes it from the list)
in the unwind path.

Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Reviewed-by: Nicolas de Pesloüan <nicolas.2p.debian@free.fr>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/net/bonding/bond_main.c |    9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -1839,7 +1839,7 @@ int bond_enslave(struct net_device *bond
 				 "but new slave device does not support netpoll.\n",
 				 bond_dev->name);
 			res = -EBUSY;
-			goto err_close;
+			goto err_detach;
 		}
 	}
 #endif
@@ -1848,7 +1848,7 @@ int bond_enslave(struct net_device *bond
 
 	res = bond_create_slave_symlinks(bond_dev, slave_dev);
 	if (res)
-		goto err_close;
+		goto err_detach;
 
 	res = netdev_rx_handler_register(slave_dev, bond_handle_frame,
 					 new_slave);
@@ -1869,6 +1869,11 @@ int bond_enslave(struct net_device *bond
 err_dest_symlinks:
 	bond_destroy_slave_symlinks(bond_dev, slave_dev);
 
+err_detach:
+	write_lock_bh(&bond->lock);
+	bond_detach_slave(bond, new_slave);
+	write_unlock_bh(&bond->lock);
+
 err_close:
 	dev_close(slave_dev);
 

[38/42] PM / Sleep: Fix race between CPU hotplug and freezer

[Greg KH]

3.1-stable review patch.  If anyone has any objections, please let me know.

------------------

From: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>

commit 79cfbdfa87e84992d509e6c1648a18e1d7e68c20 upstream.

The CPU hotplug notifications sent out by the _cpu_up() and _cpu_down()
functions depend on the value of the 'tasks_frozen' argument passed to them
(which indicates whether tasks have been frozen or not).
(Examples for such CPU hotplug notifications: CPU_ONLINE, CPU_ONLINE_FROZEN,
CPU_DEAD, CPU_DEAD_FROZEN).

Thus, it is essential that while the callbacks for those notifications are
running, the state of the system with respect to the tasks being frozen or
not remains unchanged, *throughout that duration*. Hence there is a need for
synchronizing the CPU hotplug code with the freezer subsystem.

Since the freezer is involved only in the Suspend/Hibernate call paths, this
patch hooks the CPU hotplug code to the suspend/hibernate notifiers
PM_[SUSPEND|HIBERNATE]_PREPARE and PM_POST_[SUSPEND|HIBERNATE] to prevent
the race between CPU hotplug and freezer, thus ensuring that CPU hotplug
notifications will always be run with the state of the system really being
what the notifications indicate, _throughout_ their execution time.

Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 kernel/cpu.c |   74 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 74 insertions(+)

--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -15,6 +15,7 @@
 #include <linux/stop_machine.h>
 #include <linux/mutex.h>
 #include <linux/gfp.h>
+#include <linux/suspend.h>
 
 #ifdef CONFIG_SMP
 /* Serializes the updates to cpu_online_mask, cpu_present_mask */
@@ -476,6 +477,79 @@ static int alloc_frozen_cpus(void)
 	return 0;
 }
 core_initcall(alloc_frozen_cpus);
+
+/*
+ * Prevent regular CPU hotplug from racing with the freezer, by disabling CPU
+ * hotplug when tasks are about to be frozen. Also, don't allow the freezer
+ * to continue until any currently running CPU hotplug operation gets
+ * completed.
+ * To modify the 'cpu_hotplug_disabled' flag, we need to acquire the
+ * 'cpu_add_remove_lock'. And this same lock is also taken by the regular
+ * CPU hotplug path and released only after it is complete. Thus, we
+ * (and hence the freezer) will block here until any currently running CPU
+ * hotplug operation gets completed.
+ */
+void cpu_hotplug_disable_before_freeze(void)
+{
+	cpu_maps_update_begin();
+	cpu_hotplug_disabled = 1;
+	cpu_maps_update_done();
+}
+
+
+/*
+ * When tasks have been thawed, re-enable regular CPU hotplug (which had been
+ * disabled while beginning to freeze tasks).
+ */
+void cpu_hotplug_enable_after_thaw(void)
+{
+	cpu_maps_update_begin();
+	cpu_hotplug_disabled = 0;
+	cpu_maps_update_done();
+}
+
+/*
+ * When callbacks for CPU hotplug notifications are being executed, we must
+ * ensure that the state of the system with respect to the tasks being frozen
+ * or not, as reported by the notification, remains unchanged *throughout the
+ * duration* of the execution of the callbacks.
+ * Hence we need to prevent the freezer from racing with regular CPU hotplug.
+ *
+ * This synchronization is implemented by mutually excluding regular CPU
+ * hotplug and Suspend/Hibernate call paths by hooking onto the Suspend/
+ * Hibernate notifications.
+ */
+static int
+cpu_hotplug_pm_callback(struct notifier_block *nb,
+			unsigned long action, void *ptr)
+{
+	switch (action) {
+
+	case PM_SUSPEND_PREPARE:
+	case PM_HIBERNATION_PREPARE:
+		cpu_hotplug_disable_before_freeze();
+		break;
+
+	case PM_POST_SUSPEND:
+	case PM_POST_HIBERNATION:
+		cpu_hotplug_enable_after_thaw();
+		break;
+
+	default:
+		return NOTIFY_DONE;
+	}
+
+	return NOTIFY_OK;
+}
+
+
+int cpu_hotplug_pm_sync_init(void)
+{
+	pm_notifier(cpu_hotplug_pm_callback, 0);
+	return 0;
+}
+core_initcall(cpu_hotplug_pm_sync_init);
+
 #endif /* CONFIG_PM_SLEEP_SMP */
 
 /**

[39/42] SCSI: mpt2sas: Added missing mpt2sas_base_detach call from scsih_remove context

[Greg KH]

3.1-stable review patch.  If anyone has any objections, please let me know.

------------------

From: "kashyap.desai@lsi.com" <kashyap.desai@lsi.com>

commit 9ae89b0296e275d5a556068b40b7c2557a556a85 upstream.

mpt2sas_base_detach() call was removed from _scsih_remove() while
doing some code shuffling.  Mainly when we work on adding code for
scsih_shutdown().  I have added back mpt2sas_base_detach() which will
get callled from _scsih_remove().

Signed-off-by: Kashyap Desai <kashyap.desai@lsi.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>

---
 drivers/scsi/mpt2sas/mpt2sas_scsih.c |    1 +
 1 file changed, 1 insertion(+)

--- a/drivers/scsi/mpt2sas/mpt2sas_scsih.c
+++ b/drivers/scsi/mpt2sas/mpt2sas_scsih.c
@@ -7354,6 +7354,7 @@ _scsih_remove(struct pci_dev *pdev)
 	}
 
 	sas_remove_host(shost);
+	mpt2sas_base_detach(ioc);
 	list_del(&ioc->list);
 	scsi_remove_host(shost);
 	scsi_host_put(shost);

[40/42] usb: cdc-acm: Fix acm_tty_hangup() vs. acm_tty_close() race

[Greg KH]

3.1-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Thilo-Alexander Ginkel <thilo@ginkel.com>

[Not upstream s it was fixed differently there for 3.3 with a much more
"intrusive" rework of the driver - gregkh]

There is a race condition involving acm_tty_hangup() and acm_tty_close()
where hangup() would attempt to access tty->driver_data without proper
locking and NULL checking after close() has potentially already set it
to NULL.  One possibility to (sporadically) trigger this behavior is to
perform a suspend/resume cycle with a running WWAN data connection.

This patch addresses the issue by introducing a NULL check for
tty->driver_data in acm_tty_hangup() protected by open_mutex and exiting
gracefully when hangup() is invoked on a device that has already been
closed.

Signed-off-by: Thilo-Alexander Ginkel <thilo@ginkel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 drivers/usb/class/cdc-acm.c |   12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

--- a/drivers/usb/class/cdc-acm.c
+++ b/drivers/usb/class/cdc-acm.c
@@ -554,10 +554,18 @@ static void acm_port_down(struct acm *ac
 
 static void acm_tty_hangup(struct tty_struct *tty)
 {
-	struct acm *acm = tty->driver_data;
-	tty_port_hangup(&acm->port);
+	struct acm *acm;
+
 	mutex_lock(&open_mutex);
+	acm = tty->driver_data;
+
+	if (!acm)
+		goto out;
+
+	tty_port_hangup(&acm->port);
 	acm_port_down(acm);
+
+out:
 	mutex_unlock(&open_mutex);
 }
 

[41/42] xfs: validate acl count

[Greg KH]

3.1-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Christoph Hellwig <hch@infradead.org>

commit fa8b18edd752a8b4e9d1ee2cd615b82c93cf8bba upstream.

This prevents in-memory corruption and possible panics if the on-disk
ACL is badly corrupted.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Ben Myers <bpm@sgi.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 fs/xfs/xfs_acl.c |    2 ++
 1 file changed, 2 insertions(+)

--- a/fs/xfs/xfs_acl.c
+++ b/fs/xfs/xfs_acl.c
@@ -42,6 +42,8 @@ xfs_acl_from_disk(struct xfs_acl *aclp)
 	int count, i;
 
 	count = be32_to_cpu(aclp->acl_cnt);
+	if (count > XFS_ACL_MAX_ENTRIES)
+		return ERR_PTR(-EFSCORRUPTED);
 
 	acl = posix_acl_alloc(count, GFP_KERNEL);
 	if (!acl)

[42/42] xfs: fix acl count validation in xfs_acl_from_disk()

[Greg KH]

3.1-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Xi Wang <xi.wang@gmail.com>

commit 093019cf1b18dd31b2c3b77acce4e000e2cbc9ce upstream.

Commit fa8b18ed didn't prevent the integer overflow and possible
memory corruption.  "count" can go negative and bypass the check.

Signed-off-by: Xi Wang <xi.wang@gmail.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Ben Myers <bpm@sgi.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 fs/xfs/xfs_acl.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/fs/xfs/xfs_acl.c
+++ b/fs/xfs/xfs_acl.c
@@ -39,7 +39,7 @@ xfs_acl_from_disk(struct xfs_acl *aclp)
 	struct posix_acl_entry *acl_e;
 	struct posix_acl *acl;
 	struct xfs_acl_entry *ace;
-	int count, i;
+	unsigned int count, i;
 
 	count = be32_to_cpu(aclp->acl_cnt);
 	if (count > XFS_ACL_MAX_ENTRIES)

[00/42] 3.1.9-stable review

[Greg KH]

**************************************************************************
* Note, this is most likely the LAST 3.1.y kernel released.  Please move *
* now to the 3.2 kernel series.  You have been warned.                   *
**************************************************************************

This is the start of the stable review cycle for the 3.1.9 release.

There are 42 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let us know.  If anyone is a maintainer of the proper subsystem, and
wants to add a Signed-off-by: line to the patch, please respond with it.

Responses should be made by Thursday, January 12, 20:00:00 UTC.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:
	kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.1.9-rc1.gz
and the diffstat can be found below.

thanks,

greg k-h

 Documentation/HOWTO                          |    4 +-
 Documentation/development-process/5.Posting  |    8 ++--
 Documentation/usb/usbmon.txt                 |   14 +++--
 MAINTAINERS                                  |    2 +-
 Makefile                                     |    4 +-
 arch/powerpc/include/asm/time.h              |    2 +
 arch/powerpc/kernel/irq.c                    |   15 ++---
 arch/powerpc/kernel/time.c                   |    9 +++
 arch/powerpc/platforms/pseries/hvCall_inst.c |    4 +-
 arch/powerpc/platforms/pseries/lpar.c        |    2 +
 drivers/base/firmware_class.c                |   14 +++---
 drivers/infiniband/hw/qib/qib_iba6120.c      |    4 +-
 drivers/infiniband/hw/qib/qib_iba7220.c      |    4 +-
 drivers/infiniband/hw/qib/qib_iba7322.c      |    6 ++-
 drivers/net/bonding/bond_main.c              |    9 +++-
 drivers/net/usb/asix.c                       |    6 ++-
 drivers/net/wireless/rt2x00/rt2800usb.c      |    2 +-
 drivers/net/wireless/wl12xx/boot.c           |   14 +++++
 drivers/net/wireless/wl12xx/cmd.c            |   22 ++++++++
 drivers/net/wireless/wl12xx/testmode.c       |    1 +
 drivers/scsi/mpt2sas/mpt2sas_scsih.c         |    1 +
 drivers/tty/serial/atmel_serial.c            |    5 +-
 drivers/usb/class/cdc-acm.c                  |   16 +++++-
 drivers/usb/core/hcd.c                       |    5 +-
 drivers/usb/core/quirks.c                    |    5 ++-
 drivers/usb/host/ehci-q.c                    |    2 +-
 drivers/usb/host/ohci-hcd.c                  |   15 ++---
 drivers/usb/host/ohci-pci.c                  |   26 ---------
 drivers/usb/host/ohci.h                      |    1 -
 drivers/usb/host/pci-quirks.c                |   50 ++++++++----------
 drivers/usb/host/uhci-q.c                    |    2 +-
 drivers/usb/host/whci/qset.c                 |    4 +-
 drivers/usb/host/xhci-ring.c                 |    4 +-
 drivers/usb/host/xhci.c                      |    4 +-
 drivers/usb/host/xhci.h                      |    1 -
 drivers/usb/misc/isight_firmware.c           |    6 ++-
 drivers/usb/musb/musb_core.c                 |    2 -
 drivers/usb/serial/cp210x.c                  |    1 +
 drivers/usb/serial/omninet.c                 |    2 +-
 drivers/usb/serial/option.c                  |   10 ++++
 drivers/usb/storage/usb.c                    |    1 +
 drivers/video/offb.c                         |   52 ++++++++----------
 fs/ext3/inode.c                              |   24 +++++++-
 fs/reiserfs/super.c                          |   27 ++++++----
 fs/udf/file.c                                |    6 +-
 fs/udf/inode.c                               |   21 ++++++-
 fs/xfs/xfs_acl.c                             |    4 +-
 include/linux/usb.h                          |    1 +
 include/linux/usb/ch9.h                      |   20 +++++++-
 kernel/cgroup.c                              |    6 +-
 kernel/cpu.c                                 |   74 ++++++++++++++++++++++++++
 net/ipv4/igmp.c                              |    2 +
 tools/perf/util/trace-event-parse.c          |    2 +
 53 files changed, 368 insertions(+), 180 deletions(-)

Re: [41/42] xfs: validate acl count

[Christoph Hellwig]

On Tue, Jan 10, 2012 at 01:48:51PM -0800, Greg KH wrote:
> 3.1-stable review patch.  If anyone has any objections, please let me know.

Just curious, how well tested are all the patches on 2.6.32 and 3.1 hat I only
submitted for 3.0?  I'd really prefer if they at least get an xfstest run
before they get sent out to the world.

Re: [41/42] xfs: validate acl count

[Greg KH]

On Wed, Jan 11, 2012 at 08:41:35AM +0100, Christoph Hellwig wrote:
> On Tue, Jan 10, 2012 at 01:48:51PM -0800, Greg KH wrote:
> > 3.1-stable review patch.  If anyone has any objections, please let me know.
> 
> Just curious, how well tested are all the patches on 2.6.32 and 3.1 hat I only
> submitted for 3.0?  I'd really prefer if they at least get an xfstest run
> before they get sent out to the world.

I took these patches on my own as they were reported to fix a public
vulnerability which was assigned a CVE.  They applied with no fuzz and
"looked correct" so I applied them on my own.

If I shouldn't have, please let me know and I'll drop them.

Otherwise, a nice run of xfstest by someone would be appreciated.

thanks,

greg k-h

Re: [41/42] xfs: validate acl count

[Ben Myers]

Hi Christoph & Greg,

On Wed, Jan 11, 2012 at 07:00:21AM -0800, Greg KH wrote:
> On Wed, Jan 11, 2012 at 08:41:35AM +0100, Christoph Hellwig wrote:
> > On Tue, Jan 10, 2012 at 01:48:51PM -0800, Greg KH wrote:
> > > 3.1-stable review patch.  If anyone has any objections, please let me know.
> > 
> > Just curious, how well tested are all the patches on 2.6.32 and 3.1 hat I only
> > submitted for 3.0?  I'd really prefer if they at least get an xfstest run
> > before they get sent out to the world.
> 
> I took these patches on my own as they were reported to fix a public
> vulnerability which was assigned a CVE.  They applied with no fuzz and
> "looked correct" so I applied them on my own.
> 
> If I shouldn't have, please let me know and I'll drop them.
> 
> Otherwise, a nice run of xfstest by someone would be appreciated.

I have a 3.1 test rig and will get this done today, then I'll go after
2.6.32.

Regards,
	Ben


> thanks,
> 
> greg k-h

Re: [41/42] xfs: validate acl count

[Ben Myers]

Hey Greg,

On Wed, Jan 11, 2012 at 09:05:32AM -0600, Ben Myers wrote:
> Hi Christoph & Greg,
> 
> On Wed, Jan 11, 2012 at 07:00:21AM -0800, Greg KH wrote:
> > On Wed, Jan 11, 2012 at 08:41:35AM +0100, Christoph Hellwig wrote:
> > > On Tue, Jan 10, 2012 at 01:48:51PM -0800, Greg KH wrote:
> > > > 3.1-stable review patch.  If anyone has any objections, please let me know.
> > > 
> > > Just curious, how well tested are all the patches on 2.6.32 and 3.1 hat I only
> > > submitted for 3.0?  I'd really prefer if they at least get an xfstest run
> > > before they get sent out to the world.
> > 
> > I took these patches on my own as they were reported to fix a public
> > vulnerability which was assigned a CVE.  They applied with no fuzz and
> > "looked correct" so I applied them on my own.
> > 
> > If I shouldn't have, please let me know and I'll drop them.
> > 
> > Otherwise, a nice run of xfstest by someone would be appreciated.
> 
> I have a 3.1 test rig and will get this done today, then I'll go after
> 2.6.32.

I ran xfstests with 'xfs: validate acl count' and 'xfs: fix acl count
validation in xfs_acl_from_disk()' applied to 3.1-stable.  It came out
ok.  I'll get started on 2.6.32.

-Ben

Re: [41/42] xfs: validate acl count

[Greg KH]

On Fri, Jan 13, 2012 at 10:17:27AM -0600, Ben Myers wrote:
> Hey Greg,
> 
> On Wed, Jan 11, 2012 at 09:05:32AM -0600, Ben Myers wrote:
> > Hi Christoph & Greg,
> > 
> > On Wed, Jan 11, 2012 at 07:00:21AM -0800, Greg KH wrote:
> > > On Wed, Jan 11, 2012 at 08:41:35AM +0100, Christoph Hellwig wrote:
> > > > On Tue, Jan 10, 2012 at 01:48:51PM -0800, Greg KH wrote:
> > > > > 3.1-stable review patch.  If anyone has any objections, please let me know.
> > > > 
> > > > Just curious, how well tested are all the patches on 2.6.32 and 3.1 hat I only
> > > > submitted for 3.0?  I'd really prefer if they at least get an xfstest run
> > > > before they get sent out to the world.
> > > 
> > > I took these patches on my own as they were reported to fix a public
> > > vulnerability which was assigned a CVE.  They applied with no fuzz and
> > > "looked correct" so I applied them on my own.
> > > 
> > > If I shouldn't have, please let me know and I'll drop them.
> > > 
> > > Otherwise, a nice run of xfstest by someone would be appreciated.
> > 
> > I have a 3.1 test rig and will get this done today, then I'll go after
> > 2.6.32.
> 
> I ran xfstests with 'xfs: validate acl count' and 'xfs: fix acl count
> validation in xfs_acl_from_disk()' applied to 3.1-stable.  It came out
> ok.  I'll get started on 2.6.32.

Thanks, how about the 3.0 release?

greg k-h

Re: [41/42] xfs: validate acl count

[Ben Myers]

On Fri, Jan 13, 2012 at 10:19:52AM -0800, Greg KH wrote:
> On Fri, Jan 13, 2012 at 10:17:27AM -0600, Ben Myers wrote:
> > Hey Greg,
> > 
> > On Wed, Jan 11, 2012 at 09:05:32AM -0600, Ben Myers wrote:
> > > Hi Christoph & Greg,
> > > 
> > > On Wed, Jan 11, 2012 at 07:00:21AM -0800, Greg KH wrote:
> > > > On Wed, Jan 11, 2012 at 08:41:35AM +0100, Christoph Hellwig wrote:
> > > > > On Tue, Jan 10, 2012 at 01:48:51PM -0800, Greg KH wrote:
> > > > > > 3.1-stable review patch.  If anyone has any objections, please let me know.
> > > > > 
> > > > > Just curious, how well tested are all the patches on 2.6.32 and 3.1 hat I only
> > > > > submitted for 3.0?  I'd really prefer if they at least get an xfstest run
> > > > > before they get sent out to the world.
> > > > 
> > > > I took these patches on my own as they were reported to fix a public
> > > > vulnerability which was assigned a CVE.  They applied with no fuzz and
> > > > "looked correct" so I applied them on my own.
> > > > 
> > > > If I shouldn't have, please let me know and I'll drop them.
> > > > 
> > > > Otherwise, a nice run of xfstest by someone would be appreciated.
> > > 
> > > I have a 3.1 test rig and will get this done today, then I'll go after
> > > 2.6.32.
> > 
> > I ran xfstests with 'xfs: validate acl count' and 'xfs: fix acl count
> > validation in xfs_acl_from_disk()' applied to 3.1-stable.  It came out
> > ok.  I'll get started on 2.6.32.
> 
> Thanks, how about the 3.0 release?

HCH would have given them a spin before he sent them to stable@.

-Ben

Re: [41/42] xfs: validate acl count

[Greg KH]

On Fri, Jan 13, 2012 at 01:42:18PM -0600, Ben Myers wrote:
> On Fri, Jan 13, 2012 at 10:19:52AM -0800, Greg KH wrote:
> > On Fri, Jan 13, 2012 at 10:17:27AM -0600, Ben Myers wrote:
> > > Hey Greg,
> > > 
> > > On Wed, Jan 11, 2012 at 09:05:32AM -0600, Ben Myers wrote:
> > > > Hi Christoph & Greg,
> > > > 
> > > > On Wed, Jan 11, 2012 at 07:00:21AM -0800, Greg KH wrote:
> > > > > On Wed, Jan 11, 2012 at 08:41:35AM +0100, Christoph Hellwig wrote:
> > > > > > On Tue, Jan 10, 2012 at 01:48:51PM -0800, Greg KH wrote:
> > > > > > > 3.1-stable review patch.  If anyone has any objections, please let me know.
> > > > > > 
> > > > > > Just curious, how well tested are all the patches on 2.6.32 and 3.1 hat I only
> > > > > > submitted for 3.0?  I'd really prefer if they at least get an xfstest run
> > > > > > before they get sent out to the world.
> > > > > 
> > > > > I took these patches on my own as they were reported to fix a public
> > > > > vulnerability which was assigned a CVE.  They applied with no fuzz and
> > > > > "looked correct" so I applied them on my own.
> > > > > 
> > > > > If I shouldn't have, please let me know and I'll drop them.
> > > > > 
> > > > > Otherwise, a nice run of xfstest by someone would be appreciated.
> > > > 
> > > > I have a 3.1 test rig and will get this done today, then I'll go after
> > > > 2.6.32.
> > > 
> > > I ran xfstests with 'xfs: validate acl count' and 'xfs: fix acl count
> > > validation in xfs_acl_from_disk()' applied to 3.1-stable.  It came out
> > > ok.  I'll get started on 2.6.32.
> > 
> > Thanks, how about the 3.0 release?
> 
> HCH would have given them a spin before he sent them to stable@.

You are right, sorry, for some reason I thought that was for 3.1, too
many different kernel trees at the moment :(

greg k-h

Re: [41/42] xfs: validate acl count

[Ben Myers]

Hey Greg,

On Fri, Jan 13, 2012 at 11:52:06AM -0800, Greg KH wrote:
> On Fri, Jan 13, 2012 at 01:42:18PM -0600, Ben Myers wrote:
> > On Fri, Jan 13, 2012 at 10:19:52AM -0800, Greg KH wrote:
> > > On Fri, Jan 13, 2012 at 10:17:27AM -0600, Ben Myers wrote:
> > > > Hey Greg,
> > > > 
> > > > On Wed, Jan 11, 2012 at 09:05:32AM -0600, Ben Myers wrote:
> > > > > Hi Christoph & Greg,
> > > > > 
> > > > > On Wed, Jan 11, 2012 at 07:00:21AM -0800, Greg KH wrote:
> > > > > > On Wed, Jan 11, 2012 at 08:41:35AM +0100, Christoph Hellwig wrote:
> > > > > > > On Tue, Jan 10, 2012 at 01:48:51PM -0800, Greg KH wrote:
> > > > > > > > 3.1-stable review patch.  If anyone has any objections, please let me know.
> > > > > > > 
> > > > > > > Just curious, how well tested are all the patches on 2.6.32 and 3.1 hat I only
> > > > > > > submitted for 3.0?  I'd really prefer if they at least get an xfstest run
> > > > > > > before they get sent out to the world.
> > > > > > 
> > > > > > I took these patches on my own as they were reported to fix a public
> > > > > > vulnerability which was assigned a CVE.  They applied with no fuzz and
> > > > > > "looked correct" so I applied them on my own.
> > > > > > 
> > > > > > If I shouldn't have, please let me know and I'll drop them.
> > > > > > 
> > > > > > Otherwise, a nice run of xfstest by someone would be appreciated.
> > > > > 
> > > > > I have a 3.1 test rig and will get this done today, then I'll go after
> > > > > 2.6.32.
> > > > 
> > > > I ran xfstests with 'xfs: validate acl count' and 'xfs: fix acl count
> > > > validation in xfs_acl_from_disk()' applied to 3.1-stable.  It came out
> > > > ok.  I'll get started on 2.6.32.
> > > 
> > > Thanks, how about the 3.0 release?
> > 
> > HCH would have given them a spin before he sent them to stable@.
> 
> You are right, sorry, for some reason I thought that was for 3.1, too
> many different kernel trees at the moment :(

My v2.6.32.54 test run came out ok too.

Thanks,
Ben

Re: [41/42] xfs: validate acl count

[Greg KH]

On Mon, Jan 16, 2012 at 09:53:09AM -0600, Ben Myers wrote:
> Hey Greg,
> 
> On Fri, Jan 13, 2012 at 11:52:06AM -0800, Greg KH wrote:
> > On Fri, Jan 13, 2012 at 01:42:18PM -0600, Ben Myers wrote:
> > > On Fri, Jan 13, 2012 at 10:19:52AM -0800, Greg KH wrote:
> > > > On Fri, Jan 13, 2012 at 10:17:27AM -0600, Ben Myers wrote:
> > > > > Hey Greg,
> > > > > 
> > > > > On Wed, Jan 11, 2012 at 09:05:32AM -0600, Ben Myers wrote:
> > > > > > Hi Christoph & Greg,
> > > > > > 
> > > > > > On Wed, Jan 11, 2012 at 07:00:21AM -0800, Greg KH wrote:
> > > > > > > On Wed, Jan 11, 2012 at 08:41:35AM +0100, Christoph Hellwig wrote:
> > > > > > > > On Tue, Jan 10, 2012 at 01:48:51PM -0800, Greg KH wrote:
> > > > > > > > > 3.1-stable review patch.  If anyone has any objections, please let me know.
> > > > > > > > 
> > > > > > > > Just curious, how well tested are all the patches on 2.6.32 and 3.1 hat I only
> > > > > > > > submitted for 3.0?  I'd really prefer if they at least get an xfstest run
> > > > > > > > before they get sent out to the world.
> > > > > > > 
> > > > > > > I took these patches on my own as they were reported to fix a public
> > > > > > > vulnerability which was assigned a CVE.  They applied with no fuzz and
> > > > > > > "looked correct" so I applied them on my own.
> > > > > > > 
> > > > > > > If I shouldn't have, please let me know and I'll drop them.
> > > > > > > 
> > > > > > > Otherwise, a nice run of xfstest by someone would be appreciated.
> > > > > > 
> > > > > > I have a 3.1 test rig and will get this done today, then I'll go after
> > > > > > 2.6.32.
> > > > > 
> > > > > I ran xfstests with 'xfs: validate acl count' and 'xfs: fix acl count
> > > > > validation in xfs_acl_from_disk()' applied to 3.1-stable.  It came out
> > > > > ok.  I'll get started on 2.6.32.
> > > > 
> > > > Thanks, how about the 3.0 release?
> > > 
> > > HCH would have given them a spin before he sent them to stable@.
> > 
> > You are right, sorry, for some reason I thought that was for 3.1, too
> > many different kernel trees at the moment :(
> 
> My v2.6.32.54 test run came out ok too.

Wonderful, thanks for testing and letting us know.

greg k-h

Re: [41/42] xfs: validate acl count

[Christoph Hellwig]

On Fri, Jan 13, 2012 at 11:52:06AM -0800, Greg KH wrote:
> > > > I ran xfstests with 'xfs: validate acl count' and 'xfs: fix acl count
> > > > validation in xfs_acl_from_disk()' applied to 3.1-stable.  It came out
> > > > ok.  I'll get started on 2.6.32.
> > > 
> > > Thanks, how about the 3.0 release?
> > 
> > HCH would have given them a spin before he sent them to stable@.
> 
> You are right, sorry, for some reason I thought that was for 3.1, too
> many different kernel trees at the moment :(

This should go into 3.0 and 3.1 stable, too.

And I think this one actually is simple enough that I don't need a QA
run, so if you can just add it, please do.

Re: [41/42] xfs: validate acl count

[Ben Myers]

Christoph,

On Tue, Jan 24, 2012 at 05:33:01PM +0100, Christoph Hellwig wrote:
> On Fri, Jan 13, 2012 at 11:52:06AM -0800, Greg KH wrote:
> > > > > I ran xfstests with 'xfs: validate acl count' and 'xfs: fix acl count
> > > > > validation in xfs_acl_from_disk()' applied to 3.1-stable.  It came out
> > > > > ok.  I'll get started on 2.6.32.
> > > > 
> > > > Thanks, how about the 3.0 release?
> > > 
> > > HCH would have given them a spin before he sent them to stable@.
> > 
> > You are right, sorry, for some reason I thought that was for 3.1, too
> > many different kernel trees at the moment :(
> 
> This should go into 3.0 and 3.1 stable, too.

This made 3.0, but unfortunately not 3.1, which is end-of-life.

-Ben

> And I think this one actually is simple enough that I don't need a QA
> run, so if you can just add it, please do.
>