Skip to contentSkip to conversation

3.4.1-stable review

PATCH In review Greg KH 7 participants 116 messages May 27, 2012 – Jun 5, 2012

Subsystems (61)
lore
Share & tools
lore

Greg KH

author maintainer
#0 lore raw

cover 3.4.1-stable review

Note, I've tested this release a bit differently than I have in the past. For this release, I've only tested it on one machine, my laptop, with a pretty minimal configuration to save on build times. That means, while this release works for me, it might not for you, and it might not even build at all for you. Please test to verify that I haven't messed anything up. I'll give everyone at least an extra day than "normal" for this review cycle before I cut a final 3.4.1 release.

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

This is the start of the stable review cycle for the 3.4.1 release. There are 92 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 me know.

Responses should be made by Wed May 30 00:30:00 UTC 2012. 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.4.1-rc1.gz

and the diffstat can be found below.

thanks,

greg k-h

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

 Documentation/HOWTO                       | 32 ++++++++--------
 Makefile                                  |  4 +-
 arch/arm/boot/dts/tegra-cardhu.dts        |  2 +-
 arch/arm/include/asm/cacheflush.h         |  2 +-
 arch/arm/kernel/traps.c                   |  4 +-
 arch/powerpc/kernel/idle.c                | 14 +++----
 arch/s390/mm/fault.c                      | 14 ++++++-
 arch/sparc/Kconfig                        |  3 ++
 arch/sparc/kernel/systbls_64.S            |  2 +-
 arch/tile/include/asm/bitops.h            | 12 +++---
 arch/um/include/asm/pgtable.h             | 10 ++++-
 arch/x86/Makefile                         |  1 +
 arch/x86/kernel/cpu/mcheck/mce-severity.c | 16 +++++---
 arch/x86/kernel/cpu/mcheck/mce.c          |  8 ++++
 arch/x86/kernel/cpu/perf_event_amd.c      | 11 +++++-
 arch/x86/pci/xen.c                        |  4 ++
 arch/x86/tools/relocs.c                   | 12 ++++++
 drivers/gpio/gpio-mpc8xxx.c               |  3 +-
 drivers/gpu/drm/gma500/psb_device.c       |  6 ++-
 drivers/gpu/drm/i915/i915_irq.c           |  9 ++---
 drivers/gpu/drm/i915/i915_reg.h           | 15 ++++++++
 drivers/gpu/drm/i915/intel_display.c      | 19 +++++++++-
 drivers/gpu/drm/nouveau/nouveau_bo.c      |  2 +-
 drivers/hid/hid-logitech-dj.c             |  5 ++-
 drivers/hid/hid-wiimote-core.c            | 16 +++-----
 drivers/hid/usbhid/hid-core.c             | 61 ++++++++++++++++++++++++++++---
 drivers/i2c/busses/i2c-davinci.c          |  2 +-
 drivers/i2c/busses/i2c-tegra.c            | 13 +++----
 drivers/infiniband/core/umem.c            |  2 +-
 drivers/infiniband/hw/cxgb4/cm.c          | 13 ++++---
 drivers/iommu/dmar.c                      |  4 +-
 drivers/iommu/intel-iommu.c               | 17 ++++++---
 drivers/isdn/gigaset/capi.c               | 26 ++++++-------
 drivers/isdn/gigaset/ev-layer.c           |  4 +-
 drivers/md/md.c                           |  2 +-
 drivers/media/dvb/siano/smsusb.c          |  2 +
 drivers/media/video/uvc/uvc_v4l2.c        |  2 +-
 drivers/mmc/core/cd-gpio.c                |  3 ++
 drivers/mmc/core/sdio.c                   |  2 +-
 drivers/mmc/core/sdio_irq.c               | 11 ++++--
 drivers/mmc/host/omap_hsmmc.c             |  2 +-
 drivers/net/wireless/b43legacy/main.c     |  2 -
 drivers/net/wireless/ipw2x00/ipw2200.c    | 21 +++--------
 drivers/net/wireless/iwlwifi/iwl-6000.c   |  4 +-
 drivers/regulator/core.c                  |  2 +
 drivers/scsi/isci/init.c                  |  2 +-
 drivers/scsi/mpt2sas/mpt2sas_base.c       |  6 +--
 drivers/spi/spi-fsl-spi.c                 |  2 +-
 drivers/staging/android/persistent_ram.c  | 19 +---------
 drivers/staging/comedi/comedi_fops.c      |  2 +-
 drivers/tty/hvc/hvc_xen.c                 |  4 +-
 drivers/tty/serial/8250/8250.c            |  9 +++--
 drivers/tty/serial/8250/8250_pci.c        | 18 +++++++++
 drivers/tty/serial/mxs-auart.c            |  2 +
 drivers/tty/serial/serial_core.c          |  1 +
 drivers/usb/class/cdc-wdm.c               | 31 +++++++++++-----
 drivers/usb/core/devio.c                  | 33 +++++++++++++----
 drivers/usb/core/hub.c                    |  4 ++
 drivers/usb/core/quirks.c                 |  3 ++
 drivers/usb/core/urb.c                    | 21 +++++++++++
 drivers/usb/gadget/fsl_udc_core.c         |  2 +
 drivers/usb/host/ehci-omap.c              | 18 ++++-----
 drivers/usb/host/ehci-pci.c               |  4 +-
 drivers/usb/host/ehci-platform.c          |  2 -
 drivers/usb/host/ohci-at91.c              | 11 +++++-
 drivers/usb/host/pci-quirks.c             | 32 +++++++++++++++-
 drivers/usb/host/xhci-hub.c               | 22 ++++++-----
 drivers/usb/host/xhci-mem.c               | 27 ++++++++++++++
 drivers/usb/host/xhci-pci.c               |  1 +
 drivers/usb/host/xhci-ring.c              | 22 +++++++++--
 drivers/usb/host/xhci.c                   | 12 +++++-
 drivers/usb/host/xhci.h                   |  3 ++
 drivers/usb/misc/usbtest.c                | 17 ++++++---
 drivers/usb/otg/gpio_vbus.c               |  8 ++--
 drivers/usb/serial/ftdi_sio.c             |  1 +
 drivers/usb/serial/ftdi_sio_ids.h         |  8 ++++
 drivers/usb/serial/ti_usb_3410_5052.c     |  6 ++-
 drivers/usb/serial/ti_usb_3410_5052.h     |  1 +
 drivers/usb/serial/usb-serial.c           |  9 ++++-
 drivers/usb/storage/unusual_devs.h        |  7 ++++
 drivers/video/sh_mobile_lcdcfb.c          |  5 ++-
 drivers/video/sh_mobile_lcdcfb.h          |  1 +
 drivers/xen/events.c                      |  5 ++-
 fs/aio.c                                  | 30 +++++++--------
 include/linux/mmc/host.h                  |  2 +
 include/linux/usb.h                       |  3 ++
 include/xen/events.h                      |  3 ++
 init/main.c                               |  7 ++--
 kernel/workqueue.c                        |  9 ++++-
 mm/mempolicy.c                            | 41 +++++++++------------
 net/wireless/reg.c                        | 10 +++++
 security/selinux/selinuxfs.c              |  1 +
 tools/usb/ffs-test.c                      |  2 +-
 93 files changed, 629 insertions(+), 281 deletions(-)
author maintainer
#1 lore raw

PATCH 1/91 isdn/gigaset: ratelimit CAPI message dumps

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

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

From: Tilman Schmidt <[email protected]>

commit 8e618aad5348b6e6c5a90e8d97ea643197963b20 upstream.

Introduce a global ratelimit for CAPI message dumps to protect against possible log flood.
Drop the ratelimit for ignored messages which is now covered by the global one.

---
 drivers/isdn/gigaset/capi.c |   22 +++++++++-------------
 1 file changed, 9 insertions(+), 13 deletions(-)
drivers/isdn/gigaset/capi.c +9 -13
@@ -14,6 +14,7 @@
 #include "gigaset.h"
 #include <linux/proc_fs.h>
 #include <linux/seq_file.h>
+#include <linux/ratelimit.h>
 #include <linux/isdn/capilli.h>
 #include <linux/isdn/capicmd.h>
 #include <linux/isdn/capiutil.h>
