[00/29] 2.6.32.6 stable review

[00/29] 2.6.32.6 stable review

[Greg KH]

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

Responses should be made by Monday, January 24, 00:00:00 UTC.
Anything received after that time might be too late.

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

thanks,

greg k-h


 Makefile                              |    2 +-
 arch/x86/kernel/cpuid.c               |    5 +-
 arch/x86/kernel/msr.c                 |    4 +-
 arch/x86/pci/i386.c                   |    9 +++
 block/blk-settings.c                  |   22 ++++++
 drivers/acpi/ec.c                     |  125 +++++++++++++++++++++------------
 drivers/char/nozomi.c                 |    2 +-
 drivers/char/tty_io.c                 |    2 +-
 drivers/gpu/drm/i915/intel_sdvo.c     |   83 +++++++++++++++++++++-
 drivers/md/dm-table.c                 |   20 ++----
 drivers/media/video/gspca/sunplus.c   |   26 ++++----
 drivers/misc/enclosure.c              |    1 +
 drivers/serial/8250_pnp.c             |   10 +---
 drivers/staging/asus_oled/asus_oled.c |   12 ++-
 drivers/staging/hv/Hv.c               |   50 +++++++-------
 drivers/staging/hv/Hv.h               |    6 +-
 drivers/staging/hv/Vmbus.c            |   12 ++--
 drivers/usb/core/devices.c            |    2 +-
 drivers/usb/core/hub.c                |    3 +
 drivers/usb/core/message.c            |    8 +-
 drivers/usb/core/sysfs.c              |    6 ++
 drivers/usb/host/ehci-hcd.c           |    5 +-
 drivers/usb/host/ehci-hub.c           |   20 +++++-
 drivers/usb/host/ehci-q.c             |   11 ++-
 drivers/usb/host/uhci-hcd.c           |   15 ++++-
 drivers/usb/host/uhci-hub.c           |    2 +-
 drivers/usb/serial/generic.c          |    2 +
 drivers/usb/storage/unusual_devs.h    |    7 --
 drivers/usb/storage/usb.c             |    3 +-
 fs/ecryptfs/crypto.c                  |    4 +-
 fs/ecryptfs/file.c                    |   14 ++--
 include/linux/blkdev.h                |    2 +
 include/linux/enclosure.h             |    2 +
 kernel/perf_event.c                   |   29 +++++++-
 mm/vmalloc.c                          |    4 +-
 tools/perf/builtin-timechart.c        |    2 +-
 36 files changed, 365 insertions(+), 167 deletions(-)

[01/29] x86, msr/cpuid: Register enough minors for the MSR and CPUID drivers

[Greg KH]

2.6.32-stable review patch.  If anyone has any objections, please let us know.

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

From: H. Peter Anvin <hpa@zytor.com>

commit 0b962d473af32ec334df271b54ff4973cb2b4c73 upstream.

register_chrdev() hardcodes registering 256 minors, presumably to
avoid breaking old drivers.  However, we need to register enough
minors so that we have all possible CPUs.

checkpatch warns on this patch, but the patch is correct: NR_CPUS here
is a static *upper bound* on the *maximum CPU index* (not *number of
CPUs!*) and that is what we want.

Reported-and-tested-by: Russ Anderson <rja@sgi.com>
Cc: Tejun Heo <tj@kernel.org>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Takashi Iwai <tiwai@suse.de>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
LKML-Reference: <tip-*@git.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 arch/x86/kernel/cpuid.c |    5 +++--
 arch/x86/kernel/msr.c   |    4 ++--
 2 files changed, 5 insertions(+), 4 deletions(-)

--- a/arch/x86/kernel/cpuid.c
+++ b/arch/x86/kernel/cpuid.c
@@ -192,7 +192,8 @@ static int __init cpuid_init(void)
 	int i, err = 0;
 	i = 0;
 
-	if (register_chrdev(CPUID_MAJOR, "cpu/cpuid", &cpuid_fops)) {
+	if (__register_chrdev(CPUID_MAJOR, 0, NR_CPUS,
+			      "cpu/cpuid", &cpuid_fops)) {
 		printk(KERN_ERR "cpuid: unable to get major %d for cpuid\n",
 		       CPUID_MAJOR);
 		err = -EBUSY;
@@ -221,7 +222,7 @@ out_class:
 	}
 	class_destroy(cpuid_class);
 out_chrdev:
-	unregister_chrdev(CPUID_MAJOR, "cpu/cpuid");
+	__unregister_chrdev(CPUID_MAJOR, 0, NR_CPUS, "cpu/cpuid");
 out:
 	return err;
 }
--- a/arch/x86/kernel/msr.c
+++ b/arch/x86/kernel/msr.c
@@ -251,7 +251,7 @@ static int __init msr_init(void)
 	int i, err = 0;
 	i = 0;
 
-	if (register_chrdev(MSR_MAJOR, "cpu/msr", &msr_fops)) {
+	if (__register_chrdev(MSR_MAJOR, 0, NR_CPUS, "cpu/msr", &msr_fops)) {
 		printk(KERN_ERR "msr: unable to get major %d for msr\n",
 		       MSR_MAJOR);
 		err = -EBUSY;
@@ -279,7 +279,7 @@ out_class:
 		msr_device_destroy(i);
 	class_destroy(msr_class);
 out_chrdev:
-	unregister_chrdev(MSR_MAJOR, "cpu/msr");
+	__unregister_chrdev(MSR_MAJOR, 0, NR_CPUS, "cpu/msr");
 out:
 	return err;
 }

[02/29] V4L/DVB (13900): gspca - sunplus: Fix bridge exchanges.

[Greg KH]

2.6.32-stable review patch.  If anyone has any objections, please let us know.

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

From: Jean-Francois Moine <moinejf@free.fr>

commit 07d1c69b2dcfdd1b21e36af0ff8b9506234908ee upstream.

A previous code optimization inverted bridge registers and values,
doing a regression in kernel  2.6.32.

Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/media/video/gspca/sunplus.c |   26 +++++++++++++-------------
 1 file changed, 13 insertions(+), 13 deletions(-)

--- a/drivers/media/video/gspca/sunplus.c
+++ b/drivers/media/video/gspca/sunplus.c
@@ -705,7 +705,7 @@ static void spca504B_SetSizeType(struct 
 		rc = spca504B_PollingDataReady(gspca_dev);
 
 		/* Init the cam width height with some values get on init ? */
-		reg_w_riv(dev, 0x31, 0, 0x04);
+		reg_w_riv(dev, 0x31, 0x04, 0);
 		spca504B_WaitCmdStatus(gspca_dev);
 		rc = spca504B_PollingDataReady(gspca_dev);
 		break;
@@ -807,14 +807,14 @@ static void init_ctl_reg(struct gspca_de
 	default:
 /*	case BRIDGE_SPCA533: */
 /*	case BRIDGE_SPCA504B: */
-		reg_w_riv(dev, 0, 0x00, 0x21ad);	/* hue */
-		reg_w_riv(dev, 0, 0x01, 0x21ac);	/* sat/hue */
-		reg_w_riv(dev, 0, 0x00, 0x21a3);	/* gamma */
+		reg_w_riv(dev, 0, 0x21ad, 0x00);	/* hue */
+		reg_w_riv(dev, 0, 0x21ac, 0x01);	/* sat/hue */
+		reg_w_riv(dev, 0, 0x21a3, 0x00);	/* gamma */
 		break;
 	case BRIDGE_SPCA536:
-		reg_w_riv(dev, 0, 0x40, 0x20f5);
-		reg_w_riv(dev, 0, 0x01, 0x20f4);
-		reg_w_riv(dev, 0, 0x00, 0x2089);
+		reg_w_riv(dev, 0, 0x20f5, 0x40);
+		reg_w_riv(dev, 0, 0x20f4, 0x01);
+		reg_w_riv(dev, 0, 0x2089, 0x00);
 		break;
 	}
 	if (pollreg)
@@ -888,11 +888,11 @@ static int sd_init(struct gspca_dev *gsp
 	switch (sd->bridge) {
 	case BRIDGE_SPCA504B:
 		reg_w_riv(dev, 0x1d, 0x00, 0);
-		reg_w_riv(dev, 0, 0x01, 0x2306);
-		reg_w_riv(dev, 0, 0x00, 0x0d04);
-		reg_w_riv(dev, 0, 0x00, 0x2000);
-		reg_w_riv(dev, 0, 0x13, 0x2301);
-		reg_w_riv(dev, 0, 0x00, 0x2306);
+		reg_w_riv(dev, 0, 0x2306, 0x01);
+		reg_w_riv(dev, 0, 0x0d04, 0x00);
+		reg_w_riv(dev, 0, 0x2000, 0x00);
+		reg_w_riv(dev, 0, 0x2301, 0x13);
+		reg_w_riv(dev, 0, 0x2306, 0x00);
 		/* fall thru */
 	case BRIDGE_SPCA533:
 		spca504B_PollingDataReady(gspca_dev);
@@ -1011,7 +1011,7 @@ static int sd_start(struct gspca_dev *gs
 			spca504B_WaitCmdStatus(gspca_dev);
 			break;
 		default:
-			reg_w_riv(dev, 0x31, 0, 0x04);
+			reg_w_riv(dev, 0x31, 0x04, 0);
 			spca504B_WaitCmdStatus(gspca_dev);
 			spca504B_PollingDataReady(gspca_dev);
 			break;

[03/29] Staging: asus_oled: fix oops in 2.6.32.2

[Greg KH]

2.6.32-stable review patch.  If anyone has any objections, please let us know.

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

From: Eugeni Dodonov <eugeni@mandriva.com>

commit 20633bf0141c5e93e3396770d5eb7d200ee4068a upstream.

After updating to 2.6.32 kernel, I started experiencing Oopses caused by
the asus_oled module. After quick investigation, I wrapped this simple
patch which fixes an Oops in by asus_oled module on 2.6.32.2 kernel,
caused by incorrect usage of strict_strtoul function call within
set_enabled and set_disabled functions. This can be triggered by simple
running the userspace client for asus_old (e.g., 'asusoled -e' or
'asusoled -d').

Signed-off-by: Eugeni Dodonov <eugeni@mandriva.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/staging/asus_oled/asus_oled.c |   12 ++++++++----
 1 file changed, 8 insertions(+), 4 deletions(-)

--- a/drivers/staging/asus_oled/asus_oled.c
+++ b/drivers/staging/asus_oled/asus_oled.c
@@ -194,9 +194,11 @@ static ssize_t set_enabled(struct device
 {
 	struct usb_interface *intf = to_usb_interface(dev);
 	struct asus_oled_dev *odev = usb_get_intfdata(intf);
-	int temp = strict_strtoul(buf, 10, NULL);
+	unsigned long value;
+	if (strict_strtoul(buf, 10, &value))
+		return -EINVAL;
 
-	enable_oled(odev, temp);
+	enable_oled(odev, value);
 
 	return count;
 }
@@ -207,10 +209,12 @@ static ssize_t class_set_enabled(struct 
 {
 	struct asus_oled_dev *odev =
 		(struct asus_oled_dev *) dev_get_drvdata(device);
+	unsigned long value;
 
-	int temp = strict_strtoul(buf, 10, NULL);
+	if (strict_strtoul(buf, 10, &value))
+		return -EINVAL;
 
-	enable_oled(odev, temp);
+	enable_oled(odev, value);
 
 	return count;
 }

[04/29] Staging: hv: fix smp problems in the hyperv core code

[Greg KH]

2.6.32-stable review patch.  If anyone has any objections, please let us know.

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

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

commit 7692fd4d441afac728cb83fdd33349d5ba07406c upstream.

This fixes a number of SMP problems that were in the hyperv core code.

Patch originally written by K. Y. Srinivasan <ksrinivasan@novell.com>
but forward ported to the latest in-kernel code and tweaked slightly by
me.

Novell, Inc. hereby disclaims all copyright in any derivative work
copyright associated with this patch.

Signed-off-by: K. Y. Srinivasan <ksrinivasan@novell.com>
Cc: Hank Janssen <hjanssen@microsoft.com>
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/staging/hv/Hv.c    |   50 ++++++++++++++++++++++-----------------------
 drivers/staging/hv/Hv.h    |    6 ++---
 drivers/staging/hv/Vmbus.c |   12 ++++++----
 3 files changed, 35 insertions(+), 33 deletions(-)

--- a/drivers/staging/hv/Hv.c
+++ b/drivers/staging/hv/Hv.c
@@ -386,7 +386,7 @@ u16 HvSignalEvent(void)
  * retrieve the initialized message and event pages.  Otherwise, we create and
  * initialize the message and event pages.
  */
-int HvSynicInit(u32 irqVector)
+void HvSynicInit(void *irqarg)
 {
 	u64 version;
 	union hv_synic_simp simp;
@@ -394,13 +394,14 @@ int HvSynicInit(u32 irqVector)
 	union hv_synic_sint sharedSint;
 	union hv_synic_scontrol sctrl;
 	u64 guestID;
-	int ret = 0;
+	u32 irqVector = *((u32 *)(irqarg));
+	int cpu = smp_processor_id();
 
 	DPRINT_ENTER(VMBUS);
 
 	if (!gHvContext.HypercallPage) {
 		DPRINT_EXIT(VMBUS);
-		return ret;
+		return;
 	}
 
 	/* Check the version */
@@ -425,27 +426,27 @@ int HvSynicInit(u32 irqVector)
 		 */
 		rdmsrl(HV_X64_MSR_GUEST_OS_ID, guestID);
 		if (guestID == HV_LINUX_GUEST_ID) {
-			gHvContext.synICMessagePage[0] =
+			gHvContext.synICMessagePage[cpu] =
 				phys_to_virt(simp.BaseSimpGpa << PAGE_SHIFT);
-			gHvContext.synICEventPage[0] =
+			gHvContext.synICEventPage[cpu] =
 				phys_to_virt(siefp.BaseSiefpGpa << PAGE_SHIFT);
 		} else {
 			DPRINT_ERR(VMBUS, "unknown guest id!!");
 			goto Cleanup;
 		}
 		DPRINT_DBG(VMBUS, "MAPPED: Simp: %p, Sifep: %p",
-			   gHvContext.synICMessagePage[0],
-			   gHvContext.synICEventPage[0]);
+			   gHvContext.synICMessagePage[cpu],
+			   gHvContext.synICEventPage[cpu]);
 	} else {
-		gHvContext.synICMessagePage[0] = osd_PageAlloc(1);
-		if (gHvContext.synICMessagePage[0] == NULL) {
+		gHvContext.synICMessagePage[cpu] = (void *)get_zeroed_page(GFP_ATOMIC);
+		if (gHvContext.synICMessagePage[cpu] == NULL) {
 			DPRINT_ERR(VMBUS,
 				   "unable to allocate SYNIC message page!!");
 			goto Cleanup;
 		}
 
-		gHvContext.synICEventPage[0] = osd_PageAlloc(1);
-		if (gHvContext.synICEventPage[0] == NULL) {
+		gHvContext.synICEventPage[cpu] = (void *)get_zeroed_page(GFP_ATOMIC);
+		if (gHvContext.synICEventPage[cpu] == NULL) {
 			DPRINT_ERR(VMBUS,
 				   "unable to allocate SYNIC event page!!");
 			goto Cleanup;
@@ -454,7 +455,7 @@ int HvSynicInit(u32 irqVector)
 		/* Setup the Synic's message page */
 		rdmsrl(HV_X64_MSR_SIMP, simp.AsUINT64);
 		simp.SimpEnabled = 1;
-		simp.BaseSimpGpa = virt_to_phys(gHvContext.synICMessagePage[0])
+		simp.BaseSimpGpa = virt_to_phys(gHvContext.synICMessagePage[cpu])
 					>> PAGE_SHIFT;
 
 		DPRINT_DBG(VMBUS, "HV_X64_MSR_SIMP msr set to: %llx",
@@ -465,7 +466,7 @@ int HvSynicInit(u32 irqVector)
 		/* Setup the Synic's event page */
 		rdmsrl(HV_X64_MSR_SIEFP, siefp.AsUINT64);
 		siefp.SiefpEnabled = 1;
-		siefp.BaseSiefpGpa = virt_to_phys(gHvContext.synICEventPage[0])
+		siefp.BaseSiefpGpa = virt_to_phys(gHvContext.synICEventPage[cpu])
 					>> PAGE_SHIFT;
 
 		DPRINT_DBG(VMBUS, "HV_X64_MSR_SIEFP msr set to: %llx",
@@ -501,32 +502,30 @@ int HvSynicInit(u32 irqVector)
 
 	DPRINT_EXIT(VMBUS);
 
-	return ret;
+	return;
 
 Cleanup:
-	ret = -1;
-
 	if (gHvContext.GuestId == HV_LINUX_GUEST_ID) {
-		if (gHvContext.synICEventPage[0])
-			osd_PageFree(gHvContext.synICEventPage[0], 1);
+		if (gHvContext.synICEventPage[cpu])
+			osd_PageFree(gHvContext.synICEventPage[cpu], 1);
 
-		if (gHvContext.synICMessagePage[0])
-			osd_PageFree(gHvContext.synICMessagePage[0], 1);
+		if (gHvContext.synICMessagePage[cpu])
+			osd_PageFree(gHvContext.synICMessagePage[cpu], 1);
 	}
 
 	DPRINT_EXIT(VMBUS);
-
-	return ret;
+	return;
 }
 
 /**
  * HvSynicCleanup - Cleanup routine for HvSynicInit().
  */
-void HvSynicCleanup(void)
+void HvSynicCleanup(void *arg)
 {
 	union hv_synic_sint sharedSint;
 	union hv_synic_simp simp;
 	union hv_synic_siefp siefp;
+	int cpu = smp_processor_id();
 
 	DPRINT_ENTER(VMBUS);
 
@@ -539,6 +538,7 @@ void HvSynicCleanup(void)
 
 	sharedSint.Masked = 1;
 
+	/* Need to correctly cleanup in the case of SMP!!! */
 	/* Disable the interrupt */
 	wrmsrl(HV_X64_MSR_SINT0 + VMBUS_MESSAGE_SINT, sharedSint.AsUINT64);
 
@@ -560,8 +560,8 @@ void HvSynicCleanup(void)
 
 		wrmsrl(HV_X64_MSR_SIEFP, siefp.AsUINT64);
 
-		osd_PageFree(gHvContext.synICMessagePage[0], 1);
-		osd_PageFree(gHvContext.synICEventPage[0], 1);
+		osd_PageFree(gHvContext.synICMessagePage[cpu], 1);
+		osd_PageFree(gHvContext.synICEventPage[cpu], 1);
 	}
 
 	DPRINT_EXIT(VMBUS);
--- a/drivers/staging/hv/Hv.h
+++ b/drivers/staging/hv/Hv.h
@@ -93,7 +93,7 @@ static const struct hv_guid VMBUS_SERVIC
 	},
 };
 
-#define MAX_NUM_CPUS	1
+#define MAX_NUM_CPUS	32
 
 
 struct hv_input_signal_event_buffer {
@@ -137,8 +137,8 @@ extern u16 HvPostMessage(union hv_connec
 
 extern u16 HvSignalEvent(void);
 
-extern int HvSynicInit(u32 irqVector);
+extern void HvSynicInit(void *irqarg);
 
-extern void HvSynicCleanup(void);
+extern void HvSynicCleanup(void *arg);
 
 #endif /* __HV_H__ */
--- a/drivers/staging/hv/Vmbus.c
+++ b/drivers/staging/hv/Vmbus.c
@@ -129,7 +129,7 @@ static int VmbusOnDeviceAdd(struct hv_de
 
 	/* strcpy(dev->name, "vmbus"); */
 	/* SynIC setup... */
-	ret = HvSynicInit(*irqvector);
+	on_each_cpu(HvSynicInit, (void *)irqvector, 1);
 
 	/* Connect to VMBus in the root partition */
 	ret = VmbusConnect();
@@ -150,7 +150,7 @@ static int VmbusOnDeviceRemove(struct hv
 	DPRINT_ENTER(VMBUS);
 	VmbusChannelReleaseUnattachedChannels();
 	VmbusDisconnect();
-	HvSynicCleanup();
+	on_each_cpu(HvSynicCleanup, NULL, 1);
 	DPRINT_EXIT(VMBUS);
 
 	return ret;
@@ -173,7 +173,8 @@ static void VmbusOnCleanup(struct hv_dri
  */
 static void VmbusOnMsgDPC(struct hv_driver *drv)
 {
-	void *page_addr = gHvContext.synICMessagePage[0];
+	int cpu = smp_processor_id();
+	void *page_addr = gHvContext.synICMessagePage[cpu];
 	struct hv_message *msg = (struct hv_message *)page_addr +
 				  VMBUS_MESSAGE_SINT;
 	struct hv_message *copied;
@@ -230,11 +231,12 @@ static void VmbusOnEventDPC(struct hv_dr
 static int VmbusOnISR(struct hv_driver *drv)
 {
 	int ret = 0;
+	int cpu = smp_processor_id();
 	void *page_addr;
 	struct hv_message *msg;
 	union hv_synic_event_flags *event;
 
-	page_addr = gHvContext.synICMessagePage[0];
+	page_addr = gHvContext.synICMessagePage[cpu];
 	msg = (struct hv_message *)page_addr + VMBUS_MESSAGE_SINT;
 
 	DPRINT_ENTER(VMBUS);
@@ -248,7 +250,7 @@ static int VmbusOnISR(struct hv_driver *
 	}
 
 	/* TODO: Check if there are events to be process */
-	page_addr = gHvContext.synICEventPage[0];
+	page_addr = gHvContext.synICEventPage[cpu];
 	event = (union hv_synic_event_flags *)page_addr + VMBUS_MESSAGE_SINT;
 
 	/* Since we are a child, we only need to check bit 0 */

[05/29] tty: fix race in tty_fasync

[Greg KH]

2.6.32-stable review patch.  If anyone has any objections, please let us know.

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

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

commit 703625118069f9f8960d356676662d3db5a9d116 upstream.

We need to keep the lock held over the call to __f_setown() to
prevent a PID race.

Thanks to Al Viro for pointing out the problem, and to Travis for
making us look here in the first place.

Cc: Eric W. Biederman <ebiederm@xmission.com>
Cc: Al Viro <viro@ZenIV.linux.org.uk>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Tavis Ormandy <taviso@google.com>
Cc: Jeff Dike <jdike@addtoit.com>
Cc: Julien Tinnes <jln@google.com>
Cc: Matt Mackall <mpm@selenic.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

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

--- a/drivers/char/tty_io.c
+++ b/drivers/char/tty_io.c
@@ -1930,8 +1930,8 @@ static int tty_fasync(int fd, struct fil
 			pid = task_pid(current);
 			type = PIDTYPE_PID;
 		}
-		spin_unlock_irqrestore(&tty->ctrl_lock, flags);
 		retval = __f_setown(filp, pid, type, 0);
+		spin_unlock_irqrestore(&tty->ctrl_lock, flags);
 		if (retval)
 			goto out;
 	} else {

[06/29] ecryptfs: use after free

[Greg KH]

2.6.32-stable review patch.  If anyone has any objections, please let us know.

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

From: Dan Carpenter <error27@gmail.com>

commit ece550f51ba175c14ec3ec047815927d7386ea1f upstream.

The "full_alg_name" variable is used on a couple error paths, so we
shouldn't free it until the end.

Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Tyler Hicks <tyhicks@linux.vnet.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 fs/ecryptfs/crypto.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/fs/ecryptfs/crypto.c
+++ b/fs/ecryptfs/crypto.c
@@ -1748,7 +1748,7 @@ ecryptfs_process_key_cipher(struct crypt
 			    char *cipher_name, size_t *key_size)
 {
 	char dummy_key[ECRYPTFS_MAX_KEY_BYTES];
-	char *full_alg_name;
+	char *full_alg_name = NULL;
 	int rc;
 
 	*key_tfm = NULL;
@@ -1763,7 +1763,6 @@ ecryptfs_process_key_cipher(struct crypt
 	if (rc)
 		goto out;
 	*key_tfm = crypto_alloc_blkcipher(full_alg_name, 0, CRYPTO_ALG_ASYNC);
-	kfree(full_alg_name);
 	if (IS_ERR(*key_tfm)) {
 		rc = PTR_ERR(*key_tfm);
 		printk(KERN_ERR "Unable to allocate crypto cipher with name "
@@ -1786,6 +1785,7 @@ ecryptfs_process_key_cipher(struct crypt
 		goto out;
 	}
 out:
+	kfree(full_alg_name);
 	return rc;
 }
 

[07/29] ecryptfs: initialize private persistent file before dereferencing pointer

[Greg KH]

2.6.32-stable review patch.  If anyone has any objections, please let us know.

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

From: Erez Zadok <ezk@cs.sunysb.edu>

commit e27759d7a333d1f25d628c4f7caf845c51be51c2 upstream.

Ecryptfs_open dereferences a pointer to the private lower file (the one
stored in the ecryptfs inode), without checking if the pointer is NULL.
Right afterward, it initializes that pointer if it is NULL.  Swap order of
statements to first initialize.  Bug discovered by Duckjin Kang.

Signed-off-by: Duckjin Kang <fromdj2k@gmail.com>
Signed-off-by: Erez Zadok <ezk@cs.sunysb.edu>
Cc: Dustin Kirkland <kirkland@canonical.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Tyler Hicks <tyhicks@linux.vnet.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 fs/ecryptfs/file.c |   14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

--- a/fs/ecryptfs/file.c
+++ b/fs/ecryptfs/file.c
@@ -191,13 +191,6 @@ static int ecryptfs_open(struct inode *i
 				      | ECRYPTFS_ENCRYPTED);
 	}
 	mutex_unlock(&crypt_stat->cs_mutex);
-	if ((ecryptfs_inode_to_private(inode)->lower_file->f_flags & O_RDONLY)
-	    && !(file->f_flags & O_RDONLY)) {
-		rc = -EPERM;
-		printk(KERN_WARNING "%s: Lower persistent file is RO; eCryptfs "
-		       "file must hence be opened RO\n", __func__);
-		goto out;
-	}
 	if (!ecryptfs_inode_to_private(inode)->lower_file) {
 		rc = ecryptfs_init_persistent_file(ecryptfs_dentry);
 		if (rc) {
@@ -208,6 +201,13 @@ static int ecryptfs_open(struct inode *i
 			goto out;
 		}
 	}
+	if ((ecryptfs_inode_to_private(inode)->lower_file->f_flags & O_RDONLY)
+	    && !(file->f_flags & O_RDONLY)) {
+		rc = -EPERM;
+		printk(KERN_WARNING "%s: Lower persistent file is RO; eCryptfs "
+		       "file must hence be opened RO\n", __func__);
+		goto out;
+	}
 	ecryptfs_set_file_lower(
 		file, ecryptfs_inode_to_private(inode)->lower_file);
 	if (S_ISDIR(ecryptfs_dentry->d_inode->i_mode)) {

[08/29] nozomi: quick fix for the close/close bug

[Greg KH]

2.6.32-stable review patch.  If anyone has any objections, please let us know.

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

From: Alan Cox <alan@linux.intel.com>

commit eeec32a731631a9bad9abb21c626b9f2840bee0d upstream.

Nozomi goes wrong if you get the sequence

	open
	open
	close

	[stuff]
	close

which turns out to occur on some ppp type setups.

This is a quick patch up for the problem. It's not really fixing Nozomi
which completely fails to implement tty open/close semantics and all the
other needed stuff. Doing it right is a rather more invasive patch set and
not one that will backport.

Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

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

--- a/drivers/char/nozomi.c
+++ b/drivers/char/nozomi.c
@@ -1629,10 +1629,10 @@ static void ntty_close(struct tty_struct
 
 	dc->open_ttys--;
 	port->count--;
-	tty_port_tty_set(port, NULL);
 
 	if (port->count == 0) {
 		DBG1("close: %d", nport->token_dl);
+		tty_port_tty_set(port, NULL);
 		spin_lock_irqsave(&dc->spin_mutex, flags);
 		dc->last_ier &= ~(nport->token_dl);
 		writew(dc->last_ier, dc->reg_ier);

[09/29] serial: 8250_pnp: use wildcard for serial Wacom tablets

[Greg KH]

2.6.32-stable review patch.  If anyone has any objections, please let us know.

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

From: Matthew Garrett <mjg@redhat.com>

commit 6d34855d9aa281f72c533ecb827405139d1b0fe9 upstream.

Wacom claims that the WACF namespace will always be devoted to serial
Wacom tablets.  Remove the existing entries and add a wildcard to avoid
having to update the kernel every time they add a new device.

Signed-off-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Tested-by: Ping Cheng <pingc@wacom.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/serial/8250_pnp.c |   10 +---------
 1 file changed, 1 insertion(+), 9 deletions(-)

--- a/drivers/serial/8250_pnp.c
+++ b/drivers/serial/8250_pnp.c
@@ -328,15 +328,7 @@ static const struct pnp_device_id pnp_de
 	/* U.S. Robotics 56K Voice INT PnP*/
 	{	"USR9190",		0	},
 	/* Wacom tablets */
-	{	"WACF004",		0	},
-	{	"WACF005",		0	},
-	{       "WACF006",              0       },
-	{       "WACF007",              0       },
-	{       "WACF008",              0       },
-	{       "WACF009",              0       },
-	{       "WACF00A",              0       },
-	{       "WACF00B",              0       },
-	{       "WACF00C",              0       },
+	{	"WACFXXX",		0	},
 	/* Compaq touchscreen */
 	{       "FPI2002",              0 },
 	/* Fujitsu Stylistic touchscreens */

[10/29] usb: serial: fix memory leak in generic driver

[Greg KH]

2.6.32-stable review patch.  If anyone has any objections, please let us know.

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

From: Johan Hovold <jhovold@gmail.com>

commit 2591530204a76fecc843529ade56afe865dd2657 upstream.

Fix a regression introduced by commit
715b1dc01fe44537e8fce9566e4bb48d6821d84b ("USB: usb_debug,
usb_generic_serial: implement multi urb write").

URB transfer buffer was never freed when using multi-urb writes.
Currently the only driver enabling multi-urb writes is usb_debug.

Signed-off-by: Johan Hovold <jhovold@gmail.com>
Cc: Greg KH <greg@kroah.com>
Acked-by: Jason Wessel <jason.wessel@windriver.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

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

--- a/drivers/usb/serial/generic.c
+++ b/drivers/usb/serial/generic.c
@@ -489,6 +489,8 @@ void usb_serial_generic_write_bulk_callb
 	dbg("%s - port %d", __func__, port->number);
 
 	if (port->serial->type->max_in_flight_urbs) {
+		kfree(urb->transfer_buffer);
+
 		spin_lock_irqsave(&port->lock, flags);
 		--port->urbs_in_flight;
 		port->tx_bytes_flight -= urb->transfer_buffer_length;

[11/29] USB: fix bitmask merge error

[Greg KH]

2.6.32-stable review patch.  If anyone has any objections, please let us know.

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

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

commit a91b593edd4b3e8aa91f671b763b27b8119eb49d upstream.

This patch adds a mask bit which was mistakenly omitted from the
as1311 patch (usb-storage: add BAD_SENSE flag).

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/usb/storage/usb.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/usb/storage/usb.c
+++ b/drivers/usb/storage/usb.c
@@ -430,7 +430,8 @@ static void adjust_quirks(struct us_data
 	u16 vid = le16_to_cpu(us->pusb_dev->descriptor.idVendor);
 	u16 pid = le16_to_cpu(us->pusb_dev->descriptor.idProduct);
 	unsigned f = 0;
-	unsigned int mask = (US_FL_SANE_SENSE | US_FL_FIX_CAPACITY |
+	unsigned int mask = (US_FL_SANE_SENSE | US_FL_BAD_SENSE |
+			US_FL_FIX_CAPACITY |
 			US_FL_CAPACITY_HEURISTICS | US_FL_IGNORE_DEVICE |
 			US_FL_NOT_LOCKABLE | US_FL_MAX_SECTORS_64 |
 			US_FL_CAPACITY_OK | US_FL_IGNORE_RESIDUE |

[12/29] USB: Dont use GFP_KERNEL while we cannot reset a storage device

[Greg KH]

2.6.32-stable review patch.  If anyone has any objections, please let us know.

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

From: Oliver Neukum <oliver@neukum.org>

commit acbe2febe71abb2360b008e9ab3ee5c44169f78c upstream.

Memory allocations with GFP_KERNEL can cause IO to a storage
device which can fail resulting in a need to reset the device.
Therefore GFP_KERNEL cannot be safely used between usb_lock_device()
and usb_unlock_device(). Replace by GFP_NOIO.

Signed-off-by: Oliver Neukum <oliver@neukum.org>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/usb/core/devices.c |    2 +-
 drivers/usb/core/message.c |    8 ++++----
 2 files changed, 5 insertions(+), 5 deletions(-)

--- a/drivers/usb/core/devices.c
+++ b/drivers/usb/core/devices.c
@@ -494,7 +494,7 @@ static ssize_t usb_device_dump(char __us
 		return 0;
 	/* allocate 2^1 pages = 8K (on i386);
 	 * should be more than enough for one device */
-	pages_start = (char *)__get_free_pages(GFP_KERNEL, 1);
+	pages_start = (char *)__get_free_pages(GFP_NOIO, 1);
 	if (!pages_start)
 		return -ENOMEM;
 
--- a/drivers/usb/core/message.c
+++ b/drivers/usb/core/message.c
@@ -911,11 +911,11 @@ char *usb_cache_string(struct usb_device
 	if (index <= 0)
 		return NULL;
 
-	buf = kmalloc(MAX_USB_STRING_SIZE, GFP_KERNEL);
+	buf = kmalloc(MAX_USB_STRING_SIZE, GFP_NOIO);
 	if (buf) {
 		len = usb_string(udev, index, buf, MAX_USB_STRING_SIZE);
 		if (len > 0) {
-			smallbuf = kmalloc(++len, GFP_KERNEL);
+			smallbuf = kmalloc(++len, GFP_NOIO);
 			if (!smallbuf)
 				return buf;
 			memcpy(smallbuf, buf, len);
@@ -1682,7 +1682,7 @@ int usb_set_configuration(struct usb_dev
 	if (cp) {
 		nintf = cp->desc.bNumInterfaces;
 		new_interfaces = kmalloc(nintf * sizeof(*new_interfaces),
-				GFP_KERNEL);
+				GFP_NOIO);
 		if (!new_interfaces) {
 			dev_err(&dev->dev, "Out of memory\n");
 			return -ENOMEM;
@@ -1691,7 +1691,7 @@ int usb_set_configuration(struct usb_dev
 		for (; n < nintf; ++n) {
 			new_interfaces[n] = kzalloc(
 					sizeof(struct usb_interface),
-					GFP_KERNEL);
+					GFP_NOIO);
 			if (!new_interfaces[n]) {
 				dev_err(&dev->dev, "Out of memory\n");
 				ret = -ENOMEM;

[13/29] USB: EHCI: fix handling of unusual interrupt intervals

[Greg KH]

2.6.32-stable review patch.  If anyone has any objections, please let us know.

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

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

commit 1b9a38bfa6e664ff02511314f5586d711c83cc91 upstream.

This patch (as1320) fixes two problems related to interrupt-URB
scheduling in ehci-hcd.

	URBs with an interval of 2 or 4 microframes aren't handled.
	For the time being, the patch reduces to interval to 1 uframe.

	URBs are constrained to have an interval no larger than 1024
	frames by usb_submit_urb().  But some EHCI controllers allow
	use of a schedule as short as 256 frames; for these
	controllers we may have to decrease the interval to the
	actual schedule length.

The second problem isn't very significant since few devices expose
interrupt endpoints with an interval larger than 256 frames.  But the
first problem is critical; it will prevent the kernel from working
with devices having interrupt intervals of 2 or 4 uframes.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Glynn Farrow <farrowg@sg.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/usb/host/ehci-q.c |   11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

--- a/drivers/usb/host/ehci-q.c
+++ b/drivers/usb/host/ehci-q.c
@@ -827,9 +827,10 @@ qh_make (
 				 * But interval 1 scheduling is simpler, and
 				 * includes high bandwidth.
 				 */
-				dbg ("intr period %d uframes, NYET!",
-						urb->interval);
-				goto done;
+				urb->interval = 1;
+			} else if (qh->period > ehci->periodic_size) {
+				qh->period = ehci->periodic_size;
+				urb->interval = qh->period << 3;
 			}
 		} else {
 			int		think_time;
@@ -852,6 +853,10 @@ qh_make (
 					usb_calc_bus_time (urb->dev->speed,
 					is_input, 0, max_packet (maxp)));
 			qh->period = urb->interval;
+			if (qh->period > ehci->periodic_size) {
+				qh->period = ehci->periodic_size;
+				urb->interval = qh->period;
+			}
 		}
 	}
 

[14/29] USB: EHCI & UHCI: fix race between root-hub suspend and port resume

[Greg KH]

2.6.32-stable review patch.  If anyone has any objections, please let us know.

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

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

commit cec3a53c7fe794237b582e8e77fc0e48465e65ee upstream.

This patch (as1321) fixes a problem with EHCI and UHCI root-hub
suspends: If the suspend occurs while a port is trying to resume, the
resume doesn't finish and simply gets lost.  When remote wakeup is
enabled, this is undesirable behavior.

The patch checks first to see if any port resumes are in progress, and
if they are then it fails the root-hub suspend with -EBUSY.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/usb/host/ehci-hub.c |   20 +++++++++++++++++++-
 drivers/usb/host/uhci-hcd.c |   15 ++++++++++++++-
 2 files changed, 33 insertions(+), 2 deletions(-)

--- a/drivers/usb/host/ehci-hub.c
+++ b/drivers/usb/host/ehci-hub.c
@@ -120,9 +120,26 @@ static int ehci_bus_suspend (struct usb_
 	del_timer_sync(&ehci->watchdog);
 	del_timer_sync(&ehci->iaa_watchdog);
 
-	port = HCS_N_PORTS (ehci->hcs_params);
 	spin_lock_irq (&ehci->lock);
 
+	/* Once the controller is stopped, port resumes that are already
+	 * in progress won't complete.  Hence if remote wakeup is enabled
+	 * for the root hub and any ports are in the middle of a resume or
+	 * remote wakeup, we must fail the suspend.
+	 */
+	if (hcd->self.root_hub->do_remote_wakeup) {
+		port = HCS_N_PORTS(ehci->hcs_params);
+		while (port--) {
+			if (ehci->reset_done[port] != 0) {
+				spin_unlock_irq(&ehci->lock);
+				ehci_dbg(ehci, "suspend failed because "
+						"port %d is resuming\n",
+						port + 1);
+				return -EBUSY;
+			}
+		}
+	}
+
 	/* stop schedules, clean any completed work */
 	if (HC_IS_RUNNING(hcd->state)) {
 		ehci_quiesce (ehci);
@@ -138,6 +155,7 @@ static int ehci_bus_suspend (struct usb_
 	 */
 	ehci->bus_suspended = 0;
 	ehci->owned_ports = 0;
+	port = HCS_N_PORTS(ehci->hcs_params);
 	while (port--) {
 		u32 __iomem	*reg = &ehci->regs->port_status [port];
 		u32		t1 = ehci_readl(ehci, reg) & ~PORT_RWC_BITS;
--- a/drivers/usb/host/uhci-hcd.c
+++ b/drivers/usb/host/uhci-hcd.c
@@ -749,7 +749,20 @@ static int uhci_rh_suspend(struct usb_hc
 	spin_lock_irq(&uhci->lock);
 	if (!test_bit(HCD_FLAG_HW_ACCESSIBLE, &hcd->flags))
 		rc = -ESHUTDOWN;
-	else if (!uhci->dead)
+	else if (uhci->dead)
+		;		/* Dead controllers tell no tales */
+
+	/* Once the controller is stopped, port resumes that are already
+	 * in progress won't complete.  Hence if remote wakeup is enabled
+	 * for the root hub and any ports are in the middle of a resume or
+	 * remote wakeup, we must fail the suspend.
+	 */
+	else if (hcd->self.root_hub->do_remote_wakeup &&
+			uhci->resuming_ports) {
+		dev_dbg(uhci_dev(uhci), "suspend failed because a port "
+				"is resuming\n");
+		rc = -EBUSY;
+	} else
 		suspend_rh(uhci, UHCI_RH_SUSPENDED);
 	spin_unlock_irq(&uhci->lock);
 	return rc;

[15/29] USB: add missing delay during remote wakeup

[Greg KH]

2.6.32-stable review patch.  If anyone has any objections, please let us know.

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

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

commit 49d0f078f494b9d81e820a13dd8093a9bfb0b6b1 upstream.

This patch (as1330) fixes a bug in khbud's handling of remote
wakeups.  When a device sends a remote-wakeup request, the parent hub
(or the host controller driver, for directly attached devices) begins
the resume sequence and notifies khubd when the sequence finishes.  At
this point the port's SUSPEND feature is automatically turned off.

However the device needs an additional 10-ms resume-recovery time
(TRSMRCY in the USB spec).  Khubd does not wait for this delay if the
SUSPEND feature is off, and as a result some devices fail to behave
properly following a remote wakeup.  This patch adds the missing
delay to the remote-wakeup path.

It also extends the resume-signalling delay used by ehci-hcd and
uhci-hcd from 20 ms (the value in the spec) to 25 ms (the value we use
for non-remote-wakeup resumes).  The extra time appears to help some
devices.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Cc: Rickard Bellini <rickard.bellini@ericsson.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/usb/core/hub.c      |    3 +++
 drivers/usb/host/ehci-hcd.c |    5 +++--
 drivers/usb/host/uhci-hub.c |    2 +-
 3 files changed, 7 insertions(+), 3 deletions(-)

--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -3286,6 +3286,9 @@ static void hub_events(void)
 					USB_PORT_FEAT_C_SUSPEND);
 				udev = hdev->children[i-1];
 				if (udev) {
+					/* TRSMRCY = 10 msec */
+					msleep(10);
+
 					usb_lock_device(udev);
 					ret = remote_wakeup(hdev->
 							children[i-1]);
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -785,9 +785,10 @@ static irqreturn_t ehci_irq (struct usb_
 
 			/* start 20 msec resume signaling from this port,
 			 * and make khubd collect PORT_STAT_C_SUSPEND to
-			 * stop that signaling.
+			 * stop that signaling.  Use 5 ms extra for safety,
+			 * like usb_port_resume() does.
 			 */
-			ehci->reset_done [i] = jiffies + msecs_to_jiffies (20);
+			ehci->reset_done[i] = jiffies + msecs_to_jiffies(25);
 			ehci_dbg (ehci, "port %d remote wakeup\n", i + 1);
 			mod_timer(&hcd->rh_timer, ehci->reset_done[i]);
 		}
--- a/drivers/usb/host/uhci-hub.c
+++ b/drivers/usb/host/uhci-hub.c
@@ -167,7 +167,7 @@ static void uhci_check_ports(struct uhci
 				/* Port received a wakeup request */
 				set_bit(port, &uhci->resuming_ports);
 				uhci->ports_timeout = jiffies +
-						msecs_to_jiffies(20);
+						msecs_to_jiffies(25);
 
 				/* Make sure we see the port again
 				 * after the resuming period is over. */

[16/29] USB: add speed values for USB 3.0 and wireless controllers

[Greg KH]

2.6.32-stable review patch.  If anyone has any objections, please let us know.

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

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

commit b132b04e193908a94d95065d0628f8fb0159cc55 upstream.

These controllers say "unknown" for their speed in sysfs, which
obviously isn't correct.

Reported-by: Kurt Garloff <garloff@novell.com>
Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: David Vrabel <david.vrabel@csr.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/usb/core/sysfs.c |    6 ++++++
 1 file changed, 6 insertions(+)

--- a/drivers/usb/core/sysfs.c
+++ b/drivers/usb/core/sysfs.c
@@ -115,6 +115,12 @@ show_speed(struct device *dev, struct de
 	case USB_SPEED_HIGH:
 		speed = "480";
 		break;
+	case USB_SPEED_VARIABLE:
+		speed = "480";
+		break;
+	case USB_SPEED_SUPER:
+		speed = "5000";
+		break;
 	default:
 		speed = "unknown";
 	}

[17/29] ACPI: EC: Accelerate query execution

[Greg KH]

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

2.6.32-stable review patch.  If anyone has any objections, please let us know.

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

From: Alexey Starikovskiy <astarikovskiy@suse.de>

commit a62e8f1978f49e52f87a711ff6711b323d4b12ff upstream.

Split EC query handling into acknowledge and execution phase.
This allows much smaller pending query lattency and lowers chances
of EC going "wild" and losing events.

Reference: http://bugzilla.kernel.org/show_bug.cgi?id=14858

Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de>
Signed-off-by: Len Brown <len.brown@intel.com>
Cc: François Valenduc <francois.valenduc@tvcablenet.be>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/acpi/ec.c |  122 ++++++++++++++++++++++++++++++++++--------------------
 1 file changed, 77 insertions(+), 45 deletions(-)

--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -201,14 +201,13 @@ unlock:
 	spin_unlock_irqrestore(&ec->curr_lock, flags);
 }
 
-static void acpi_ec_gpe_query(void *ec_cxt);
+static int acpi_ec_sync_query(struct acpi_ec *ec);
 
-static int ec_check_sci(struct acpi_ec *ec, u8 state)
+static int ec_check_sci_sync(struct acpi_ec *ec, u8 state)
 {
 	if (state & ACPI_EC_FLAG_SCI) {
 		if (!test_and_set_bit(EC_FLAGS_QUERY_PENDING, &ec->flags))
-			return acpi_os_execute(OSL_EC_BURST_HANDLER,
-				acpi_ec_gpe_query, ec);
+			return acpi_ec_sync_query(ec);
 	}
 	return 0;
 }
@@ -249,11 +248,6 @@ static int acpi_ec_transaction_unlocked(
 {
 	unsigned long tmp;
 	int ret = 0;
-	pr_debug(PREFIX "transaction start\n");
-	/* disable GPE during transaction if storm is detected */
-	if (test_bit(EC_FLAGS_GPE_STORM, &ec->flags)) {
-		acpi_disable_gpe(NULL, ec->gpe);
-	}
 	if (EC_FLAGS_MSI)
 		udelay(ACPI_EC_MSI_UDELAY);
 	/* start transaction */
@@ -269,16 +263,6 @@ static int acpi_ec_transaction_unlocked(
 	spin_lock_irqsave(&ec->curr_lock, tmp);
 	ec->curr = NULL;
 	spin_unlock_irqrestore(&ec->curr_lock, tmp);
-	if (test_bit(EC_FLAGS_GPE_STORM, &ec->flags)) {
-		/* check if we received SCI during transaction */
-		ec_check_sci(ec, acpi_ec_read_status(ec));
-		/* it is safe to enable GPE outside of transaction */
-		acpi_enable_gpe(NULL, ec->gpe);
-	} else if (t->irq_count > ACPI_EC_STORM_THRESHOLD) {
-		pr_info(PREFIX "GPE storm detected, "
-			"transactions will use polling mode\n");
-		set_bit(EC_FLAGS_GPE_STORM, &ec->flags);
-	}
 	return ret;
 }
 
@@ -321,7 +305,24 @@ static int acpi_ec_transaction(struct ac
 		status = -ETIME;
 		goto end;
 	}
+	pr_debug(PREFIX "transaction start\n");
+	/* disable GPE during transaction if storm is detected */
+	if (test_bit(EC_FLAGS_GPE_STORM, &ec->flags)) {
+		acpi_disable_gpe(NULL, ec->gpe);
+	}
+
 	status = acpi_ec_transaction_unlocked(ec, t);
+
+	/* check if we received SCI during transaction */
+	ec_check_sci_sync(ec, acpi_ec_read_status(ec));
+	if (test_bit(EC_FLAGS_GPE_STORM, &ec->flags)) {
+		/* it is safe to enable GPE outside of transaction */
+		acpi_enable_gpe(NULL, ec->gpe);
+	} else if (t->irq_count > ACPI_EC_STORM_THRESHOLD) {
+		pr_info(PREFIX "GPE storm detected, "
+			"transactions will use polling mode\n");
+		set_bit(EC_FLAGS_GPE_STORM, &ec->flags);
+	}
 end:
 	if (ec->global_lock)
 		acpi_release_global_lock(glk);
@@ -443,7 +444,7 @@ int ec_transaction(u8 command,
 
 EXPORT_SYMBOL(ec_transaction);
 
-static int acpi_ec_query(struct acpi_ec *ec, u8 * data)
+static int acpi_ec_query_unlocked(struct acpi_ec *ec, u8 * data)
 {
 	int result;
 	u8 d;
@@ -452,20 +453,16 @@ static int acpi_ec_query(struct acpi_ec 
 				.wlen = 0, .rlen = 1};
 	if (!ec || !data)
 		return -EINVAL;
-
 	/*
 	 * Query the EC to find out which _Qxx method we need to evaluate.
 	 * Note that successful completion of the query causes the ACPI_EC_SCI
 	 * bit to be cleared (and thus clearing the interrupt source).
 	 */
-
-	result = acpi_ec_transaction(ec, &t);
+	result = acpi_ec_transaction_unlocked(ec, &t);
 	if (result)
 		return result;
-
 	if (!d)
 		return -ENODATA;
-
 	*data = d;
 	return 0;
 }
@@ -509,43 +506,78 @@ void acpi_ec_remove_query_handler(struct
 
 EXPORT_SYMBOL_GPL(acpi_ec_remove_query_handler);
 
-static void acpi_ec_gpe_query(void *ec_cxt)
+static void acpi_ec_run(void *cxt)
 {
-	struct acpi_ec *ec = ec_cxt;
-	u8 value = 0;
-	struct acpi_ec_query_handler *handler, copy;
-
-	if (!ec || acpi_ec_query(ec, &value))
+	struct acpi_ec_query_handler *handler = cxt;
+	if (!handler)
 		return;
-	mutex_lock(&ec->lock);
+	pr_debug(PREFIX "start query execution\n");
+	if (handler->func)
+		handler->func(handler->data);
+	else if (handler->handle)
+		acpi_evaluate_object(handler->handle, NULL, NULL, NULL);
+	pr_debug(PREFIX "stop query execution\n");
+	kfree(handler);
+}
+
+static int acpi_ec_sync_query(struct acpi_ec *ec)
+{
+	u8 value = 0;
+	int status;
+	struct acpi_ec_query_handler *handler, *copy;
+	if ((status = acpi_ec_query_unlocked(ec, &value)))
+		return status;
 	list_for_each_entry(handler, &ec->list, node) {
 		if (value == handler->query_bit) {
 			/* have custom handler for this bit */
-			memcpy(&copy, handler, sizeof(copy));
-			mutex_unlock(&ec->lock);
-			if (copy.func) {
-				copy.func(copy.data);
-			} else if (copy.handle) {
-				acpi_evaluate_object(copy.handle, NULL, NULL, NULL);
-			}
-			return;
+			copy = kmalloc(sizeof(*handler), GFP_KERNEL);
+			if (!copy)
+				return -ENOMEM;
+			memcpy(copy, handler, sizeof(*copy));
+			pr_debug(PREFIX "push query execution (0x%2x) on queue\n", value);
+			return acpi_os_execute(OSL_GPE_HANDLER,
+				acpi_ec_run, copy);
 		}
 	}
+	return 0;
+}
+
+static void acpi_ec_gpe_query(void *ec_cxt)
+{
+	struct acpi_ec *ec = ec_cxt;
+	if (!ec)
+		return;
+	mutex_lock(&ec->lock);
+	acpi_ec_sync_query(ec);
 	mutex_unlock(&ec->lock);
 }
 
+static void acpi_ec_gpe_query(void *ec_cxt);
+
+static int ec_check_sci(struct acpi_ec *ec, u8 state)
+{
+	if (state & ACPI_EC_FLAG_SCI) {
+		if (!test_and_set_bit(EC_FLAGS_QUERY_PENDING, &ec->flags)) {
+			pr_debug(PREFIX "push gpe query to the queue\n");
+			return acpi_os_execute(OSL_NOTIFY_HANDLER,
+				acpi_ec_gpe_query, ec);
+		}
+	}
+	return 0;
+}
+
 static u32 acpi_ec_gpe_handler(void *data)
 {
 	struct acpi_ec *ec = data;
-	u8 status;
 
 	pr_debug(PREFIX "~~~> interrupt\n");
-	status = acpi_ec_read_status(ec);
 
-	advance_transaction(ec, status);
-	if (ec_transaction_done(ec) && (status & ACPI_EC_FLAG_IBF) == 0)
+	advance_transaction(ec, acpi_ec_read_status(ec));
+	if (ec_transaction_done(ec) &&
+	    (acpi_ec_read_status(ec) & ACPI_EC_FLAG_IBF) == 0) {
 		wake_up(&ec->wait);
-	ec_check_sci(ec, status);
+		ec_check_sci(ec, acpi_ec_read_status(ec));
+	}
 	return ACPI_INTERRUPT_HANDLED;
 }
 

[18/29] ACPI: EC: Add wait for irq storm

[Greg KH]

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

2.6.32-stable review patch.  If anyone has any objections, please let us know.

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

From: Alexey Starikovskiy <astarikovskiy@suse.de>

commit 54070101f86ca9a6e9ba243c999d144721ec3db7 upstream.

Merge of poll and irq modes accelerated EC transaction, so
that keyboard starts to suffer again. Add msleep(1) into
transaction path for the storm to allow keyboard controller
to do its job.

Reference: http://bugzilla.kernel.org/show_bug.cgi?id=14747

Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de>
Signed-off-by: Len Brown <len.brown@intel.com>
Cc: François Valenduc <francois.valenduc@tvcablenet.be>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/acpi/ec.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -259,7 +259,6 @@ static int acpi_ec_transaction_unlocked(
 		clear_bit(EC_FLAGS_QUERY_PENDING, &ec->flags);
 	spin_unlock_irqrestore(&ec->curr_lock, tmp);
 	ret = ec_poll(ec);
-	pr_debug(PREFIX "transaction end\n");
 	spin_lock_irqsave(&ec->curr_lock, tmp);
 	ec->curr = NULL;
 	spin_unlock_irqrestore(&ec->curr_lock, tmp);
@@ -316,6 +315,7 @@ static int acpi_ec_transaction(struct ac
 	/* check if we received SCI during transaction */
 	ec_check_sci_sync(ec, acpi_ec_read_status(ec));
 	if (test_bit(EC_FLAGS_GPE_STORM, &ec->flags)) {
+		msleep(1);
 		/* it is safe to enable GPE outside of transaction */
 		acpi_enable_gpe(NULL, ec->gpe);
 	} else if (t->irq_count > ACPI_EC_STORM_THRESHOLD) {
@@ -323,6 +323,7 @@ static int acpi_ec_transaction(struct ac
 			"transactions will use polling mode\n");
 		set_bit(EC_FLAGS_GPE_STORM, &ec->flags);
 	}
+	pr_debug(PREFIX "transaction end\n");
 end:
 	if (ec->global_lock)
 		acpi_release_global_lock(glk);

[19/29] SCSI: enclosure: fix oops while iterating enclosure_status array

[Greg KH]

2.6.32-stable review patch.  If anyone has any objections, please let us know.

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

From: James Bottomley <James.Bottomley@suse.de>

commit cc9b2e9f6603190c009e5d2629ce8e3f99571346 upstream.

Based on patch originally by Jeff Mahoney <jeffm@suse.com>

 enclosure_status is expected to be a NULL terminated array of strings
 but isn't actually NULL terminated. When writing an invalid value to
 /sys/class/enclosure/.../.../status, it goes off the end of the array
 and Oopses.


Fix by making the assumption true and adding NULL at the end.

Reported-by: Artur Wojcik <artur.wojcik@intel.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/misc/enclosure.c  |    1 +
 include/linux/enclosure.h |    2 ++
 2 files changed, 3 insertions(+)

--- a/drivers/misc/enclosure.c
+++ b/drivers/misc/enclosure.c
@@ -391,6 +391,7 @@ static const char *const enclosure_statu
 	[ENCLOSURE_STATUS_NOT_INSTALLED] = "not installed",
 	[ENCLOSURE_STATUS_UNKNOWN] = "unknown",
 	[ENCLOSURE_STATUS_UNAVAILABLE] = "unavailable",
+	[ENCLOSURE_STATUS_MAX] = NULL,
 };
 
 static const char *const enclosure_type [] = {
--- a/include/linux/enclosure.h
+++ b/include/linux/enclosure.h
@@ -42,6 +42,8 @@ enum enclosure_status {
 	ENCLOSURE_STATUS_NOT_INSTALLED,
 	ENCLOSURE_STATUS_UNKNOWN,
 	ENCLOSURE_STATUS_UNAVAILABLE,
+	/* last element for counting purposes */
+	ENCLOSURE_STATUS_MAX
 };
 
 /* SFF-8485 activity light settings */

[20/29] drm/i915: Read the response after issuing DDC bus switch command

[Greg KH]

2.6.32-stable review patch.  If anyone has any objections, please let us know.

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

From: Zhao Yakui <yakui.zhao@intel.com>

commit 6a304caf0bf9c429fc261f260b86cabf5bde2cbb upstream.

For some SDVO cards based on conexant chip, we can't read the EDID if
we don't read the response after issuing SDVO DDC bus switch
command.

>From the SDVO spec once when another I2C transaction is finished after
completing the I2C transaction of issuing the bus switch command, it
will be switched back to the SDVO internal state again. So we can't
initiate a new I2C transaction to read the response after issuing the
DDC bus switch command. Instead we should issue DDC bus switch command
and read the response in the same I2C transaction.

https://bugs.freedesktop.org/show_bug.cgi?id=23842
https://bugs.freedesktop.org/show_bug.cgi?id=24458
https://bugs.freedesktop.org/show_bug.cgi?id=24522
https://bugs.freedesktop.org/show_bug.cgi?id=24282

Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Tested-by: Sebastien Caty <sebastien.caty@mrnf.gouv.qc.ca>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/gpu/drm/i915/intel_sdvo.c |   57 +++++++++++++++++++++++++++++++++++---
 1 file changed, 53 insertions(+), 4 deletions(-)

--- a/drivers/gpu/drm/i915/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/intel_sdvo.c
@@ -472,14 +472,63 @@ static int intel_sdvo_get_pixel_multipli
 }
 
 /**
- * Don't check status code from this as it switches the bus back to the
- * SDVO chips which defeats the purpose of doing a bus switch in the first
- * place.
+ * Try to read the response after issuie the DDC switch command. But it
+ * is noted that we must do the action of reading response and issuing DDC
+ * switch command in one I2C transaction. Otherwise when we try to start
+ * another I2C transaction after issuing the DDC bus switch, it will be
+ * switched to the internal SDVO register.
  */
 static void intel_sdvo_set_control_bus_switch(struct intel_output *intel_output,
 					      u8 target)
 {
-	intel_sdvo_write_cmd(intel_output, SDVO_CMD_SET_CONTROL_BUS_SWITCH, &target, 1);
+	struct intel_sdvo_priv *sdvo_priv = intel_output->dev_priv;
+	u8 out_buf[2], cmd_buf[2], ret_value[2], ret;
+	struct i2c_msg msgs[] = {
+		{
+			.addr = sdvo_priv->slave_addr >> 1,
+			.flags = 0,
+			.len = 2,
+			.buf = out_buf,
+		},
+		/* the following two are to read the response */
+		{
+			.addr = sdvo_priv->slave_addr >> 1,
+			.flags = 0,
+			.len = 1,
+			.buf = cmd_buf,
+		},
+		{
+			.addr = sdvo_priv->slave_addr >> 1,
+			.flags = I2C_M_RD,
+			.len = 1,
+			.buf = ret_value,
+		},
+	};
+
+	intel_sdvo_debug_write(intel_output, SDVO_CMD_SET_CONTROL_BUS_SWITCH,
+					&target, 1);
+	/* write the DDC switch command argument */
+	intel_sdvo_write_byte(intel_output, SDVO_I2C_ARG_0, target);
+
+	out_buf[0] = SDVO_I2C_OPCODE;
+	out_buf[1] = SDVO_CMD_SET_CONTROL_BUS_SWITCH;
+	cmd_buf[0] = SDVO_I2C_CMD_STATUS;
+	cmd_buf[1] = 0;
+	ret_value[0] = 0;
+	ret_value[1] = 0;
+
+	ret = i2c_transfer(intel_output->i2c_bus, msgs, 3);
+	if (ret != 3) {
+		/* failure in I2C transfer */
+		DRM_DEBUG_KMS("I2c transfer returned %d\n", ret);
+		return;
+	}
+	if (ret_value[0] != SDVO_CMD_STATUS_SUCCESS) {
+		DRM_DEBUG_KMS("DDC switch command returns response %d\n",
+					ret_value[0]);
+		return;
+	}
+	return;
 }
 
 static bool intel_sdvo_set_target_input(struct intel_output *intel_output, bool target_0, bool target_1)

[21/29] drm/i915: try another possible DDC bus for the SDVO device with multiple outputs

[Greg KH]

2.6.32-stable review patch.  If anyone has any objections, please let us know.

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

From: Zhao Yakui <yakui.zhao@intel.com>

commit 7c3f0a2726fed78e0e0afe3b6fc3c1f5b298e447 upstream.

There exist multiple DDC buses for the SDVO cards with multiple outputs.
When we can't get the EDID by using the select DDC bus, we can try the other
possible DDC bus to see whether the EDID can be obtained.

https://bugs.freedesktop.org/show_bug.cgi?id=23842

Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Tested-by: Sebastien Caty <sebastien.caty@mrnf.gouv.qc.ca>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/gpu/drm/i915/intel_sdvo.c |   26 ++++++++++++++++++++++++++
 1 file changed, 26 insertions(+)

--- a/drivers/gpu/drm/i915/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/intel_sdvo.c
@@ -1638,6 +1638,32 @@ intel_sdvo_hdmi_sink_detect(struct drm_c
 	edid = drm_get_edid(&intel_output->base,
 			    intel_output->ddc_bus);
 
+	/* This is only applied to SDVO cards with multiple outputs */
+	if (edid == NULL && intel_sdvo_multifunc_encoder(intel_output)) {
+		uint8_t saved_ddc, temp_ddc;
+		saved_ddc = sdvo_priv->ddc_bus;
+		temp_ddc = sdvo_priv->ddc_bus >> 1;
+		/*
+		 * Don't use the 1 as the argument of DDC bus switch to get
+		 * the EDID. It is used for SDVO SPD ROM.
+		 */
+		while(temp_ddc > 1) {
+			sdvo_priv->ddc_bus = temp_ddc;
+			edid = drm_get_edid(&intel_output->base,
+				intel_output->ddc_bus);
+			if (edid) {
+				/*
+				 * When we can get the EDID, maybe it is the
+				 * correct DDC bus. Update it.
+				 */
+				sdvo_priv->ddc_bus = temp_ddc;
+				break;
+			}
+			temp_ddc >>= 1;
+		}
+		if (edid == NULL)
+			sdvo_priv->ddc_bus = saved_ddc;
+	}
 	/* when there is no edid and no monitor is connected with VGA
 	 * port, try to use the CRT ddc to read the EDID for DVI-connector
 	 */

[22/29] block: bdev_stack_limits wrapper

[Greg KH]

2.6.32-stable review patch.  If anyone has any objections, please let us know.

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

From: Martin K. Petersen <martin.petersen@oracle.com>

commit 17be8c245054b9c7786545af3ba3ca4e54cd4ad9 upstream.

DM does not want to know about partition offsets.  Add a partition-aware
wrapper that DM can use when stacking block devices.

Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Acked-by: Mike Snitzer <snitzer@redhat.com>
Reviewed-by: Alasdair G Kergon <agk@redhat.com>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 block/blk-settings.c   |   22 ++++++++++++++++++++++
 include/linux/blkdev.h |    2 ++
 2 files changed, 24 insertions(+)

--- a/block/blk-settings.c
+++ b/block/blk-settings.c
@@ -560,6 +560,28 @@ int blk_stack_limits(struct queue_limits
 EXPORT_SYMBOL(blk_stack_limits);
 
 /**
+ * bdev_stack_limits - adjust queue limits for stacked drivers
+ * @t:	the stacking driver limits (top device)
+ * @bdev:  the component block_device (bottom)
+ * @start:  first data sector within component device
+ *
+ * Description:
+ *    Merges queue limits for a top device and a block_device.  Returns
+ *    0 if alignment didn't change.  Returns -1 if adding the bottom
+ *    device caused misalignment.
+ */
+int bdev_stack_limits(struct queue_limits *t, struct block_device *bdev,
+		      sector_t start)
+{
+	struct request_queue *bq = bdev_get_queue(bdev);
+
+	start += get_start_sect(bdev);
+
+	return blk_stack_limits(t, &bq->limits, start << 9);
+}
+EXPORT_SYMBOL(bdev_stack_limits);
+
+/**
  * disk_stack_limits - adjust queue limits for stacked drivers
  * @disk:  MD/DM gendisk (top)
  * @bdev:  the underlying block device (bottom)
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@ -942,6 +942,8 @@ extern void blk_queue_io_opt(struct requ
 extern void blk_set_default_limits(struct queue_limits *lim);
 extern int blk_stack_limits(struct queue_limits *t, struct queue_limits *b,
 			    sector_t offset);
+extern int bdev_stack_limits(struct queue_limits *t, struct block_device *bdev,
+			    sector_t offset);
 extern void disk_stack_limits(struct gendisk *disk, struct block_device *bdev,
 			      sector_t offset);
 extern void blk_queue_stack_limits(struct request_queue *t, struct request_queue *b);

[23/29] DM: Fix device mapper topology stacking

[Greg KH]

2.6.32-stable review patch.  If anyone has any objections, please let us know.

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

From: Martin K. Petersen <martin.petersen@oracle.com>

commit b27d7f16d3c6c27345d4280a739809c1c2c4c0b5 upstream.

Make DM use bdev_stack_limits() function so that partition offsets get
taken into account when calculating alignment.  Clarify stacking
warnings.

Also remove obsolete clearing of final alignment_offset and misalignment
flag.

Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Cc: Alasdair G. Kergon <agk@redhat.com>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/md/dm-table.c |   20 +++++---------------
 1 file changed, 5 insertions(+), 15 deletions(-)

--- a/drivers/md/dm-table.c
+++ b/drivers/md/dm-table.c
@@ -499,16 +499,15 @@ int dm_set_device_limits(struct dm_targe
 		return 0;
 	}
 
-	if (blk_stack_limits(limits, &q->limits, start << 9) < 0)
-		DMWARN("%s: target device %s is misaligned: "
+	if (bdev_stack_limits(limits, bdev, start) < 0)
+		DMWARN("%s: adding target device %s caused an alignment inconsistency: "
 		       "physical_block_size=%u, logical_block_size=%u, "
 		       "alignment_offset=%u, start=%llu",
 		       dm_device_name(ti->table->md), bdevname(bdev, b),
 		       q->limits.physical_block_size,
 		       q->limits.logical_block_size,
 		       q->limits.alignment_offset,
-		       (unsigned long long) start << 9);
-
+		       (unsigned long long) start << SECTOR_SHIFT);
 
 	/*
 	 * Check if merge fn is supported.
@@ -1025,9 +1024,9 @@ combine_limits:
 		 * for the table.
 		 */
 		if (blk_stack_limits(limits, &ti_limits, 0) < 0)
-			DMWARN("%s: target device "
+			DMWARN("%s: adding target device "
 			       "(start sect %llu len %llu) "
-			       "is misaligned",
+			       "caused an alignment inconsistency",
 			       dm_device_name(table->md),
 			       (unsigned long long) ti->begin,
 			       (unsigned long long) ti->len);
@@ -1079,15 +1078,6 @@ void dm_table_set_restrictions(struct dm
 			       struct queue_limits *limits)
 {
 	/*
-	 * Each target device in the table has a data area that should normally
-	 * be aligned such that the DM device's alignment_offset is 0.
-	 * FIXME: Propagate alignment_offsets up the stack and warn of
-	 *	  sub-optimal or inconsistent settings.
-	 */
-	limits->alignment_offset = 0;
-	limits->misaligned = 0;
-
-	/*
 	 * Copy table's limits to the DM device's request_queue
 	 */
 	q->limits = *limits;

[24/29] x86/PCI/PAT: return EINVAL for pci mmap WC request for !pat_enabled

[Greg KH]

From: Suresh Siddha <suresh.b.siddha@intel.com>

commit 2992e545ea006992ec9dc91c4fa996ce1e15f921 upstream.

Thomas Schlichter reported:
> X.org uses libpciaccess which tries to mmap with write combining enabled via
> /sys/bus/pci/devices/*/resource0_wc. Currently, when PAT is not enabled, the
> kernel does fall back to uncached mmap. Then libpciaccess thinks it succeeded
> mapping with write combining enabled and does not set up suited MTRR entries.
> ;-(

Instead of silently mapping pci mmap region as UC minus in the case
of !pat_enabled and wc request, we can return error. Eric Anholt mentioned
that caller (like X) typically follows up with UC minus pci mmap request and
if there is a free mtrr slot, caller will manage adding WC mtrr.

Jesse Barnes says:
> Older versions of libpciaccess will behave better if we do it that way
> (iirc it only allocates an MTRR if the resource_wc file doesn't exist or
> fails to get mapped).

Reported-by: Thomas Schlichter <thomas.schlichter@web.de>
Signed-off-by: Thomas Schlichter <thomas.schlichter@web.de>
Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
Acked-by: Eric Anholt <eric@anholt.net>
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 arch/x86/pci/i386.c |    9 +++++++++
 1 file changed, 9 insertions(+)

--- a/arch/x86/pci/i386.c
+++ b/arch/x86/pci/i386.c
@@ -282,6 +282,15 @@ int pci_mmap_page_range(struct pci_dev *
 		return -EINVAL;
 
 	prot = pgprot_val(vma->vm_page_prot);
+
+	/*
+ 	 * Return error if pat is not enabled and write_combine is requested.
+ 	 * Caller can followup with UC MINUS request and add a WC mtrr if there
+ 	 * is a free mtrr slot.
+ 	 */
+	if (!pat_enabled && write_combine)
+		return -EINVAL;
+
 	if (pat_enabled && write_combine)
 		prot |= _PAGE_CACHE_WC;
 	else if (pat_enabled || boot_cpu_data.x86 > 3)

[25/29] USB: fix usbstorage for 2770:915d delivers no FAT

[Greg KH]

2.6.32-stable review patch.  If anyone has any objections, please let us know.

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

From: Ryan May <rmay31@gmail.com>

commit 10d2cdb6102669279bee2d9a00a22431b74583d5 upstream.

Resolves kernel.org bug 14914.

Remove entry for 2770:915d (usb digital camera with mass storage
support) from unusual_devs.h. The fix triggered by the entry causes
the file system on the camera to be completely inaccessible (no
partition table, the device is not mountable).

The patch works, but let me clarify a few things about it.  All the
patch does is remove the entry for this device from the
drivers/usb/storage/unusual_devs.h, which is supposed to help with a
problem with the device's reported size (I think).  I'm pretty sure it
was originally added for a reason, so I'm not sure removing it won't
cause other problems to reappear.  Also, I should note that this
unusual_devs.h entry was present (and activating workarounds) in
2.6.29, but in that version everything works fine.  Starting with
2.6.30, things no longer work.

Signed-off-by: Ryan May <rmay31@gmail.com>
Cc: Rohan Hart <rohan.hart17@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/usb/storage/unusual_devs.h |    7 -------
 1 file changed, 7 deletions(-)

--- a/drivers/usb/storage/unusual_devs.h
+++ b/drivers/usb/storage/unusual_devs.h
@@ -1807,13 +1807,6 @@ UNUSUAL_DEV(  0x2735, 0x100b, 0x0000, 0x
 		US_SC_DEVICE, US_PR_DEVICE, NULL,
 		US_FL_GO_SLOW ),
 
-/* Reported by Rohan Hart <rohan.hart17@gmail.com> */
-UNUSUAL_DEV(  0x2770, 0x915d, 0x0010, 0x0010,
-		"INTOVA",
-		"Pixtreme",
-		US_SC_DEVICE, US_PR_DEVICE, NULL,
-		US_FL_FIX_CAPACITY ),
-
 /* Reported by Frederic Marchal <frederic.marchal@wowcompany.com>
  * Mio Moov 330
  */

Re: [Stable-review] [25/29] USB: fix usbstorage for 2770:915d delivers no FAT

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 1433 bytes --]

On Fri, 2010-01-22 at 16:10 -0800, Greg KH wrote:
> 2.6.32-stable review patch.  If anyone has any objections, please let us know.
> 
> ------------------
> 
> From: Ryan May <rmay31@gmail.com>
> 
> commit 10d2cdb6102669279bee2d9a00a22431b74583d5 upstream.
> 
> Resolves kernel.org bug 14914.
> 
> Remove entry for 2770:915d (usb digital camera with mass storage
> support) from unusual_devs.h. The fix triggered by the entry causes
> the file system on the camera to be completely inaccessible (no
> partition table, the device is not mountable).
> 
> The patch works, but let me clarify a few things about it.  All the
> patch does is remove the entry for this device from the
> drivers/usb/storage/unusual_devs.h, which is supposed to help with a
> problem with the device's reported size (I think).  I'm pretty sure it
> was originally added for a reason, so I'm not sure removing it won't
> cause other problems to reappear.  Also, I should note that this
> unusual_devs.h entry was present (and activating workarounds) in
> 2.6.29, but in that version everything works fine.  Starting with
> 2.6.30, things no longer work.
[...]

It doesn't sound like this bug or fix are sufficiently well understood
yet to be suitable for a stable update.  The bug report is currently
marked as invalid!

Ben.

-- 
Ben Hutchings
Any smoothly functioning technology is indistinguishable from a rigged demo.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: [Stable-review] [25/29] USB: fix usbstorage for 2770:915d delivers no FAT

[Greg KH]

On Sat, Jan 23, 2010 at 02:43:46AM +0000, Ben Hutchings wrote:
> On Fri, 2010-01-22 at 16:10 -0800, Greg KH wrote:
> > 2.6.32-stable review patch.  If anyone has any objections, please let us know.
> > 
> > ------------------
> > 
> > From: Ryan May <rmay31@gmail.com>
> > 
> > commit 10d2cdb6102669279bee2d9a00a22431b74583d5 upstream.
> > 
> > Resolves kernel.org bug 14914.
> > 
> > Remove entry for 2770:915d (usb digital camera with mass storage
> > support) from unusual_devs.h. The fix triggered by the entry causes
> > the file system on the camera to be completely inaccessible (no
> > partition table, the device is not mountable).
> > 
> > The patch works, but let me clarify a few things about it.  All the
> > patch does is remove the entry for this device from the
> > drivers/usb/storage/unusual_devs.h, which is supposed to help with a
> > problem with the device's reported size (I think).  I'm pretty sure it
> > was originally added for a reason, so I'm not sure removing it won't
> > cause other problems to reappear.  Also, I should note that this
> > unusual_devs.h entry was present (and activating workarounds) in
> > 2.6.29, but in that version everything works fine.  Starting with
> > 2.6.30, things no longer work.
> [...]
> 
> It doesn't sound like this bug or fix are sufficiently well understood
> yet to be suitable for a stable update.  The bug report is currently
> marked as invalid!

It was marked that way as we couldn't take a patch through a bug report.
The email thread for it said it solved the problem, and I have had a
number of other users report that it solves their problem as well.

So I do think it needs to remain, unless someone has a report to the
contrary?  And if so, I'll be glad to take it out of the main tree, and
then take that back to the -stable tree.

thanks,

greg k-h

[26/29] vmalloc: remove BUG_ON due to racy counting of VM_LAZY_FREE

[Greg KH]

2.6.32-stable review patch.  If anyone has any objections, please let us know.

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

From: Yongseok Koh <yongseok.koh@samsung.com>

commit 88f5004430babb836cfce886d5d54c82166f8ba4 upstream.

In free_unmap_area_noflush(), va->flags is marked as VM_LAZY_FREE first, and
then vmap_lazy_nr is increased atomically.

But, in __purge_vmap_area_lazy(), while traversing of vmap_are_list, nr
is counted by checking VM_LAZY_FREE is set to va->flags.  After counting
the variable nr, kernel reads vmap_lazy_nr atomically and checks a
BUG_ON condition whether nr is greater than vmap_lazy_nr to prevent
vmap_lazy_nr from being negative.

The problem is that, if interrupted right after marking VM_LAZY_FREE,
increment of vmap_lazy_nr can be delayed.  Consequently, BUG_ON
condition can be met because nr is counted more than vmap_lazy_nr.

It is highly probable when vmalloc/vfree are called frequently.  This
scenario have been verified by adding delay between marking VM_LAZY_FREE
and increasing vmap_lazy_nr in free_unmap_area_noflush().

Even the vmap_lazy_nr is for checking high watermark, it never be the
strict watermark.  Although the BUG_ON condition is to prevent
vmap_lazy_nr from being negative, vmap_lazy_nr is signed variable.  So,
it could go down to negative value temporarily.

Consequently, removing the BUG_ON condition is proper.

A possible BUG_ON message is like the below.

   kernel BUG at mm/vmalloc.c:517!
   invalid opcode: 0000 [#1] SMP
   EIP: 0060:[<c04824a4>] EFLAGS: 00010297 CPU: 3
   EIP is at __purge_vmap_area_lazy+0x144/0x150
   EAX: ee8a8818 EBX: c08e77d4 ECX: e7c7ae40 EDX: c08e77ec
   ESI: 000081fe EDI: e7c7ae60 EBP: e7c7ae64 ESP: e7c7ae3c
   DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
   Call Trace:
   [<c0482ad9>] free_unmap_vmap_area_noflush+0x69/0x70
   [<c0482b02>] remove_vm_area+0x22/0x70
   [<c0482c15>] __vunmap+0x45/0xe0
   [<c04831ec>] vmalloc+0x2c/0x30
   Code: 8d 59 e0 eb 04 66 90 89 cb 89 d0 e8 87 fe ff ff 8b 43 20 89 da 8d 48 e0 8d 43 20 3b 04 24 75 e7 fe 05 a8 a5 a3 c0 e9 78 ff ff ff <0f> 0b eb fe 90 8d b4 26 00 00 00 00 56 89 c6 b8 ac a5 a3 c0 31
   EIP: [<c04824a4>] __purge_vmap_area_lazy+0x144/0x150 SS:ESP 0068:e7c7ae3c

[ See also http://marc.info/?l=linux-kernel&m=126335856228090&w=2 ]

Signed-off-by: Yongseok Koh <yongseok.koh@samsung.com>
Reviewed-by: Minchan Kim <minchan.kim@gmail.com>
Cc: Nick Piggin <npiggin@suse.de>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 mm/vmalloc.c |    4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -555,10 +555,8 @@ static void __purge_vmap_area_lazy(unsig
 	}
 	rcu_read_unlock();
 
-	if (nr) {
-		BUG_ON(nr > atomic_read(&vmap_lazy_nr));
+	if (nr)
 		atomic_sub(nr, &vmap_lazy_nr);
-	}
 
 	if (nr || force_flush)
 		flush_tlb_kernel_range(*start, *end);

[27/29] perf timechart: Use tid not pid for COMM change

[Greg KH]

2.6.32-stable review patch.  If anyone has any objections, please let us know.

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

From: Arjan van de Ven <arjan@linux.intel.com>

commit 8f06d7e6e1bbfb32698d6d455583ab7460c090e2 upstream.

A process that changes its comm field, does this on a per kernel
task struct basis. The timechart tool used, incorrectly, the pid
to track this, and should have used the tid instead...

Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
LKML-Reference: <20100116125319.34ac3edd@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 tools/perf/builtin-timechart.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/tools/perf/builtin-timechart.c
+++ b/tools/perf/builtin-timechart.c
@@ -275,7 +275,7 @@ static u64 cpus_pstate_state[MAX_CPUS];
 static int
 process_comm_event(event_t *event)
 {
-	pid_set_comm(event->comm.pid, event->comm.comm);
+	pid_set_comm(event->comm.tid, event->comm.comm);
 	return 0;
 }
 static int

[28/29] perf events: Dont report side-band events on each cpu for per-task-per-cpu events

[Greg KH]

2.6.32-stable review patch.  If anyone has any objections, please let us know.

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

From: Peter Zijlstra <a.p.zijlstra@chello.nl>

commit 5d27c23df09b702868d9a3bff86ec6abd22963ac upstream.

Acme noticed that his FORK/MMAP numbers were inflated by about
the same factor as his cpu-count.

This led to the discovery of a few more sites that need to
respect the event->cpu filter.

Reported-by: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
LKML-Reference: <20091217121830.215333434@chello.nl>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 kernel/perf_event.c |   20 ++++++++++++++++++--
 1 file changed, 18 insertions(+), 2 deletions(-)

--- a/kernel/perf_event.c
+++ b/kernel/perf_event.c
@@ -1359,6 +1359,9 @@ static void perf_ctx_adjust_freq(struct 
 		if (event->state != PERF_EVENT_STATE_ACTIVE)
 			continue;
 
+		if (event->cpu != -1 && event->cpu != smp_processor_id())
+			continue;
+
 		hwc = &event->hw;
 
 		interrupts = hwc->interrupts;
@@ -3226,6 +3229,9 @@ static void perf_event_task_output(struc
 
 static int perf_event_task_match(struct perf_event *event)
 {
+	if (event->cpu != -1 && event->cpu != smp_processor_id())
+		return 0;
+
 	if (event->attr.comm || event->attr.mmap || event->attr.task)
 		return 1;
 
@@ -3262,6 +3268,7 @@ static void perf_event_task_event(struct
 		ctx = rcu_dereference(task_event->task->perf_event_ctxp);
 	if (ctx)
 		perf_event_task_ctx(ctx, task_event);
+	put_cpu_var(perf_cpu_context);
 	rcu_read_unlock();
 }
 
@@ -3338,6 +3345,9 @@ static void perf_event_comm_output(struc
 
 static int perf_event_comm_match(struct perf_event *event)
 {
+	if (event->cpu != -1 && event->cpu != smp_processor_id())
+		return 0;
+
 	if (event->attr.comm)
 		return 1;
 
@@ -3378,7 +3388,6 @@ static void perf_event_comm_event(struct
 
 	cpuctx = &get_cpu_var(perf_cpu_context);
 	perf_event_comm_ctx(&cpuctx->ctx, comm_event);
-	put_cpu_var(perf_cpu_context);
 
 	rcu_read_lock();
 	/*
@@ -3388,6 +3397,7 @@ static void perf_event_comm_event(struct
 	ctx = rcu_dereference(current->perf_event_ctxp);
 	if (ctx)
 		perf_event_comm_ctx(ctx, comm_event);
+	put_cpu_var(perf_cpu_context);
 	rcu_read_unlock();
 }
 
@@ -3462,6 +3472,9 @@ static void perf_event_mmap_output(struc
 static int perf_event_mmap_match(struct perf_event *event,
 				   struct perf_mmap_event *mmap_event)
 {
+	if (event->cpu != -1 && event->cpu != smp_processor_id())
+		return 0;
+
 	if (event->attr.mmap)
 		return 1;
 
@@ -3539,7 +3552,6 @@ got_name:
 
 	cpuctx = &get_cpu_var(perf_cpu_context);
 	perf_event_mmap_ctx(&cpuctx->ctx, mmap_event);
-	put_cpu_var(perf_cpu_context);
 
 	rcu_read_lock();
 	/*
@@ -3549,6 +3561,7 @@ got_name:
 	ctx = rcu_dereference(current->perf_event_ctxp);
 	if (ctx)
 		perf_event_mmap_ctx(ctx, mmap_event);
+	put_cpu_var(perf_cpu_context);
 	rcu_read_unlock();
 
 	kfree(buf);
@@ -3811,6 +3824,9 @@ static int perf_swevent_match(struct per
 				enum perf_type_id type,
 				u32 event_id, struct pt_regs *regs)
 {
+	if (event->cpu != -1 && event->cpu != smp_processor_id())
+		return 0;
+
 	if (!perf_swevent_is_counting(event))
 		return 0;
 

Re: [Stable-review] [28/29] perf events: Dont report side-band events on each cpu for per-task-per-cpu events

[Stefan Bader]

Greg KH wrote:
> 2.6.32-stable review patch.  If anyone has any objections, please let us know.
> 
> ------------------
> 
> From: Peter Zijlstra <a.p.zijlstra@chello.nl>
> 
> commit 5d27c23df09b702868d9a3bff86ec6abd22963ac upstream.
> 
> Acme noticed that his FORK/MMAP numbers were inflated by about
> the same factor as his cpu-count.
> 
> This led to the discovery of a few more sites that need to
> respect the event->cpu filter.
> 
> Reported-by: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
> Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
> Cc: Paul Mackerras <paulus@samba.org>
> LKML-Reference: <20091217121830.215333434@chello.nl>
> Signed-off-by: Ingo Molnar <mingo@elte.hu>
> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
> 
> ---
>  kernel/perf_event.c |   20 ++++++++++++++++++--
>  1 file changed, 18 insertions(+), 2 deletions(-)
> 
> --- a/kernel/perf_event.c
> +++ b/kernel/perf_event.c
> @@ -1359,6 +1359,9 @@ static void perf_ctx_adjust_freq(struct 
>  		if (event->state != PERF_EVENT_STATE_ACTIVE)
>  			continue;
>  
> +		if (event->cpu != -1 && event->cpu != smp_processor_id())
> +			continue;
> +
>  		hwc = &event->hw;
>  
>  		interrupts = hwc->interrupts;
> @@ -3226,6 +3229,9 @@ static void perf_event_task_output(struc
>  
>  static int perf_event_task_match(struct perf_event *event)
>  {
> +	if (event->cpu != -1 && event->cpu != smp_processor_id())
> +		return 0;
> +
>  	if (event->attr.comm || event->attr.mmap || event->attr.task)
>  		return 1;
>  

> @@ -3262,6 +3268,7 @@ static void perf_event_task_event(struct
>  		ctx = rcu_dereference(task_event->task->perf_event_ctxp);
>  	if (ctx)
>  		perf_event_task_ctx(ctx, task_event);
> +	put_cpu_var(perf_cpu_context);
>  	rcu_read_unlock();
>  }

I believe this hunk drops the move of put_cpu_var. The upstream hunk looks like
this:

@ -3290,12 +3296,11 @@ static void perf_event_task_event(struct perf_task_event
        rcu_read_lock();
        cpuctx = &get_cpu_var(perf_cpu_context);
        perf_event_task_ctx(&cpuctx->ctx, task_event);
-       put_cpu_var(perf_cpu_context);
-
        if (!ctx)
                ctx = rcu_dereference(task_event->task->perf_event_ctxp);
        if (ctx)
                perf_event_task_ctx(ctx, task_event);
+       put_cpu_var(perf_cpu_context);
        rcu_read_unlock();
 }

> @@ -3338,6 +3345,9 @@ static void perf_event_comm_output(struc
>  
>  static int perf_event_comm_match(struct perf_event *event)
>  {
> +	if (event->cpu != -1 && event->cpu != smp_processor_id())
> +		return 0;
> +
>  	if (event->attr.comm)
>  		return 1;
>  
> @@ -3378,7 +3388,6 @@ static void perf_event_comm_event(struct
>  
>  	cpuctx = &get_cpu_var(perf_cpu_context);
>  	perf_event_comm_ctx(&cpuctx->ctx, comm_event);
> -	put_cpu_var(perf_cpu_context);
>  
>  	rcu_read_lock();
>  	/*
> @@ -3388,6 +3397,7 @@ static void perf_event_comm_event(struct
>  	ctx = rcu_dereference(current->perf_event_ctxp);
>  	if (ctx)
>  		perf_event_comm_ctx(ctx, comm_event);
> +	put_cpu_var(perf_cpu_context);
>  	rcu_read_unlock();
>  }
>  
> @@ -3462,6 +3472,9 @@ static void perf_event_mmap_output(struc
>  static int perf_event_mmap_match(struct perf_event *event,
>  				   struct perf_mmap_event *mmap_event)
>  {
> +	if (event->cpu != -1 && event->cpu != smp_processor_id())
> +		return 0;
> +
>  	if (event->attr.mmap)
>  		return 1;
>  
> @@ -3539,7 +3552,6 @@ got_name:
>  
>  	cpuctx = &get_cpu_var(perf_cpu_context);
>  	perf_event_mmap_ctx(&cpuctx->ctx, mmap_event);
> -	put_cpu_var(perf_cpu_context);
>  
>  	rcu_read_lock();
>  	/*
> @@ -3549,6 +3561,7 @@ got_name:
>  	ctx = rcu_dereference(current->perf_event_ctxp);
>  	if (ctx)
>  		perf_event_mmap_ctx(ctx, mmap_event);
> +	put_cpu_var(perf_cpu_context);
>  	rcu_read_unlock();
>  
>  	kfree(buf);
> @@ -3811,6 +3824,9 @@ static int perf_swevent_match(struct per
>  				enum perf_type_id type,
>  				u32 event_id, struct pt_regs *regs)
>  {
> +	if (event->cpu != -1 && event->cpu != smp_processor_id())
> +		return 0;
> +
>  	if (!perf_swevent_is_counting(event))
>  		return 0;
>  
> 
> 
> _______________________________________________
> Stable-review mailing list
> Stable-review@linux.kernel.org
> http://linux.kernel.org/mailman/listinfo/stable-review

Re: [Stable-review] [28/29] perf events: Dont report side-band events on each cpu for per-task-per-cpu events

[Greg KH]

On Sat, Jan 23, 2010 at 12:38:41PM +0100, Stefan Bader wrote:
> Greg KH wrote:
> > 2.6.32-stable review patch.  If anyone has any objections, please let us know.
> > 
> > ------------------
> > 
> > From: Peter Zijlstra <a.p.zijlstra@chello.nl>
> > 
> > commit 5d27c23df09b702868d9a3bff86ec6abd22963ac upstream.
> > 
> > Acme noticed that his FORK/MMAP numbers were inflated by about
> > the same factor as his cpu-count.
> > 
> > This led to the discovery of a few more sites that need to
> > respect the event->cpu filter.
> > 
> > Reported-by: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
> > Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
> > Cc: Paul Mackerras <paulus@samba.org>
> > LKML-Reference: <20091217121830.215333434@chello.nl>
> > Signed-off-by: Ingo Molnar <mingo@elte.hu>
> > Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
> > 
> > ---
> >  kernel/perf_event.c |   20 ++++++++++++++++++--
> >  1 file changed, 18 insertions(+), 2 deletions(-)
> > 
> > --- a/kernel/perf_event.c
> > +++ b/kernel/perf_event.c
> > @@ -1359,6 +1359,9 @@ static void perf_ctx_adjust_freq(struct 
> >  		if (event->state != PERF_EVENT_STATE_ACTIVE)
> >  			continue;
> >  
> > +		if (event->cpu != -1 && event->cpu != smp_processor_id())
> > +			continue;
> > +
> >  		hwc = &event->hw;
> >  
> >  		interrupts = hwc->interrupts;
> > @@ -3226,6 +3229,9 @@ static void perf_event_task_output(struc
> >  
> >  static int perf_event_task_match(struct perf_event *event)
> >  {
> > +	if (event->cpu != -1 && event->cpu != smp_processor_id())
> > +		return 0;
> > +
> >  	if (event->attr.comm || event->attr.mmap || event->attr.task)
> >  		return 1;
> >  
> 
> > @@ -3262,6 +3268,7 @@ static void perf_event_task_event(struct
> >  		ctx = rcu_dereference(task_event->task->perf_event_ctxp);
> >  	if (ctx)
> >  		perf_event_task_ctx(ctx, task_event);
> > +	put_cpu_var(perf_cpu_context);
> >  	rcu_read_unlock();
> >  }
> 
> I believe this hunk drops the move of put_cpu_var. The upstream hunk looks like
> this:
> 
> @ -3290,12 +3296,11 @@ static void perf_event_task_event(struct perf_task_event
>         rcu_read_lock();
>         cpuctx = &get_cpu_var(perf_cpu_context);
>         perf_event_task_ctx(&cpuctx->ctx, task_event);
> -       put_cpu_var(perf_cpu_context);
> -
>         if (!ctx)
>                 ctx = rcu_dereference(task_event->task->perf_event_ctxp);
>         if (ctx)
>                 perf_event_task_ctx(ctx, task_event);
> +       put_cpu_var(perf_cpu_context);
>         rcu_read_unlock();
>  }

Good catch, thanks, I merged this by hand (it was needed by the patch
after this), and I missed this chunk.

thanks,

greg k-h

Re: [Stable-review] [28/29] perf events: Dont report side-band events on each cpu for per-task-per-cpu events

[Greg KH]

On Sat, Jan 23, 2010 at 12:38:41PM +0100, Stefan Bader wrote:
> Greg KH wrote:
> > 2.6.32-stable review patch.  If anyone has any objections, please let us know.
> > 
> > ------------------
> > 
> > From: Peter Zijlstra <a.p.zijlstra@chello.nl>
> > 
> > commit 5d27c23df09b702868d9a3bff86ec6abd22963ac upstream.
> > 
> > Acme noticed that his FORK/MMAP numbers were inflated by about
> > the same factor as his cpu-count.
> > 
> > This led to the discovery of a few more sites that need to
> > respect the event->cpu filter.
> > 
> > Reported-by: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
> > Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
> > Cc: Paul Mackerras <paulus@samba.org>
> > LKML-Reference: <20091217121830.215333434@chello.nl>
> > Signed-off-by: Ingo Molnar <mingo@elte.hu>
> > Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
> > 
> > ---
> >  kernel/perf_event.c |   20 ++++++++++++++++++--
> >  1 file changed, 18 insertions(+), 2 deletions(-)
> > 
> > --- a/kernel/perf_event.c
> > +++ b/kernel/perf_event.c
> > @@ -1359,6 +1359,9 @@ static void perf_ctx_adjust_freq(struct 
> >  		if (event->state != PERF_EVENT_STATE_ACTIVE)
> >  			continue;
> >  
> > +		if (event->cpu != -1 && event->cpu != smp_processor_id())
> > +			continue;
> > +
> >  		hwc = &event->hw;
> >  
> >  		interrupts = hwc->interrupts;
> > @@ -3226,6 +3229,9 @@ static void perf_event_task_output(struc
> >  
> >  static int perf_event_task_match(struct perf_event *event)
> >  {
> > +	if (event->cpu != -1 && event->cpu != smp_processor_id())
> > +		return 0;
> > +
> >  	if (event->attr.comm || event->attr.mmap || event->attr.task)
> >  		return 1;
> >  
> 
> > @@ -3262,6 +3268,7 @@ static void perf_event_task_event(struct
> >  		ctx = rcu_dereference(task_event->task->perf_event_ctxp);
> >  	if (ctx)
> >  		perf_event_task_ctx(ctx, task_event);
> > +	put_cpu_var(perf_cpu_context);
> >  	rcu_read_unlock();
> >  }
> 
> I believe this hunk drops the move of put_cpu_var. The upstream hunk looks like
> this:
> 
> @ -3290,12 +3296,11 @@ static void perf_event_task_event(struct perf_task_event
>         rcu_read_lock();
>         cpuctx = &get_cpu_var(perf_cpu_context);
>         perf_event_task_ctx(&cpuctx->ctx, task_event);
> -       put_cpu_var(perf_cpu_context);
> -
>         if (!ctx)
>                 ctx = rcu_dereference(task_event->task->perf_event_ctxp);
>         if (ctx)
>                 perf_event_task_ctx(ctx, task_event);
> +       put_cpu_var(perf_cpu_context);
>         rcu_read_unlock();
>  }

All fixed up now, thanks again for the review.

greg k-h

[29/29] perf: Honour event state for aux stream data

[Greg KH]

2.6.32-stable review patch.  If anyone has any objections, please let us know.

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

From: Peter Zijlstra <a.p.zijlstra@chello.nl>

commit 22e190851f8709c48baf00ed9ce6144cdc54d025 upstream.

Anton reported that perf record kept receiving events even after calling
ioctl(PERF_EVENT_IOC_DISABLE). It turns out that FORK,COMM and MMAP
events didn't respect the disabled state and kept flowing in.

Reported-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Tested-by: Anton Blanchard <anton@samba.org>
LKML-Reference: <1263459187.4244.265.camel@laptop>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 kernel/perf_event.c |    9 +++++++++
 1 file changed, 9 insertions(+)

--- a/kernel/perf_event.c
+++ b/kernel/perf_event.c
@@ -3229,6 +3229,9 @@ static void perf_event_task_output(struc
 
 static int perf_event_task_match(struct perf_event *event)
 {
+	if (event->state != PERF_EVENT_STATE_ACTIVE)
+		return 0;
+
 	if (event->cpu != -1 && event->cpu != smp_processor_id())
 		return 0;
 
@@ -3345,6 +3348,9 @@ static void perf_event_comm_output(struc
 
 static int perf_event_comm_match(struct perf_event *event)
 {
+	if (event->state != PERF_EVENT_STATE_ACTIVE)
+		return 0;
+
 	if (event->cpu != -1 && event->cpu != smp_processor_id())
 		return 0;
 
@@ -3472,6 +3478,9 @@ static void perf_event_mmap_output(struc
 static int perf_event_mmap_match(struct perf_event *event,
 				   struct perf_mmap_event *mmap_event)
 {
+	if (event->state != PERF_EVENT_STATE_ACTIVE)
+		return 0;
+
 	if (event->cpu != -1 && event->cpu != smp_processor_id())
 		return 0;
 

Re: [stable] [00/29] 2.6.32.6 stable review

[Andrew Morton]

On Fri, 22 Jan 2010 16:11:45 -0800 Greg KH <gregkh@suse.de> wrote:

> This is the start of the stable review cycle for the 2.6.32.6 release.
> There are 29 patches in this series, all will be posted as a response to
> this one.  If anyone has any issues with these being applied, please let
> us know.  If anyone is a maintainer of the proper subsystem, and wants
> to add a Signed-off-by: line to the patch, please respond with it.
> 
> Responses should be made by Monday, January 24, 00:00:00 UTC.
> Anything received after that time might be too late.

2.6.32.6 will still contain the regression described in (for example)

http://bugzilla.kernel.org/show_bug.cgi?id=15117 
http://bugzilla.kernel.org/show_bug.cgi?id=15005

It's fixed with the below revert which has been in -mm (and only in
-mm) for ten days.

I don't what's going on - perhaps we're waiting for Thomas, and he's
otherwise engaged.  There's a fix in the lkml thread "Re: [RFC PATCH
0/4] clockevents: fix clockevent_devices list corruption after cpu
hotplug" to which Thomas replied

    I just applied your patch, but kept the cpuweight check.  This
    is the least intrusive solution for now.  The logic needs an
    overhaul, but thats neither rc4 nor stable material"

but no such patch is present in linux-next.



From: Andrew Morton <akpm@linux-foundation.org>

Revert

: commit bb6eddf7676e1c1f3e637aa93c5224488d99036f
: Author:     Thomas Gleixner <tglx@linutronix.de>
: AuthorDate: Thu Dec 10 15:35:10 2009 +0100
: Commit:     Thomas Gleixner <tglx@linutronix.de>
: CommitDate: Fri Dec 11 10:28:08 2009 +0100
: 
:     clockevents: Prevent clockevent_devices list corruption on cpu hotplug

due to the regression reported in
http://bugzilla.kernel.org/show_bug.cgi?id=15005

Cc: Xiaotian Feng <dfeng@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
Reported-by: Martin Bammer <mrb74@gmx.at>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 kernel/time/clockevents.c |   18 +++---------------
 1 file changed, 3 insertions(+), 15 deletions(-)

diff -puN kernel/time/clockevents.c~revert-clockevents-prevent-clockevent_devices-list-corruption-on-cpu-hotplug kernel/time/clockevents.c
--- a/kernel/time/clockevents.c~revert-clockevents-prevent-clockevent_devices-list-corruption-on-cpu-hotplug
+++ a/kernel/time/clockevents.c
@@ -238,9 +238,8 @@ void clockevents_exchange_device(struct 
  */
 void clockevents_notify(unsigned long reason, void *arg)
 {
-	struct clock_event_device *dev, *tmp;
+	struct list_head *node, *tmp;
 	unsigned long flags;
-	int cpu;
 
 	raw_spin_lock_irqsave(&clockevents_lock, flags);
 	clockevents_do_notify(reason, arg);
@@ -251,19 +250,8 @@ void clockevents_notify(unsigned long re
 		 * Unregister the clock event devices which were
 		 * released from the users in the notify chain.
 		 */
-		list_for_each_entry_safe(dev, tmp, &clockevents_released, list)
-			list_del(&dev->list);
-		/*
-		 * Now check whether the CPU has left unused per cpu devices
-		 */
-		cpu = *((int *)arg);
-		list_for_each_entry_safe(dev, tmp, &clockevent_devices, list) {
-			if (cpumask_test_cpu(cpu, dev->cpumask) &&
-			    cpumask_weight(dev->cpumask) == 1) {
-				BUG_ON(dev->mode != CLOCK_EVT_MODE_UNUSED);
-				list_del(&dev->list);
-			}
-		}
+		list_for_each_safe(node, tmp, &clockevents_released)
+			list_del(node);
 		break;
 	default:
 		break;
_

Re: [stable] [00/29] 2.6.32.6 stable review

[Thomas Gleixner]

On Sat, 23 Jan 2010, Andrew Morton wrote:

> On Fri, 22 Jan 2010 16:11:45 -0800 Greg KH <gregkh@suse.de> wrote:
> 
> > This is the start of the stable review cycle for the 2.6.32.6 release.
> > There are 29 patches in this series, all will be posted as a response to
> > this one.  If anyone has any issues with these being applied, please let
> > us know.  If anyone is a maintainer of the proper subsystem, and wants
> > to add a Signed-off-by: line to the patch, please respond with it.
> > 
> > Responses should be made by Monday, January 24, 00:00:00 UTC.
> > Anything received after that time might be too late.
> 
> 2.6.32.6 will still contain the regression described in (for example)
> 
> http://bugzilla.kernel.org/show_bug.cgi?id=15117 
> http://bugzilla.kernel.org/show_bug.cgi?id=15005
> 
> It's fixed with the below revert which has been in -mm (and only in
> -mm) for ten days.
> 
> I don't what's going on - perhaps we're waiting for Thomas, and he's
> otherwise engaged.  There's a fix in the lkml thread "Re: [RFC PATCH
> 0/4] clockevents: fix clockevent_devices list corruption after cpu
> hotplug" to which Thomas replied
> 
>     I just applied your patch, but kept the cpuweight check.  This
>     is the least intrusive solution for now.  The logic needs an
>     overhaul, but thats neither rc4 nor stable material"

Just sent the pull request for it. Sorry for the delay. The patch
needs to go into 32.6 as well.

Thanks,

	tglx

Re: [stable] [00/29] 2.6.32.6 stable review

[Ozan Çağlayan]

Thomas Gleixner wrote On 24-01-2010 18:29:
> On Sat, 23 Jan 2010, Andrew Morton wrote:
> 
>> On Fri, 22 Jan 2010 16:11:45 -0800 Greg KH <gregkh@suse.de> wrote:
>>
>>> This is the start of the stable review cycle for the 2.6.32.6 release.
>>> There are 29 patches in this series, all will be posted as a response to
>>> this one.  If anyone has any issues with these being applied, please let
>>> us know.  If anyone is a maintainer of the proper subsystem, and wants
>>> to add a Signed-off-by: line to the patch, please respond with it.
>>>
>>> Responses should be made by Monday, January 24, 00:00:00 UTC.
>>> Anything received after that time might be too late.
>> 2.6.32.6 will still contain the regression described in (for example)
>>
>> http://bugzilla.kernel.org/show_bug.cgi?id=15117 
>> http://bugzilla.kernel.org/show_bug.cgi?id=15005
>>
>> It's fixed with the below revert which has been in -mm (and only in
>> -mm) for ten days.
>>
>> I don't what's going on - perhaps we're waiting for Thomas, and he's
>> otherwise engaged.  There's a fix in the lkml thread "Re: [RFC PATCH
>> 0/4] clockevents: fix clockevent_devices list corruption after cpu
>> hotplug" to which Thomas replied
>>
>>     I just applied your patch, but kept the cpuweight check.  This
>>     is the least intrusive solution for now.  The logic needs an
>>     overhaul, but thats neither rc4 nor stable material"
> 
> Just sent the pull request for it. Sorry for the delay. The patch
> needs to go into 32.6 as well.

tick-internal.h should be included for this to fix build failure. Already included
in 2.6.33 with 8e1a928a2ed7e8.

Regards,

Re: [stable] [00/29] 2.6.32.6 stable review

[Greg KH]

On Mon, Jan 25, 2010 at 10:40:35AM +0200, Ozan Çağlayan wrote:
> Thomas Gleixner wrote On 24-01-2010 18:29:
> > On Sat, 23 Jan 2010, Andrew Morton wrote:
> > 
> >> On Fri, 22 Jan 2010 16:11:45 -0800 Greg KH <gregkh@suse.de> wrote:
> >>
> >>> This is the start of the stable review cycle for the 2.6.32.6 release.
> >>> There are 29 patches in this series, all will be posted as a response to
> >>> this one.  If anyone has any issues with these being applied, please let
> >>> us know.  If anyone is a maintainer of the proper subsystem, and wants
> >>> to add a Signed-off-by: line to the patch, please respond with it.
> >>>
> >>> Responses should be made by Monday, January 24, 00:00:00 UTC.
> >>> Anything received after that time might be too late.
> >> 2.6.32.6 will still contain the regression described in (for example)
> >>
> >> http://bugzilla.kernel.org/show_bug.cgi?id=15117 
> >> http://bugzilla.kernel.org/show_bug.cgi?id=15005
> >>
> >> It's fixed with the below revert which has been in -mm (and only in
> >> -mm) for ten days.
> >>
> >> I don't what's going on - perhaps we're waiting for Thomas, and he's
> >> otherwise engaged.  There's a fix in the lkml thread "Re: [RFC PATCH
> >> 0/4] clockevents: fix clockevent_devices list corruption after cpu
> >> hotplug" to which Thomas replied
> >>
> >>     I just applied your patch, but kept the cpuweight check.  This
> >>     is the least intrusive solution for now.  The logic needs an
> >>     overhaul, but thats neither rc4 nor stable material"
> > 
> > Just sent the pull request for it. Sorry for the delay. The patch
> > needs to go into 32.6 as well.
> 
> tick-internal.h should be included for this to fix build failure. Already included
> in 2.6.33 with 8e1a928a2ed7e8.

Huh?  That says:
	clockevents: Add missing include to pacify sparse

and does not sound like a problem that needs to be fixed for "real"
users, right?

Or does .32.6 have a build problem somewhere?

confused,

greg k-h

Re: [stable] [00/29] 2.6.32.6 stable review

[Ozan Çağlayan]

Greg KH wrote:
> On Mon, Jan 25, 2010 at 10:40:35AM +0200, Ozan Çağlayan wrote:

> 
> Huh?  That says:
> 	clockevents: Add missing include to pacify sparse
> 
> and does not sound like a problem that needs to be fixed for "real"
> users, right?
> 
> Or does .32.6 have a build problem somewhere?

Applying the patch on top of 2.6.32.y causes build failure as the fix calls a macro from
"tick-internal.h".

#include "tick-internal.h"

was added to clockevents.c with 8e1a928a2ed7e8 in linux-2.6/master for another reason e.g.
the patch is OK for linux-2.6/master but should be modified to add #include directive
for .32.y when backporting.

Regards,

Re: [stable] [00/29] 2.6.32.6 stable review

[Greg KH]

On Mon, Jan 25, 2010 at 07:39:57PM +0200, Ozan Çağlayan wrote:
> Greg KH wrote:
> > On Mon, Jan 25, 2010 at 10:40:35AM +0200, Ozan Çağlayan wrote:
> 
> > 
> > Huh?  That says:
> > 	clockevents: Add missing include to pacify sparse
> > 
> > and does not sound like a problem that needs to be fixed for "real"
> > users, right?
> > 
> > Or does .32.6 have a build problem somewhere?
> 
> Applying the patch on top of 2.6.32.y causes build failure as the fix calls a macro from
> "tick-internal.h".
> 
> #include "tick-internal.h"
> 
> was added to clockevents.c with 8e1a928a2ed7e8 in linux-2.6/master for another reason e.g.
> the patch is OK for linux-2.6/master but should be modified to add #include directive
> for .32.y when backporting.

Hm, please, can someone give me _exactly_ which git commit ids they wish
to see in the .32-stable tree to resolve this issue?

thanks,

greg k-h

Re: [stable] [00/29] 2.6.32.6 stable review

[Greg KH]

On Mon, Jan 25, 2010 at 09:46:25AM -0800, Greg KH wrote:
> On Mon, Jan 25, 2010 at 07:39:57PM +0200, Ozan Çağlayan wrote:
> > Greg KH wrote:
> > > On Mon, Jan 25, 2010 at 10:40:35AM +0200, Ozan Çağlayan wrote:
> > 
> > > 
> > > Huh?  That says:
> > > 	clockevents: Add missing include to pacify sparse
> > > 
> > > and does not sound like a problem that needs to be fixed for "real"
> > > users, right?
> > > 
> > > Or does .32.6 have a build problem somewhere?
> > 
> > Applying the patch on top of 2.6.32.y causes build failure as the fix calls a macro from
> > "tick-internal.h".
> > 
> > #include "tick-internal.h"
> > 
> > was added to clockevents.c with 8e1a928a2ed7e8 in linux-2.6/master for another reason e.g.
> > the patch is OK for linux-2.6/master but should be modified to add #include directive
> > for .32.y when backporting.
> 
> Hm, please, can someone give me _exactly_ which git commit ids they wish
> to see in the .32-stable tree to resolve this issue?

Ok, I think I got it now, nevermind...

thanks,

greg k-h

Re: [stable] [00/29] 2.6.32.6 stable review

[Thomas Gleixner]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2171 bytes --]

On Mon, 25 Jan 2010, Greg KH wrote:

> On Mon, Jan 25, 2010 at 10:40:35AM +0200, Ozan Çağlayan wrote:
> > Thomas Gleixner wrote On 24-01-2010 18:29:
> > > On Sat, 23 Jan 2010, Andrew Morton wrote:
> > > 
> > >> On Fri, 22 Jan 2010 16:11:45 -0800 Greg KH <gregkh@suse.de> wrote:
> > >>
> > >>> This is the start of the stable review cycle for the 2.6.32.6 release.
> > >>> There are 29 patches in this series, all will be posted as a response to
> > >>> this one.  If anyone has any issues with these being applied, please let
> > >>> us know.  If anyone is a maintainer of the proper subsystem, and wants
> > >>> to add a Signed-off-by: line to the patch, please respond with it.
> > >>>
> > >>> Responses should be made by Monday, January 24, 00:00:00 UTC.
> > >>> Anything received after that time might be too late.
> > >> 2.6.32.6 will still contain the regression described in (for example)
> > >>
> > >> http://bugzilla.kernel.org/show_bug.cgi?id=15117 
> > >> http://bugzilla.kernel.org/show_bug.cgi?id=15005
> > >>
> > >> It's fixed with the below revert which has been in -mm (and only in
> > >> -mm) for ten days.
> > >>
> > >> I don't what's going on - perhaps we're waiting for Thomas, and he's
> > >> otherwise engaged.  There's a fix in the lkml thread "Re: [RFC PATCH
> > >> 0/4] clockevents: fix clockevent_devices list corruption after cpu
> > >> hotplug" to which Thomas replied
> > >>
> > >>     I just applied your patch, but kept the cpuweight check.  This
> > >>     is the least intrusive solution for now.  The logic needs an
> > >>     overhaul, but thats neither rc4 nor stable material"
> > > 
> > > Just sent the pull request for it. Sorry for the delay. The patch
> > > needs to go into 32.6 as well.
> > 
> > tick-internal.h should be included for this to fix build failure. Already included
> > in 2.6.33 with 8e1a928a2ed7e8.
> 
> Huh?  That says:
> 	clockevents: Add missing include to pacify sparse
> 
> and does not sound like a problem that needs to be fixed for "real"
> users, right?
> 
> Or does .32.6 have a build problem somewhere?

If you pick ea9d8e3f45404d411c00ae67b45cc35c58265bb7 then you need
that include.

Thanks,

	tglx

Re: [stable] [00/29] 2.6.32.6 stable review

[Greg KH]

On Sun, Jan 24, 2010 at 05:29:26PM +0100, Thomas Gleixner wrote:
> On Sat, 23 Jan 2010, Andrew Morton wrote:
> 
> > On Fri, 22 Jan 2010 16:11:45 -0800 Greg KH <gregkh@suse.de> wrote:
> > 
> > > This is the start of the stable review cycle for the 2.6.32.6 release.
> > > There are 29 patches in this series, all will be posted as a response to
> > > this one.  If anyone has any issues with these being applied, please let
> > > us know.  If anyone is a maintainer of the proper subsystem, and wants
> > > to add a Signed-off-by: line to the patch, please respond with it.
> > > 
> > > Responses should be made by Monday, January 24, 00:00:00 UTC.
> > > Anything received after that time might be too late.
> > 
> > 2.6.32.6 will still contain the regression described in (for example)
> > 
> > http://bugzilla.kernel.org/show_bug.cgi?id=15117 
> > http://bugzilla.kernel.org/show_bug.cgi?id=15005
> > 
> > It's fixed with the below revert which has been in -mm (and only in
> > -mm) for ten days.
> > 
> > I don't what's going on - perhaps we're waiting for Thomas, and he's
> > otherwise engaged.  There's a fix in the lkml thread "Re: [RFC PATCH
> > 0/4] clockevents: fix clockevent_devices list corruption after cpu
> > hotplug" to which Thomas replied
> > 
> >     I just applied your patch, but kept the cpuweight check.  This
> >     is the least intrusive solution for now.  The logic needs an
> >     overhaul, but thats neither rc4 nor stable material"
> 
> Just sent the pull request for it. Sorry for the delay. The patch
> needs to go into 32.6 as well.

So that would be commit id ea9d8e3f45404d411c00ae67b45cc35c58265bb7 ?

Or something else?

I'll queue that one up for the next .32 stable update, but will refrain
from having it in this specific release in an hour, as there has not
been any time to test it all out.  I will start up a round for the next
.32 kernel right afterward, later today, with this patch in it.

thanks,

greg k-h