@@ -223,10 +224,14 @@ get_appl(struct gigaset_capi_ctr *iif, u
 static inline void dump_cmsg(enum debuglevel level, const char *tag, _cmsg *p)
 {
 #ifdef CONFIG_GIGASET_DEBUG
+	/* dump at most 20 messages in 20 secs */
+	static DEFINE_RATELIMIT_STATE(msg_dump_ratelimit, 20 * HZ, 20);
 	_cdebbuf *cdb;
 
 	if (!(gigaset_debuglevel & level))
 		return;
+	if (!___ratelimit(&msg_dump_ratelimit, tag))
+		return;
 
 	cdb = capi_cmsg2str(p);
 	if (cdb) {
@@ -2059,12 +2064,6 @@ static void do_reset_b3_req(struct gigas
 }
 
 /*
- * dump unsupported/ignored messages at most twice per minute,
- * some apps send those very frequently
- */
-static unsigned long ignored_msg_dump_time;
-
-/*
  * unsupported CAPI message handler
  */
 static void do_unsupported(struct gigaset_capi_ctr *iif,
@@ -2073,8 +2072,7 @@ static void do_unsupported(struct gigase
 {
 	/* decode message */
 	capi_message2cmsg(&iif->acmsg, skb->data);
-	if (printk_timed_ratelimit(&ignored_msg_dump_time, 30 * 1000))
-		dump_cmsg(DEBUG_CMD, __func__, &iif->acmsg);
+	dump_cmsg(DEBUG_CMD, __func__, &iif->acmsg);
 	send_conf(iif, ap, skb, CapiMessageNotSupportedInCurrentState);
 }
 
@@ -2085,11 +2083,9 @@ static void do_nothing(struct gigaset_ca
 		       struct gigaset_capi_appl *ap,
 		       struct sk_buff *skb)
 {
-	if (printk_timed_ratelimit(&ignored_msg_dump_time, 30 * 1000)) {
-		/* decode message */
-		capi_message2cmsg(&iif->acmsg, skb->data);
-		dump_cmsg(DEBUG_CMD, __func__, &iif->acmsg);
-	}
+	/* decode message */
+	capi_message2cmsg(&iif->acmsg, skb->data);
+	dump_cmsg(DEBUG_CMD, __func__, &iif->acmsg);
 	dev_kfree_skb_any(skb);
 }
 
author maintainer
#2 lore raw

PATCH 2/91 isdn/gigaset: fix CAPI disconnect B3 handling

In reply to Greg KH

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

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

From: Tilman Schmidt <[email protected]>

commit 62a1cfe052346b96a552b6a9178d412c709711bb upstream.

If DISCONNECT_B3_IND was synthesized because of a DISCONNECT_REQ with existing logical connections, the connection state wasn't updated accordingly. Also the emitted DISCONNECT_B3_IND message wasn't included in the debug log as requested.
This patch fixes both of these issues.

---
 drivers/isdn/gigaset/capi.c |    4 ++++
 1 file changed, 4 insertions(+)
drivers/isdn/gigaset/capi.c +4 -0
@@ -1887,6 +1887,9 @@ static void do_disconnect_req(struct gig
 
 	/* check for active logical connection */
 	if (bcs->apconnstate >= APCONN_ACTIVE) {
+		/* clear it */
+		bcs->apconnstate = APCONN_SETUP;
+
 		/*
 		 * emit DISCONNECT_B3_IND with cause 0x3301
 		 * use separate cmsg structure, as the content of iif->acmsg
@@ -1911,6 +1914,7 @@ static void do_disconnect_req(struct gig
 		}
 		capi_cmsg2message(b3cmsg,
 				  __skb_put(b3skb, CAPI_DISCONNECT_B3_IND_BASELEN));
+		dump_cmsg(DEBUG_CMD, __func__, b3cmsg);
 		kfree(b3cmsg);
 		capi_ctr_handle_message(&iif->ctr, ap->id, b3skb);
 	}
author maintainer
#3 lore raw

PATCH 3/91 isdn/gigaset: improve error handling querying firmware version

In reply to Greg KH

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

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

From: Tilman Schmidt <[email protected]>

commit e055d03dc088a990fe5ea24a2d64033a168da23c upstream.

An out-of-place "OK" response to the "AT+GMR" (get firmware version) command turns out to be, more often than not, a delayed response to a previous command rather than an actual error, so continue waiting for the version number in that case.

---
 drivers/isdn/gigaset/ev-layer.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/isdn/gigaset/ev-layer.c +3 -1
@@ -190,6 +190,7 @@ struct reply_t gigaset_tab_nocid[] =
 								  ACT_INIT} },
 	{RSP_OK,	121, 121, -1,			  0,  0, {ACT_GOTVER,
 								  ACT_INIT} },
+	{RSP_NONE,	121, 121, -1,			120,  0, {ACT_GETSTRING} },
 
 /* leave dle mode */
 	{RSP_INIT,	  0,   0, SEQ_DLE0,		201,  5, {0},	"^SDLE=0\r"},
@@ -1314,8 +1315,9 @@ static void do_action(int action, struct
 		s = ev->ptr;
 
 		if (!strcmp(s, "OK")) {
+			/* OK without version string: assume old response */
 			*p_genresp = 1;
-			*p_resp_code = RSP_ERROR;
+			*p_resp_code = RSP_NONE;
 			break;
 		}
 
author maintainer
#4 lore raw

PATCH 4/91 vfs: make AIO use the proper rw_verify_area() area helpers

In reply to Greg KH

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

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

From: Linus Torvalds <[email protected]>

commit a70b52ec1aaeaf60f4739edb1b422827cb6f3893 upstream.

We had for some reason overlooked the AIO interface, and it didn't use the proper rw_verify_area() helper function that checks (for example) mandatory locking on the file, and that the size of the access doesn't cause us to overflow the provided offset limits etc.

Instead, AIO did just the security_file_permission() thing (that rw_verify_area() also does) directly.

This fixes it to do all the proper helper functions, which not only means that now mandatory file locking works with AIO too, we can actually remove lines of code.

---
 fs/aio.c |   30 ++++++++++++++----------------
 1 file changed, 14 insertions(+), 16 deletions(-)
fs/aio.c +14 -16
@@ -1456,6 +1456,10 @@ static ssize_t aio_setup_vectored_rw(int
 	if (ret < 0)
 		goto out;
 
+	ret = rw_verify_area(type, kiocb->ki_filp, &kiocb->ki_pos, ret);
+	if (ret < 0)
+		goto out;
+
 	kiocb->ki_nr_segs = kiocb->ki_nbytes;
 	kiocb->ki_cur_seg = 0;
 	/* ki_nbytes/left now reflect bytes instead of segs */
@@ -1467,11 +1471,17 @@ out:
 	return ret;
 }
 
-static ssize_t aio_setup_single_vector(struct kiocb *kiocb)
+static ssize_t aio_setup_single_vector(int type, struct file * file, struct kiocb *kiocb)
 {
+	int bytes;
+
+	bytes = rw_verify_area(type, file, &kiocb->ki_pos, kiocb->ki_left);
+	if (bytes < 0)
+		return bytes;
+
 	kiocb->ki_iovec = &kiocb->ki_inline_vec;
 	kiocb->ki_iovec->iov_base = kiocb->ki_buf;
-	kiocb->ki_iovec->iov_len = kiocb->ki_left;
+	kiocb->ki_iovec->iov_len = bytes;
 	kiocb->ki_nr_segs = 1;
 	kiocb->ki_cur_seg = 0;
 	return 0;
@@ -1496,10 +1506,7 @@ static ssize_t aio_setup_iocb(struct kio
 		if (unlikely(!access_ok(VERIFY_WRITE, kiocb->ki_buf,
 			kiocb->ki_left)))
 			break;
-		ret = security_file_permission(file, MAY_READ);
-		if (unlikely(ret))
-			break;
-		ret = aio_setup_single_vector(kiocb);
+		ret = aio_setup_single_vector(READ, file, kiocb);
 		if (ret)
 			break;
 		ret = -EINVAL;
@@ -1514,10 +1521,7 @@ static ssize_t aio_setup_iocb(struct kio
 		if (unlikely(!access_ok(VERIFY_READ, kiocb->ki_buf,
 			kiocb->ki_left)))
 			break;
-		ret = security_file_permission(file, MAY_WRITE);
-		if (unlikely(ret))
-			break;
-		ret = aio_setup_single_vector(kiocb);
+		ret = aio_setup_single_vector(WRITE, file, kiocb);
 		if (ret)
 			break;
 		ret = -EINVAL;
@@ -1528,9 +1532,6 @@ static ssize_t aio_setup_iocb(struct kio
 		ret = -EBADF;
 		if (unlikely(!(file->f_mode & FMODE_READ)))
 			break;
-		ret = security_file_permission(file, MAY_READ);
-		if (unlikely(ret))
-			break;
 		ret = aio_setup_vectored_rw(READ, kiocb, compat);
 		if (ret)
 			break;
@@ -1542,9 +1543,6 @@ static ssize_t aio_setup_iocb(struct kio
 		ret = -EBADF;
 		if (unlikely(!(file->f_mode & FMODE_WRITE)))
 			break;
-		ret = security_file_permission(file, MAY_WRITE);
-		if (unlikely(ret))
-			break;
 		ret = aio_setup_vectored_rw(WRITE, kiocb, compat);
 		if (ret)
 			break;
author maintainer
#5 lore raw

PATCH 5/91 iwlwifi: use 6000G2B for 6030 device series

In reply to Greg KH

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

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

From: Wey-Yi Guy <[email protected]>

commit 35e7adaaf6932c5ffb22c6ec521734434c65adc5 upstream.

"iwlwifi: use correct released ucode version" change the ucode api ok from 6000G2 to 6000G2B, but it shall belong to 6030 device series, not the 6005 device series. Fix it

---
 drivers/net/wireless/iwlwifi/iwl-6000.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/wireless/iwlwifi/iwl-6000.c +1 -1
@@ -390,7 +390,7 @@ const struct iwl_cfg iwl6005_2agn_mow2_c
 #define IWL_DEVICE_6030						\
 	.fw_name_pre = IWL6030_FW_PRE,				\
 	.ucode_api_max = IWL6000G2_UCODE_API_MAX,		\
-	.ucode_api_ok = IWL6000G2B_UCODE_API_OK,		\
+	.ucode_api_ok = IWL6000G2_UCODE_API_OK,			\
 	.ucode_api_min = IWL6000G2_UCODE_API_MIN,		\
 	.max_inst_size = IWL60_RTC_INST_SIZE,			\
 	.max_data_size = IWL60_RTC_DATA_SIZE,			\
#6 lore raw

Re: [ 05/91] iwlwifi: use 6000G2B for 6030 device series

Quoted 11 lines · Greg KH

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

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

From: Wey-Yi Guy <[email protected]>

commit 35e7adaaf6932c5ffb22c6ec521734434c65adc5 upstream.

"iwlwifi: use correct released ucode version" change the ucode api ok from 6000G2 to 6000G2B, but it shall belong to 6030 device series, not the 6005 device series. Fix it

The relevant changes are:

(a)
commit e377a4fc768d7d477e58888bdbddd0103d6238bf

Author: Meenakshi Venkataraman <[email protected]>
Date:   Sun Apr 22 07:55:27 2012 -0700

iwlwifi: use correct released ucode version

- changed IWL_DEVICE_6005 to use IWL6000G2B_UCODE_API_OK
- upstream in this merge window; not cc'd to stable; redundant with next change

(b)
commit 78cbcf2b9dbe0565820dc7721316f9c401000a68

Author: Meenakshi Venkataraman <[email protected]>
Date:   Sun Apr 22 07:55:27 2012 -0700

iwlwifi: use correct released ucode version

- changed IWL_DEVICE_6005 to use IWL6000G2B_UCODE_API_OK (among many other changes)
- upstream in 3.4; cc'd to stable; applied in 3.2.17 and 3.3.5

(c)
commit 35e7adaaf6932c5ffb22c6ec521734434c65adc5

Author: Wey-Yi Guy <[email protected]>
Date:   Wed Apr 25 08:10:08 2012 -0700

iwlwifi: use 6000G2B for 6030 device series

- changed IWL_DEVICE_6005 back to IWL6000G2_UCODE_API_OK
- upstream in this merge window; cc'd to stable; redundant with next change

(d)
commit 1ed2ec37b44e86eaa8e0a03b908a39c80f65ee45

Author: Wey-Yi Guy <[email protected]>
Date:   Wed Apr 25 08:10:08 2012 -0700

iwlwifi: use 6000G2B for 6030 device series

- changed IWL_DEVICE_6005 back to IWL6000G2_UCODE_API_OK and IWL_DEVICE_6030 to IWL6000G2B_UCODE_API_OK
- upstream in 3.4; cc'd to stable; applied in 3.2.17 and 3.3.5

We have applied (b) and (d); (a) and (c) are thus redundant.

This is (a) but applied in the wrong place; the next patch (06/91) is
(c) but applied in the wrong place; together they are reverting the effect of (d)).

Ben.

Signature · 3 lines
Ben Hutchings
The obvious mathematical breakthrough [to break modern encryption] would be
development of an easy way to factor large prime numbers. - Bill Gates
author maintainer
#7 lore raw

Re: [ 05/91] iwlwifi: use 6000G2B for 6030 device series

Quoted 52 lines · Ben Hutchings
Quoted 11 lines · Greg KH

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

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

From: Wey-Yi Guy <[email protected]>

commit 35e7adaaf6932c5ffb22c6ec521734434c65adc5 upstream.

"iwlwifi: use correct released ucode version" change the ucode api ok from 6000G2 to 6000G2B, but it shall belong to 6030 device series, not the 6005 device series. Fix it

The relevant changes are:

(a)
commit e377a4fc768d7d477e58888bdbddd0103d6238bf

Author: Meenakshi Venkataraman <[email protected]>
Date:   Sun Apr 22 07:55:27 2012 -0700

iwlwifi: use correct released ucode version

- changed IWL_DEVICE_6005 to use IWL6000G2B_UCODE_API_OK
- upstream in this merge window; not cc'd to stable; redundant with next change

(b)
commit 78cbcf2b9dbe0565820dc7721316f9c401000a68

Author: Meenakshi Venkataraman <[email protected]>
Date:   Sun Apr 22 07:55:27 2012 -0700

iwlwifi: use correct released ucode version

- changed IWL_DEVICE_6005 to use IWL6000G2B_UCODE_API_OK (among many other changes)
- upstream in 3.4; cc'd to stable; applied in 3.2.17 and 3.3.5

(c)
commit 35e7adaaf6932c5ffb22c6ec521734434c65adc5

Author: Wey-Yi Guy <[email protected]>
Date:   Wed Apr 25 08:10:08 2012 -0700

iwlwifi: use 6000G2B for 6030 device series

- changed IWL_DEVICE_6005 back to IWL6000G2_UCODE_API_OK
- upstream in this merge window; cc'd to stable; redundant with next change

(d)
commit 1ed2ec37b44e86eaa8e0a03b908a39c80f65ee45

Author: Wey-Yi Guy <[email protected]>
Date:   Wed Apr 25 08:10:08 2012 -0700

iwlwifi: use 6000G2B for 6030 device series

Quoted 8 lines

- changed IWL_DEVICE_6005 back to IWL6000G2_UCODE_API_OK and IWL_DEVICE_6030 to IWL6000G2B_UCODE_API_OK
- upstream in 3.4; cc'd to stable; applied in 3.2.17 and 3.3.5

We have applied (b) and (d); (a) and (c) are thus redundant.

This is (a) but applied in the wrong place; the next patch (06/91) is
(c) but applied in the wrong place; together they are reverting the effect of (d)).

Ugh, messy. I've now removed both of these from the 3.4 stable queue, thanks.

greg k-h

author maintainer
#8 lore raw

PATCH 6/91 iwlwifi: use correct released ucode version

In reply to Greg KH

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

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

From: Meenakshi Venkataraman <[email protected]>

commit e377a4fc768d7d477e58888bdbddd0103d6238bf upstream.

Report correctly the latest released version
of the iwlwifi firmware for all
iwlwifi-supported devices.

---
 drivers/net/wireless/iwlwifi/iwl-6000.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/wireless/iwlwifi/iwl-6000.c +1 -1
@@ -336,7 +336,7 @@ static const struct iwl_bt_params iwl600
 #define IWL_DEVICE_6005						\
 	.fw_name_pre = IWL6005_FW_PRE,				\
 	.ucode_api_max = IWL6000G2_UCODE_API_MAX,		\
-	.ucode_api_ok = IWL6000G2_UCODE_API_OK,			\
+	.ucode_api_ok = IWL6000G2B_UCODE_API_OK,		\
 	.ucode_api_min = IWL6000G2_UCODE_API_MIN,		\
 	.max_inst_size = IWL60_RTC_INST_SIZE,			\
 	.max_data_size = IWL60_RTC_DATA_SIZE,			\
author maintainer
#9 lore raw

PATCH 7/91 net/wireless: ipw2200: Fix WARN_ON occurring in wiphy_register called by ipw_pci_probe

In reply to Greg KH

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

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

From: Stanislav Yakovlev <[email protected]>

commit 7ed85b65ab611ba841d508ae4ff8c45fa0c48c80 upstream.

The problem was found by Stefan Lippers-Hollmann
http://marc.info/?l=linux-wireless&m=132720334512946&w=2

WARNING: at /tmp/buildd/linux-aptosid-3.2/debian/build/source_i386_none/net/wireless/core.c:562 wiphy_register+0x45/0x38d [cfg80211]()
Hardware name: TravelMate 290 \xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff
Modules linked in: ipw2200(+) iTCO_wdt libipw joydev drm snd_seq snd_timer snd_seq_device iTCO_vendor_support yenta_socket snd intel_agp i2c_i801 pcmcia_rsrc cfg80211 soundcore parport_pc psmouse parport rng_core snd_page_alloc serio_raw pcspkr i2c_algo_bit intel_gtt pcmcia_core evdev irda crc_ccitt rfkill lib80211 processor container ac battery shpchp pci_hotplug button ext4 mbcache jbd2 crc16 dm_mod sd_mod sr_mod crc_t10dif cdrom ata_generic pata_acpi ata_piix libata scsi_mod firewire_ohci firewire_core crc_itu_t 8139too 8139cp mii uhci_hcd ehci_hcd usbcore usb_common [last unloaded: scsi_wait_scan]
Pid: 328, comm: modprobe Not tainted 3.2-1.slh.4-aptosid-686 #1
Call Trace:
[<c012eaf4>] ? warn_slowpath_common+0x7c/0x8f
[<e0ff0b3e>] ? wiphy_register+0x45/0x38d [cfg80211]
[<e0ff0b3e>] ? wiphy_register+0x45/0x38d [cfg80211]
[<c012eb22>] ? warn_slowpath_null+0x1b/0x1f
[<e0ff0b3e>] ? wiphy_register+0x45/0x38d [cfg80211]
[<c01f89d7>] ? internal_create_group+0xf5/0xff
[<e0a2de1c>] ? ipw_pci_probe+0xa9a/0xbd0 [ipw2200]
[<c01519f4>] ? arch_local_irq_save+0xf/0x14
[<c0252986>] ? pci_device_probe+0x53/0x9a
[<c02c2820>] ? driver_probe_device+0x94/0x124
[<c0252871>] ? pci_match_id+0x15/0x34
[<c02c28f0>] ? __driver_attach+0x40/0x5b
[<c02c1d81>] ? bus_for_each_dev+0x37/0x60
[<c02c25aa>] ? driver_attach+0x17/0x1a
[<c02c28b0>] ? driver_probe_device+0x124/0x124
[<c02c22c4>] ? bus_add_driver+0x92/0x1d1

[<e099d000>] ? 0xe099cfff
[<c02c2cb8>] ? driver_register+0x7d/0xd4 [<c017cd50>] ? jump_label_module_notify+0xec/0x167 [<e099d000>] ? 0xe099cfff
[<c0253017>] ? __pci_register_driver+0x32/0x87 [<e099d000>] ? 0xe099cfff
[<e099d02e>] ? ipw_init+0x2e/0x72 [ipw2200] [<c0101173>] ? do_one_initcall+0x7d/0x132 [<c0145016>] ? __blocking_notifier_call_chain+0x47/0x4f [<c0154a73>] ? sys_init_module+0x13a4/0x159c [<c03a639f>] ? sysenter_do_call+0x12/0x28

This warning appears only if we apply Ben Hutchings' fix
http://marc.info/?l=linux-wireless&m=132720195012653&w=2
for the bug reported by Cesare Leonardi
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=656813
with cfg80211 warning during device registration ("cfg80211: failed to add phy80211 symlink to netdev!").

We separate device bring up and registration with network stack to avoid the problem.

After that Ben Hutchings' fix can be applied to fix the bug.

---
 drivers/net/wireless/ipw2x00/ipw2200.c |   21 ++++++---------------
 1 file changed, 6 insertions(+), 15 deletions(-)
drivers/net/wireless/ipw2x00/ipw2200.c +6 -15
@@ -11443,20 +11443,6 @@ static void ipw_bg_down(struct work_stru
 	mutex_unlock(&priv->mutex);
 }
 
-/* Called by register_netdev() */
-static int ipw_net_init(struct net_device *dev)
-{
-	int rc = 0;
-	struct ipw_priv *priv = libipw_priv(dev);
-
-	mutex_lock(&priv->mutex);
-	if (ipw_up(priv))
-		rc = -EIO;
-	mutex_unlock(&priv->mutex);
-
-	return rc;
-}
-
 static int ipw_wdev_init(struct net_device *dev)
 {
 	int i, rc = 0;
@@ -11722,7 +11708,6 @@ static void ipw_prom_free(struct ipw_pri
 #endif
 
 static const struct net_device_ops ipw_netdev_ops = {
-	.ndo_init		= ipw_net_init,
 	.ndo_open		= ipw_net_open,
 	.ndo_stop		= ipw_net_stop,
 	.ndo_set_rx_mode	= ipw_net_set_multicast_list,
@@ -11849,6 +11834,12 @@ static int __devinit ipw_pci_probe(struc
 		goto out_release_irq;
 	}
 
+	if (ipw_up(priv)) {
+		mutex_unlock(&priv->mutex);
+		err = -EIO;
+		goto out_remove_sysfs;
+	}
+
 	mutex_unlock(&priv->mutex);
 	err = register_netdev(net_dev);
 	if (err) {
#10 lore raw

Re: [ 07/91] net/wireless: ipw2200: Fix WARN_ON occurring in wiphy_register called by ipw_pci_probe

Quoted 3 lines · Greg KH

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

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

As I see, this is not needed on 3.4.x or 3.3.x, since the commit "ipw2200: Fix order of device registration", wasn't included in 3.4 or any earlier kernels.

This is fixing an issue introduced on that commit ("ipw2200: Fix order of device registration"), that moved register_netdev after ipw_wdev_init, but ipw_wdev_init needs initialization made on ndo_init callback.

Unless there is any plan to include any of the "... Fix order of device registration" commits on 3.4 stable, I don't see any reason to include the fix for them.

Besides that, I noted that ipw2100 seems to need a similar fix as below after the change "ipw2100: Fix order of device registration". ipw2100 will have the same issue I expect: because ipw2100_wdev_init was moved before register_netdev, the ndo_init callback that runs ipw2100_up will only execute later with required initialization, after wiphy_register inside ipw2100_wdev_init runs.

Quoted 113 lines

From: Stanislav Yakovlev <[email protected]>

commit 7ed85b65ab611ba841d508ae4ff8c45fa0c48c80 upstream.

The problem was found by Stefan Lippers-Hollmann
http://marc.info/?l=linux-wireless&m=132720334512946&w=2

WARNING: at /tmp/buildd/linux-aptosid-3.2/debian/build/source_i386_none/net/wireless/core.c:562 wiphy_register+0x45/0x38d [cfg80211]()
Hardware name: TravelMate 290 \xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff
Modules linked in: ipw2200(+) iTCO_wdt libipw joydev drm snd_seq snd_timer snd_seq_device iTCO_vendor_support yenta_socket snd intel_agp i2c_i801 pcmcia_rsrc cfg80211 soundcore parport_pc psmouse parport rng_core snd_page_alloc serio_raw pcspkr i2c_algo_bit intel_gtt pcmcia_core evdev irda crc_ccitt rfkill lib80211 processor container ac battery shpchp pci_hotplug button ext4 mbcache jbd2 crc16 dm_mod sd_mod sr_mod crc_t10dif cdrom ata_generic pata_acpi ata_piix libata scsi_mod firewire_ohci firewire_core crc_itu_t 8139too 8139cp mii uhci_hcd ehci_hcd usbcore usb_common [last unloaded: scsi_wait_scan]
Pid: 328, comm: modprobe Not tainted 3.2-1.slh.4-aptosid-686 #1
Call Trace:
[<c012eaf4>] ? warn_slowpath_common+0x7c/0x8f
[<e0ff0b3e>] ? wiphy_register+0x45/0x38d [cfg80211]
[<e0ff0b3e>] ? wiphy_register+0x45/0x38d [cfg80211]
[<c012eb22>] ? warn_slowpath_null+0x1b/0x1f
[<e0ff0b3e>] ? wiphy_register+0x45/0x38d [cfg80211]
[<c01f89d7>] ? internal_create_group+0xf5/0xff
[<e0a2de1c>] ? ipw_pci_probe+0xa9a/0xbd0 [ipw2200]
[<c01519f4>] ? arch_local_irq_save+0xf/0x14
[<c0252986>] ? pci_device_probe+0x53/0x9a
[<c02c2820>] ? driver_probe_device+0x94/0x124
[<c0252871>] ? pci_match_id+0x15/0x34
[<c02c28f0>] ? __driver_attach+0x40/0x5b
[<c02c1d81>] ? bus_for_each_dev+0x37/0x60
[<c02c25aa>] ? driver_attach+0x17/0x1a
[<c02c28b0>] ? driver_probe_device+0x124/0x124
[<c02c22c4>] ? bus_add_driver+0x92/0x1d1

[<e099d000>] ? 0xe099cfff
[<c02c2cb8>] ? driver_register+0x7d/0xd4 [<c017cd50>] ? jump_label_module_notify+0xec/0x167 [<e099d000>] ? 0xe099cfff
[<c0253017>] ? __pci_register_driver+0x32/0x87 [<e099d000>] ? 0xe099cfff
[<e099d02e>] ? ipw_init+0x2e/0x72 [ipw2200] [<c0101173>] ? do_one_initcall+0x7d/0x132 [<c0145016>] ? __blocking_notifier_call_chain+0x47/0x4f [<c0154a73>] ? sys_init_module+0x13a4/0x159c [<c03a639f>] ? sysenter_do_call+0x12/0x28

This warning appears only if we apply Ben Hutchings' fix
http://marc.info/?l=linux-wireless&m=132720195012653&w=2
for the bug reported by Cesare Leonardi
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=656813
with cfg80211 warning during device registration ("cfg80211: failed to add phy80211 symlink to netdev!").

We separate device bring up and registration with network stack to avoid the problem.

After that Ben Hutchings' fix can be applied to fix the bug.

---
 drivers/net/wireless/ipw2x00/ipw2200.c |   21 ++++++---------------
 1 file changed, 6 insertions(+), 15 deletions(-)
drivers/net/wireless/ipw2x00/ipw2200.c +6 -16
@@ -11443,20 +11443,6 @@ static void ipw_bg_down(struct work_stru
 	mutex_unlock(&priv->mutex);
 }
 
-/* Called by register_netdev() */
-static int ipw_net_init(struct net_device *dev)
-{
-	int rc = 0;
-	struct ipw_priv *priv = libipw_priv(dev);
-
-	mutex_lock(&priv->mutex);
-	if (ipw_up(priv))
-		rc = -EIO;
-	mutex_unlock(&priv->mutex);
-
-	return rc;
-}
-
 static int ipw_wdev_init(struct net_device *dev)
 {
 	int i, rc = 0;
@@ -11722,7 +11708,6 @@ static void ipw_prom_free(struct ipw_pri
 #endif
 
 static const struct net_device_ops ipw_netdev_ops = {
-	.ndo_init		= ipw_net_init,
 	.ndo_open		= ipw_net_open,
 	.ndo_stop		= ipw_net_stop,
 	.ndo_set_rx_mode	= ipw_net_set_multicast_list,
@@ -11849,6 +11834,12 @@ static int __devinit ipw_pci_probe(struc
 		goto out_release_irq;
 	}
 
+	if (ipw_up(priv)) {
+		mutex_unlock(&priv->mutex);
+		err = -EIO;
+		goto out_remove_sysfs;
+	}
+
 	mutex_unlock(&priv->mutex);
 	err = register_netdev(net_dev);
 	if (err) {
 
 
--

To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Signature · 2 lines
[]'s
Herton
#11 lore raw

Re: [ 07/91] net/wireless: ipw2200: Fix WARN_ON occurring in wiphy_register called by ipw_pci_probe

Quoted 17 lines · Herton Ronaldo Krzesinski
Quoted 3 lines · Greg KH

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

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

As I see, this is not needed on 3.4.x or 3.3.x, since the commit "ipw2200: Fix order of device registration", wasn't included in 3.4 or any earlier kernels.

This is fixing an issue introduced on that commit ("ipw2200: Fix order of device registration"), that moved register_netdev after ipw_wdev_init, but ipw_wdev_init needs initialization made on ndo_init callback.

Unless there is any plan to include any of the "... Fix order of device registration" commits on 3.4 stable, I don't see any reason to include the fix for them.

Quoted 6 lines

Besides that, I noted that ipw2100 seems to need a similar fix as below after the change "ipw2100: Fix order of device registration". ipw2100 will have the same issue I expect: because ipw2100_wdev_init was moved before register_netdev, the ndo_init callback that runs ipw2100_up will only execute later with required initialization, after wiphy_register inside ipw2100_wdev_init runs.

[...]

Right.

As it happens, ipw2100 also has a comment explaining why .ndo_init is used now:

* If we called ipw2100_up before we registered the device, then the
* device name wasn't registered. So, we instead use the net_dev->init
* member to call a function that then just turns and calls ipw2100_up.
* net_dev->init is called after name allocation but before the
* notifier chain is called */

So this can result in log messages referring to "wlan%d" rather than the yet-to-be-determined device name. (That can be avoided by using netdev_printk, which will log the PCI address.)

If userland depends on the "phy80211" symlinks for wireless net devices in sysfs then all 4 fixes would be worth applying to stable. Otherwise, none of them should be applied.

Ben.

Signature · 3 lines
Ben Hutchings
The obvious mathematical breakthrough [to break modern encryption] would be
development of an easy way to factor large prime numbers. - Bill Gates
author maintainer
#12 lore raw

PATCH 8/91 cfg80211: warn if db.txt is empty with CONFIG_CFG80211_INTERNAL_REGDB

In reply to Greg KH

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

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

From: "Luis R. Rodriguez" <[email protected]>

commit 80007efeff0568375b08faf93c7aad65602cb97e upstream.

It has happened twice now where elaborate troubleshooting has undergone on systems where CONFIG_CFG80211_INTERNAL_REGDB [0] has been set but yet net/wireless/db.txt was not updated.

Despite the documentation on this it seems system integrators could use some more help with this, so throw out a kernel warning at boot time when their database is empty.

This does mean that the error-prone system integrator won't likely realize the issue until they boot the machine but -- it does not seem to make sense to enable a build bug breaking random build testing.

[0] http://wireless.kernel.org/en/developers/Regulatory/CRDA#CONFIG_CFG80211_INTERNAL_REGDB

---
 net/wireless/reg.c |   10 ++++++++++
 1 file changed, 10 insertions(+)
net/wireless/reg.c +10 -0
@@ -388,7 +388,15 @@ static void reg_regdb_query(const char *
 
 	schedule_work(&reg_regdb_work);
 }
+
+/* Feel free to add any other sanity checks here */
+static void reg_regdb_size_check(void)
+{
+	/* We should ideally BUILD_BUG_ON() but then random builds would fail */
+	WARN_ONCE(!reg_regdb_size, "db.txt is empty, you should update it...");
+}
 #else
+static inline void reg_regdb_size_check(void) {}
 static inline void reg_regdb_query(const char *alpha2) {}
 #endif /* CONFIG_CFG80211_INTERNAL_REGDB */
 
@@ -2322,6 +2330,8 @@ int __init regulatory_init(void)
 	spin_lock_init(&reg_requests_lock);
 	spin_lock_init(&reg_pending_beacons_lock);
 
+	reg_regdb_size_check();
+
 	cfg80211_regdomain = cfg80211_world_regdom;
 
 	user_alpha2[0] = '9';
author maintainer
#13 lore raw

PATCH 9/91 regulator: core: Release regulator-regulator supplies on error

In reply to Greg KH

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

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

From: Mark Brown <[email protected]>

commit e81dba85c6388dfabcb76cbc2b8bd02836a53ae5 upstream.

If we fail while registering a regulator make sure we release the supply for the regulator if there is one.

---
 drivers/regulator/core.c |    2 ++
 1 file changed, 2 insertions(+)
drivers/regulator/core.c +2 -0
@@ -2971,6 +2971,8 @@ unset_supplies:
 	unset_regulator_supplies(rdev);
 
 scrub:
+	if (rdev->supply)
+		regulator_put(rdev->supply);
 	kfree(rdev->constraints);
 	device_unregister(&rdev->dev);
 	/* device core frees rdev */
author maintainer
#14 lore raw

PATCH 10/91 Fix blocking allocations called very early during bootup

In reply to Greg KH

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

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

From: Linus Torvalds <[email protected]>

commit 31a67102f4762df5544bc2dfb34a931233d2a5b2 upstream.

During early boot, when the scheduler hasn't really been fully set up, we really can't do blocking allocations because with certain (dubious) configurations the "might_resched()" calls can actually result in scheduling events.

We could just make such users always use GFP_ATOMIC, but quite often the code that does the allocation isn't really aware of the fact that the scheduler isn't up yet, and forcing that kind of random knowledge on the initialization code is just annoying and not good for anybody.

And we actually have a the 'gfp_allowed_mask' exactly for this reason:
it's just that the kernel init sequence happens to set it to allow blocking allocations much too early.

So move the 'gfp_allowed_mask' initialization from 'start_kernel()' (which is some of the earliest init code, and runs with preemption disabled for good reasons) into 'kernel_init()'. kernel_init() is run in the newly created thread that will become the 'init' process, as opposed to the early startup code that runs within the context of what will be the first idle thread.

So by the time we reach 'kernel_init()', we know that the scheduler must be at least limping along, because we've already scheduled from the idle thread into the init thread.

---
 init/main.c |    7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)
init/main.c +4 -3
@@ -560,9 +560,6 @@ asmlinkage void __init start_kernel(void
 	early_boot_irqs_disabled = false;
 	local_irq_enable();
 
-	/* Interrupts are enabled now so all GFP allocations are safe. */
-	gfp_allowed_mask = __GFP_BITS_MASK;
-
 	kmem_cache_init_late();
 
 	/*
@@ -842,6 +839,10 @@ static int __init kernel_init(void * unu
 	 * Wait until kthreadd is all set-up.
 	 */
 	wait_for_completion(&kthreadd_done);
+
+	/* Now the scheduler is fully set up and can do blocking allocations */
+	gfp_allowed_mask = __GFP_BITS_MASK;
+
 	/*
 	 * init can allocate pages on any node
 	 */
author maintainer
#15 lore raw

PATCH 11/91 s390/pfault: fix task state race

In reply to Greg KH

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

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

From: Heiko Carstens <[email protected]>

commit d5e50a51ccbda36b379aba9d1131a852eb908dda upstream.

When setting the current task state to TASK_UNINTERRUPTIBLE this can race with a different cpu. The other cpu could set the task state after it inspected it (while it was still TASK_RUNNING) to TASK_RUNNING which would change the state from TASK_UNINTERRUPTIBLE to TASK_RUNNING again.

This race was always present in the pfault interrupt code but didn't cause anything harmful before commit f2db2e6c "[S390] pfault: cpu hotplug vs missing completion interrupts" which relied on the fact that after setting the task state to TASK_UNINTERRUPTIBLE the task would really sleep.
Since this is not necessarily the case the result may be a list corruption of the pfault_list or, as observed, a use-after-free bug while trying to access the task_struct of a task which terminated itself already.

To fix this, we need to get a reference of the affected task when receiving the initial pfault interrupt and add special handling if we receive yet another initial pfault interrupt when the task is already enqueued in the pfault list.

---
 arch/s390/mm/fault.c |   14 ++++++++++++--
 1 file changed, 12 insertions(+), 2 deletions(-)
arch/s390/mm/fault.c +12 -2
@@ -574,6 +574,7 @@ static void pfault_interrupt(struct ext_
 			tsk->thread.pfault_wait = 0;
 			list_del(&tsk->thread.list);
 			wake_up_process(tsk);
+			put_task_struct(tsk);
 		} else {
 			/* Completion interrupt was faster than initial
 			 * interrupt. Set pfault_wait to -1 so the initial
@@ -588,14 +589,22 @@ static void pfault_interrupt(struct ext_
 		put_task_struct(tsk);
 	} else {
 		/* signal bit not set -> a real page is missing. */
-		if (tsk->thread.pfault_wait == -1) {
+		if (tsk->thread.pfault_wait == 1) {
+			/* Already on the list with a reference: put to sleep */
+			set_task_state(tsk, TASK_UNINTERRUPTIBLE);
+			set_tsk_need_resched(tsk);
+		} else if (tsk->thread.pfault_wait == -1) {
 			/* Completion interrupt was faster than the initial
 			 * interrupt (pfault_wait == -1). Set pfault_wait
 			 * back to zero and exit. */
 			tsk->thread.pfault_wait = 0;
 		} else {
 			/* Initial interrupt arrived before completion
-			 * interrupt. Let the task sleep. */
+			 * interrupt. Let the task sleep.
+			 * An extra task reference is needed since a different
+			 * cpu may set the task state to TASK_RUNNING again
+			 * before the scheduler is reached. */
+			get_task_struct(tsk);
 			tsk->thread.pfault_wait = 1;
 			list_add(&tsk->thread.list, &pfault_list);
 			set_task_state(tsk, TASK_UNINTERRUPTIBLE);
@@ -620,6 +629,7 @@ static int __cpuinit pfault_cpu_notify(s
 			list_del(&thread->list);
 			tsk = container_of(thread, struct task_struct, thread);
 			wake_up_process(tsk);
+			put_task_struct(tsk);
 		}
 		spin_unlock_irq(&pfault_lock);
 		break;
author maintainer
#16 lore raw

PATCH 12/91 SCSI: mpt2sas: Fix for panic happening because of improper memory allocation

In reply to Greg KH

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

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

From: "[email protected]" <[email protected]>

commit e42fafc25fa86c61824e8d4c5e7582316415d24f upstream.

The ioc->pfacts member in the IOC structure is getting set to zero following a call to _base_get_ioc_facts due to the memset in that routine. So if the ioc->pfacts was read after a host reset, there would be a NULL pointer dereference. The routine _base_get_ioc_facts is called from context of host reset. The problem in _base_get_ioc_facts is the size of Mpi2IOCFactsReply is 64, whereas the sizeof "struct mpt2sas_facts" is 60, so there is a four byte overflow resulting from the memset.

Also, there is memset in _base_get_port_facts using the incorrect structure, it should be "struct mpt2sas_port_facts" instead of Mpi2PortFactsReply.

---
 drivers/scsi/mpt2sas/mpt2sas_base.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/scsi/mpt2sas/mpt2sas_base.c +3 -3
@@ -3343,7 +3343,7 @@ _base_get_port_facts(struct MPT2SAS_ADAP
 	}
 
 	pfacts = &ioc->pfacts[port];
-	memset(pfacts, 0, sizeof(Mpi2PortFactsReply_t));
+	memset(pfacts, 0, sizeof(struct mpt2sas_port_facts));
 	pfacts->PortNumber = mpi_reply.PortNumber;
 	pfacts->VP_ID = mpi_reply.VP_ID;
 	pfacts->VF_ID = mpi_reply.VF_ID;
@@ -3385,7 +3385,7 @@ _base_get_ioc_facts(struct MPT2SAS_ADAPT
 	}
 
 	facts = &ioc->facts;
-	memset(facts, 0, sizeof(Mpi2IOCFactsReply_t));
+	memset(facts, 0, sizeof(struct mpt2sas_facts));
 	facts->MsgVersion = le16_to_cpu(mpi_reply.MsgVersion);
 	facts->HeaderVersion = le16_to_cpu(mpi_reply.HeaderVersion);
 	facts->VP_ID = mpi_reply.VP_ID;
@@ -4262,7 +4262,7 @@ mpt2sas_base_attach(struct MPT2SAS_ADAPT
 		goto out_free_resources;
 
 	ioc->pfacts = kcalloc(ioc->facts.NumberOfPorts,
-	    sizeof(Mpi2PortFactsReply_t), GFP_KERNEL);
+	    sizeof(struct mpt2sas_port_facts), GFP_KERNEL);
 	if (!ioc->pfacts) {
 		r = -ENOMEM;
 		goto out_free_resources;
author maintainer
#17 lore raw

PATCH 13/91 isci: fix oem parameter validation on single controller skus

In reply to Greg KH

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

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

From: Dan Williams <[email protected]>

commit fc25f79af321c01a739150ba2c09435cf977a63d upstream.

OEM parameters [1] are parsed from the platform option-rom / efi driver. By default the driver was validating the parameters for the dual-controller case, but in single-controller case only the first set of parameters may be valid.

Limit the validation to the number of actual controllers detected otherwise the driver may fail to parse the valid parameters leading to driver-load or runtime failures.

[1] the platform specific set of phy address, configuration,and analog tuning values

---
 drivers/scsi/isci/init.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/scsi/isci/init.c +1 -1
@@ -476,7 +476,7 @@ static int __devinit isci_pci_probe(stru
 	if (!orom)
 		orom = isci_request_oprom(pdev);
 
-	for (i = 0; orom && i < ARRAY_SIZE(orom->ctrl); i++) {
+	for (i = 0; orom && i < num_controllers(pdev); i++) {
 		if (sci_oem_parameters_validate(&orom->ctrl[i],
 						orom->hdr.version)) {
 			dev_warn(&pdev->dev,
author maintainer
#18 lore raw

PATCH 14/91 RDMA/cxgb4: Always wake up waiters in c4iw_peer_abort_intr()

In reply to Greg KH

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

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

From: Steve Wise <[email protected]>

commit 0f1dcfae6bc5563424346ad3a03282b8235a4c33 upstream.

This fixes a race where an ingress abort fails to wake up the thread blocked in rdma_init() causing the app to hang.

---
 drivers/infiniband/hw/cxgb4/cm.c |    5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)
drivers/infiniband/hw/cxgb4/cm.c +1 -4
@@ -2667,11 +2667,8 @@ static int peer_abort_intr(struct c4iw_d
 
 	/*
 	 * Wake up any threads in rdma_init() or rdma_fini().
-	 * However, this is not needed if com state is just
-	 * MPA_REQ_SENT
 	 */
-	if (ep->com.state != MPA_REQ_SENT)
-		c4iw_wake_up(&ep->com.wr_wait, -ECONNRESET);
+	c4iw_wake_up(&ep->com.wr_wait, -ECONNRESET);
 	sched(dev, skb);
 	return 0;
 }
author maintainer
#19 lore raw

PATCH 15/91 RDMA/cxgb4: Use dst parameter in import_ep()

In reply to Greg KH

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

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

From: Steve Wise <[email protected]>

commit bd61baaf59669accae2720799394a51fecabe5d9 upstream.

Function import_ep() is incorrectly using ep->dst instead of the dst ptr passed in. This causes a crash when accepting new rdma connections becase ep->dst is not initialized yet.

---
 drivers/infiniband/hw/cxgb4/cm.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/infiniband/hw/cxgb4/cm.c +1 -1
@@ -1593,7 +1593,7 @@ static int import_ep(struct c4iw_ep *ep,
 					n, n->dev, 0);
 		if (!ep->l2t)
 			goto out;
-		ep->mtu = dst_mtu(ep->dst);
+		ep->mtu = dst_mtu(dst);
 		ep->tx_chan = cxgb4_port_chan(n->dev);
 		ep->smac_idx = (cxgb4_port_viid(n->dev) & 0x7F) << 1;
 		step = cdev->rdev.lldi.ntxq /
author maintainer
#20 lore raw

PATCH 16/91 RDMA/cxgb4: Drop peer_abort when no endpoint found

In reply to Greg KH

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

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

From: Steve Wise <[email protected]>

commit 14b9222808bb8bfefc71f72bc0dbdcf3b2f0140f upstream.

Log a warning and drop the abort message. Otherwise we will do a bogus wake_up() and crash.

---
 drivers/infiniband/hw/cxgb4/cm.c |    6 ++++++
 1 file changed, 6 insertions(+)
drivers/infiniband/hw/cxgb4/cm.c +6 -0
@@ -2656,6 +2656,12 @@ static int peer_abort_intr(struct c4iw_d
 	unsigned int tid = GET_TID(req);
 
 	ep = lookup_tid(t, tid);
+	if (!ep) {
+		printk(KERN_WARNING MOD
+		       "Abort on non-existent endpoint, tid %d\n", tid);
+		kfree_skb(skb);
+		return 0;
+	}
 	if (is_neg_adv_abort(req->status)) {
 		PDBG("%s neg_adv_abort ep %p tid %u\n", __func__, ep,
 		     ep->hwtid);
author maintainer
#21 lore raw

PATCH 17/91 powerpc: Fix broken cpu_idle_wait() implementation

In reply to Greg KH

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

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

From: Thomas Gleixner <[email protected]>

commit 9cd75e13de2dcf32ecc21c7f277cff3c0ced059e upstream.

commit 771dae818 (powerpc/cpuidle: Add cpu_idle_wait() to allow switching of idle routines) implemented cpu_idle_wait() for powerpc.

The changelog says:
"The equivalent routine for x86 is in arch/x86/kernel/process.c
but the powerpc implementation is different.":

Unfortunately the changelog is completely useless as it does not tell _WHY_ it is different.

Aside of being different the implementation is patently wrong.

The rescheduling IPI is async. That means that there is no guarantee, that the other cores have executed the IPI when cpu_idle_wait() returns. But that's the whole purpose of this function: to guarantee that no CPU uses the old idle handler anymore.

Use the smp_functional_call() based implementation, which fulfils the requirements.

[ This code is going to replaced by a core version to remove all the
pointless copies in arch/*, but this one should go to stable ]

---
 arch/powerpc/kernel/idle.c |   14 +++++---------
 1 file changed, 5 insertions(+), 9 deletions(-)
arch/powerpc/kernel/idle.c +5 -9
@@ -113,6 +113,9 @@ void cpu_idle(void)
 	}
 }
 
+static void do_nothing(void *unused)
+{
+}
 
 /*
  * cpu_idle_wait - Used to ensure that all the CPUs come out of the old
@@ -123,16 +126,9 @@ void cpu_idle(void)
  */
 void cpu_idle_wait(void)
 {
-	int cpu;
 	smp_mb();
-
-	/* kick all the CPUs so that they exit out of old idle routine */
-	get_online_cpus();
-	for_each_online_cpu(cpu) {
-		if (cpu != smp_processor_id())
-			smp_send_reschedule(cpu);
-	}
-	put_online_cpus();
+	/* kick all the CPUs so that they exit out of pm_idle */
+	smp_call_function(do_nothing, NULL, 1);
 }
 EXPORT_SYMBOL_GPL(cpu_idle_wait);
 
author maintainer
#22 lore raw

PATCH 18/91 KEYS: Use the compat keyctl() syscall wrapper on Sparc64 for Sparc32 compat

In reply to Greg KH

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

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

From: David Howells <[email protected]>

commit 45de6767dc51358a188f75dc4ad9dfddb7fb9480 upstream.

Use the 32-bit compat keyctl() syscall wrapper on Sparc64 for Sparc32 binary compatibility.

Without this, keyctl(KEYCTL_INSTANTIATE_IOV) is liable to malfunction as it uses an iovec array read from userspace - though the kernel should survive this as it checks pointers and sizes anyway.

I think all the other keyctl() function should just work, provided (a) the top 32-bits of each 64-bit argument register are cleared prior to invoking the syscall routine, and the 32-bit address space is right at the 0-end of the 64-bit address space. Most of the arguments are 32-bit anyway, and so for those clearing is not required.

---
 arch/sparc/Kconfig             |    3 +++
 arch/sparc/kernel/systbls_64.S |    2 +-
 2 files changed, 4 insertions(+), 1 deletion(-)
arch/sparc/Kconfig +3 -0
@@ -584,6 +584,9 @@ config SYSVIPC_COMPAT
 	depends on COMPAT && SYSVIPC
 	default y
 
+config KEYS_COMPAT
+	def_bool y if COMPAT && KEYS
+
 endmenu
 
 source "net/Kconfig"
arch/sparc/kernel/systbls_64.S +1 -1
@@ -74,7 +74,7 @@ sys_call_table32:
 	.word sys_timer_delete, compat_sys_timer_create, sys_ni_syscall, compat_sys_io_setup, sys_io_destroy
 /*270*/	.word sys32_io_submit, sys_io_cancel, compat_sys_io_getevents, sys32_mq_open, sys_mq_unlink
 	.word compat_sys_mq_timedsend, compat_sys_mq_timedreceive, compat_sys_mq_notify, compat_sys_mq_getsetattr, compat_sys_waitid
-/*280*/	.word sys32_tee, sys_add_key, sys_request_key, sys_keyctl, compat_sys_openat
+/*280*/	.word sys32_tee, sys_add_key, sys_request_key, compat_sys_keyctl, compat_sys_openat
 	.word sys_mkdirat, sys_mknodat, sys_fchownat, compat_sys_futimesat, compat_sys_fstatat64
 /*290*/	.word sys_unlinkat, sys_renameat, sys_linkat, sys_symlinkat, sys_readlinkat
 	.word sys_fchmodat, sys_faccessat, compat_sys_pselect6, compat_sys_ppoll, sys_unshare
author maintainer
#23 lore raw

PATCH 19/91 SELinux: if sel_make_bools errors dont leave inconsistent state

In reply to Greg KH

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

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

From: Eric Paris <[email protected]>

commit 154c50ca4eb9ae472f50b6a481213e21ead4457d upstream.

We reset the bool names and values array to NULL, but do not reset the number of entries in these arrays to 0. If we error out and then get back into this function we will walk these NULL pointers based on the belief that they are non-zero length.

---
 security/selinux/selinuxfs.c |    1 +
 1 file changed, 1 insertion(+)
security/selinux/selinuxfs.c +1 -0
@@ -1232,6 +1232,7 @@ static int sel_make_bools(void)
 		kfree(bool_pending_names[i]);
 	kfree(bool_pending_names);
 	kfree(bool_pending_values);
+	bool_num = 0;
 	bool_pending_names = NULL;
 	bool_pending_values = NULL;
 
author maintainer
#24 lore raw

PATCH 20/91 fbdev: sh_mobile_lcdc: Dont confuse line size with pitch

In reply to Greg KH

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

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

From: Laurent Pinchart <[email protected]>

commit 72c04af9a2d57b7945cf3de8e71461bd80695d50 upstream.

When using the MERAM the LCDC line size needs to be programmed with a MERAM-specific value different than the real frame buffer pitch. Fix it.

---
 drivers/video/sh_mobile_lcdcfb.c |    5 +++--
 drivers/video/sh_mobile_lcdcfb.h |    1 +
 2 files changed, 4 insertions(+), 2 deletions(-)
drivers/video/sh_mobile_lcdcfb.c +3 -2
@@ -758,7 +758,7 @@ static void __sh_mobile_lcdc_start(struc
 		}
 
 		lcdc_write_chan(ch, LDDFR, tmp);
-		lcdc_write_chan(ch, LDMLSR, ch->pitch);
+		lcdc_write_chan(ch, LDMLSR, ch->line_size);
 		lcdc_write_chan(ch, LDSA1R, ch->base_addr_y);
 		if (ch->format->yuv)
 			lcdc_write_chan(ch, LDSA2R, ch->base_addr_c);
@@ -847,6 +847,7 @@ static int sh_mobile_lcdc_start(struct s
 
 		ch->base_addr_y = ch->dma_handle;
 		ch->base_addr_c = ch->base_addr_y + ch->xres * ch->yres_virtual;
+		ch->line_size = ch->pitch;
 
 		/* Enable MERAM if possible. */
 		if (mdev == NULL || mdev->ops == NULL ||
@@ -882,7 +883,7 @@ static int sh_mobile_lcdc_start(struct s
 
 		meram = mdev->ops->meram_register(mdev, ch->cfg->meram_cfg,
 					ch->pitch, ch->yres, pixelformat,
-					&ch->pitch);
+					&ch->line_size);
 		if (!IS_ERR(meram)) {
 			mdev->ops->meram_update(mdev, meram,
 					ch->base_addr_y, ch->base_addr_c,
drivers/video/sh_mobile_lcdcfb.h +1 -0
@@ -84,6 +84,7 @@ struct sh_mobile_lcdc_chan {
 
 	unsigned long base_addr_y;
 	unsigned long base_addr_c;
+	unsigned int line_size;
 
 	int (*notify)(struct sh_mobile_lcdc_chan *ch,
 		      enum sh_mobile_lcdc_entity_event event,
author maintainer
#25 lore raw

PATCH 21/91 IB/core: Fix mismatch between locked and pinned pages

In reply to Greg KH

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

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

From: Yishai Hadas <[email protected]>

commit c4870eb874ac16dccef40e1bc7a002c7e9156adc upstream.

Commit bc3e53f682d9 ("mm: distinguish between mlocked and pinned pages") introduced a separate counter for pinned pages and used it in the IB stack. However, in ib_umem_get() the pinned counter is incremented, but ib_umem_release() wrongly decrements the locked counter. Fix this.

---
 drivers/infiniband/core/umem.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/infiniband/core/umem.c +1 -1
@@ -269,7 +269,7 @@ void ib_umem_release(struct ib_umem *ume
 	} else
 		down_write(&mm->mmap_sem);
 
-	current->mm->locked_vm -= diff;
+	current->mm->pinned_vm -= diff;
 	up_write(&mm->mmap_sem);
 	mmput(mm);
 	kfree(umem);
author maintainer
#26 lore raw

PATCH 22/91 drivers/staging/comedi/comedi_fops.c: add missing vfree

In reply to Greg KH

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

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

From: Julia Lawall <[email protected]>

commit abae41e6438b798e046d721b6ccdd55b4a398170 upstream.

aux_free is freed on all other exits from the function. By removing the return, we can benefit from the vfree already at the end of the function.

---
 drivers/staging/comedi/comedi_fops.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/staging/comedi/comedi_fops.c +1 -1
@@ -280,7 +280,7 @@ static int do_devconfig_ioctl(struct com
 	if (ret == 0) {
 		if (!try_module_get(dev->driver->module)) {
 			comedi_device_detach(dev);
-			return -ENOSYS;
+			ret = -ENOSYS;
 		}
 	}
 
author maintainer
#27 lore raw

PATCH 23/91 perf/x86: Update event scheduling constraints for AMD family 15h models

In reply to Greg KH

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

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

From: Robert Richter <[email protected]>

commit 5bcdf5e4fee3c45e1281c25e4941f2163cb28c65 upstream.

This update is for newer family 15h cpu models from 0x02 to 0x1f.

---
 arch/x86/kernel/cpu/perf_event_amd.c |   11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)
arch/x86/kernel/cpu/perf_event_amd.c +10 -1
@@ -493,6 +493,7 @@ static __initconst const struct x86_pmu
  * 0x023	DE	PERF_CTL[2:0]
  * 0x02D	LS	PERF_CTL[3]
  * 0x02E	LS	PERF_CTL[3,0]
+ * 0x031	LS	PERF_CTL[2:0] (**)
  * 0x043	CU	PERF_CTL[2:0]
  * 0x045	CU	PERF_CTL[2:0]
  * 0x046	CU	PERF_CTL[2:0]
@@ -506,10 +507,12 @@ static __initconst const struct x86_pmu
  * 0x0DD	LS	PERF_CTL[5:0]
  * 0x0DE	LS	PERF_CTL[5:0]
  * 0x0DF	LS	PERF_CTL[5:0]
+ * 0x1C0	EX	PERF_CTL[5:3]
  * 0x1D6	EX	PERF_CTL[5:0]
  * 0x1D8	EX	PERF_CTL[5:0]
  *
- * (*) depending on the umask all FPU counters may be used
+ * (*)  depending on the umask all FPU counters may be used
+ * (**) only one unitmask enabled at a time
  */
 
 static struct event_constraint amd_f15_PMC0  = EVENT_CONSTRAINT(0, 0x01, 0);
@@ -559,6 +562,12 @@ amd_get_event_constraints_f15h(struct cp
 			return &amd_f15_PMC3;
 		case 0x02E:
 			return &amd_f15_PMC30;
+		case 0x031:
+			if (hweight_long(hwc->config & ARCH_PERFMON_EVENTSEL_UMASK) <= 1)
+				return &amd_f15_PMC20;
+			return &emptyconstraint;
+		case 0x1C0:
+			return &amd_f15_PMC53;
 		default:
 			return &amd_f15_PMC50;
 		}
author maintainer
#28 lore raw

PATCH 24/91 HID: wiimote: Fix IR data parser

In reply to Greg KH

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

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

From: David Herrmann <[email protected]>

commit 74b89e8a3625c17c7452532dfb997ac4f1a38751 upstream.

We incorrectly parse incoming IR data. The extra byte contains the upper bits and not the lower bits of the x/y coordinates. User-space expects absolute position data from us so this patch does not break existing applications. On the contrary, it extends the virtual view and fixes garbage reports for margin areas of the virtual screen.

---
 drivers/hid/hid-wiimote-core.c |   16 +++++-----------
 1 file changed, 5 insertions(+), 11 deletions(-)
drivers/hid/hid-wiimote-core.c +5 -11
@@ -769,7 +769,7 @@ static void __ir_to_input(struct wiimote
 
 	/*
 	 * Basic IR data is encoded into 3 bytes. The first two bytes are the
-	 * upper 8 bit of the X/Y data, the 3rd byte contains the lower 2 bits
+	 * lower 8 bit of the X/Y data, the 3rd byte contains the upper 2 bits
 	 * of both.
 	 * If data is packed, then the 3rd byte is put first and slightly
 	 * reordered. This allows to interleave packed and non-packed data to
@@ -778,17 +778,11 @@ static void __ir_to_input(struct wiimote
 	 */
 
 	if (packed) {
-		x = ir[1] << 2;
-		y = ir[2] << 2;
-
-		x |= ir[0] & 0x3;
-		y |= (ir[0] >> 2) & 0x3;
+		x = ir[1] | ((ir[0] & 0x03) << 8);
+		y = ir[2] | ((ir[0] & 0x0c) << 6);
 	} else {
-		x = ir[0] << 2;
-		y = ir[1] << 2;
-
-		x |= (ir[2] >> 4) & 0x3;
-		y |= (ir[2] >> 6) & 0x3;
+		x = ir[0] | ((ir[2] & 0x30) << 4);
+		y = ir[1] | ((ir[2] & 0xc0) << 2);
 	}
 
 	input_report_abs(wdata->ir, xid, x);
author maintainer
#29 lore raw

PATCH 25/91 usbhid: prevent deadlock during timeout

In reply to Greg KH

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

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

From: Oliver Neukum <[email protected]>

commit 8815bb09af21316aeb5f8948b24ac62181670db2 upstream.

On some HCDs usb_unlink_urb() can directly call the completion handler. That limits the spinlocks that can be taken in the handler to locks not held while calling usb_unlink_urb()
To prevent a race with resubmission, this patch exposes usbcore's infrastructure for blocking submission, uses it and so drops the lock without causing a race in usbhid.

---
 drivers/hid/usbhid/hid-core.c |   61 +++++++++++++++++++++++++++++++++++++-----
 drivers/usb/core/urb.c        |   21 ++++++++++++++
 include/linux/usb.h           |    3 ++
 3 files changed, 79 insertions(+), 6 deletions(-)
drivers/hid/usbhid/hid-core.c +55 -6
@@ -399,6 +399,16 @@ static int hid_submit_ctrl(struct hid_de
  * Output interrupt completion handler.
  */
 
+static int irq_out_pump_restart(struct hid_device *hid)
+{
+	struct usbhid_device *usbhid = hid->driver_data;
+
+	if (usbhid->outhead != usbhid->outtail)
+		return hid_submit_out(hid);
+	else
+		return -1;
+}
+
 static void hid_irq_out(struct urb *urb)
 {
 	struct hid_device *hid = urb->context;
@@ -428,7 +438,7 @@ static void hid_irq_out(struct urb *urb)
 	else
 		usbhid->outtail = (usbhid->outtail + 1) & (HID_OUTPUT_FIFO_SIZE - 1);
 
-	if (usbhid->outhead != usbhid->outtail && !hid_submit_out(hid)) {
+	if (!irq_out_pump_restart(hid)) {
 		/* Successfully submitted next urb in queue */
 		spin_unlock_irqrestore(&usbhid->lock, flags);
 		return;
@@ -443,6 +453,15 @@ static void hid_irq_out(struct urb *urb)
 /*
  * Control pipe completion handler.
  */
+static int ctrl_pump_restart(struct hid_device *hid)
+{
+	struct usbhid_device *usbhid = hid->driver_data;
+
+	if (usbhid->ctrlhead != usbhid->ctrltail)
+		return hid_submit_ctrl(hid);
+	else
+		return -1;
+}
 
 static void hid_ctrl(struct urb *urb)
 {
@@ -476,7 +495,7 @@ static void hid_ctrl(struct urb *urb)
 	else
 		usbhid->ctrltail = (usbhid->ctrltail + 1) & (HID_CONTROL_FIFO_SIZE - 1);
 
-	if (usbhid->ctrlhead != usbhid->ctrltail && !hid_submit_ctrl(hid)) {
+	if (!ctrl_pump_restart(hid)) {
 		/* Successfully submitted next urb in queue */
 		spin_unlock(&usbhid->lock);
 		return;
@@ -535,11 +554,27 @@ static void __usbhid_submit_report(struc
 			 * the queue is known to run
 			 * but an earlier request may be stuck
 			 * we may need to time out
-			 * no race because this is called under
+			 * no race because the URB is blocked under
 			 * spinlock
 			 */
-			if (time_after(jiffies, usbhid->last_out + HZ * 5))
+			if (time_after(jiffies, usbhid->last_out + HZ * 5)) {
+				usb_block_urb(usbhid->urbout);
+				/* drop lock to not deadlock if the callback is called */
+				spin_unlock(&usbhid->lock);
 				usb_unlink_urb(usbhid->urbout);
+				spin_lock(&usbhid->lock);
+				usb_unblock_urb(usbhid->urbout);
+				/*
+				 * if the unlinking has already completed
+				 * the pump will have been stopped
+				 * it must be restarted now
+				 */
+				if (!test_bit(HID_OUT_RUNNING, &usbhid->iofl))
+					if (!irq_out_pump_restart(hid))
+						set_bit(HID_OUT_RUNNING, &usbhid->iofl);
+
+
+			}
 		}
 		return;
 	}
@@ -583,11 +618,25 @@ static void __usbhid_submit_report(struc
 		 * the queue is known to run
 		 * but an earlier request may be stuck
 		 * we may need to time out
-		 * no race because this is called under
+		 * no race because the URB is blocked under
 		 * spinlock
 		 */
-		if (time_after(jiffies, usbhid->last_ctrl + HZ * 5))
+		if (time_after(jiffies, usbhid->last_ctrl + HZ * 5)) {
+			usb_block_urb(usbhid->urbctrl);
+			/* drop lock to not deadlock if the callback is called */
+			spin_unlock(&usbhid->lock);
 			usb_unlink_urb(usbhid->urbctrl);
+			spin_lock(&usbhid->lock);
+			usb_unblock_urb(usbhid->urbctrl);
+			/*
+			 * if the unlinking has already completed
+			 * the pump will have been stopped
+			 * it must be restarted now
+			 */
+			if (!test_bit(HID_CTRL_RUNNING, &usbhid->iofl))
+				if (!ctrl_pump_restart(hid))
+					set_bit(HID_CTRL_RUNNING, &usbhid->iofl);
+		}
 	}
 }
 
drivers/usb/core/urb.c +21 -0
@@ -681,6 +681,27 @@ void usb_unpoison_urb(struct urb *urb)
 EXPORT_SYMBOL_GPL(usb_unpoison_urb);
 
 /**
+ * usb_block_urb - reliably prevent further use of an URB
+ * @urb: pointer to URB to be blocked, may be NULL
+ *
+ * After the routine has run, attempts to resubmit the URB will fail
+ * with error -EPERM.  Thus even if the URB's completion handler always
+ * tries to resubmit, it will not succeed and the URB will become idle.
+ *
+ * The URB must not be deallocated while this routine is running.  In
+ * particular, when a driver calls this routine, it must insure that the
+ * completion handler cannot deallocate the URB.
+ */
+void usb_block_urb(struct urb *urb)
+{
+	if (!urb)
+		return;
+
+	atomic_inc(&urb->reject);
+}
+EXPORT_SYMBOL_GPL(usb_block_urb);
+
+/**
  * usb_kill_anchored_urbs - cancel transfer requests en masse
  * @anchor: anchor the requests are bound to
  *
include/linux/usb.h +3 -0
@@ -1379,6 +1379,7 @@ extern int usb_unlink_urb(struct urb *ur
 extern void usb_kill_urb(struct urb *urb);
 extern void usb_poison_urb(struct urb *urb);
 extern void usb_unpoison_urb(struct urb *urb);
+extern void usb_block_urb(struct urb *urb);
 extern void usb_kill_anchored_urbs(struct usb_anchor *anchor);
 extern void usb_poison_anchored_urbs(struct usb_anchor *anchor);
 extern void usb_unpoison_anchored_urbs(struct usb_anchor *anchor);
@@ -1391,6 +1392,8 @@ extern struct urb *usb_get_from_anchor(s
 extern void usb_scuttle_anchored_urbs(struct usb_anchor *anchor);
 extern int usb_anchor_empty(struct usb_anchor *anchor);
 
+#define usb_unblock_urb	usb_unpoison_urb
+
 /**
  * usb_urb_dir_in - check if an URB describes an IN transfer
  * @urb: URB to be checked
author maintainer
#30 lore raw

PATCH 26/91 HID: logitech: read all 32 bits of report type bitfield

In reply to Greg KH

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

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

From: Jonathan Nieder <[email protected]>

commit 44d27f7dfedd9aadc082cda31462f6600f56e4ec upstream.

On big-endian systems (e.g., Apple PowerBook), trying to use a logitech wireless mouse with the Logitech Unifying Receiver does not work with v3.2 and later kernels. The device doesn't show up in /dev/input. Older kernels work fine.

That is because the new hid-logitech-dj driver claims the device. The device arrival notification appears:

	20 00 41 02 00 00 00 00 00 00 00 00 00 00 00

and we read the report_types bitfield (02 00 00 00) to find out what kind of device it is. Unfortunately the driver only reads the first 8 bits and treats that value as a 32-bit little-endian number, so on a powerpc the report type seems to be 0x02000000 and is not recognized.

Even on little-endian machines, connecting a media center remote control (report type 00 01 00 00) with this driver loaded would presumably fail for the same reason.

Fix both problems by using get_unaligned_le32() to read all four bytes, which is a little clearer anyway. After this change, the wireless mouse works on Hugo's PowerBook again.

Based on a patch by Nestor Lopez Casado.
Addresses http://bugs.debian.org/671292

---
 drivers/hid/hid-logitech-dj.c |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)
drivers/hid/hid-logitech-dj.c +3 -2
@@ -26,6 +26,7 @@
 #include <linux/hid.h>
 #include <linux/module.h>
 #include <linux/usb.h>
+#include <asm/unaligned.h>
 #include "usbhid/usbhid.h"
 #include "hid-ids.h"
 #include "hid-logitech-dj.h"
@@ -265,8 +266,8 @@ static void logi_dj_recv_add_djhid_devic
 		goto dj_device_allocate_fail;
 	}
 
-	dj_dev->reports_supported = le32_to_cpu(
-		dj_report->report_params[DEVICE_PAIRED_RF_REPORT_TYPE]);
+	dj_dev->reports_supported = get_unaligned_le32(
+		dj_report->report_params + DEVICE_PAIRED_RF_REPORT_TYPE);
 	dj_dev->hdev = dj_hiddev;
 	dj_dev->dj_receiver_dev = djrcv_dev;
 	dj_dev->device_index = dj_report->device_index;
author maintainer
#31 lore raw

PATCH 27/91 um: Fix __swp_type()

In reply to Greg KH

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

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

From: Richard Weinberger <[email protected]>

commit 2b76ebaa728f8a3967c52aa189261c72fe56a6f1 upstream.

The current __swp_type() function uses a too small bitshift. Using more than one swap files causes bad pages because the type bits clash with other page flags.

---
 arch/um/include/asm/pgtable.h |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
arch/um/include/asm/pgtable.h +2 -2
@@ -348,11 +348,11 @@ extern pte_t *virt_to_pte(struct mm_stru
 #define update_mmu_cache(vma,address,ptep) do ; while (0)
 
 /* Encode and de-code a swap entry */
-#define __swp_type(x)			(((x).val >> 4) & 0x3f)
+#define __swp_type(x)			(((x).val >> 5) & 0x1f)
 #define __swp_offset(x)			((x).val >> 11)
 
 #define __swp_entry(type, offset) \
-	((swp_entry_t) { ((type) << 4) | ((offset) << 11) })
+	((swp_entry_t) { ((type) << 5) | ((offset) << 11) })
 #define __pte_to_swp_entry(pte) \
 	((swp_entry_t) { pte_val(pte_mkuptodate(pte)) })
 #define __swp_entry_to_pte(x)		((pte_t) { (x).val })
author maintainer
#32 lore raw

PATCH 28/91 um: Implement a custom pte_same() function

In reply to Greg KH

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

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

From: Richard Weinberger <[email protected]>

commit f15b9000eb1d09bbaa4b0a6b2089d7e1f64e84b3 upstream.

UML uses the _PAGE_NEWPAGE flag to mark pages which are not jet installed on the host side using mmap().
pte_same() has to ignore this flag, otherwise unuse_pte_range() is unable to unuse the page because two identical
page tables entries with different _PAGE_NEWPAGE flags would not match and swapoff() would never return.

---
 arch/um/include/asm/pgtable.h |    6 ++++++
 1 file changed, 6 insertions(+)
arch/um/include/asm/pgtable.h +6 -0
@@ -273,6 +273,12 @@ static inline void set_pte(pte_t *pteptr
 }
 #define set_pte_at(mm,addr,ptep,pteval) set_pte(ptep,pteval)
 
+#define __HAVE_ARCH_PTE_SAME
+static inline int pte_same(pte_t pte_a, pte_t pte_b)
+{
+	return !((pte_val(pte_a) ^ pte_val(pte_b)) & ~_PAGE_NEWPAGE);
+}
+
 /*
  * Conversion functions: convert a page and protection to a page entry,
  * and a page entry and page directory to the page they refer to.
author maintainer
#33 lore raw

PATCH 29/91 persistent_ram: Fix buffer size clamping during writes

In reply to Greg KH

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

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

From: Anton Vorontsov <[email protected]>

commit 484dd30e016eb425b0de871357fff2c9bb93be45 upstream.

This is a longstanding bug, almost unnoticeable when calling persistent_ram_write() for small buffers.

But when called for large data buffers, the write routine behaves incorrectly, as the size may never update: instead of clamping the size to the maximum buffer size, buffer_size_add_clamp() returns an error (which is never checked by the write routine, btw).

To fix this, we now use buffer_size_add() that actually clamps the size to the max value.

Also remove buffer_size_add_clamp(), it is no longer needed.

---
 drivers/staging/android/persistent_ram.c |   19 +------------------
 1 file changed, 1 insertion(+), 18 deletions(-)
drivers/staging/android/persistent_ram.c +1 -18
@@ -79,23 +79,6 @@ static inline void buffer_size_add(struc
 	} while (atomic_cmpxchg(&prz->buffer->size, old, new) != old);
 }
 
-/* increase the size counter, retuning an error if it hits the max size */
-static inline ssize_t buffer_size_add_clamp(struct persistent_ram_zone *prz,
-	size_t a)
-{
-	size_t old;
-	size_t new;
-
-	do {
-		old = atomic_read(&prz->buffer->size);
-		new = old + a;
-		if (new > prz->buffer_size)
-			return -ENOMEM;
-	} while (atomic_cmpxchg(&prz->buffer->size, old, new) != old);
-
-	return 0;
-}
-
 static void notrace persistent_ram_encode_rs8(struct persistent_ram_zone *prz,
 	uint8_t *data, size_t len, uint8_t *ecc)
 {
@@ -300,7 +283,7 @@ int notrace persistent_ram_write(struct
 		c = prz->buffer_size;
 	}
 
-	buffer_size_add_clamp(prz, c);
+	buffer_size_add(prz, c);
 
 	start = buffer_start_add(prz, c);
 
author maintainer
#34 lore raw

PATCH 30/91 docs: update HOWTO for 2.6.x -> 3.x versioning

In reply to Greg KH

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

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

From: Kees Cook <[email protected]>

commit 591bfc6bf9e5e25e464fd4c87d64afd5135667c4 upstream.

The HOWTO document needed updating for the new kernel versioning. The git URI for -next was updated as well.

---
 Documentation/HOWTO |   32 ++++++++++++++++----------------
 1 file changed, 16 insertions(+), 16 deletions(-)
Documentation/HOWTO +16 -16
@@ -218,16 +218,16 @@ The development process
 Linux kernel development process currently consists of a few different
 main kernel "branches" and lots of different subsystem-specific kernel
 branches.  These different branches are:
-  - main 2.6.x kernel tree
-  - 2.6.x.y -stable kernel tree
-  - 2.6.x -git kernel patches
+  - main 3.x kernel tree
+  - 3.x.y -stable kernel tree
+  - 3.x -git kernel patches
   - subsystem specific kernel trees and patches
-  - the 2.6.x -next kernel tree for integration tests
+  - the 3.x -next kernel tree for integration tests
 
-2.6.x kernel tree
+3.x kernel tree
 -----------------
-2.6.x kernels are maintained by Linus Torvalds, and can be found on
-kernel.org in the pub/linux/kernel/v2.6/ directory.  Its development
+3.x kernels are maintained by Linus Torvalds, and can be found on
+kernel.org in the pub/linux/kernel/v3.x/ directory.  Its development
 process is as follows:
   - As soon as a new kernel is released a two weeks window is open,
     during this period of time maintainers can submit big diffs to
@@ -262,20 +262,20 @@ mailing list about kernel releases:
 	released according to perceived bug status, not according to a
 	preconceived timeline."
 
-2.6.x.y -stable kernel tree
+3.x.y -stable kernel tree
 ---------------------------
-Kernels with 4-part versions are -stable kernels. They contain
+Kernels with 3-part versions are -stable kernels. They contain
 relatively small and critical fixes for security problems or significant
-regressions discovered in a given 2.6.x kernel.
+regressions discovered in a given 3.x kernel.
 
 This is the recommended branch for users who want the most recent stable
 kernel and are not interested in helping test development/experimental
 versions.
 
-If no 2.6.x.y kernel is available, then the highest numbered 2.6.x
+If no 3.x.y kernel is available, then the highest numbered 3.x
 kernel is the current stable kernel.
 
-2.6.x.y are maintained by the "stable" team <[email protected]>, and
+3.x.y are maintained by the "stable" team <[email protected]>, 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
@@ -285,7 +285,7 @@ The file Documentation/stable_kernel_rul
 documents what kinds of changes are acceptable for the -stable tree, and
 how the release process works.
 
-2.6.x -git patches
+3.x -git patches
 ------------------
 These are daily snapshots of Linus' kernel tree which are managed in a
 git repository (hence the name.) These patches are usually released
@@ -317,13 +317,13 @@ revisions to it, and maintainers can mar
 accepted, or rejected.  Most of these patchwork sites are listed at
 http://patchwork.kernel.org/.
 
-2.6.x -next kernel tree for integration tests
+3.x -next kernel tree for integration tests
 ---------------------------------------------
-Before updates from subsystem trees are merged into the mainline 2.6.x
+Before updates from subsystem trees are merged into the mainline 3.x
 tree, they need to be integration-tested.  For this purpose, a special
 testing repository exists into which virtually all subsystem trees are
 pulled on an almost daily basis:
-	http://git.kernel.org/?p=linux/kernel/git/sfr/linux-next.git
+	http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git
 	http://linux.f-seidel.de/linux-next/pmwiki/
 
 This way, the -next kernel gives a summary outlook onto what will be
author maintainer
#35 lore raw

PATCH 31/91 USB: cdc-wdm: sanitize error returns

In reply to Greg KH

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

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

From: Oliver Neukum <[email protected]>

commit 24a85bae5da2b43fed423859c09c5a81ab359473 upstream.

wdm_flush() returns unsanitized USB error codes. They must be cleaned up to before being anded to user space

---
 drivers/usb/class/cdc-wdm.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/usb/class/cdc-wdm.c +1 -1
@@ -534,7 +534,7 @@ static int wdm_flush(struct file *file,
 		dev_err(&desc->intf->dev, "Error in flush path: %d\n",
 			desc->werr);
 
-	return desc->werr;
+	return usb_translate_errors(desc->werr);
 }
 
 static unsigned int wdm_poll(struct file *file, struct poll_table_struct *wait)
author maintainer
#36 lore raw

PATCH 32/91 USB: cdc-wdm: fix memory leak

In reply to Greg KH

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

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

From: Oliver Neukum <[email protected]>

commit 2f338c8a1904e2e7aa5a8bd12fb0cf2422d17da4 upstream.

cleanup() is not called if the last close() comes after disconnect(). That leads to a memory leak. Rectified by checking for an earlier disconnect() in release()

---
 drivers/usb/class/cdc-wdm.c |    2 ++
 1 file changed, 2 insertions(+)
drivers/usb/class/cdc-wdm.c +2 -0
@@ -625,6 +625,8 @@ static int wdm_release(struct inode *ino
 		kill_urbs(desc);
 		if (!test_bit(WDM_DISCONNECTING, &desc->flags))
 			desc->manage_power(desc->intf, 0);
+		else
+			cleanup(desc);
 	}
 	mutex_unlock(&wdm_mutex);
 	return 0;
author maintainer
#37 lore raw

PATCH 33/91 USB: cdc-wdm: poll must return POLLHUP if device is gone

In reply to Greg KH

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

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

From: Bjørn Mork <[email protected]>

commit 616b6937e348ef2b4c6ea5fef2cd3c441145efb0 upstream.

Else the poll will be restarted indefinitely in a tight loop, preventing final device cleanup.

---
 drivers/usb/class/cdc-wdm.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/usb/class/cdc-wdm.c +1 -1
@@ -545,7 +545,7 @@ static unsigned int wdm_poll(struct file
 
 	spin_lock_irqsave(&desc->iuspin, flags);
 	if (test_bit(WDM_DISCONNECTING, &desc->flags)) {
-		mask = POLLERR;
+		mask = POLLHUP | POLLERR;
 		spin_unlock_irqrestore(&desc->iuspin, flags);
 		goto desc_out;
 	}
author maintainer
#38 lore raw

PATCH 34/91 USB: cdc-wdm: cannot use dev_printk when device is gone

In reply to Greg KH

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

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

From: Bjørn Mork <[email protected]>

commit 6b0b79d38806481c1c8fffa7c5842f3c83679a42 upstream.

We cannot dereference a removed USB interface for dev_printk. Use pr_debug instead where necessary.

Flush errors are expected if device is unplugged and are therefore best ingored at this point.

Move the kill_urbs() call in wdm_release with dev_dbg() for the non disconnect, as we know it has already been called if WDM_DISCONNECTING is set. This does not actually fix anything, but keeps the code more consistent.

---
 drivers/usb/class/cdc-wdm.c |   15 ++++++++++-----
 1 file changed, 10 insertions(+), 5 deletions(-)
drivers/usb/class/cdc-wdm.c +10 -5
@@ -530,7 +530,9 @@ static int wdm_flush(struct file *file,
 	struct wdm_device *desc = file->private_data;
 
 	wait_event(desc->wait, !test_bit(WDM_IN_USE, &desc->flags));
-	if (desc->werr < 0)
+
+	/* cannot dereference desc->intf if WDM_DISCONNECTING */
+	if (desc->werr < 0 && !test_bit(WDM_DISCONNECTING, &desc->flags))
 		dev_err(&desc->intf->dev, "Error in flush path: %d\n",
 			desc->werr);
 
@@ -621,12 +623,15 @@ static int wdm_release(struct inode *ino
 	mutex_unlock(&desc->wlock);
 
 	if (!desc->count) {
-		dev_dbg(&desc->intf->dev, "wdm_release: cleanup");
-		kill_urbs(desc);
-		if (!test_bit(WDM_DISCONNECTING, &desc->flags))
+		if (!test_bit(WDM_DISCONNECTING, &desc->flags)) {
+			dev_dbg(&desc->intf->dev, "wdm_release: cleanup");
+			kill_urbs(desc);
 			desc->manage_power(desc->intf, 0);
-		else
+		} else {
+			/* must avoid dev_printk here as desc->intf is invalid */
+			pr_debug(KBUILD_MODNAME " %s: device gone - cleaning up\n", __func__);
 			cleanup(desc);
+		}
 	}
 	mutex_unlock(&wdm_mutex);
 	return 0;
author maintainer
#39 lore raw

PATCH 35/91 USB: cdc-wdm: remove from device list on disconnect

In reply to Greg KH

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

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

From: Bjørn Mork <[email protected]>

commit 6286d85e8efdb59252d1ceb99a56fa6b0b11526c upstream.

Prevents dereferencing an invalid struct usb_interface pointer.

Always delete entry from device list whether or not the rest of the device state cleanup is postponed. The device list uses desc->intf as key, and wdm_open will dereference this key while searching for a matching device. A device should not appear in the list unless probe() has succeeded and disconnect() has not finished.

---
 drivers/usb/class/cdc-wdm.c |   12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)
drivers/usb/class/cdc-wdm.c +9 -3
@@ -309,9 +309,6 @@ static void free_urbs(struct wdm_device
 
 static void cleanup(struct wdm_device *desc)
 {
-	spin_lock(&wdm_device_list_lock);
-	list_del(&desc->device_list);
-	spin_unlock(&wdm_device_list_lock);
 	kfree(desc->sbuf);
 	kfree(desc->inbuf);
 	kfree(desc->orq);
@@ -778,6 +775,9 @@ static int wdm_create(struct usb_interfa
 out:
 	return rv;
 err:
+	spin_lock(&wdm_device_list_lock);
+	list_del(&desc->device_list);
+	spin_unlock(&wdm_device_list_lock);
 	cleanup(desc);
 	return rv;
 }
@@ -903,6 +903,12 @@ static void wdm_disconnect(struct usb_in
 	cancel_work_sync(&desc->rxwork);
 	mutex_unlock(&desc->wlock);
 	mutex_unlock(&desc->rlock);
+
+	/* the desc->intf pointer used as list key is now invalid */
+	spin_lock(&wdm_device_list_lock);
+	list_del(&desc->device_list);
+	spin_unlock(&wdm_device_list_lock);
+
 	if (!desc->count)
 		cleanup(desc);
 	mutex_unlock(&wdm_mutex);
author maintainer
#40 lore raw

PATCH 36/91 workqueue: skip nr_running sanity check in worker_enter_idle() if trustee is active

In reply to Greg KH

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

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

From: Tejun Heo <[email protected]>

commit 544ecf310f0e7f51fa057ac2a295fc1b3b35a9d3 upstream.

worker_enter_idle() has WARN_ON_ONCE() which triggers if nr_running isn't zero when every worker is idle. This can trigger spuriously while a cpu is going down due to the way trustee sets %WORKER_ROGUE and zaps nr_running.

It first sets %WORKER_ROGUE on all workers without updating nr_running, releases gcwq->lock, schedules, regrabs gcwq->lock and then zaps nr_running. If the last running worker enters idle inbetween, it would see stale nr_running which hasn't been zapped yet and trigger the WARN_ON_ONCE().

Fix it by performing the sanity check iff the trustee is idle.

---
 kernel/workqueue.c |    9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)
kernel/workqueue.c +7 -2
@@ -1210,8 +1210,13 @@ static void worker_enter_idle(struct wor
 	} else
 		wake_up_all(&gcwq->trustee_wait);
 
-	/* sanity check nr_running */
-	WARN_ON_ONCE(gcwq->nr_workers == gcwq->nr_idle &&
+	/*
+	 * Sanity check nr_running.  Because trustee releases gcwq->lock
+	 * between setting %WORKER_ROGUE and zapping nr_running, the
+	 * warning may trigger spuriously.  Check iff trustee is idle.
+	 */
+	WARN_ON_ONCE(gcwq->trustee_state == TRUSTEE_DONE &&
+		     gcwq->nr_workers == gcwq->nr_idle &&
 		     atomic_read(get_gcwq_nr_running(gcwq->cpu)));
 }
 
author maintainer
#41 lore raw

PATCH 37/91 mm: mempolicy: Let vma_merge and vma_split handle vma->vm_policy linkages

In reply to Greg KH

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

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

From: Mel Gorman <[email protected]>

commit 05f144a0d5c2207a0349348127f996e104ad7404 upstream.

Dave Jones' system call fuzz testing tool "trinity" triggered the following bug error with slab debugging enabled

    =============================================================================
    BUG numa_policy (Not tainted): Poison overwritten
    -----------------------------------------------------------------------------

    INFO: 0xffff880146498250-0xffff880146498250. First byte 0x6a instead of 0x6b
    INFO: Allocated in mpol_new+0xa3/0x140 age=46310 cpu=6 pid=32154
     __slab_alloc+0x3d3/0x445
     kmem_cache_alloc+0x29d/0x2b0
     mpol_new+0xa3/0x140
     sys_mbind+0x142/0x620
     system_call_fastpath+0x16/0x1b
    INFO: Freed in __mpol_put+0x27/0x30 age=46268 cpu=6 pid=32154
     __slab_free+0x2e/0x1de
     kmem_cache_free+0x25a/0x260
     __mpol_put+0x27/0x30
     remove_vma+0x68/0x90
     exit_mmap+0x118/0x140
     mmput+0x73/0x110
     exit_mm+0x108/0x130
     do_exit+0x162/0xb90
     do_group_exit+0x4f/0xc0
     sys_exit_group+0x17/0x20
     system_call_fastpath+0x16/0x1b
    INFO: Slab 0xffffea0005192600 objects=27 used=27 fp=0x          (null) flags=0x20000000004080
    INFO: Object 0xffff880146498250 @offset=592 fp=0xffff88014649b9d0

This implied a reference counting bug and the problem happened during mbind().

mbind() applies a new memory policy to a range and uses mbind_range() to merge existing VMAs or split them as necessary. In the event of splits, mpol_dup() will allocate a new struct mempolicy and maintain existing reference counts whose rules are documented in Documentation/vm/numa_memory_policy.txt .

The problem occurs with shared memory policies. The vm_op->set_policy increments the reference count if necessary and split_vma() and vma_merge() have already handled the existing reference counts. However, policy_vma() screws it up by replacing an existing vma->vm_policy with one that potentially has the wrong reference count leading to a premature free. This patch removes the damage caused by policy_vma().

With this patch applied Dave's trinity tool runs an mbind test for 5 minutes without error. /proc/slabinfo reported that there are no numa_policy or shared_policy_node objects allocated after the test completed and the shared memory region was deleted.

Cc Dave Jones <[email protected]>
Cc KOSAKI Motohiro <[email protected]>
Cc Stephen Wilson <[email protected]>
Cc Christoph Lameter <[email protected]>
Cc Andrew Morton <[email protected]>
---
 mm/mempolicy.c |   41 +++++++++++++++++------------------------
 1 file changed, 17 insertions(+), 24 deletions(-)
mm/mempolicy.c +17 -24
@@ -607,27 +607,6 @@ check_range(struct mm_struct *mm, unsign
 	return first;
 }
 
-/* Apply policy to a single VMA */
-static int policy_vma(struct vm_area_struct *vma, struct mempolicy *new)
-{
-	int err = 0;
-	struct mempolicy *old = vma->vm_policy;
-
-	pr_debug("vma %lx-%lx/%lx vm_ops %p vm_file %p set_policy %p\n",
-		 vma->vm_start, vma->vm_end, vma->vm_pgoff,
-		 vma->vm_ops, vma->vm_file,
-		 vma->vm_ops ? vma->vm_ops->set_policy : NULL);
-
-	if (vma->vm_ops && vma->vm_ops->set_policy)
-		err = vma->vm_ops->set_policy(vma, new);
-	if (!err) {
-		mpol_get(new);
-		vma->vm_policy = new;
-		mpol_put(old);
-	}
-	return err;
-}
-
 /* Step 2: apply policy to a range and do splits. */
 static int mbind_range(struct mm_struct *mm, unsigned long start,
 		       unsigned long end, struct mempolicy *new_pol)
@@ -676,9 +655,23 @@ static int mbind_range(struct mm_struct
 			if (err)
 				goto out;
 		}
-		err = policy_vma(vma, new_pol);
-		if (err)
-			goto out;
+
+		/*
+		 * Apply policy to a single VMA. The reference counting of
+		 * policy for vma_policy linkages has already been handled by
+		 * vma_merge and split_vma as necessary. If this is a shared
+		 * policy then ->set_policy will increment the reference count
+		 * for an sp node.
+		 */
+		pr_debug("vma %lx-%lx/%lx vm_ops %p vm_file %p set_policy %p\n",
+			vma->vm_start, vma->vm_end, vma->vm_pgoff,
+			vma->vm_ops, vma->vm_file,
+			vma->vm_ops ? vma->vm_ops->set_policy : NULL);
+		if (vma->vm_ops && vma->vm_ops->set_policy) {
+			err = vma->vm_ops->set_policy(vma, new_pol);
+			if (err)
+				goto out;
+		}
 	}
 
  out:
author maintainer
#42 lore raw

PATCH 38/91 md: using GFP_NOIO to allocate bio for flush request

In reply to Greg KH

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

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

From: Shaohua Li <[email protected]>

commit b5e1b8cee7ad58a15d2fa79bcd7946acb592602d upstream.

A flush request is usually issued in transaction commit code path, so using GFP_KERNEL to allocate memory for flush request bio falls into the classic deadlock issue.

This is suitable for any -stable kernel to which it applies as it avoids a possible deadlock.

---
 drivers/md/md.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/md/md.c +1 -1
@@ -452,7 +452,7 @@ static void submit_flushes(struct work_s
 			atomic_inc(&rdev->nr_pending);
 			atomic_inc(&rdev->nr_pending);
 			rcu_read_unlock();
-			bi = bio_alloc_mddev(GFP_KERNEL, 0, mddev);
+			bi = bio_alloc_mddev(GFP_NOIO, 0, mddev);
 			bi->bi_end_io = md_end_flush;
 			bi->bi_private = rdev;
 			bi->bi_bdev = rdev->bdev;
author maintainer
#43 lore raw

PATCH 39/91 Add missing call to uart_update_timeout()

In reply to Greg KH

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

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

From: Lothar Waßmann <[email protected]>

commit 8b979f7c6bf13a57e7b6002f1175312a44773960 upstream.

This patch fixes a problem reported here:
http://article.gmane.org/gmane.linux.ports.arm.kernel/155242/match=auart

---
 drivers/tty/serial/mxs-auart.c |    2 ++
 1 file changed, 2 insertions(+)
drivers/tty/serial/mxs-auart.c +2 -0
@@ -369,6 +369,8 @@ static void mxs_auart_settermios(struct
 
 	writel(ctrl, u->membase + AUART_LINECTRL);
 	writel(ctrl2, u->membase + AUART_CTRL2);
+
+	uart_update_timeout(u, termios->c_cflag, baud);
 }
 
 static irqreturn_t mxs_auart_irq_handle(int irq, void *context)
author maintainer
#44 lore raw

PATCH 40/91 8250.c: less than 2400 baud fix.

In reply to Greg KH

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

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

From: Christian Melki <[email protected]>

commit f9a9111b540fd67db5dab332f4b83d86c90e27b1 upstream.

We noticed that we were loosing data at speed less than 2400 baud. It turned out our (TI16750 compatible) uart with 64 byte outgoing fifo was truncated to 16 byte (bit 5 sets fifo len) when modifying the fcr reg.
The input code still fills the buffer with 64 bytes if I remember correctly and thus data is lost.
Our fix was to remove whiping of the fcr content and just add the TRIGGER_1 which we want for latency.
I can't see why this would not work on less than 2400 always, for all uarts ...
Otherwise one would have to make sure the filling of the fifo re-checks the current state of available fifo size (urrk).

---
 drivers/tty/serial/8250/8250.c |    9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)
drivers/tty/serial/8250/8250.c +5 -4
@@ -2280,10 +2280,11 @@ serial8250_do_set_termios(struct uart_po
 		quot++;
 
 	if (up->capabilities & UART_CAP_FIFO && port->fifosize > 1) {
-		if (baud < 2400)
-			fcr = UART_FCR_ENABLE_FIFO | UART_FCR_TRIGGER_1;
-		else
-			fcr = uart_config[port->type].fcr;
+		fcr = uart_config[port->type].fcr;
+		if (baud < 2400) {
+			fcr &= ~UART_FCR_TRIGGER_MASK;
+			fcr |= UART_FCR_TRIGGER_1;
+		}
 	}
 
 	/*
author maintainer
#45 lore raw

PATCH 41/91 8250_pci: fix pch uart matching

In reply to Greg KH

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

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

From: Arnaud Patard <[email protected]>

commit aaa10eb1d0034eccc096f583fe308f0921617598 upstream.

The rules used to make 8250_pci "ignore" the PCH uarts are lacking pci subids entries, preventing it to match and thus is breaking serial port support for theses systems.

This has been tested on a nanoETXexpress-TT, which has a specifici uart clock.

[stable@: please apply to 3.0-stable, 3.2-stable and 3.3-stable]
---
 drivers/tty/serial/8250/8250_pci.c |   18 ++++++++++++++++++
 1 file changed, 18 insertions(+)
drivers/tty/serial/8250/8250_pci.c +18 -0
@@ -1609,54 +1609,72 @@ static struct pci_serial_quirk pci_seria
 	{
 		.vendor         = PCI_VENDOR_ID_INTEL,
 		.device         = 0x8811,
+		.subvendor	= PCI_ANY_ID,
+		.subdevice	= PCI_ANY_ID,
 		.init		= pci_eg20t_init,
 		.setup		= pci_default_setup,
 	},
 	{
 		.vendor         = PCI_VENDOR_ID_INTEL,
 		.device         = 0x8812,
+		.subvendor	= PCI_ANY_ID,
+		.subdevice	= PCI_ANY_ID,
 		.init		= pci_eg20t_init,
 		.setup		= pci_default_setup,
 	},
 	{
 		.vendor         = PCI_VENDOR_ID_INTEL,
 		.device         = 0x8813,
+		.subvendor	= PCI_ANY_ID,
+		.subdevice	= PCI_ANY_ID,
 		.init		= pci_eg20t_init,
 		.setup		= pci_default_setup,
 	},
 	{
 		.vendor         = PCI_VENDOR_ID_INTEL,
 		.device         = 0x8814,
+		.subvendor	= PCI_ANY_ID,
+		.subdevice	= PCI_ANY_ID,
 		.init		= pci_eg20t_init,
 		.setup		= pci_default_setup,
 	},
 	{
 		.vendor         = 0x10DB,
 		.device         = 0x8027,
+		.subvendor	= PCI_ANY_ID,
+		.subdevice	= PCI_ANY_ID,
 		.init		= pci_eg20t_init,
 		.setup		= pci_default_setup,
 	},
 	{
 		.vendor         = 0x10DB,
 		.device         = 0x8028,
+		.subvendor	= PCI_ANY_ID,
+		.subdevice	= PCI_ANY_ID,
 		.init		= pci_eg20t_init,
 		.setup		= pci_default_setup,
 	},
 	{
 		.vendor         = 0x10DB,
 		.device         = 0x8029,
+		.subvendor	= PCI_ANY_ID,
+		.subdevice	= PCI_ANY_ID,
 		.init		= pci_eg20t_init,
 		.setup		= pci_default_setup,
 	},
 	{
 		.vendor         = 0x10DB,
 		.device         = 0x800C,
+		.subvendor	= PCI_ANY_ID,
+		.subdevice	= PCI_ANY_ID,
 		.init		= pci_eg20t_init,
 		.setup		= pci_default_setup,
 	},
 	{
 		.vendor         = 0x10DB,
 		.device         = 0x800D,
+		.subvendor	= PCI_ANY_ID,
+		.subdevice	= PCI_ANY_ID,
 		.init		= pci_eg20t_init,
 		.setup		= pci_default_setup,
 	},
author maintainer
#46 lore raw

PATCH 42/91 tty: Allow uart_register/unregister/register

In reply to Greg KH

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

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

From: Alan Cox <[email protected]>

commit 1e66cded334e6cea596c72f6f650eec351b1e959 upstream.

This is legitimate but because we don't clear the drv->state pointer in the unregister code causes a bogus BUG().

Resolves-bug: https://bugzilla.kernel.org/show_bug.cgi?id=42880

---
 drivers/tty/serial/serial_core.c |    1 +
 1 file changed, 1 insertion(+)
drivers/tty/serial/serial_core.c +1 -0
@@ -2282,6 +2282,7 @@ void uart_unregister_driver(struct uart_
 	tty_unregister_driver(p);
 	put_tty_driver(p);
 	kfree(drv->state);
+	drv->state = NULL;
 	drv->tty_driver = NULL;
 }
 
author maintainer
#47 lore raw

PATCH 43/91 USB: ftdi-sio: add support for Physik Instrumente E-861

In reply to Greg KH

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

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

From: Éric Piel <[email protected]>

commit b69cc672052540e8efb1368420f10d7d4d8b8a3d upstream.

This adds VID/PID for the PI E-861. Without it, I had to do:
modprobe -q ftdi-sio product=0x1008 vendor=0x1a72

http://www.physikinstrumente.com/en/products/prdetail.php?sortnr=900610

---
 drivers/usb/serial/ftdi_sio.c     |    1 +
 drivers/usb/serial/ftdi_sio_ids.h |    8 ++++++++
 2 files changed, 9 insertions(+)
drivers/usb/serial/ftdi_sio.c +1 -0
@@ -809,6 +809,7 @@ static struct usb_device_id id_table_com
 		.driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
 	{ USB_DEVICE(LARSENBRUSGAARD_VID, LB_ALTITRACK_PID) },
 	{ USB_DEVICE(GN_OTOMETRICS_VID, AURICAL_USB_PID) },
+	{ USB_DEVICE(PI_VID, PI_E861_PID) },
 	{ USB_DEVICE(BAYER_VID, BAYER_CONTOUR_CABLE_PID) },
 	{ USB_DEVICE(FTDI_VID, MARVELL_OPENRD_PID),
 		.driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
drivers/usb/serial/ftdi_sio_ids.h +8 -0
@@ -785,6 +785,14 @@
 #define RTSYSTEMS_SERIAL_VX7_PID	0x9e52	/* Serial converter for VX-7 Radios using FT232RL */
 #define RTSYSTEMS_CT29B_PID		0x9e54	/* CT29B Radio Cable */
 
+
+/*
+ * Physik Instrumente
+ * http://www.physikinstrumente.com/en/products/
+ */
+#define PI_VID              0x1a72  /* Vendor ID */
+#define PI_E861_PID         0x1008  /* E-861 piezo controller USB connection */
+
 /*
  * Bayer Ascensia Contour blood glucose meter USB-converter cable.
  * http://winglucofacts.com/cables/
author maintainer
#48 lore raw

PATCH 44/91 usb-serial: ftdi_sio: fix oops during autosuspend

In reply to Greg KH

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

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

From: Alan Stern <[email protected]>

commit 5cbe61c5aff0a8ada691eb8b07dbfb55c303f640 upstream.

This patch (as1550) fixes a bug in the usb-serial core that affects the ftdi_sio driver and most likely others as well. The core implements suspend and resume routines, but it doesn't store pointers to those routines in the usb_driver structures that it registers, even though it does set those drivers' supports_autosuspend flag. The end result is that when one of these devices is autosuspended, we try to call through a NULL pointer.

The patch fixes the problem by setting the suspend and resume method pointers to the appropriate routines in the USB serial core, along with the supports_autosuspend field, in each driver as it is registered.

This should be back-ported to all the stable kernels that have the new usb_serial_register_drivers() interface.

---
 drivers/usb/serial/usb-serial.c |    9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)
drivers/usb/serial/usb-serial.c +7 -2
@@ -1338,7 +1338,6 @@ static int usb_serial_register(struct us
 				driver->description);
 		return -EINVAL;
 	}
-	driver->usb_driver->supports_autosuspend = 1;
 
 	/* Add this device to our list of devices */
 	mutex_lock(&table_lock);
@@ -1373,7 +1372,7 @@ static void usb_serial_deregister(struct
  * @serial_drivers: NULL-terminated array of pointers to drivers to be registered
  *
  * Registers @udriver and all the drivers in the @serial_drivers array.
- * Automatically fills in the .no_dynamic_id field in @udriver and
+ * Automatically fills in the .no_dynamic_id and PM fields in @udriver and
  * the .usb_driver field in each serial driver.
  */
 int usb_serial_register_drivers(struct usb_driver *udriver,
@@ -1392,11 +1391,17 @@ int usb_serial_register_drivers(struct u
 	 * the serial drivers are registered, because the probe would
 	 * simply fail for lack of a matching serial driver.
 	 * Therefore save off udriver's id_table until we are all set.
+	 *
+	 * Suspend/resume support is implemented in the usb-serial core,
+	 * so fill in the PM-related fields in udriver.
 	 */
 	saved_id_table = udriver->id_table;
 	udriver->id_table = NULL;
 
 	udriver->no_dynamic_id = 1;
+	udriver->supports_autosuspend = 1;
+	udriver->suspend = usb_serial_suspend;
+	udriver->resume = usb_serial_resume;
 	rc = usb_register(udriver);
 	if (rc)
 		return rc;
author maintainer
#49 lore raw

PATCH 45/91 usb-storage: unusual_devs entry for Yarvik PMP400 MP4 player

In reply to Greg KH

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

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

From: Alan Stern <[email protected]>

commit df767b71e5816692134d59c0c17e0f77cd73333d upstream.

This patch (as1553) adds an unusual_dev entrie for the Yarvik PMP400 MP4 music player.

---
 drivers/usb/storage/unusual_devs.h |    7 +++++++
 1 file changed, 7 insertions(+)
drivers/usb/storage/unusual_devs.h +7 -0
@@ -1885,6 +1885,13 @@ UNUSUAL_DEV(  0x1652, 0x6600, 0x0201, 0x
 		USB_SC_DEVICE, USB_PR_DEVICE, NULL,
 		US_FL_IGNORE_RESIDUE ),
 
+/* Reported by Jesse Feddema <[email protected]> */
+UNUSUAL_DEV(  0x177f, 0x0400, 0x0000, 0x0000,
+		"Yarvik",
+		"PMP400",
+		USB_SC_DEVICE, USB_PR_DEVICE, NULL,
+		US_FL_BULK_IGNORE_TAG | US_FL_MAX_SECTORS_64 ),
+
 /* Reported by Hans de Goede <[email protected]>
  * These Appotech controllers are found in Picture Frames, they provide a
  * (buggy) emulation of a cdrom drive which contains the windows software
author maintainer
#50 lore raw

PATCH 46/91 USB: ffs-test: fix length argument of out function call

In reply to Greg KH

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

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

From: Matthias Fend <[email protected]>

commit eb9c5836384cd2a276254df6254ed71117983626 upstream.

The out functions should only handle actual available data instead of the complete buffer. Otherwise for example the ep0_consume function will report ghost events since it tries to decode the complete buffer - which may contain partly invalid data.

---
 tools/usb/ffs-test.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
tools/usb/ffs-test.c +1 -1
@@ -297,7 +297,7 @@ static void *start_thread_helper(void *a
 
 		ret = t->in(t, t->buf, t->buf_size);
 		if (ret > 0) {
-			ret = t->out(t, t->buf, t->buf_size);
+			ret = t->out(t, t->buf, ret);
 			name = out_name;
 			op = "write";
 		} else {
author maintainer
#51 lore raw

PATCH 47/91 usb: usbtest: two super speed fixes for usbtest

In reply to Greg KH

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

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

From: Paul Zimmerman <[email protected]>

commit 6a23ccd216b6a8ba2c67a9f9d8969b4431ad2920 upstream.

bMaxPacketSize0 field for super speed is a power of 2, not a count. The size itself is always 512.

Max packet size for a super speed bulk endpoint is 1024, so allocate the urb size in halt_simple() accordingly.

---
 drivers/usb/misc/usbtest.c |   17 ++++++++++++-----
 1 file changed, 12 insertions(+), 5 deletions(-)
drivers/usb/misc/usbtest.c +12 -5
@@ -1028,7 +1028,10 @@ test_ctrl_queue(struct usbtest_dev *dev,
 		case 13:	/* short read, resembling case 10 */
 			req.wValue = cpu_to_le16((USB_DT_CONFIG << 8) | 0);
 			/* last data packet "should" be DATA1, not DATA0 */
-			len = 1024 - udev->descriptor.bMaxPacketSize0;
+			if (udev->speed == USB_SPEED_SUPER)
+				len = 1024 - 512;
+			else
+				len = 1024 - udev->descriptor.bMaxPacketSize0;
 			expected = -EREMOTEIO;
 			break;
 		case 14:	/* short read; try to fill the last packet */
@@ -1387,11 +1390,15 @@ static int test_halt(struct usbtest_dev
 
 static int halt_simple(struct usbtest_dev *dev)
 {
-	int		ep;
-	int		retval = 0;
-	struct urb	*urb;
+	int			ep;
+	int			retval = 0;
+	struct urb		*urb;
+	struct usb_device	*udev = testdev_to_usbdev(dev);
 
-	urb = simple_alloc_urb(testdev_to_usbdev(dev), 0, 512);
+	if (udev->speed == USB_SPEED_SUPER)
+		urb = simple_alloc_urb(udev, 0, 1024);
+	else
+		urb = simple_alloc_urb(udev, 0, 512);
 	if (urb == NULL)
 		return -ENOMEM;
 
author maintainer
#52 lore raw

PATCH 48/91 USB: ehci-platform: remove update_device

In reply to Greg KH

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

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

From: Hauke Mehrtens <[email protected]>

commit 8377c94f627f7943da9a7eefdb21fd2e9e7ec629 upstream.

The update_device callback is not needed and the function used here is from the pci ehci driver. Without this patch we get a compile error if ehci-platform is compiled without ehci-pci.

---
 drivers/usb/host/ehci-platform.c |    2 --
 1 file changed, 2 deletions(-)
drivers/usb/host/ehci-platform.c +0 -2
@@ -75,8 +75,6 @@ static const struct hc_driver ehci_platf
 	.relinquish_port	= ehci_relinquish_port,
 	.port_handed_over	= ehci_port_handed_over,
 
-	.update_device		= ehci_update_device,
-
 	.clear_tt_buffer_complete = ehci_clear_tt_buffer_complete,
 };
 
author maintainer
#53 lore raw

PATCH 49/91 USB: EHCI: OMAP: Finish ehci omap phy reset cycle before adding hcd.

In reply to Greg KH

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

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

From: Russ Dill <[email protected]>

commit 3aa2ae74ba630ec9b98736d64aea8e4cb490861d upstream.

'ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue' (1fcb57d0f) created a regression with Beagleboard xM if booting the kernel after running 'usb start' under u-boot.

Finishing the reset before calling 'usb_add_hcd' fixes the regression. This is most likely due to usb_add_hcd calling the driver's reset and init functions which expect the hardware to be up and running.

---
 drivers/usb/host/ehci-omap.c |   18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)
drivers/usb/host/ehci-omap.c +9 -9
@@ -242,15 +242,6 @@ static int ehci_hcd_omap_probe(struct pl
 
 	ehci_reset(omap_ehci);
 
-	ret = usb_add_hcd(hcd, irq, IRQF_SHARED);
-	if (ret) {
-		dev_err(dev, "failed to add hcd with err %d\n", ret);
-		goto err_add_hcd;
-	}
-
-	/* root ports should always stay powered */
-	ehci_port_power(omap_ehci, 1);
-
 	if (pdata->phy_reset) {
 		/* Hold the PHY in RESET for enough time till
 		 * PHY is settled and ready
@@ -264,6 +255,15 @@ static int ehci_hcd_omap_probe(struct pl
 			gpio_set_value(pdata->reset_gpio_port[1], 1);
 	}
 
+	ret = usb_add_hcd(hcd, irq, IRQF_SHARED);
+	if (ret) {
+		dev_err(dev, "failed to add hcd with err %d\n", ret);
+		goto err_add_hcd;
+	}
+
+	/* root ports should always stay powered */
+	ehci_port_power(omap_ehci, 1);
+
 	return 0;
 
 err_add_hcd:
author maintainer
#54 lore raw

PATCH 50/91 USB: gpio_vbus: provide an appropriate debounce interval

In reply to Greg KH

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

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

From: Shinya Kuribayashi <[email protected]>

commit 934ccec4da14dc0586dfe08b36166364bdd2181b upstream.

In commit c2344f13b59e007d782a3e591ebc551bc583a8b7 (USB: gpio_vbus:
add delayed vbus_session calls, 2009-01-24), usb_gadget_vbus_connect() and ...disconnect() were extracted from the interrupt handler, so to allow vbus_session handlers to deal with msleep() calls.

This patch takes the approach one step further.

USB2.0 specification (7.1.7.3 Connect and Disconnect Signaling) says that the USB system software (shall) provide a debounce interval with a minimum duration of 100 ms, which ensures that the electrical and mechanical connection is stable before software attempts to reset the attached device.

---
 drivers/usb/otg/gpio_vbus.c |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)
drivers/usb/otg/gpio_vbus.c +4 -4
@@ -37,7 +37,7 @@ struct gpio_vbus_data {
 	struct regulator       *vbus_draw;
 	int			vbus_draw_enabled;
 	unsigned		mA;
-	struct work_struct	work;
+	struct delayed_work	work;
 };
 
 
@@ -94,7 +94,7 @@ static int is_vbus_powered(struct gpio_v
 static void gpio_vbus_work(struct work_struct *work)
 {
 	struct gpio_vbus_data *gpio_vbus =
-		container_of(work, struct gpio_vbus_data, work);
+		container_of(work, struct gpio_vbus_data, work.work);
 	struct gpio_vbus_mach_info *pdata = gpio_vbus->dev->platform_data;
 	int gpio, status;
 
@@ -152,7 +152,7 @@ static irqreturn_t gpio_vbus_irq(int irq
 		otg->gadget ? otg->gadget->name : "none");
 
 	if (otg->gadget)
-		schedule_work(&gpio_vbus->work);
+		schedule_delayed_work(&gpio_vbus->work, msecs_to_jiffies(100));
 
 	return IRQ_HANDLED;
 }
@@ -300,7 +300,7 @@ static int __init gpio_vbus_probe(struct
 
 	ATOMIC_INIT_NOTIFIER_HEAD(&gpio_vbus->phy.notifier);
 
-	INIT_WORK(&gpio_vbus->work, gpio_vbus_work);
+	INIT_DELAYED_WORK(&gpio_vbus->work, gpio_vbus_work);
 
 	gpio_vbus->vbus_draw = regulator_get(&pdev->dev, "vbus_draw");
 	if (IS_ERR(gpio_vbus->vbus_draw)) {
author maintainer
#55 lore raw

PATCH 51/91 USB: ohci-at91: add a reset function to fix race condition

In reply to Greg KH

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

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

From: Nicolas Ferre <[email protected]>

commit 07e4e556eff4938eb2edf2591de3aa7d7fb82b52 upstream.

A possible race condition appears because we are not initializing the ohci->regs before calling usb_hcd_request_irqs().
We move the call to ohci_init() in hcd->driver->reset() instead of hcd->driver->start() to fix this.
This was experienced when we share the same IRQ line between OHCI and EHCI controllers.

---
 drivers/usb/host/ohci-at91.c |   11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)
drivers/usb/host/ohci-at91.c +10 -1
@@ -223,7 +223,7 @@ static void __devexit usb_hcd_at91_remov
 /*-------------------------------------------------------------------------*/
 
 static int __devinit
-ohci_at91_start (struct usb_hcd *hcd)
+ohci_at91_reset (struct usb_hcd *hcd)
 {
 	struct at91_usbh_data	*board = hcd->self.controller->platform_data;
 	struct ohci_hcd		*ohci = hcd_to_ohci (hcd);
@@ -233,6 +233,14 @@ ohci_at91_start (struct usb_hcd *hcd)
 		return ret;
 
 	ohci->num_ports = board->ports;
+	return 0;
+}
+
+static int __devinit
+ohci_at91_start (struct usb_hcd *hcd)
+{
+	struct ohci_hcd		*ohci = hcd_to_ohci (hcd);
+	int			ret;
 
 	if ((ret = ohci_run(ohci)) < 0) {
 		err("can't start %s", hcd->self.bus_name);
@@ -418,6 +426,7 @@ static const struct hc_driver ohci_at91_
 	/*
 	 * basic lifecycle operations
 	 */
+	.reset =		ohci_at91_reset,
 	.start =		ohci_at91_start,
 	.stop =			ohci_stop,
 	.shutdown =		ohci_shutdown,
author maintainer
#56 lore raw

PATCH 52/91 USB: Remove races in devio.c

In reply to Greg KH

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

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

From: Huajun Li <[email protected]>

commit 4e09dcf20f7b5358615514c2ec8584b248ab8874 upstream.

There exist races in devio.c, below is one case, and there are similar races in destroy_async() and proc_unlinkurb(). Remove these races.

cancel_bulk_urbs() async_completed()
------------------- -----------------------
spin_unlock(&ps->lock);

                           list_move_tail(&as->asynclist,
		                    &ps->async_completed);

                           wake_up(&ps->wait);

                           Lead to free_async() be triggered,
                           then urb and 'as' will be freed.

usb_unlink_urb(as->urb);
===> refer to the freed 'as'

---
 drivers/usb/core/devio.c |   33 +++++++++++++++++++++++++--------
 1 file changed, 25 insertions(+), 8 deletions(-)
drivers/usb/core/devio.c +25 -8
@@ -333,17 +333,14 @@ static struct async *async_getcompleted(
 static struct async *async_getpending(struct dev_state *ps,
 					     void __user *userurb)
 {
-	unsigned long flags;
 	struct async *as;
 
-	spin_lock_irqsave(&ps->lock, flags);
 	list_for_each_entry(as, &ps->async_pending, asynclist)
 		if (as->userurb == userurb) {
 			list_del_init(&as->asynclist);
-			spin_unlock_irqrestore(&ps->lock, flags);
 			return as;
 		}
-	spin_unlock_irqrestore(&ps->lock, flags);
+
 	return NULL;
 }
 
@@ -398,6 +395,7 @@ static void cancel_bulk_urbs(struct dev_
 __releases(ps->lock)
 __acquires(ps->lock)
 {
+	struct urb *urb;
 	struct async *as;
 
 	/* Mark all the pending URBs that match bulk_addr, up to but not
@@ -420,8 +418,11 @@ __acquires(ps->lock)
 	list_for_each_entry(as, &ps->async_pending, asynclist) {
 		if (as->bulk_status == AS_UNLINK) {
 			as->bulk_status = 0;		/* Only once */
+			urb = as->urb;
+			usb_get_urb(urb);
 			spin_unlock(&ps->lock);		/* Allow completions */
-			usb_unlink_urb(as->urb);
+			usb_unlink_urb(urb);
+			usb_put_urb(urb);
 			spin_lock(&ps->lock);
 			goto rescan;
 		}
@@ -472,6 +473,7 @@ static void async_completed(struct urb *
 
 static void destroy_async(struct dev_state *ps, struct list_head *list)
 {
+	struct urb *urb;
 	struct async *as;
 	unsigned long flags;
 
@@ -479,10 +481,13 @@ static void destroy_async(struct dev_sta
 	while (!list_empty(list)) {
 		as = list_entry(list->next, struct async, asynclist);
 		list_del_init(&as->asynclist);
+		urb = as->urb;
+		usb_get_urb(urb);
 
 		/* drop the spinlock so the completion handler can run */
 		spin_unlock_irqrestore(&ps->lock, flags);
-		usb_kill_urb(as->urb);
+		usb_kill_urb(urb);
+		usb_put_urb(urb);
 		spin_lock_irqsave(&ps->lock, flags);
 	}
 	spin_unlock_irqrestore(&ps->lock, flags);
@@ -1410,12 +1415,24 @@ static int proc_submiturb(struct dev_sta
 
 static int proc_unlinkurb(struct dev_state *ps, void __user *arg)
 {
+	struct urb *urb;
 	struct async *as;
+	unsigned long flags;
 
+	spin_lock_irqsave(&ps->lock, flags);
 	as = async_getpending(ps, arg);
-	if (!as)
+	if (!as) {
+		spin_unlock_irqrestore(&ps->lock, flags);
 		return -EINVAL;
-	usb_kill_urb(as->urb);
+	}
+
+	urb = as->urb;
+	usb_get_urb(urb);
+	spin_unlock_irqrestore(&ps->lock, flags);
+
+	usb_kill_urb(urb);
+	usb_put_urb(urb);
+
 	return 0;
 }
 
author maintainer
#57 lore raw

PATCH 53/91 USB: serial: ti_usb_3410_5052: Add support for the FRI2 serial console

In reply to Greg KH

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

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

From: Darren Hart <[email protected]>

commit 975dc33b82cb887d75a29b1e3835c8eb063a8e99 upstream.

The Kontron M2M development board, also known as the Fish River Island II, has an optional daughter card providing access to the PCH_UART (EG20T) via a ti_usb_3410_5052 uart to usb chip.

http://us.kontron.com/products/systems+and+platforms/m2m/m2m+smart+services+developer+kit.html

---
 drivers/usb/serial/ti_usb_3410_5052.c |    6 ++++--
 drivers/usb/serial/ti_usb_3410_5052.h |    1 +
 2 files changed, 5 insertions(+), 2 deletions(-)
drivers/usb/serial/ti_usb_3410_5052.c +4 -2
@@ -165,7 +165,7 @@ static unsigned int product_5052_count;
 /* the array dimension is the number of default entries plus */
 /* TI_EXTRA_VID_PID_COUNT user defined entries plus 1 terminating */
 /* null entry */
-static struct usb_device_id ti_id_table_3410[14+TI_EXTRA_VID_PID_COUNT+1] = {
+static struct usb_device_id ti_id_table_3410[15+TI_EXTRA_VID_PID_COUNT+1] = {
 	{ USB_DEVICE(TI_VENDOR_ID, TI_3410_PRODUCT_ID) },
 	{ USB_DEVICE(TI_VENDOR_ID, TI_3410_EZ430_ID) },
 	{ USB_DEVICE(MTS_VENDOR_ID, MTS_GSM_NO_FW_PRODUCT_ID) },
@@ -180,6 +180,7 @@ static struct usb_device_id ti_id_table_
 	{ USB_DEVICE(IBM_VENDOR_ID, IBM_454B_PRODUCT_ID) },
 	{ USB_DEVICE(IBM_VENDOR_ID, IBM_454C_PRODUCT_ID) },
 	{ USB_DEVICE(ABBOTT_VENDOR_ID, ABBOTT_PRODUCT_ID) },
+	{ USB_DEVICE(TI_VENDOR_ID, FRI2_PRODUCT_ID) },
 };
 
 static struct usb_device_id ti_id_table_5052[5+TI_EXTRA_VID_PID_COUNT+1] = {
@@ -189,7 +190,7 @@ static struct usb_device_id ti_id_table_
 	{ USB_DEVICE(TI_VENDOR_ID, TI_5052_FIRMWARE_PRODUCT_ID) },
 };
 
-static struct usb_device_id ti_id_table_combined[18+2*TI_EXTRA_VID_PID_COUNT+1] = {
+static struct usb_device_id ti_id_table_combined[19+2*TI_EXTRA_VID_PID_COUNT+1] = {
 	{ USB_DEVICE(TI_VENDOR_ID, TI_3410_PRODUCT_ID) },
 	{ USB_DEVICE(TI_VENDOR_ID, TI_3410_EZ430_ID) },
 	{ USB_DEVICE(MTS_VENDOR_ID, MTS_GSM_NO_FW_PRODUCT_ID) },
@@ -208,6 +209,7 @@ static struct usb_device_id ti_id_table_
 	{ USB_DEVICE(IBM_VENDOR_ID, IBM_454B_PRODUCT_ID) },
 	{ USB_DEVICE(IBM_VENDOR_ID, IBM_454C_PRODUCT_ID) },
 	{ USB_DEVICE(ABBOTT_VENDOR_ID, ABBOTT_PRODUCT_ID) },
+	{ USB_DEVICE(TI_VENDOR_ID, FRI2_PRODUCT_ID) },
 	{ }
 };
 
drivers/usb/serial/ti_usb_3410_5052.h +1 -0
@@ -37,6 +37,7 @@
 #define TI_5152_BOOT_PRODUCT_ID		0x5152	/* no EEPROM, no firmware */
 #define TI_5052_EEPROM_PRODUCT_ID	0x505A	/* EEPROM, no firmware */
 #define TI_5052_FIRMWARE_PRODUCT_ID	0x505F	/* firmware is running */
+#define FRI2_PRODUCT_ID			0x5053  /* Fish River Island II */
 
 /* Multi-Tech vendor and product ids */
 #define MTS_VENDOR_ID			0x06E0
author maintainer
#58 lore raw

PATCH 54/91 usb: gadget: fsl_udc_core: dTDs next dtd pointer need to be updated once written

In reply to Greg KH

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

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

From: Peter Chen <[email protected]>

commit 4d0947dec4db1224354e2f6f00ae22ce38e62a43 upstream.

dTD's next dtd pointer need to be updated once CPU writes it, or this request may not be handled by controller, then host will get NAK from device forever.

This problem occurs when there is a request is handling, we need to add a new request to dTD list, if this new request is added before the current one is finished, the new request is intended to added as next dtd pointer at current dTD, but without wmb(), the dTD's next dtd pointer may not be updated when the controller reads it. In that case, the controller will still get Terminate Bit is 1 at dTD's next dtd pointer, that means there is no next request, then this new request is missed by controller.

---
 drivers/usb/gadget/fsl_udc_core.c |    2 ++
 1 file changed, 2 insertions(+)
drivers/usb/gadget/fsl_udc_core.c +2 -0
@@ -736,6 +736,8 @@ static void fsl_queue_td(struct fsl_ep *
 		lastreq = list_entry(ep->queue.prev, struct fsl_req, queue);
 		lastreq->tail->next_td_ptr =
 			cpu_to_hc32(req->head->td_dma & DTD_ADDR_MASK);
+		/* Ensure dTD's next dtd pointer to be updated */
+		wmb();
 		/* Read prime bit, if 1 goto done */
 		if (fsl_readl(&dr_regs->endpointprime) & bitmask)
 			return;
author maintainer
#59 lore raw

PATCH 55/91 usb: add USB_QUIRK_RESET_RESUME for M-Audio 88es

In reply to Greg KH

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

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

From: =?UTF-8?q?Steffen=20M=C3=BCller?= <[email protected]>

commit 166cb70e97bd83d7ae9bbec6ae59a178fd9bb823 upstream.

---
 drivers/usb/core/quirks.c |    3 +++
 1 file changed, 3 insertions(+)
drivers/usb/core/quirks.c +3 -0
@@ -123,6 +123,9 @@ static const struct usb_device_id usb_qu
 	/* Guillemot Webcam Hercules Dualpix Exchange*/
 	{ USB_DEVICE(0x06f8, 0x3005), .driver_info = USB_QUIRK_RESET_RESUME },
 
+	/* Midiman M-Audio Keystation 88es */
+	{ USB_DEVICE(0x0763, 0x0192), .driver_info = USB_QUIRK_RESET_RESUME },
+
 	/* M-Systems Flash Disk Pioneers */
 	{ USB_DEVICE(0x08ec, 0x1000), .driver_info = USB_QUIRK_RESET_RESUME },
 
author maintainer
#60 lore raw

PATCH 56/91 xhci: Add Lynx Point to list of Intel switchable hosts.

In reply to Greg KH

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

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

From: Sarah Sharp <[email protected]>

commit 1c12443ab8eba71a658fae4572147e56d1f84f66 upstream.

The upcoming Intel Lynx Point chipset includes an xHCI host controller that can have ports switched from the EHCI host controller, just like the Intel Panther Point xHCI host. This time, ports from both EHCI hosts can be switched to the xHCI host controller. The PCI config registers to do the port switching are in the exact same place in the xHCI PCI configuration registers, with the same semantics.

Hooray for shipping patches for next-gen hardware before the current gen hardware is even available for purchase!

This patch should be backported to stable kernels as old as 3.0, that contain commit 69e848c2090aebba5698a1620604c7dccb448684 "Intel xhci: Support EHCI/xHCI port switching."

---
 drivers/usb/host/ehci-pci.c   |    4 +++-
 drivers/usb/host/pci-quirks.c |   18 +++++++++++++++++-
 2 files changed, 20 insertions(+), 2 deletions(-)
drivers/usb/host/ehci-pci.c +3 -1
@@ -368,7 +368,9 @@ static bool usb_is_intel_switchable_ehci
 {
 	return pdev->class == PCI_CLASS_SERIAL_USB_EHCI &&
 		pdev->vendor == PCI_VENDOR_ID_INTEL &&
-		pdev->device == 0x1E26;
+		(pdev->device == 0x1E26 ||
+		 pdev->device == 0x8C2D ||
+		 pdev->device == 0x8C26);
 }
 
 static void ehci_enable_xhci_companion(void)
drivers/usb/host/pci-quirks.c +17 -1
@@ -712,12 +712,28 @@ static int handshake(void __iomem *ptr,
 	return -ETIMEDOUT;
 }
 
-bool usb_is_intel_switchable_xhci(struct pci_dev *pdev)
+#define PCI_DEVICE_ID_INTEL_LYNX_POINT_XHCI	0x8C31
+
+bool usb_is_intel_ppt_switchable_xhci(struct pci_dev *pdev)
 {
 	return pdev->class == PCI_CLASS_SERIAL_USB_XHCI &&
 		pdev->vendor == PCI_VENDOR_ID_INTEL &&
 		pdev->device == PCI_DEVICE_ID_INTEL_PANTHERPOINT_XHCI;
 }
+
+/* The Intel Lynx Point chipset also has switchable ports. */
+bool usb_is_intel_lpt_switchable_xhci(struct pci_dev *pdev)
+{
+	return pdev->class == PCI_CLASS_SERIAL_USB_XHCI &&
+		pdev->vendor == PCI_VENDOR_ID_INTEL &&
+		pdev->device == PCI_DEVICE_ID_INTEL_LYNX_POINT_XHCI;
+}
+
+bool usb_is_intel_switchable_xhci(struct pci_dev *pdev)
+{
+	return usb_is_intel_ppt_switchable_xhci(pdev) ||
+		usb_is_intel_lpt_switchable_xhci(pdev);
+}
 EXPORT_SYMBOL_GPL(usb_is_intel_switchable_xhci);
 
 /*
author maintainer
#61 lore raw

PATCH 57/91 xHCI: keep track of ports being resumed and indicate in hub_status_data

In reply to Greg KH

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

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

From: Andiry Xu <[email protected]>

commit f370b9968a220a3d79d870dd7dee674cc0ff3d10 upstream.

This commit adds a bit-array to xhci bus_state for keeping track of which ports are undergoing a resume transition. If any of the bits are set when xhci_hub_status_data() is called, the routine will return a non-zero value even if no ports have any status changes pending. This will allow usbcore to handle races between root-hub suspend and port wakeup.

This patch should be backported to kernels as old as 3.4, that contain the commit 879d38e6bc36d73b0ac40ec9b0d839fda9fa8b1a "USB: fix race between root-hub suspend and remote wakeup".

---
 drivers/usb/host/xhci-hub.c  |   22 ++++++++++++----------
 drivers/usb/host/xhci-ring.c |    1 +
 drivers/usb/host/xhci.c      |   12 ++++++++++--
 drivers/usb/host/xhci.h      |    2 ++
 4 files changed, 25 insertions(+), 12 deletions(-)
drivers/usb/host/xhci-hub.c +12 -10
@@ -558,6 +558,7 @@ int xhci_hub_control(struct usb_hcd *hcd
 				xhci_dbg(xhci, "Resume USB2 port %d\n",
 					wIndex + 1);
 				bus_state->resume_done[wIndex] = 0;
+				clear_bit(wIndex, &bus_state->resuming_ports);
 				xhci_set_link_state(xhci, port_array, wIndex,
 							XDEV_U0);
 				xhci_dbg(xhci, "set port %d resume\n",
@@ -845,7 +846,12 @@ int xhci_hub_status_data(struct usb_hcd
 	/* Initial status is no changes */
 	retval = (max_ports + 8) / 8;
 	memset(buf, 0, retval);
-	status = 0;
+
+	/*
+	 * Inform the usbcore about resume-in-progress by returning
+	 * a non-zero value even if there are no status changes.
+	 */
+	status = bus_state->resuming_ports;
 
 	mask = PORT_CSC | PORT_PEC | PORT_OCC | PORT_PLC | PORT_WRC;
 
@@ -885,15 +891,11 @@ int xhci_bus_suspend(struct usb_hcd *hcd
 	spin_lock_irqsave(&xhci->lock, flags);
 
 	if (hcd->self.root_hub->do_remote_wakeup) {
-		port_index = max_ports;
-		while (port_index--) {
-			if (bus_state->resume_done[port_index] != 0) {
-				spin_unlock_irqrestore(&xhci->lock, flags);
-				xhci_dbg(xhci, "suspend failed because "
-						"port %d is resuming\n",
-						port_index + 1);
-				return -EBUSY;
-			}
+		if (bus_state->resuming_ports) {
+			spin_unlock_irqrestore(&xhci->lock, flags);
+			xhci_dbg(xhci, "suspend failed because "
+						"a port is resuming\n");
+			return -EBUSY;
 		}
 	}
 
drivers/usb/host/xhci-ring.c +1 -0
@@ -1377,6 +1377,7 @@ static void handle_port_status(struct xh
 			xhci_dbg(xhci, "resume HS port %d\n", port_id);
 			bus_state->resume_done[faked_port_index] = jiffies +
 				msecs_to_jiffies(20);
+			set_bit(faked_port_index, &bus_state->resuming_ports);
 			mod_timer(&hcd->rh_timer,
 				  bus_state->resume_done[faked_port_index]);
 			/* Do the rest in GetPortStatus */
drivers/usb/host/xhci.c +10 -2
@@ -152,7 +152,7 @@ int xhci_reset(struct xhci_hcd *xhci)
 {
 	u32 command;
 	u32 state;
-	int ret;
+	int ret, i;
 
 	state = xhci_readl(xhci, &xhci->op_regs->status);
 	if ((state & STS_HALT) == 0) {
@@ -175,7 +175,15 @@ int xhci_reset(struct xhci_hcd *xhci)
 	 * xHCI cannot write to any doorbells or operational registers other
 	 * than status until the "Controller Not Ready" flag is cleared.
 	 */
-	return handshake(xhci, &xhci->op_regs->status, STS_CNR, 0, 250 * 1000);
+	ret = handshake(xhci, &xhci->op_regs->status, STS_CNR, 0, 250 * 1000);
+
+	for (i = 0; i < 2; ++i) {
+		xhci->bus_state[i].port_c_suspend = 0;
+		xhci->bus_state[i].suspended_ports = 0;
+		xhci->bus_state[i].resuming_ports = 0;
+	}
+
+	return ret;
 }
 
 #ifdef CONFIG_PCI
drivers/usb/host/xhci.h +2 -0
@@ -1362,6 +1362,8 @@ struct xhci_bus_state {
 	u32			suspended_ports;
 	u32			port_remote_wakeup;
 	unsigned long		resume_done[USB_MAXCHILDREN];
+	/* which ports have started to resume */
+	unsigned long		resuming_ports;
 };
 
 static inline unsigned int hcd_index(struct usb_hcd *hcd)
author maintainer
#62 lore raw

PATCH 58/91 xhci: Avoid dead ports when CONFIG_USB_XHCI_HCD=n

In reply to Greg KH

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

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

From: Sarah Sharp <[email protected]>

commit 51c9e6c7732b67769c0a514d31f505e49fa82dd4 upstream.

If the user chooses to say "no" to CONFIG_USB_XHCI_HCD on a system with an Intel Panther Point chipset, the PCI quirks code or the EHCI driver will switch the ports over to the xHCI host, but the xHCI driver will never load. The ports will be powered off and seem "dead" to the user.

Fix this by only switching the ports over if CONFIG_USB_XHCI_HCD is either compiled in, or compiled as a module.

This patch should be backported to stable kernels as old as 3.0, that contain commit 69e848c2090aebba5698a1620604c7dccb448684 "Intel xhci: Support EHCI/xHCI port switching."

---
 drivers/usb/host/pci-quirks.c |   14 ++++++++++++++
 1 file changed, 14 insertions(+)
drivers/usb/host/pci-quirks.c +14 -0
@@ -9,6 +9,7 @@
  */
 
 #include <linux/types.h>
+#include <linux/kconfig.h>
 #include <linux/kernel.h>
 #include <linux/pci.h>
 #include <linux/init.h>
@@ -758,6 +759,19 @@ void usb_enable_xhci_ports(struct pci_de
 {
 	u32		ports_available;
 
+	/* Don't switchover the ports if the user hasn't compiled the xHCI
+	 * driver.  Otherwise they will see "dead" USB ports that don't power
+	 * the devices.
+	 */
+	if (!IS_ENABLED(CONFIG_USB_XHCI_HCD)) {
+		dev_warn(&xhci_pdev->dev,
+				"CONFIG_USB_XHCI_HCD is turned off, "
+				"defaulting to EHCI.\n");
+		dev_warn(&xhci_pdev->dev,
+				"USB 3.0 devices will work at USB 2.0 speeds.\n");
+		return;
+	}
+
 	ports_available = 0xffffffff;
 	/* Write USB3_PSSEN, the USB 3.0 Port SuperSpeed Enable
 	 * Register, to turn on SuperSpeed terminations for all
author maintainer
#63 lore raw

PATCH 59/91 usb-xhci: Handle COMP_TX_ERR for isoc tds

In reply to Greg KH

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

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

From: Hans de Goede <[email protected]>

commit 9c745995ae5c4ff787f34a359de908facc11ee00 upstream.

While testing unplugging an UVC HD webcam with usb-redirection (so through usbdevfs), my userspace usb-redir code was getting a value of -1 in iso_frame_desc[n].status, which according to Documentation/usb/error-codes.txt is not a valid value.

The source of this -1 is the default case in xhci-ring.c:process_isoc_td() adding a kprintf there showed the value of trb_comp_code to be COMP_TX_ERR in this case, so this patch adds handling for that completion code to process_isoc_td().

This was observed and tested with the following xhci controller:
1033:0194 NEC Corporation uPD720200 USB 3.0 Host Controller (rev 04)

Note: I also wonder if setting frame->status to -1 (-EPERM) is the best we can do, but since I cannot come up with anything better I've left that as is.

This patch should be backported to kernels as old as 2.6.36, which contain the commit 04e51901dd44f40a5a385ced897f6bca87d5f40a "USB: xHCI: Isochronous transfer implementation".

---
 drivers/usb/host/xhci-ring.c |    1 +
 1 file changed, 1 insertion(+)
drivers/usb/host/xhci-ring.c +1 -0
@@ -1804,6 +1804,7 @@ static int process_isoc_td(struct xhci_h
 		break;
 	case COMP_DEV_ERR:
 	case COMP_STALL:
+	case COMP_TX_ERR:
 		frame->status = -EPROTO;
 		skip_td = true;
 		break;
author maintainer
#64 lore raw

PATCH 60/91 xhci: Reset reserved command ring TRBs on cleanup.

In reply to Greg KH

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

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

From: Sarah Sharp <[email protected]>

commit 33b2831ac870d50cc8e01c317b07fb1e69c13fe1 upstream.

When the xHCI driver needs to clean up memory (perhaps due to a failed register restore on resume from S3 or resume from S4), it needs to reset the number of reserved TRBs on the command ring to zero. Otherwise, several resume cycles (about 30) with a UAS device attached will continually increment the number of reserved TRBs, until all command submissions fail because there isn't enough room on the command ring.

This patch should be backported to kernels as old as 2.6.32, that contain the commit 913a8a344ffcaf0b4a586d6662a2c66a7106557d "USB: xhci: Change how xHCI commands are handled."

---
 drivers/usb/host/xhci-mem.c |    1 +
 1 file changed, 1 insertion(+)
drivers/usb/host/xhci-mem.c +1 -0
@@ -1807,6 +1807,7 @@ void xhci_mem_cleanup(struct xhci_hcd *x
 	xhci->event_ring = NULL;
 	xhci_dbg(xhci, "Freed event ring\n");
 
+	xhci->cmd_ring_reserved_trbs = 0;
 	if (xhci->cmd_ring)
 		xhci_ring_free(xhci, xhci->cmd_ring);
 	xhci->cmd_ring = NULL;
author maintainer
#65 lore raw

PATCH 61/91 xhci: Add new short TX quirk for Fresco Logic host.

In reply to Greg KH

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

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

From: Sarah Sharp <[email protected]>

commit 1530bbc6272d9da1e39ef8e06190d42c13a02733 upstream.

Sergio reported that when he recorded audio from a USB headset mic plugged into the USB 3.0 port on his ASUS N53SV-DH72, the audio sounded "robotic". When plugged into the USB 2.0 port under EHCI on the same laptop, the audio sounded fine. The device is:

Bus 002 Device 004: ID 046d:0a0c Logitech, Inc. Clear Chat Comfort USB Headset

The problem was tracked down to the Fresco Logic xHCI host controller not correctly reporting short transfers on isochronous IN endpoints. The driver would submit a 96 byte transfer, the device would only send 88 or 90 bytes, and the xHCI host would report the transfer had a "successful" completion code, with an untransferred buffer length of 8 or 6 bytes.

The successful completion code and non-zero untransferred length is a contradiction. The xHCI host is supposed to only mark a transfer as successful if all the bytes are transferred. Otherwise, the transfer should be marked with a short packet completion code. Without the EHCI bus trace, we wouldn't know whether the xHCI driver should trust the completion code or the untransferred length. With it, we know to trust the untransferred length.

Add a new xHCI quirk for the Fresco Logic host controller. If a transfer is reported as successful, but the untransferred length is non-zero, print a warning. For the Fresco Logic host, change the completion code to COMP_SHORT_TX and process the transfer like a short transfer.

This should be backported to stable kernels that contain the commit f5182b4155b9d686c5540a6822486400e34ddd98 "xhci: Disable MSI for some Fresco Logic hosts." That commit was marked for stable kernels as old as 2.6.36.

---
 drivers/usb/host/xhci-pci.c  |    1 +
 drivers/usb/host/xhci-ring.c |   20 +++++++++++++++++---
 drivers/usb/host/xhci.h      |    1 +
 3 files changed, 19 insertions(+), 3 deletions(-)
drivers/usb/host/xhci-pci.c +1 -0
@@ -72,6 +72,7 @@ static void xhci_pci_quirks(struct devic
 		xhci_dbg(xhci, "QUIRK: Fresco Logic revision %u "
 				"has broken MSI implementation\n",
 				pdev->revision);
+		xhci->quirks |= XHCI_TRUST_TX_LENGTH;
 	}
 
 	if (pdev->vendor == PCI_VENDOR_ID_NEC)
drivers/usb/host/xhci-ring.c +17 -3
@@ -1787,8 +1787,12 @@ static int process_isoc_td(struct xhci_h
 	/* handle completion code */
 	switch (trb_comp_code) {
 	case COMP_SUCCESS:
-		frame->status = 0;
-		break;
+		if (TRB_LEN(le32_to_cpu(event->transfer_len)) == 0) {
+			frame->status = 0;
+			break;
+		}
+		if ((xhci->quirks & XHCI_TRUST_TX_LENGTH))
+			trb_comp_code = COMP_SHORT_TX;
 	case COMP_SHORT_TX:
 		frame->status = td->urb->transfer_flags & URB_SHORT_NOT_OK ?
 				-EREMOTEIO : 0;
@@ -1885,13 +1889,16 @@ static int process_bulk_intr_td(struct x
 	switch (trb_comp_code) {
 	case COMP_SUCCESS:
 		/* Double check that the HW transferred everything. */
-		if (event_trb != td->last_trb) {
+		if (event_trb != td->last_trb ||
+				TRB_LEN(le32_to_cpu(event->transfer_len)) != 0) {
 			xhci_warn(xhci, "WARN Successful completion "
 					"on short TX\n");
 			if (td->urb->transfer_flags & URB_SHORT_NOT_OK)
 				*status = -EREMOTEIO;
 			else
 				*status = 0;
+			if ((xhci->quirks & XHCI_TRUST_TX_LENGTH))
+				trb_comp_code = COMP_SHORT_TX;
 		} else {
 			*status = 0;
 		}
@@ -2050,6 +2057,13 @@ static int handle_tx_event(struct xhci_h
 	 * transfer type
 	 */
 	case COMP_SUCCESS:
+		if (TRB_LEN(le32_to_cpu(event->transfer_len)) == 0)
+			break;
+		if (xhci->quirks & XHCI_TRUST_TX_LENGTH)
+			trb_comp_code = COMP_SHORT_TX;
+		else
+			xhci_warn(xhci, "WARN Successful completion on short TX: "
+					"needs XHCI_TRUST_TX_LENGTH quirk?\n");
 	case COMP_SHORT_TX:
 		break;
 	case COMP_STOP:
drivers/usb/host/xhci.h +1 -0
@@ -1481,6 +1481,7 @@ struct xhci_hcd {
 #define XHCI_RESET_ON_RESUME	(1 << 7)
 #define	XHCI_SW_BW_CHECKING	(1 << 8)
 #define XHCI_AMD_0x96_HOST	(1 << 9)
+#define XHCI_TRUST_TX_LENGTH	(1 << 10)
 	unsigned int		num_active_eps;
 	unsigned int		limit_active_eps;
 	/* There are two roothubs to keep track of bus suspend info for */
author maintainer
#66 lore raw

PATCH 62/91 USB: fix resource leak in xhci power loss path

In reply to Greg KH

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

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

From: Oliver Neukum <[email protected]>

commit f8a9e72d125f4e00ec529ba67b674321a1f3bf31 upstream.

Some more data structures must be freed and counters reset if an XHCI controller has lost power. The failure to do so renders some chips inoperative after a certain number of S4 cycles.

This patch should be backported to kernels as old as 3.2, that contain the commits c29eea621900f18287d50519f72cb9113746d75a "xhci: Implement HS/FS/LS bandwidth checking." and commit 839c817ce67178ca3c7c7ad534c571bba1e69ebe
"xhci: Implement HS/FS/LS bandwidth checking."

---
 drivers/usb/host/xhci-mem.c |   26 ++++++++++++++++++++++++++
 1 file changed, 26 insertions(+)
drivers/usb/host/xhci-mem.c +26 -0
@@ -1791,6 +1791,14 @@ void xhci_mem_cleanup(struct xhci_hcd *x
 {
 	struct pci_dev	*pdev = to_pci_dev(xhci_to_hcd(xhci)->self.controller);
 	struct dev_info	*dev_info, *next;
+	struct list_head *tt_list_head;
+	struct list_head *tt;
+	struct list_head *endpoints;
+	struct list_head *ep, *q;
+	struct xhci_tt_bw_info *tt_info;
+	struct xhci_interval_bw_table *bwt;
+	struct xhci_virt_ep *virt_ep;
+
 	unsigned long	flags;
 	int size;
 	int i;
@@ -1850,8 +1858,26 @@ void xhci_mem_cleanup(struct xhci_hcd *x
 	}
 	spin_unlock_irqrestore(&xhci->lock, flags);
 
+	bwt = &xhci->rh_bw->bw_table;
+	for (i = 0; i < XHCI_MAX_INTERVAL; i++) {
+		endpoints = &bwt->interval_bw[i].endpoints;
+		list_for_each_safe(ep, q, endpoints) {
+			virt_ep = list_entry(ep, struct xhci_virt_ep, bw_endpoint_list);
+			list_del(&virt_ep->bw_endpoint_list);
+			kfree(virt_ep);
+		}
+	}
+
+	tt_list_head = &xhci->rh_bw->tts;
+	list_for_each_safe(tt, q, tt_list_head) {
+		tt_info = list_entry(tt, struct xhci_tt_bw_info, tt_list);
+		list_del(tt);
+		kfree(tt_info);
+	}
+
 	xhci->num_usb2_ports = 0;
 	xhci->num_usb3_ports = 0;
+	xhci->num_active_eps = 0;
 	kfree(xhci->usb2_ports);
 	kfree(xhci->usb3_ports);
 	kfree(xhci->port_array);
author maintainer
#67 lore raw

PATCH 63/91 usbcore: enable USB2 LPM if port suspend fails

In reply to Greg KH

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

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

From: Andiry Xu <[email protected]>

commit c3e751e4f4754793bb52bd5ae30e9cc027edbb12 upstream.

USB2 LPM is disabled when device begin to suspend and enabled after device is resumed. That's because USB spec does not define the transition from U1/U2 state to U3 state.

If usb_port_suspend() fails, usb_port_resume() is never called, and USB2 LPM is disabled in this situation. Enable USB2 LPM if port suspend fails.

This patch should be backported to kernels as old as 3.2, that contain the commit 65580b4321eb36f16ae8b5987bfa1bb948fc5112 "xHCI: set USB2 hardware LPM".

---
 drivers/usb/core/hub.c |    4 ++++
 1 file changed, 4 insertions(+)
drivers/usb/core/hub.c +4 -0
@@ -2499,6 +2499,10 @@ int usb_port_suspend(struct usb_device *
 				NULL, 0,
 				USB_CTRL_SET_TIMEOUT);
 
+		/* Try to enable USB2 hardware LPM again */
+		if (udev->usb2_hw_lpm_capable == 1)
+			usb_set_usb2_hardware_lpm(udev, 1);
+
 		/* System sleep transitions should never fail */
 		if (!PMSG_IS_AUTO(msg))
 			status = 0;
author maintainer
#68 lore raw

PATCH 64/91 gma500: Fix Poulsbo suspend/resume crash on devices with SDVO ports

In reply to Greg KH

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

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

From: Alan Cox <[email protected]>

commit 7beff62ee39d3ccf088bb77f61a63037f714d235 upstream.

---
 drivers/gpu/drm/gma500/psb_device.c |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/gpu/drm/gma500/psb_device.c +4 -2
@@ -197,7 +197,8 @@ static int psb_save_display_registers(st
 	}
 
 	list_for_each_entry(connector, &dev->mode_config.connector_list, head)
-		connector->funcs->save(connector);
+		if (connector->funcs->save)
+			connector->funcs->save(connector);
 
 	mutex_unlock(&dev->mode_config.mutex);
 	return 0;
@@ -235,7 +236,8 @@ static int psb_restore_display_registers
 			crtc->funcs->restore(crtc);
 
 	list_for_each_entry(connector, &dev->mode_config.connector_list, head)
-		connector->funcs->restore(connector);
+		if (connector->funcs->restore)
+			connector->funcs->restore(connector);
 
 	mutex_unlock(&dev->mode_config.mutex);
 	return 0;
author maintainer
#69 lore raw

PATCH 65/91 b43legacy: Fix error due to MMIO access with SSB unpowered

In reply to Greg KH

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

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

From: Larry Finger <[email protected]>

commit 8f4b20388fa77226a3605627a33a23f90d559e50 upstream.

There is a dummy read of a PCI MMIO register that occurs before the SSB bus has been powered, which is an error. This bug has not been seen earlier, but was apparently exposed when udev was updated to version 182.

---
 drivers/net/wireless/b43legacy/main.c |    2 --
 1 file changed, 2 deletions(-)
drivers/net/wireless/b43legacy/main.c +0 -2
@@ -1571,8 +1571,6 @@ static void b43legacy_request_firmware(s
 	const char *filename;
 	int err;
 
-	/* do dummy read */
-	ssb_read32(dev->dev, SSB_TMSHIGH);
 	if (!fw->ucode) {
 		if (rev == 2)
 			filename = "ucode2";
author maintainer
#70 lore raw

PATCH 66/91 drm/i915: Avoid a double-read of PCH_IIR during interrupt handling

In reply to Greg KH

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

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

From: Chris Wilson <[email protected]>

commit 9adab8b5a7fde248504f484e197589f3e3c922e2 upstream.

Currently the code re-reads PCH_IIR during the hotplug interrupt processing. Not only is this a wasted read, but introduces a potential for handling a spurious interrupt as we then may not clear all the interrupts processed (since the re-read IIR may contains more interrupts asserted than we clear using the result of the original read).

---
 drivers/gpu/drm/i915/i915_irq.c |    9 +++------
 1 file changed, 3 insertions(+), 6 deletions(-)
drivers/gpu/drm/i915/i915_irq.c +3 -6
@@ -424,14 +424,11 @@ static void gen6_pm_rps_work(struct work
 	mutex_unlock(&dev_priv->dev->struct_mutex);
 }
 
-static void pch_irq_handler(struct drm_device *dev)
+static void pch_irq_handler(struct drm_device *dev, u32 pch_iir)
 {
 	drm_i915_private_t *dev_priv = (drm_i915_private_t *) dev->dev_private;
-	u32 pch_iir;
 	int pipe;
 
-	pch_iir = I915_READ(SDEIIR);
-
 	if (pch_iir & SDE_AUDIO_POWER_MASK)
 		DRM_DEBUG_DRIVER("PCH audio power change on port %d\n",
 				 (pch_iir & SDE_AUDIO_POWER_MASK) >>
@@ -529,7 +526,7 @@ static irqreturn_t ivybridge_irq_handler
 	if (de_iir & DE_PCH_EVENT_IVB) {
 		if (pch_iir & SDE_HOTPLUG_MASK_CPT)
 			queue_work(dev_priv->wq, &dev_priv->hotplug_work);
-		pch_irq_handler(dev);
+		pch_irq_handler(dev, pch_iir);
 	}
 
 	if (pm_iir & GEN6_PM_DEFERRED_EVENTS) {
@@ -629,7 +626,7 @@ static irqreturn_t ironlake_irq_handler(
 	if (de_iir & DE_PCH_EVENT) {
 		if (pch_iir & hotplug_mask)
 			queue_work(dev_priv->wq, &dev_priv->hotplug_work);
-		pch_irq_handler(dev);
+		pch_irq_handler(dev, pch_iir);
 	}
 
 	if (de_iir & DE_PCU_EVENT) {
author maintainer
#71 lore raw

PATCH 67/91 drm/i915: [GEN7] Use HW scheduler for fixed function shaders

In reply to Greg KH

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

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

From: Ben Widawsky <[email protected]>

commit a1e969e0332de7a430e62822cee8f2ec8d83cd7c upstream.

This originally started as a patch from Bernard as a way of simply setting the VS scheduler. After submitting the RFC patch, we decided to also modify the DS scheduler. To be most explicit, I've made the patch explicitly set all scheduler modes, and included the defines for other modes (in case someone feels frisky later).

The rest of the story gets a bit weird. The first version of the patch showed an almost unbelievable performance improvement. Since rebasing my branch it appears the performance improvement has gone, unfortunately. But setting these bits seem to be the right thing to do given that the docs describe corruption that can occur with the default settings.

In summary, I am seeing no more perf improvements (or regressions) in my limited testing, but we believe this should be set to prevent rendering corruption, therefore cc stable.

v1: Clear bit 4 also (Ken + Eugeni)
Do a full clear + set of the bits we want (Me).

Cc: Bernard Kilarski <[email protected]> Reviewed-by (RFC): Kenneth Graunke <[email protected]>

---
 drivers/gpu/drm/i915/i915_reg.h      |   15 +++++++++++++++
 drivers/gpu/drm/i915/intel_display.c |   14 ++++++++++++++
 2 files changed, 29 insertions(+)
drivers/gpu/drm/i915/i915_reg.h +15 -0
@@ -615,6 +615,21 @@
 
 #define GEN6_BSD_RNCID			0x12198
 
+#define GEN7_FF_THREAD_MODE		0x20a0
+#define   GEN7_FF_SCHED_MASK		0x0077070
+#define   GEN7_FF_TS_SCHED_HS1		(0x5<<16)
+#define   GEN7_FF_TS_SCHED_HS0		(0x3<<16)
+#define   GEN7_FF_TS_SCHED_LOAD_BALANCE	(0x1<<16)
+#define   GEN7_FF_TS_SCHED_HW		(0x0<<16) /* Default */
+#define   GEN7_FF_VS_SCHED_HS1		(0x5<<12)
+#define   GEN7_FF_VS_SCHED_HS0		(0x3<<12)
+#define   GEN7_FF_VS_SCHED_LOAD_BALANCE	(0x1<<12) /* Default */
+#define   GEN7_FF_VS_SCHED_HW		(0x0<<12)
+#define   GEN7_FF_DS_SCHED_HS1		(0x5<<4)
+#define   GEN7_FF_DS_SCHED_HS0		(0x3<<4)
+#define   GEN7_FF_DS_SCHED_LOAD_BALANCE	(0x1<<4)  /* Default */
+#define   GEN7_FF_DS_SCHED_HW		(0x0<<4)
+
 /*
  * Framebuffer compression (915+ only)
  */
drivers/gpu/drm/i915/intel_display.c +14 -0
@@ -8612,6 +8612,18 @@ static void gen6_init_clock_gating(struc
 	}
 }
 
+static void gen7_setup_fixed_func_scheduler(struct drm_i915_private *dev_priv)
+{
+	uint32_t reg = I915_READ(GEN7_FF_THREAD_MODE);
+
+	reg &= ~GEN7_FF_SCHED_MASK;
+	reg |= GEN7_FF_TS_SCHED_HW;
+	reg |= GEN7_FF_VS_SCHED_HW;
+	reg |= GEN7_FF_DS_SCHED_HW;
+
+	I915_WRITE(GEN7_FF_THREAD_MODE, reg);
+}
+
 static void ivybridge_init_clock_gating(struct drm_device *dev)
 {
 	struct drm_i915_private *dev_priv = dev->dev_private;
@@ -8656,6 +8668,8 @@ static void ivybridge_init_clock_gating(
 			   DISPPLANE_TRICKLE_FEED_DISABLE);
 		intel_flush_display_plane(dev_priv, pipe);
 	}
+
+	gen7_setup_fixed_func_scheduler(dev_priv);
 }
 
 static void g4x_init_clock_gating(struct drm_device *dev)
author maintainer
#72 lore raw

PATCH 68/91 drm/i915: dont clobber the pipe param in sanitize_modesetting

In reply to Greg KH

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

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

From: Daniel Vetter <[email protected]>

commit a9dcf84b14ef4e9a609910367576995e6f32f3dc upstream.

... we need it later on in the function to clean up pipe <-> plane associations. This regression has been introduced in

commit f47166d2b0001fcb752b40c5a2d4db986dfbea68

Author: Chris Wilson <[email protected]>
Date:   Thu Mar 22 15:00:50 2012 +0000

drm/i915: Sanitize BIOS debugging bits from PIPECONF

Spotted by staring at debug output of an (as it turns out) totally unrelated bug.

v2: I've totally failed to do the s/pipe/i/ correctly, spotted by Chris Wilson.

---
 drivers/gpu/drm/i915/intel_display.c |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)
drivers/gpu/drm/i915/intel_display.c +3 -2
@@ -7617,10 +7617,11 @@ static void intel_sanitize_modesetting(s
 {
 	struct drm_i915_private *dev_priv = dev->dev_private;
 	u32 reg, val;
+	int i;
 
 	/* Clear any frame start delays used for debugging left by the BIOS */
-	for_each_pipe(pipe) {
-		reg = PIPECONF(pipe);
+	for_each_pipe(i) {
+		reg = PIPECONF(i);
 		I915_WRITE(reg, I915_READ(reg) & ~PIPECONF_FRAME_START_DELAY_MASK);
 	}
 
author maintainer
#73 lore raw

PATCH 69/91 gpio: mpc8xxx: Prevent NULL pointer deref in demux handler

In reply to Greg KH

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

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

From: Thomas Gleixner <[email protected]>

commit d6de85e85edcc38c9edcde45a0a568818fcddc13 upstream.

commit cfadd838(powerpc/8xxx: Fix interrupt handling in MPC8xxx GPIO driver) added an unconditional call of chip->irq_eoi() to the demux handler.

This leads to a NULL pointer derefernce on MPC512x platforms which use this driver as well.

Make it conditional.

---
 drivers/gpio/gpio-mpc8xxx.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/gpio/gpio-mpc8xxx.c +2 -1
@@ -163,7 +163,8 @@ static void mpc8xxx_gpio_irq_cascade(uns
 	if (mask)
 		generic_handle_irq(irq_linear_revmap(mpc8xxx_gc->irq,
 						     32 - ffs(mask)));
-	chip->irq_eoi(&desc->irq_data);
+	if (chip->irq_eoi)
+		chip->irq_eoi(&desc->irq_data);
 }
 
 static void mpc8xxx_irq_unmask(struct irq_data *d)
author maintainer
#74 lore raw

PATCH 70/91 spi/spi-fsl-spi: reference correct pdata in fsl_spi_cs_control

In reply to Greg KH

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

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

From: Herton Ronaldo Krzesinski <[email protected]>

commit 067aa4815a9bc12a569d8a06afef50ba5773afbf upstream.

Commit 178db7d3, "spi: Fix device unregistration when unregistering the bus master", changed spi device initialization of dev.parent pointer to be the master's device pointer instead of his parent.

This introduced a bug in spi-fsl-spi, since its usage of spi device pointer was not updated accordingly. This was later fixed by commit 5039a86, "spi/mpc83xx: fix NULL pdata dereference bug", but it missed another spot on fsl_spi_cs_control function where we also need to update usage of spi device pointer. This change address that.

---
 drivers/spi/spi-fsl-spi.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/spi/spi-fsl-spi.c +1 -1
@@ -933,7 +933,7 @@ err:
 
 static void fsl_spi_cs_control(struct spi_device *spi, bool on)
 {
-	struct device *dev = spi->dev.parent;
+	struct device *dev = spi->dev.parent->parent;
 	struct mpc8xxx_spi_probe_info *pinfo = to_of_pinfo(dev->platform_data);
 	u16 cs = spi->chip_select;
 	int gpio = pinfo->gpios[cs];
author maintainer
#75 lore raw

PATCH 71/91 hvc_xen: NULL dereference on allocation failure

In reply to Greg KH

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

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

From: Dan Carpenter <[email protected]>

commit 201a52bea928687b7557728b176ac4f8a37d5cbd upstream.

If kzalloc() returns a NULL here, we pass a NULL to xencons_disconnect_backend() which will cause an Oops.

Also I removed the __GFP_ZERO while I was at it since kzalloc() implies __GFP_ZERO.

---
 drivers/tty/hvc/hvc_xen.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/tty/hvc/hvc_xen.c +2 -2
@@ -430,9 +430,9 @@ static int __devinit xencons_probe(struc
 	if (devid == 0)
 		return -ENODEV;
 
-	info = kzalloc(sizeof(struct xencons_info), GFP_KERNEL | __GFP_ZERO);
+	info = kzalloc(sizeof(struct xencons_info), GFP_KERNEL);
 	if (!info)
-		goto error_nomem;
+		return -ENOMEM;
 	dev_set_drvdata(&dev->dev, info);
 	info->xbdev = dev;
 	info->vtermno = xenbus_devid_to_vtermno(devid);
author maintainer
#76 lore raw

PATCH 72/91 xen: do not map the same GSI twice in PVHVM guests.

In reply to Greg KH

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

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

From: Stefano Stabellini <[email protected]>

commit 68c2c39a76b094e9b2773e5846424ea674bf2c46 upstream.

PV on HVM guests map GSIs into event channels. At restore time the event channels are resumed by restore_pirqs.

Device drivers might try to register the same GSI again through ACPI at restore time, but the GSI has already been mapped and bound by restore_pirqs. This patch detects these situations and avoids
mapping the same GSI multiple times.

Without this patch we get:
(XEN) irq.c:2235: dom4: pirq 23 or emuirq 28 already mapped and waste a pirq.

---
 arch/x86/pci/xen.c   |    4 ++++
 drivers/xen/events.c |    5 +++--
 include/xen/events.h |    3 +++
 3 files changed, 10 insertions(+), 2 deletions(-)
arch/x86/pci/xen.c +4 -0
@@ -64,6 +64,10 @@ static int xen_register_pirq(u32 gsi, in
 	int shareable = 0;
 	char *name;
 
+	irq = xen_irq_from_gsi(gsi);
+	if (irq > 0)
+		return irq;
+
 	if (set_pirq)
 		pirq = gsi;
 
drivers/xen/events.c +3 -2
@@ -611,7 +611,7 @@ static void disable_pirq(struct irq_data
 	disable_dynirq(data);
 }
 
-static int find_irq_by_gsi(unsigned gsi)
+int xen_irq_from_gsi(unsigned gsi)
 {
 	struct irq_info *info;
 
@@ -625,6 +625,7 @@ static int find_irq_by_gsi(unsigned gsi)
 
 	return -1;
 }
+EXPORT_SYMBOL_GPL(xen_irq_from_gsi);
 
 /*
  * Do not make any assumptions regarding the relationship between the
@@ -644,7 +645,7 @@ int xen_bind_pirq_gsi_to_irq(unsigned gs
 
 	mutex_lock(&irq_mapping_update_lock);
 
-	irq = find_irq_by_gsi(gsi);
+	irq = xen_irq_from_gsi(gsi);
 	if (irq != -1) {
 		printk(KERN_INFO "xen_map_pirq_gsi: returning irq %d for gsi %u\n",
 		       irq, gsi);
include/xen/events.h +3 -0
@@ -103,6 +103,9 @@ int xen_irq_from_pirq(unsigned pirq);
 /* Return the pirq allocated to the irq. */
 int xen_pirq_from_irq(unsigned irq);
 
+/* Return the irq allocated to the gsi */
+int xen_irq_from_gsi(unsigned gsi);
+
 /* Determine whether to ignore this IRQ if it is passed to a guest. */
 int xen_test_irq_shared(int irq);
 
author maintainer
#77 lore raw

PATCH 73/91 nouveau: nouveau_set_bo_placement takes TTM flags

In reply to Greg KH

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

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

From: Dave Airlie <[email protected]>

commit c284815debba2f14ee2fd07b1b4cc972ab116110 upstream.

This seems to be wrong to me, spotted while thinking about dma-buf.

---
 drivers/gpu/drm/nouveau/nouveau_bo.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/nouveau/nouveau_bo.c +1 -1
@@ -1030,7 +1030,7 @@ nouveau_ttm_fault_reserve_notify(struct
 
 	nvbo->placement.fpfn = 0;
 	nvbo->placement.lpfn = dev_priv->fb_mappable_pages;
-	nouveau_bo_placement_set(nvbo, TTM_PL_VRAM, 0);
+	nouveau_bo_placement_set(nvbo, TTM_PL_FLAG_VRAM, 0);
 	return nouveau_bo_validate(nvbo, false, true, false);
 }
 
author maintainer
#78 lore raw

PATCH 74/91 smsusb: add autodetection support for USB ID 2040:c0a0

In reply to Greg KH

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

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

From: Michael Krufky <[email protected]>

commit 4d1b58b84472d1d300a66e1c5fd765b21e74ba15 upstream.

---
 drivers/media/dvb/siano/smsusb.c |    2 ++
 1 file changed, 2 insertions(+)
drivers/media/dvb/siano/smsusb.c +2 -0
@@ -542,6 +542,8 @@ static const struct usb_device_id smsusb
 		.driver_info = SMS1XXX_BOARD_HAUPPAUGE_WINDHAM },
 	{ USB_DEVICE(0x2040, 0xc090),
 		.driver_info = SMS1XXX_BOARD_HAUPPAUGE_WINDHAM },
+	{ USB_DEVICE(0x2040, 0xc0a0),
+		.driver_info = SMS1XXX_BOARD_HAUPPAUGE_WINDHAM },
 	{ } /* Terminating entry */
 	};
 
author maintainer
#79 lore raw

PATCH 75/91 media: uvcvideo: Fix ENUMINPUT handling

In reply to Greg KH

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

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

From: Laurent Pinchart <[email protected]>

commit 31c5f0c5e25ed71eeced170f113bb590f2f1f6f3 upstream.

Properly validate the user-supplied index against the number of inputs. The code used the pin local variable instead of the index by mistake.

---
 drivers/media/video/uvc/uvc_v4l2.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/media/video/uvc/uvc_v4l2.c +1 -1
@@ -687,7 +687,7 @@ static long uvc_v4l2_do_ioctl(struct fil
 					break;
 			}
 			pin = iterm->id;
-		} else if (pin < selector->bNrInPins) {
+		} else if (index < selector->bNrInPins) {
 			pin = selector->baSourceID[index];
 			list_for_each_entry(iterm, &chain->entities, chain) {
 				if (!UVC_ENTITY_IS_ITERM(iterm))
author maintainer
#80 lore raw

PATCH 76/91 x86, relocs: Build clean fix

In reply to Greg KH

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

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

From: Jarkko Sakkinen <[email protected]>

commit b2d668da9307c4c163dd603d2bb3cadb10f9fd37 upstream.

relocs was not cleaned up when "make clean" is issued. This patch fixes the issue.

---
 arch/x86/Makefile |    1 +
 1 file changed, 1 insertion(+)
arch/x86/Makefile +1 -0
@@ -206,6 +206,7 @@ archclean:
 	$(Q)rm -rf $(objtree)/arch/i386
 	$(Q)rm -rf $(objtree)/arch/x86_64
 	$(Q)$(MAKE) $(clean)=$(boot)
+	$(Q)$(MAKE) $(clean)=arch/x86/tools
 
 define archhelp
   echo  '* bzImage      - Compressed kernel image (arch/x86/boot/bzImage)'
author maintainer
#81 lore raw

PATCH 77/91 x86-32, relocs: Whitelist more symbols for ld bug workaround

In reply to Greg KH

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

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

From: "H. Peter Anvin" <[email protected]>

commit fd952815307f0f272bf49fd364a7fd2f9992bc42 upstream.

As noted in checkin:

a3e854d95 x86, relocs: Workaround for binutils 2.22.52.0.1 section bug

ld version 2.22.52.0.[12] can incorrectly promote relative symbols to absolute, if the output section they appear in is otherwise empty.

Since checkin:

6520fe55 x86, realmode: 16-bit real-mode code support for relocs tool

we actually check for this and error out rather than silently creating a kernel which will malfunction if relocated.

Ingo found a configuration in which __start_builtin_fw triggered the warning.

Go through the linker script sources and look for more symbols that could plausibly get bogusly promoted to absolute, and add them to the whitelist.

In general, if the following error triggers:

Invalid absolute R_386_32 relocation: <symbol>

... then we should verify that <symbol> is really meant to be relocated, and add it and any related symbols manually to the S_REL regexp.

Please note that 6520fe55 does not introduce the error, only the check for the error -- without 6520fe55 this version of ld will simply produce a corrupt kernel if CONFIG_RELOCATABLE is set on x86-32.

---
 arch/x86/tools/relocs.c |   11 +++++++++++
 1 file changed, 11 insertions(+)
arch/x86/tools/relocs.c +11 -0
@@ -60,6 +60,17 @@ static const char * const sym_regex_kern
 	"__x86_cpu_dev_(start|end)|"
 	"(__parainstructions|__alt_instructions)(|_end)|"
 	"(__iommu_table|__apicdrivers|__smp_locks)(|_end)|"
+	"__(start|end)_pci_.*|"
+	"__(start|end)_builtin_fw|"
+	"__(start|stop)___ksymtab(|_gpl|_unused|_unused_gpl|_gpl_future)|"
+	"__(start|stop)___kcrctab(|_gpl|_unused|_unused_gpl|_gpl_future)|"
+	"__(start|stop)___param|"
+	"__(start|stop)___modver|"
+	"__(start|stop)___bug_table|"
+	"__tracedata_(start|end)|"
+	"__(start|stop)_notes|"
+	"__end_rodata|"
+	"__initramfs_start|"
 	"_end)$"
 };
 
author maintainer
#82 lore raw

PATCH 78/91 x86, relocs: Add jiffies and jiffies_64 to the relative whitelist

In reply to Greg KH

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

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

From: "H. Peter Anvin" <[email protected]>

commit ea17e7414bc62e8d3bde8d08e3df1d921c518c17 upstream.

The symbol jiffies is created in the linker script as an alias to jiffies_64. Unfortunately this is done outside any section, and apparently GNU ld 2.21 doesn't carry the section with it, so we end up with an absolute symbol and therefore a broken kernel.

Add jiffies and jiffies_64 to the whitelist.

The most disturbing bit with this discovery is that it shows that we have had multiple linker bugs in this area crossing multiple generations, and have been silently building bad kernels for some time.

---
 arch/x86/tools/relocs.c |    1 +
 1 file changed, 1 insertion(+)
arch/x86/tools/relocs.c +1 -0
@@ -71,6 +71,7 @@ static const char * const sym_regex_kern
 	"__(start|stop)_notes|"
 	"__end_rodata|"
 	"__initramfs_start|"
+	"(jiffies|jiffies_64)|"
 	"_end)$"
 };
 
author maintainer
#83 lore raw

PATCH 79/91 x86/mce: Fix check for processor context when machine check was taken.

In reply to Greg KH

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

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

From: Tony Luck <[email protected]>

commit 875e26648cf9b6db9d8dc07b7959d7c61fb3f49c upstream.

Linus pointed out that there was no value is checking whether m->ip was zero - because zero is a legimate value. If we have a reliable (or faked in the VM86 case) "m->cs" we can use it to tell whether we were in user mode or kernelwhen the machine check hit.

---
 arch/x86/kernel/cpu/mcheck/mce-severity.c |   16 ++++++++++------
 1 file changed, 10 insertions(+), 6 deletions(-)
arch/x86/kernel/cpu/mcheck/mce-severity.c +10 -6
@@ -165,15 +165,19 @@ static struct severity {
 };
 
 /*
- * If the EIPV bit is set, it means the saved IP is the
- * instruction which caused the MCE.
+ * If mcgstatus indicated that ip/cs on the stack were
+ * no good, then "m->cs" will be zero and we will have
+ * to assume the worst case (IN_KERNEL) as we actually
+ * have no idea what we were executing when the machine
+ * check hit.
+ * If we do have a good "m->cs" (or a faked one in the
+ * case we were executing in VM86 mode) we can use it to
+ * distinguish an exception taken in user from from one
+ * taken in the kernel.
  */
 static int error_context(struct mce *m)
 {
-	if (m->mcgstatus & MCG_STATUS_EIPV)
-		return (m->ip && (m->cs & 3) == 3) ? IN_USER : IN_KERNEL;
-	/* Unknown, assume kernel */
-	return IN_KERNEL;
+	return ((m->cs & 3) == 3) ? IN_USER : IN_KERNEL;
 }
 
 int mce_severity(struct mce *m, int tolerant, char **msg)
author maintainer
#84 lore raw

PATCH 80/91 mmc: sdio: avoid spurious calls to interrupt handlers

In reply to Greg KH

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

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

From: Nicolas Pitre <[email protected]>

commit bbbc4c4d8c5face097d695f9bf3a39647ba6b7e7 upstream.

Commit 06e8935feb ("optimized SDIO IRQ handling for single irq") introduced some spurious calls to SDIO function interrupt handlers, such as when the SDIO IRQ thread is started, or the safety check performed upon a system resume. Let's add a flag to perform the optimization only when a real interrupt is signaled by the host driver and we know there is no point confirming it.

---
 drivers/mmc/core/sdio.c     |    2 +-
 drivers/mmc/core/sdio_irq.c |   11 +++++++----
 include/linux/mmc/host.h    |    2 ++
 3 files changed, 10 insertions(+), 5 deletions(-)
drivers/mmc/core/sdio.c +1 -1
@@ -947,7 +947,7 @@ static int mmc_sdio_resume(struct mmc_ho
 	}
 
 	if (!err && host->sdio_irqs)
-		mmc_signal_sdio_irq(host);
+		wake_up_process(host->sdio_irq_thread);
 	mmc_release_host(host);
 
 	/*
drivers/mmc/core/sdio_irq.c +7 -4
@@ -28,18 +28,20 @@
 
 #include "sdio_ops.h"
 
-static int process_sdio_pending_irqs(struct mmc_card *card)
+static int process_sdio_pending_irqs(struct mmc_host *host)
 {
+	struct mmc_card *card = host->card;
 	int i, ret, count;
 	unsigned char pending;
 	struct sdio_func *func;
 
 	/*
 	 * Optimization, if there is only 1 function interrupt registered
-	 * call irq handler directly
+	 * and we know an IRQ was signaled then call irq handler directly.
+	 * Otherwise do the full probe.
 	 */
 	func = card->sdio_single_irq;
-	if (func) {
+	if (func && host->sdio_irq_pending) {
 		func->irq_handler(func);
 		return 1;
 	}
@@ -116,7 +118,8 @@ static int sdio_irq_thread(void *_host)
 		ret = __mmc_claim_host(host, &host->sdio_irq_thread_abort);
 		if (ret)
 			break;
-		ret = process_sdio_pending_irqs(host->card);
+		ret = process_sdio_pending_irqs(host);
+		host->sdio_irq_pending = false;
 		mmc_release_host(host);
 
 		/*
include/linux/mmc/host.h +2 -0
@@ -297,6 +297,7 @@ struct mmc_host {
 
 	unsigned int		sdio_irqs;
 	struct task_struct	*sdio_irq_thread;
+	bool			sdio_irq_pending;
 	atomic_t		sdio_irq_thread_abort;
 
 	mmc_pm_flag_t		pm_flags;	/* requested pm features */
@@ -352,6 +353,7 @@ extern int mmc_cache_ctrl(struct mmc_hos
 static inline void mmc_signal_sdio_irq(struct mmc_host *host)
 {
 	host->ops->enable_sdio_irq(host, 0);
+	host->sdio_irq_pending = true;
 	wake_up_process(host->sdio_irq_thread);
 }
 
author maintainer
#85 lore raw

PATCH 81/91 mmc: cd-gpio: protect against NULL context in mmc_cd_gpio_free()

In reply to Greg KH

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

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

From: Guennadi Liakhovetski <[email protected]>

commit 0e9f480bb553d39ee06ccd45639ba7a5446a7b81 upstream.

Do not oops, even if mmc_cd_gpio_free() is mistakenly called on a driver cleanup path, even though a previous call to mmc_cd_gpio_request() failed.

[stable@: please apply to 3.3-stable]
---
 drivers/mmc/core/cd-gpio.c |    3 +++
 1 file changed, 3 insertions(+)
drivers/mmc/core/cd-gpio.c +3 -0
@@ -73,6 +73,9 @@ void mmc_cd_gpio_free(struct mmc_host *h
 {
 	struct mmc_cd_gpio *cd = host->hotplug.handler_priv;
 
+	if (!cd)
+		return;
+
 	free_irq(host->hotplug.irq, host);
 	gpio_free(cd->gpio);
 	kfree(cd);
author maintainer
#86 lore raw

PATCH 82/91 mmc: omap_hsmmc: pass IRQF_ONESHOT to request_threaded_irq

In reply to Greg KH

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

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

From: Ming Lei <[email protected]>

commit db35f83ef47b5f180f2670d11f5f93992314ea09 upstream.

The flag of IRQF_ONESHOT should be passed to request_threaded_irq, otherwise the following failure message should be dumped because hardware handler is defined as NULL:

[    3.383483] genirq: Threaded irq requested with handler=NULL and
!ONESHOT for irq 368
[    3.392730] omap_hsmmc: probe of omap_hsmmc.0 failed with error -22

The patch fixes one kernel hang bug which is caused by mmc card probe failure and root device can't be brought up.

---
 drivers/mmc/host/omap_hsmmc.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/mmc/host/omap_hsmmc.c +1 -1
@@ -1969,7 +1969,7 @@ static int __devinit omap_hsmmc_probe(st
 		ret = request_threaded_irq(mmc_slot(host).card_detect_irq,
 					   NULL,
 					   omap_hsmmc_detect,
-					   IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING,
+					   IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
 					   mmc_hostname(mmc), host);
 		if (ret) {
 			dev_dbg(mmc_dev(host->mmc),
author maintainer
#87 lore raw

PATCH 83/91 tile: fix bug where fls(0) was not returning 0

In reply to Greg KH

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

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

From: Chris Metcalf <[email protected]>

commit 9f1d62bed7f015d11b9164078b7fea433b474114 upstream.

This is because __builtin_clz(0) returns 64 for the "undefined" case of 0, since the builtin just does a right-shift 32 and "clz" instruction. So, use the alpha approach of casting to u32 and using __builtin_clzll().

---
 arch/tile/include/asm/bitops.h |   12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)
arch/tile/include/asm/bitops.h +6 -6
@@ -77,6 +77,11 @@ static inline int ffs(int x)
 	return __builtin_ffs(x);
 }
 
+static inline int fls64(__u64 w)
+{
+	return (sizeof(__u64) * 8) - __builtin_clzll(w);
+}
+
 /**
  * fls - find last set bit in word
  * @x: the word to search
@@ -90,12 +95,7 @@ static inline int ffs(int x)
  */
 static inline int fls(int x)
 {
-	return (sizeof(int) * 8) - __builtin_clz(x);
-}
-
-static inline int fls64(__u64 w)
-{
-	return (sizeof(__u64) * 8) - __builtin_clzll(w);
+	return fls64((unsigned int) x);
 }
 
 static inline unsigned int __arch_hweight32(unsigned int w)
author maintainer
#88 lore raw

PATCH 84/91 intel-iommu: Add device info into list before doing context mapping

In reply to Greg KH

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

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

From: David Woodhouse <[email protected]>

commit e2ad23d04c1304431ab5176c89b7b476ded2d995 upstream.

Add device info into list before doing context mapping, because device info will be used by iommu_enable_dev_iotlb(). Without it, ATS won't get enabled as it should be.

ATS, while a dubious decision from a security point of view, can be very important for performance.

---
 drivers/iommu/intel-iommu.c |   17 +++++++++++------
 1 file changed, 11 insertions(+), 6 deletions(-)
drivers/iommu/intel-iommu.c +11 -6
@@ -2286,12 +2286,6 @@ static int domain_add_dev_info(struct dm
 	if (!info)
 		return -ENOMEM;
 
-	ret = domain_context_mapping(domain, pdev, translation);
-	if (ret) {
-		free_devinfo_mem(info);
-		return ret;
-	}
-
 	info->segment = pci_domain_nr(pdev->bus);
 	info->bus = pdev->bus->number;
 	info->devfn = pdev->devfn;
@@ -2304,6 +2298,17 @@ static int domain_add_dev_info(struct dm
 	pdev->dev.archdata.iommu = info;
 	spin_unlock_irqrestore(&device_domain_lock, flags);
 
+	ret = domain_context_mapping(domain, pdev, translation);
+	if (ret) {
+		spin_lock_irqsave(&device_domain_lock, flags);
+		list_del(&info->link);
+		list_del(&info->global);
+		pdev->dev.archdata.iommu = NULL;
+		spin_unlock_irqrestore(&device_domain_lock, flags);
+		free_devinfo_mem(info);
+		return ret;
+	}
+
 	return 0;
 }
 
author maintainer
#89 lore raw

PATCH 85/91 iommu: Fix off by one in dmar_get_fault_reason()

In reply to Greg KH

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

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

From: Dan Carpenter <[email protected]>

commit fefe1ed1398b81e3fadc92d11d91162d343c8836 upstream.

fault_reason - 0x20 == ARRAY_SIZE(irq_remap_fault_reasons) is one past the end of the array.

Cc Joerg Roedel <[email protected]>
Cc Youquan Song <[email protected]>
Cc walter harms <[email protected]>
Cc Suresh Siddha <[email protected]>
[bwh: Backported to 3.2: s/irq_remap_fault_reasons/intr_remap_fault_reasons/]
---
 drivers/iommu/dmar.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/iommu/dmar.c +2 -2
@@ -1056,8 +1056,8 @@ static const char *intr_remap_fault_reas
 
 const char *dmar_get_fault_reason(u8 fault_reason, int *fault_type)
 {
-	if (fault_reason >= 0x20 && (fault_reason <= 0x20 +
-				     ARRAY_SIZE(intr_remap_fault_reasons))) {
+	if (fault_reason >= 0x20 && (fault_reason - 0x20 <
+					ARRAY_SIZE(intr_remap_fault_reasons))) {
 		*fault_type = INTR_REMAP;
 		return intr_remap_fault_reasons[fault_reason - 0x20];
 	} else if (fault_reason < ARRAY_SIZE(dma_remap_fault_reasons)) {
author maintainer
#90 lore raw

PATCH 86/91 ARM: 7365/1: drop unused parameter from flush_cache_user_range

In reply to Greg KH

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

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

From: Dima Zavin <[email protected]>

commit 4542b6a0fa6b48d9ae6b41c1efeb618b7a221b2a upstream.

vma isn't used and flush_cache_user_range isn't a standard macro that is used on several archs with the same prototype. In fact only unicore32 has a macro with the same name (with an identical implementation and no in-tree users).

This is a part of a patch proposed by Dima Zavin (with Message-id:
[email protected]) that didn't get accepted.

---
 arch/arm/include/asm/cacheflush.h |    2 +-
 arch/arm/kernel/traps.c           |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)
arch/arm/include/asm/cacheflush.h +1 -1
@@ -249,7 +249,7 @@ extern void flush_cache_page(struct vm_a
  * Harvard caches are synchronised for the user space address range.
  * This is used for the ARM private sys_cacheflush system call.
  */
-#define flush_cache_user_range(vma,start,end) \
+#define flush_cache_user_range(start,end) \
 	__cpuc_coherent_user_range((start) & PAGE_MASK, PAGE_ALIGN(end))
 
 /*
arch/arm/kernel/traps.c +1 -1
@@ -496,7 +496,7 @@ do_cache_op(unsigned long start, unsigne
 		if (end > vma->vm_end)
 			end = vma->vm_end;
 
-		flush_cache_user_range(vma, start, end);
+		flush_cache_user_range(start, end);
 	}
 	up_read(&mm->mmap_sem);
 }
author maintainer
#91 lore raw

PATCH 87/91 ARM: 7409/1: Do not call flush_cache_user_range with mmap_sem held

In reply to Greg KH

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

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

From: Dima Zavin <[email protected]>

commit 435a7ef52db7d86e67a009b36cac1457f8972391 upstream.

We can't be holding the mmap_sem while calling flush_cache_user_range because the flush can fault. If we fault on a user address, the page fault handler will try to take mmap_sem again. Since both places acquire the read lock, most of the time it succeeds. However, if another thread tries to acquire the write lock on the mmap_sem (e.g. mmap) in between the call to flush_cache_user_range and the fault, the down_read in do_page_fault will deadlock.

[will: removed drop of vma parameter as already queued by rmk (7365/1)]

---
 arch/arm/kernel/traps.c |    2 ++
 1 file changed, 2 insertions(+)
arch/arm/kernel/traps.c +2 -0
@@ -496,7 +496,9 @@ do_cache_op(unsigned long start, unsigne
 		if (end > vma->vm_end)
 			end = vma->vm_end;
 
+		up_read(&mm->mmap_sem);
 		flush_cache_user_range(start, end);
+		return;
 	}
 	up_read(&mm->mmap_sem);
 }
author maintainer
#92 lore raw

PATCH 88/91 ARM: dt: tegra cardhu: fix typo in SDHCI node name

In reply to Greg KH

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

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

From: Stephen Warren <[email protected]>

commit 1dfebb426cfd16e2080f8c95e00ca2462f2325d4 upstream.

Cardhu's eMMC controller is on sdhci@78000600, not sdhci@78000400. Fix the typo. This roughly doubles the IO performance, since the support-8bit property actually takes effect.

---
 arch/arm/boot/dts/tegra-cardhu.dts |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm/boot/dts/tegra-cardhu.dts +1 -1
@@ -64,7 +64,7 @@
 		status = "disable";
 	};
 
-	sdhci@78000400 {
+	sdhci@78000600 {
 		support-8bit;
 	};
 };
author maintainer
#93 lore raw

PATCH 89/91 MCE: Fix vm86 handling for 32bit mce handler

In reply to Greg KH

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

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

From: Andi Kleen <[email protected]>

commit a129a7c84582629741e5fa6f40026efcd7a65bd4 upstream.

When running on 32bit the mce handler could misinterpret vm86 mode as ring 0. This can affect whether it does recovery or not; it was possible to panic when recovery was actually possible.

Fix this by always forcing vm86 to look like ring 3.

---
 arch/x86/kernel/cpu/mcheck/mce.c |    8 ++++++++
 1 file changed, 8 insertions(+)
arch/x86/kernel/cpu/mcheck/mce.c +8 -0
@@ -437,6 +437,14 @@ static inline void mce_gather_info(struc
 		if (m->mcgstatus & (MCG_STATUS_RIPV|MCG_STATUS_EIPV)) {
 			m->ip = regs->ip;
 			m->cs = regs->cs;
+
+			/*
+			 * When in VM86 mode make the cs look like ring 3
+			 * always. This is a lie, but it's better than passing
+			 * the additional vm86 bit around everywhere.
+			 */
+			if (v8086_mode(regs))
+				m->cs |= 3;
 		}
 		/* Use accurate RIP reporting if available. */
 		if (rip_msr)
author maintainer
#94 lore raw

PATCH 90/91 i2c: davinci: Free requested IRQ in remove

In reply to Greg KH

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

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

From: Marcus Folkesson <[email protected]>

commit 9868a060ccf769c08ec378a9829137e272e9a92c upstream.

The freed IRQ is not necessary the one requested in probe. Even if it was, with two or more i2c-controllers it will fails anyway.

---
 drivers/i2c/busses/i2c-davinci.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/i2c/busses/i2c-davinci.c +1 -1
@@ -755,7 +755,7 @@ static int davinci_i2c_remove(struct pla
 	dev->clk = NULL;
 
 	davinci_i2c_write_reg(dev, DAVINCI_I2C_MDR_REG, 0);
-	free_irq(IRQ_I2C, dev);
+	free_irq(dev->irq, dev);
 	iounmap(dev->base);
 	kfree(dev);
 
author maintainer
#95 lore raw

PATCH 91/91 i2c: tegra: notify transfer-complete after clearing status.

In reply to Greg KH

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

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

From: Laxman Dewangan <[email protected]>

commit c889e91d2cc22123f20f40dde0c0a91856a20eea upstream.

The notification of the transfer complete by calling complete() should be done after clearing all interrupt status. This avoids the race condition of misconfigure the i2c controller in multi-core environment.

---
 drivers/i2c/busses/i2c-tegra.c |   13 ++++++-------
 1 file changed, 6 insertions(+), 7 deletions(-)
drivers/i2c/busses/i2c-tegra.c +6 -7
@@ -401,8 +401,6 @@ static irqreturn_t tegra_i2c_isr(int irq
 			disable_irq_nosync(i2c_dev->irq);
 			i2c_dev->irq_disabled = 1;
 		}
-
-		complete(&i2c_dev->msg_complete);
 		goto err;
 	}
 
@@ -411,7 +409,6 @@ static irqreturn_t tegra_i2c_isr(int irq
 			i2c_dev->msg_err |= I2C_ERR_NO_ACK;
 		if (status & I2C_INT_ARBITRATION_LOST)
 			i2c_dev->msg_err |= I2C_ERR_ARBITRATION_LOST;
-		complete(&i2c_dev->msg_complete);
 		goto err;
 	}
 
@@ -429,14 +426,14 @@ static irqreturn_t tegra_i2c_isr(int irq
 			tegra_i2c_mask_irq(i2c_dev, I2C_INT_TX_FIFO_DATA_REQ);
 	}
 
+	i2c_writel(i2c_dev, status, I2C_INT_STATUS);
+	if (i2c_dev->is_dvc)
+		dvc_writel(i2c_dev, DVC_STATUS_I2C_DONE_INTR, DVC_STATUS);
+
 	if (status & I2C_INT_PACKET_XFER_COMPLETE) {
 		BUG_ON(i2c_dev->msg_buf_remaining);
 		complete(&i2c_dev->msg_complete);
 	}
-
-	i2c_writel(i2c_dev, status, I2C_INT_STATUS);
-	if (i2c_dev->is_dvc)
-		dvc_writel(i2c_dev, DVC_STATUS_I2C_DONE_INTR, DVC_STATUS);
 	return IRQ_HANDLED;
 err:
 	/* An error occurred, mask all interrupts */
@@ -446,6 +443,8 @@ err:
 	i2c_writel(i2c_dev, status, I2C_INT_STATUS);
 	if (i2c_dev->is_dvc)
 		dvc_writel(i2c_dev, DVC_STATUS_I2C_DONE_INTR, DVC_STATUS);
+
+	complete(&i2c_dev->msg_complete);
 	return IRQ_HANDLED;
 }
 
#96 lore raw
In reply to Greg KH

Hi Greg,

Quoted 7 lines · Greg KH

Note, I've tested this release a bit differently than I have in the past. For this release, I've only tested it on one machine, my laptop, with a pretty minimal configuration to save on build times. That means, while this release works for me, it might not for you, and it might not even build at all for you. Please test to verify that I haven't messed anything up. I'll give everyone at least an extra day than "normal" for this review cycle before I cut a final 3.4.1 release.

I've tested it here too on my netbook (atom N270). Tested video (i915), ethernet (atl1c), Wifi (ath9k), NFS, suspend. Nothing suspicious to report and it built without any issues.

Good job!

Willy

author maintainer
#97 lore raw
Quoted 11 lines · Willy Tarreau

Hi Greg,

Quoted 7 lines · Greg KH

Note, I've tested this release a bit differently than I have in the past. For this release, I've only tested it on one machine, my laptop, with a pretty minimal configuration to save on build times. That means, while this release works for me, it might not for you, and it might not even build at all for you. Please test to verify that I haven't messed anything up. I'll give everyone at least an extra day than "normal" for this review cycle before I cut a final 3.4.1 release.

Quoted 5 lines

I've tested it here too on my netbook (atom N270). Tested video (i915), ethernet (atl1c), Wifi (ath9k), NFS, suspend. Nothing suspicious to report and it built without any issues.

Good job!

Thanks for reporting and letting us know.

greg k-h

#98 lore raw

Re: [ 00/91] 3.4.1-stable review Fw: [PATCH 1/2] libata: add a host flag to ignore detected ATA devices FW: use hv_storvsc instead of ata_piix to handle the IDE disks devices ( but not for the CD-ROM)

In reply to Greg KH

Hi!

Quoted 1 line
Quoted 1 line

use hv_storvsc instead of ata_piix to handle the IDE disks devices ( but not for the CD-ROM)

Please, backport to 3.4.1-stable all related this:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=59d0952b43552570e0f1c3ff91ebb16d4caec171
==
days ago Linus Torvalds Merge tag 'upstream-linus' of git://git.kernel.org...
...Ugly MSFT Hyper-V workaround in ata_piix
ata_piix: defer disks to the Hyper-V drivers...

==

i.e.

http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=patch;h=db63a4c8115a0bb904496e1cdd3e7488e68b0d06
===

Quoted 1 line

From db63a4c8115a0bb904496e1cdd3e7488e68b0d06 Mon Sep 17 00:00:00 2001

From: Andy Whitcroft <[email protected]>
Date: Fri, 4 May 2012 22:15:10 +0100
Subject: [PATCH] libata: add a host flag to ignore detected ATA devices . . .
==

and

http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commitdiff_plain;h=cd006086fa5d91414d8ff9ff2b78fbb593878e3c;hp=db63a4c8115a0bb904496e1cdd3e7488e68b0d06
===
From: Andy Whitcroft <[email protected]>
Date: Fri, 4 May 2012 21:15:11 +0000 (+0100)
Subject: ata_piix: defer disks to the Hyper-V drivers by default

. . .
==

Best regards, Victor Miasnikov
Blog: http://vvm.blog.tut.by/

author maintainer
#99 lore raw

Re: [ 00/91] 3.4.1-stable review Fw: [PATCH 1/2] libata: add a host flag to ignore detected ATA devices FW: use hv_storvsc instead of ata_piix to handle the IDE disks devices ( but not for the CD-ROM)

Quoted 31 lines · Victor Miasnikov

Hi!

Quoted 1 line
Quoted 1 line

use hv_storvsc instead of ata_piix to handle the IDE disks devices ( but not for the CD-ROM)

Please, backport to 3.4.1-stable all related this:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=59d0952b43552570e0f1c3ff91ebb16d4caec171
==
days ago Linus Torvalds Merge tag 'upstream-linus' of git://git.kernel.org...
...Ugly MSFT Hyper-V workaround in ata_piix
ata_piix: defer disks to the Hyper-V drivers...

==

i.e.

http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=patch;h=db63a4c8115a0bb904496e1cdd3e7488e68b0d06
===

Quoted 1 line

From db63a4c8115a0bb904496e1cdd3e7488e68b0d06 Mon Sep 17 00:00:00 2001

From: Andy Whitcroft <[email protected]>
Date: Fri, 4 May 2012 22:15:10 +0100
Subject: [PATCH] libata: add a host flag to ignore detected ATA devices . . .
==

and

Quoted 8 lines

http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commitdiff_plain;h=cd006086fa5d91414d8ff9ff2b78fbb593878e3c;hp=db63a4c8115a0bb904496e1cdd3e7488e68b0d06
===
From: Andy Whitcroft <[email protected]>
Date: Fri, 4 May 2012 21:15:11 +0000 (+0100)
Subject: ata_piix: defer disks to the Hyper-V drivers by default

. . .
==

I do not understand, what exactly are the git commit ids that you wish to see applied to the stable tree?

And it's too late for 3.4.1, as that is already out for review.

greg k-h

#100 lore raw

Re: [ 00/91] 3.4.1-stable review Fw: [PATCH 1/2] libata: add a host flag to ignore detected ATA devices FW: use hv_storvsc instead of ata_piix to handle the IDE disks devices ( but not for the CD-ROM)

Quoted 2 lines · Greg KH

I do not understand, what exactly are the git commit ids that you wish to see applied to the stable tree?

I think he wants

cd006086fa5d ata_piix: defer disks to the Hyper-V drivers by default

and its prerequisite

db63a4c8115a libata: add a host flag to ignore detected ATA devices

Hope that helps,
Jonathan

#101 lore raw

Linux on Hyper-V 1) cd006086fa5d ata_piix: defer disks to the Hyper-V drivers by default 2) db63a4c8115a libata: add a host flag to ignore detected ATA device FW: use hv_storvsc instead of ata_piix to handle the IDE disks devices ( but not for the CD-ROM)

In reply to Greg KH

Hi!

Quoted 1 line

And it's too late for 3.4.1, as that is already out for review.

Ok: "Please, backport to 3.4.2"

{ P.S.
And "to 3.3.x" and "to 3.2.x" i.e. to all actual version after 3.1

}

Quoted 1 line
Quoted 1 line
Quoted 1 line

use hv_storvsc instead of ata_piix to handle the IDE disks devices ( but not for the CD-ROM)

VVM> Please, backport to 3.4.2-stable all related this:

Quoted 5 lines
Quoted 2 lines

...Ugly MSFT Hyper-V workaround in ata_piix
ata_piix: defer disks to the Hyper-V drivers...

I do not understand, what exactly are the git commit ids that you wish to see applied to the stable tree?

Sorry:

1)
db63a4c8115a0bb904496e1cdd3e7488e68b0d06
2)
cd006086fa5d91414d8ff9ff2b78fbb593878e3c

{
Jonathan Nieder think:

cd006086fa5d ata_piix: defer disks to the Hyper-V drivers by default

and its prerequisite

db63a4c8115a libata: add a host flag to ignore detected ATA devices

}

Some details:
1:
http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;h=db63a4c8115a0bb904496e1cdd3e7488e68b0d06
==
libata: add a host flag to ignore detected ATA devices

     author Andy Whitcroft < apw ( at ) canonical.com >
    Fri, 4 May 2012 21:15:10 +0000 (22:15 +0100)
     committer Jeff Garzik < jgarzik ( at ) redhat.com >
    Mon, 7 May 2012 19:32:23 +0000 (15:32 -0400)
     commit db63a4c8115a0bb904496e1cdd3e7488e68b0d06
     tree 326448b28bf8de7c6205ed9e598070111e8a5020

==

2:
http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;h=cd006086fa5d91414d8ff9ff2b78fbb593878e3c;hp=db63a4c8115a0bb904496e1cdd3e7488e68b0d06
==
ata_piix: defer disks to the Hyper-V drivers by default

     author Andy Whitcroft  < apw ( at ) canonical.com >
    Fri, 4 May 2012 21:15:11 +0000 (22:15 +0100)
     committer Jeff Garzik < jgarzik ( at ) redhat.com >
    Mon, 7 May 2012 19:32:58 +0000 (15:32 -0400)
     commit cd006086fa5d91414d8ff9ff2b78fbb593878e3c

==

Best regards, Victor Miasnikov
Blog: http://vvm.blog.tut.by/

author maintainer
#102 lore raw

Re: Linux on Hyper-V 1) cd006086fa5d ata_piix: defer disks to the Hyper-V drivers by default 2) db63a4c8115a libata: add a host flag to ignore detected ATA device FW: use hv_storvsc instead of ata_piix to handle the IDE disks devices ( but not for the CD-ROM)

Quoted 27 lines · Victor Miasnikov

Hi!

Quoted 1 line

And it's too late for 3.4.1, as that is already out for review.

Ok: "Please, backport to 3.4.2"

{ P.S.
And "to 3.3.x" and "to 3.2.x" i.e. to all actual version after 3.1

}

Quoted 1 line
Quoted 1 line
Quoted 1 line

use hv_storvsc instead of ata_piix to handle the IDE disks devices ( but not for the CD-ROM)

VVM> Please, backport to 3.4.2-stable all related this:

Quoted 5 lines
Quoted 2 lines

...Ugly MSFT Hyper-V workaround in ata_piix
ata_piix: defer disks to the Hyper-V drivers...

I do not understand, what exactly are the git commit ids that you wish to see applied to the stable tree?

Sorry:

1)
db63a4c8115a0bb904496e1cdd3e7488e68b0d06
2)
cd006086fa5d91414d8ff9ff2b78fbb593878e3c

Quoted 8 lines

{
Jonathan Nieder think:

cd006086fa5d ata_piix: defer disks to the Hyper-V drivers by default

and its prerequisite

db63a4c8115a libata: add a host flag to ignore detected ATA devices

Sorry, but I don't see how this meets the rules for the stable trees, do you? If so, please show me how.

thanks,

greg k-h

#103 lore raw

Re: Linux on Hyper-V 1) cd006086fa5d ata_piix: defer disks to the Hyper-V drivers by default 2) db63a4c8115a libata: add a host flag to ignore detected ATA device FW: use hv_storvsc instead of ata_piix to handle the IDE disks devices ( but not for the CD-R

Hi!

Quoted 5 lines
Quoted 3 lines

cd006086fa5d ata_piix: defer disks to the Hyper-V drivers by default
and its prerequisite
db63a4c8115a libata: add a host flag to ignore detected ATA devices

Sorry, but I don't see how this meets the rules for the stable trees, do you? If so, please show me how.

About "how" -- ask K.Y. Srinivasan

Hyper-V admins need _worked_ Linux v3.4.X / v3.3.X / v3.2.X

Please, _fix_ errors related "use hv_storvsc instead of ata_piix to handle the IDE disks devices ( but not for the CD-ROM)"

Thanks
Best regards, Victor Miasnikov
Blog: http://vvm.blog.tut.by/

author maintainer
#104 lore raw

Re: Linux on Hyper-V 1) cd006086fa5d ata_piix: defer disks to the Hyper-V drivers by default 2) db63a4c8115a libata: add a host flag to ignore detected ATA device FW: use hv_storvsc instead of ata_piix to handle the IDE disks devices ( but not for the CD-R

Quoted 6 lines · Victor Miasnikov

Hi!

Quoted 3 lines
Quoted 3 lines

cd006086fa5d ata_piix: defer disks to the Hyper-V drivers by default and its prerequisite
db63a4c8115a libata: add a host flag to ignore detected ATA devices

Quoted 8 lines
Quoted 1 line

Sorry, but I don't see how this meets the rules for the stable trees, do you? If so, please show me how.

About "how" -- ask K.Y. Srinivasan

Hyper-V admins need _worked_ Linux v3.4.X / v3.3.X / v3.2.X

Please, _fix_ errors related "use hv_storvsc instead of ata_piix to handle the IDE disks devices ( but not for the CD-ROM)"

Ok, I'll wait for KY to explain this.

greg k-h

#105 lore raw

RE: Linux on Hyper-V 1) cd006086fa5d ata_piix: defer disks to the Hyper-V drivers by default 2) db63a4c8115a libata: add a host flag to ignore detected ATA device FW: use hv_storvsc instead of ata_piix to handle the IDE disks devices ( but not for the ...

Quoted 23 lines

-----Original Message-----
From: Greg KH [mailto:[email protected]]
Sent: Friday, June 01, 2012 12:26 PM
To: Victor Miasnikov
Cc: [email protected]; Jonathan Nieder; [email protected]; KY Srinivasan
Subject: Re: Linux on Hyper-V 1) cd006086fa5d ata_piix: defer disks to the Hyper- V drivers by default 2) db63a4c8115a libata: add a host flag to ignore detected ATA device FW: use hv_storvsc instead of ata_piix to handle the IDE disks devices ( but not for the ...

Quoted 7 lines · Victor Miasnikov

Hi!

Quoted 5 lines
Quoted 3 lines

cd006086fa5d ata_piix: defer disks to the Hyper-V drivers by default and its prerequisite
db63a4c8115a libata: add a host flag to ignore detected ATA devices

Sorry, but I don't see how this meets the rules for the stable trees, do you? If

so, please show me how.

Quoted 1 line
Quoted 8 lines
Quoted 6 lines

About "how" -- ask K.Y. Srinivasan

Hyper-V admins need _worked_ Linux v3.4.X / v3.3.X / v3.2.X

Please, _fix_ errors related "use hv_storvsc instead of ata_piix to handle the IDE disks devices ( but not for the CD-ROM)"

Ok, I'll wait for KY to explain this.

Greg,

Clearly I cannot tell you anything about this that you don't know! Looking at the rules for stable tree patches, this patch does not satisfy the requirement that the patch fix a bug since we are changing the behavior here of the ata driver to accommodate Hyper-V. I don't know how much flexibility you have here for taking patches that improve the general usability of Linux in different environments. All I can say is that It will be nice to have this patch in previous stable releases.

Regards,

K. Y

author maintainer
#106 lore raw

Re: Linux on Hyper-V 1) cd006086fa5d ata_piix: defer disks to the Hyper-V drivers by default 2) db63a4c8115a libata: add a host flag to ignore detected ATA device FW: use hv_storvsc instead of ata_piix to handle the IDE disks devices ( but not for the ...

Quoted 34 lines · KY Srinivasan
Quoted 23 lines

-----Original Message-----
From: Greg KH [mailto:[email protected]]
Sent: Friday, June 01, 2012 12:26 PM
To: Victor Miasnikov
Cc: [email protected]; Jonathan Nieder; [email protected]; KY Srinivasan
Subject: Re: Linux on Hyper-V 1) cd006086fa5d ata_piix: defer disks to the Hyper- V drivers by default 2) db63a4c8115a libata: add a host flag to ignore detected ATA device FW: use hv_storvsc instead of ata_piix to handle the IDE disks devices ( but not for the ...

Quoted 7 lines · Victor Miasnikov

Hi!

Quoted 5 lines
Quoted 3 lines

cd006086fa5d ata_piix: defer disks to the Hyper-V drivers by default and its prerequisite
db63a4c8115a libata: add a host flag to ignore detected ATA devices

Sorry, but I don't see how this meets the rules for the stable trees, do you? If

so, please show me how.

Quoted 1 line
Quoted 8 lines
Quoted 6 lines

About "how" -- ask K.Y. Srinivasan

Hyper-V admins need _worked_ Linux v3.4.X / v3.3.X / v3.2.X

Please, _fix_ errors related "use hv_storvsc instead of ata_piix to handle the IDE disks devices ( but not for the CD-ROM)"

Ok, I'll wait for KY to explain this.

Greg,

Quoted 7 lines

Clearly I cannot tell you anything about this that you don't know! Looking at the rules for stable tree patches, this patch does not satisfy the requirement that the patch fix a bug since we are changing the behavior here of the ata driver to accommodate Hyper-V. I don't know how much flexibility you have here for taking patches that improve the general usability of Linux in different environments. All I can say is that It will be nice to have this patch in previous stable releases.

Lots of things would be "nice", but as this doesn't meet the stable_kernel_rules.txt rules, sorry, I can't take them.

greg k-h

#107 lore raw

Re: Linux on Hyper-V 1) cd006086fa5d ata_piix: defer disks to the Hyper-V drivers by default 2) db63a4c8115a libata: add a host flag to ignore detected ATA device FW: use hv_storvsc instead of ata_piix to handle the IDE disks devices ( but not for the ...

Hi!

VVM > > > Hyper-V admins need _worked_ Linux v3.4.X / v3.3.X / v3.2.X VVM > > >
VVM > > > Please, _fix_ errors related "use hv_storvsc instead of ata_piix to VVM > > > handle the IDE disks devices ( but not for the CD-ROM)"

K.Y.S. >> {
Clearly I cannot tell you anything about this that you don't know! Looking at the rules for stable tree patches,
this patch does not satisfy the requirement that the patch fix a bug since we are changing the behavior here of the ata driver to accommodate Hyper-V. I don't know how much flexibility you have here for taking patches that improve the general usability of Linux in different environments.
All I can say is that It will be nice to have this patch in previous stable releases. }

This is _real_ bug

{ P.S.
Dear K.Y., please read _again_ my letter
Sent: Monday, April 02, 2012 1:46 PM
}

Quoted 2 lines

Lots of things would be "nice",
but as this doesn't meet the stable_kernel_rules.txt rules, sorry, I can't take them.

IMHO, patches "does meet the stable_kernel_rules.txt rules" by _all_ criterias . . .

See info correlated with rules:
==
Rules on what kind of patches are accepted, and which ones are not, into the "-stable" tree:

{
- It must be obviously correct and tested.

Tested ( but, in early implementaition): Ubuntu 12.04 + OpenSUSE

}

{

- It cannot be bigger than 100 lines, with context.

79 lines
+
47 lines
}

{
- It must fix only one thing.

Yes

}

{

- It must fix a real bug that bothers people (not a, "This could be a problem..." type thing).

Is real bug: see URLs in my e-mails about problem
+ see tranlate from Russian language issue described by Maksim Kramarenko:
http://lists.debian.org/debian-russian/2012/01/msg00324.html
==

. . .

At the conclusion of the system through the halt or when sending a signal shutdown by ACPI to power down the console fell errors:
http://www.k-max.name/wp-content/uploads/2012/01/hyper-v.png

Errors do not interfere with work, but sneaking suspicion about future problems with the hard drive ...

. . .

in general, the source of the problem as follows:
After [VVM: turn On in kernel source] Hyper-V modules [compile and start use], a hard disk was determined as 2 with the same UUID.

. . .

Here are screenshots of what is happening:
connected to a drive:
http://www.k-max.name/wp-content/uploads/2012/01/hdd-e1327750214479.png
it is defined as a 2:
http://www.k-max.name/wp-content/uploads/2012/01/2hdd.png
Naturally, the same UUID:
http://www.k-max.name/wp-content/uploads/2012/01/blkid.png
That's what tells us the directory / dev:
http://www.k-max.name/wp-content/uploads/2012/01/uuid.png

==

}

{
- It must fix a problem that causes a build error (but not for things marked CONFIG_BROKEN), an oops, a hang, data corruption, a real security issue, or some "oh, that's not good" issue. In short, something critical.
- New device IDs and quirks are also accepted.

not related this patch

}

{
- No "theoretical race condition" issues, unless an explanation of how the race can be exploited is also provided.
- It cannot contain any "trivial" fixes in it (spelling changes, whitespace cleanups, etc).

No "theoretical" , no "trivial"

}

- It must follow the Documentation/SubmittingPatches rules.

Prepare patches -- this job duty of Microsoft employee

- It or an equivalent fix must already exist in Linus' tree (upstream).

Yes

==

Best regards, Victor Miasnikov
Blog: http://vvm.blog.tut.by/

#108 lore raw

RE: Linux on Hyper-V 1) cd006086fa5d ata_piix: defer disks to the Hyper-V drivers by default 2) db63a4c8115a libata: add a host flag to ignore detected ATA device FW: use hv_storvsc instead of ata_piix to handle the IDE disks devices ( but not for the ...

Quoted 13 lines

-----Original Message-----
From: Victor Miasnikov [mailto:[email protected]]
Sent: Monday, June 04, 2012 8:33 AM
To: Greg KH; KY Srinivasan
Cc: [email protected]; Jonathan Nieder; [email protected]; Mike Sterling
Subject: Re: Linux on Hyper-V 1) cd006086fa5d ata_piix: defer disks to the Hyper- V drivers by default 2) db63a4c8115a libata: add a host flag to ignore detected ATA device FW: use hv_storvsc instead of ata_piix to handle the IDE disks devices ( but not for the ...

Quoted 3 lines

Hi!

VVM > > > Hyper-V admins need _worked_ Linux v3.4.X / v3.3.X / v3.2.X

Victor, what distro are you using. I can help you with the ata patch on specific set of distros of interest. If the system that you are interested loads the ata_piix module, we can solve the issue on hand using modprobe rules rather than a patch against the ata driver. Let me know.

Regards,

K. Y

Quoted 1 line
#109 lore raw

Re: Linux on Hyper-V 1) cd006086fa5d ata_piix: defer disks to the Hyper-V drivers by default 2) db63a4c8115a libata: add a host flag to ignore detected ATA device FW: use hv_storvsc instead of ata_piix to handle the IDE disks devices ( but not for the ...

Hi!

Quoted 2 lines

VVM > > > Hyper-V admins need _worked_ Linux v3.4.X / v3.3.X / v3.2.X
I can help you with the ata patch on specific set of distros of interest. If the system that you are interested loads the ata_piix module, we can solve the issue on hand using modprobe rules rather than a patch against the ata driver.

K.Y.: Youre _theory_ ( about "can solve the issue on hand using modprobe rules") is wrong for:
-- OpenSUSE
-- Ubuntu
-- Debian

Why You think, what theory can solve problem in other case?

How about LiveCD ?

But "patch against the ata driver" -- solve problem 100% / 100%

Best regards, Victor Miasnikov
Blog: http://vvm.blog.tut.by/

P.S.

Quoted 1 line

Victor, what distro are you using. Let me know.

But Hyper-V admins need "result" -- if You can fix _all_ what need by "modprobe rules" -- fix issue in:

Kernel:
3.5 -- done
3.4.latest
3.3.latest
3.2.latest

Distro:
-- Arch Linux
-- Chacra
-- _all_ LiveCD
-- Gentoo
-- Debian
-- Fedora

#110 lore raw

RE: Linux on Hyper-V 1) cd006086fa5d ata_piix: defer disks to the Hyper-V drivers by default 2) db63a4c8115a libata: add a host flag to ignore detected ATA device FW: use hv_storvsc instead of ata_piix to handle the IDE disks devices ( but not for the ...

Quoted 15 lines

-----Original Message-----
From: Victor Miasnikov [mailto:[email protected]]
Sent: Monday, June 04, 2012 10:15 AM
To: KY Srinivasan; Greg KH
Cc: [email protected]; Jonathan Nieder; [email protected]; Mike Sterling
Subject: Re: Linux on Hyper-V 1) cd006086fa5d ata_piix: defer disks to the Hyper- V drivers by default 2) db63a4c8115a libata: add a host flag to ignore detected ATA device FW: use hv_storvsc instead of ata_piix to handle the IDE disks devices ( but not for the ...

Hi!

Quoted 8 lines
Quoted 4 lines

VVM > > > Hyper-V admins need _worked_ Linux v3.4.X / v3.3.X / v3.2.X I can help you with the ata patch on specific set of distros of interest. If the system that you are interested loads the ata_piix module, we can solve the issue on hand using modprobe rules rather than a patch

against the ata driver.

K.Y.: Youre _theory_ ( about "can solve the issue on hand using modprobe
rules") is wrong for:

As I said, if the ata_piix driver is a loadable module, we can solve the issue with modprobe rules. If it is not a loadable module we cannot obviously solve the problem with modprobe rules and we will need the ata patch.

Regards,

K. Y

#111 lore raw

Re: Linux on Hyper-V 1) cd006086fa5d ata_piix: defer disks to the Hyper-V drivers by default 2) db63a4c8115a libata: add a host flag to ignore detected ATA device FW: use hv_storvsc instead of ata_piix to handle the IDE disks devices ( but not for the ...

Hi!

Quoted 11 lines
Quoted 8 lines
Quoted 4 lines

VVM > > > Hyper-V admins need _worked_ Linux v3.4.X / v3.3.X / v3.2.X I can help you with the ata patch on specific set of distros of interest. If the system that you are interested loads the ata_piix module, we can solve the issue on hand using modprobe rules rather than a patch

against the ata driver.

K.Y.: Youre _theory_ ( about "can solve the issue on hand using modprobe
rules") is wrong for:

As I said, if the ata_piix driver is a loadable module, we can solve the issue with modprobe rules. If it is not a loadable module we cannot obviously solve the problem with modprobe rules and we will need the ata patch.

Nothing new:
-- "the ata patch" is need, if we want worked 100% / 100% Linux on Hyper-V
-- "solve the problem with modprobe rules" very often not worked solution ( i.e. if the ata_piix driver . . . )

Total:

{
cd006086fa5d ata_piix: defer disks to the Hyper-V drivers by default

and its prerequisite

db63a4c8115a libata: add a host flag to ignore detected ATA devices
}
need be backported from

3.5

to

3.4.latest
3.3.latest
3.2.latest

Best regards, Victor Miasnikov
Blog: http://vvm.blog.tut.by/

P.S.

Quoted 1 line

As I said, if the ata_piix driver is a loadable module, we can solve the issue with modprobe rules.

We can test Youre theory:

----- Original Message ----- From: "Victor Miasnikov"
To: "KY Srinivasan"
Sent: Monday, June 04, 2012 6:50 PM

. . .

with use only "modprobe rules" prepare binary patch ( .xDelta) for <Linux_Distib_ZZZZ_Kernel_3.2_>

. . .

Goal: work in Hyper-V guest as ( ( Linux_Distib_ZZZZ_Kernel_3.1_.iso ) + worked mouse ) ) in LiveCD and after install

--

#112 lore raw

Re: [PATCH 2/2] ata_piix: defer disks to the Hyper-V drivers by default

In reply to Victor Miasnikov

Hi,

Quoted 8 lines · Victor Miasnikov

+ see tranlate from Russian language issue described by Maksim Kramarenko:
http://lists.debian.org/debian-russian/2012/01/msg00324.html

Quoted 5 lines

Correct, that is loaded without error, sleep and wake, for a small exception:

At the conclusion of the system through the halt or when sending a signal shutdown by ACPI to power down the console fell errors:
http://www.k-max.name/wp-content/uploads/2012/01/hyper-v.png

[That image shows the message

exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 ata1.00: failed command: STANDBY IMMEDIATE
]

Quoted 2 lines
Quoted 2 lines

Errors do not interfere with work, but sneaking suspicion about future problems with the hard drive ...

[...]

Quoted 3 lines
Quoted 3 lines

in general, the source of the problem as follows:
After [VVM: turn On in kernel source] Hyper-V modules [compile and start use], a hard disk was determined as 2 with the same UUID.

[...]

Quoted 8 lines
Quoted 8 lines

connected to a drive:
http://www.k-max.name/wp-content/uploads/2012/01/hdd-e1327750214479.png
it is defined as a 2:
http://www.k-max.name/wp-content/uploads/2012/01/2hdd.png
Naturally, the same UUID:
http://www.k-max.name/wp-content/uploads/2012/01/blkid.png
That's what tells us the directory / dev:
http://www.k-max.name/wp-content/uploads/2012/01/uuid.png

Thanks --- I think this is what Greg was asking for.

If I understand correctly, the problem is that ata_piix and hv_storvsc both claim the (virtual) hard disk. That sounds worth fixing. The patch works by making ata_piix skip the disk during enumeration if hv_storvsc is enabled as a built-in driver or module.

A workaround is to blacklist the ata_piix module. However, that means losing access to CD and DVD drives which are exposed by ata_piix and not hv_storvsc.

Hoping that clarifies,
Jonathan

#113 lore raw

ToDo: backport to v3.4 , v3.3 , v3.2 patches 1b) db63a4c8115a libata 1) cd006086fa5d ata_piix: defer disks to the Hyper-V drivers by default Fw: use hv_storvsc instead of ata_piix for IDE disks ( but not for the CD-ROM)

Hi!

Quoted 1 line
Quoted 1 line
Quoted 1 line

use hv_storvsc instead of ata_piix to handle the IDE disks devices ( but not for the CD-ROM)

J.N.> the problem is that ata_piix and hv_storvscboth claim the (virtual) hard disk.

Yes:
{ About bug fixed by patches:

Quoted 5 lines
Quoted 5 lines

see tranlate from Russian language issue described by Maksim Kramarenko:
http://lists.debian.org/debian-russian/2012/01/msg00324.html

Quoted 2 lines

After [VVM: turn On in kernel source] Hyper-V modules [compile and start use], a hard disk was determined as 2 with the same UUID.

}

J.N.> {
A workaround is to blacklist the ata_piix module. However, that means losing access to CD and DVD drives which are exposed by ata_piix and not hv_storvsc. }

Yes: work without CD-ROM is not super-fine, {
best backport patches from v3.5 ( de-facto reincarnation _tested_(!) patches from Ubuntu v12.04 and/or OpenSUSE ) :

J.N.> {
The patch works by making ata_piix skip the disk during enumeration if hv_storvsc is enabled as a built-in driver or module. }

Quoted 1 line
Quoted 1 line
Quoted 1 line

VVM > > > Hyper-V admins need _worked_ Linux v3.4.X / v3.3.X / v3.2.X

i.e. need backport to all actual version after 3.1

cd006086fa5d ata_piix: defer disks to the Hyper-V drivers by default

and its prerequisite

db63a4c8115a libata: add a host flag to ignore detected ATA devices

}

Quoted 1 line

--- I think this is what Greg was asking for.

I supose . . .

Thanks,
Best regards, Victor Miasnikov
Blog: http://vvm.blog.tut.by/

P.S.

Quoted 1 line

Thanks

No problem :-)

Quoted 1 line

Hoping that clarifies,

Yes: very good description of problem and possible solution Big thanks!

--

----- Original Message ----- From: "Jonathan Nieder" To: . . . Cc: . . .
Sent: Tuesday, June 05, 2012 7:59 AM
Subject: Re: [PATCH 2/2] ata_piix: defer disks to the Hyper-V drivers by default

. . .

If I understand correctly, the problem is that ata_piix and hv_storvscboth claim the (virtual) hard disk. That sounds worth fixing. The patch works by making ata_piix skip the disk during enumeration if hv_storvsc is enabled as a built-in driver or module.

A workaround is to blacklist the ata_piix module. However, that means losing access to CD and DVD drives which are exposed by ata_piix and not hv_storvsc. --

author maintainer
#114 lore raw
In reply to Greg KH
Quoted 7 lines · Greg KH

Note, I've tested this release a bit differently than I have in the past. For this release, I've only tested it on one machine, my laptop, with a pretty minimal configuration to save on build times. That means, while this release works for me, it might not for you, and it might not even build at all for you. Please test to verify that I haven't messed anything up. I'll give everyone at least an extra day than "normal" for this review cycle before I cut a final 3.4.1 release.

It looks like people get even more time to test as I'm not going to be able to push these updates out until Thursday or Friday at the earliest, due to me being stuck in an area of Asia where the internet connectivity really isn't all that good.

Sorry for the delay,

greg k-h

author maintainer
#115 lore raw
In reply to Greg KH
Quoted 7 lines · Greg KH

Note, I've tested this release a bit differently than I have in the past. For this release, I've only tested it on one machine, my laptop, with a pretty minimal configuration to save on build times. That means, while this release works for me, it might not for you, and it might not even build at all for you. Please test to verify that I haven't messed anything up. I'll give everyone at least an extra day than "normal" for this review cycle before I cut a final 3.4.1 release.

It looks like people get even more time to test as I'm not going to be able to push these updates out until Thursday or Friday at the earliest, due to me being stuck in an area of Asia where the internet connectivity really isn't all that good.

Sorry for the delay,

greg k-h