--- /dev/null
+From 62aca403657fe30e5235c5331e9871e676d9ea0a Mon Sep 17 00:00:00 2001
+From: Andrew Morton <akpm@linux-foundation.org>
+Date: Mon, 5 Mar 2012 14:59:19 -0800
+Subject: alpha: fix 32/64-bit bug in futex support
+
+From: Andrew Morton <akpm@linux-foundation.org>
+
+commit 62aca403657fe30e5235c5331e9871e676d9ea0a upstream.
+
+Michael Cree said:
+
+: : I have noticed some user space problems (pulseaudio crashes in pthread
+: : code, glibc/nptl test suite failures, java compiler freezes on SMP alpha
+: : systems) that arise when using a 2.6.39 or later kernel on Alpha.
+: : Bisecting between 2.6.38 and 2.6.39 (using glibc/nptl test suite as
+: : criterion for good/bad kernel) eventually leads to:
+: :
+: : 8d7718aa082aaf30a0b4989e1f04858952f941bc is the first bad commit
+: : commit 8d7718aa082aaf30a0b4989e1f04858952f941bc
+: : Author: Michel Lespinasse <walken@google.com>
+: : Date: Thu Mar 10 18:50:58 2011 -0800
+: :
+: : futex: Sanitize futex ops argument types
+: :
+: : Change futex_atomic_op_inuser and futex_atomic_cmpxchg_inatomic
+: : prototypes to use u32 types for the futex as this is the data type the
+: : futex core code uses all over the place.
+: :
+: : Looking at the commit I see there is a change of the uaddr argument in
+: : the Alpha architecture specific code for futexes from int to u32, but I
+: : don't see why this should cause a problem.
+
+Richard Henderson said:
+
+: futex_atomic_cmpxchg_inatomic(u32 *uval, u32 __user *uaddr,
+: u32 oldval, u32 newval)
+: ...
+: : "r"(uaddr), "r"((long)oldval), "r"(newval)
+:
+:
+: There is no 32-bit compare instruction. These are implemented by
+: consistently extending the values to a 64-bit type. Since the
+: load instruction sign-extends, we want to sign-extend the other
+: quantity as well (despite the fact it's logically unsigned).
+:
+: So:
+:
+: - : "r"(uaddr), "r"((long)oldval), "r"(newval)
+: + : "r"(uaddr), "r"((long)(int)oldval), "r"(newval)
+:
+: should do the trick.
+
+Michael said:
+
+: This fixes the glibc test suite failures and the pulseaudio related
+: crashes, but it does not fix the java compiiler lockups that I was (and
+: are still) observing. That is some other problem.
+
+Reported-by: Michael Cree <mcree@orcon.net.nz>
+Tested-by: Michael Cree <mcree@orcon.net.nz>
+Acked-by: Phil Carmody <ext-phil.2.carmody@nokia.com>
+Cc: Richard Henderson <rth@twiddle.net>
+Cc: Michel Lespinasse <walken@google.com>
+Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
+Reviewed-by: Matt Turner <mattst88@gmail.com>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/alpha/include/asm/futex.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/alpha/include/asm/futex.h
++++ b/arch/alpha/include/asm/futex.h
+@@ -108,7 +108,7 @@ futex_atomic_cmpxchg_inatomic(u32 *uval,
+ " lda $31,3b-2b(%0)\n"
+ " .previous\n"
+ : "+r"(ret), "=&r"(prev), "=&r"(cmp)
+- : "r"(uaddr), "r"((long)oldval), "r"(newval)
++ : "r"(uaddr), "r"((long)(int)oldval), "r"(newval)
+ : "memory");
+
+ *uval = prev;
--- /dev/null
+From e39d40c65dfd8390b50c03482ae9e289b8a8f351 Mon Sep 17 00:00:00 2001
+From: Gusakov Andrey <dron0gus@gmail.com>
+Date: Sat, 3 Mar 2012 07:32:36 +0900
+Subject: ARM: S3C24XX: DMA resume regression fix
+
+From: Gusakov Andrey <dron0gus@gmail.com>
+
+commit e39d40c65dfd8390b50c03482ae9e289b8a8f351 upstream.
+
+s3c2410_dma_suspend suspends channels from 0 to dma_channels.
+s3c2410_dma_resume resumes channels in reverse order. So
+pointer should be decremented instead of being incremented.
+
+Signed-off-by: Gusakov Andrey <dron0gus@gmail.com>
+Reviewed-by: Heiko Stuebner <heiko@sntech.de>
+Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm/plat-s3c24xx/dma.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/arm/plat-s3c24xx/dma.c
++++ b/arch/arm/plat-s3c24xx/dma.c
+@@ -1249,7 +1249,7 @@ static void s3c2410_dma_resume(void)
+ struct s3c2410_dma_chan *cp = s3c2410_chans + dma_channels - 1;
+ int channel;
+
+- for (channel = dma_channels - 1; channel >= 0; cp++, channel--)
++ for (channel = dma_channels - 1; channel >= 0; cp--, channel--)
+ s3c2410_dma_resume_chan(cp);
+ }
+
--- /dev/null
+From 52abb700e16a9aa4cbc03f3d7f80206cbbc80680 Mon Sep 17 00:00:00 2001
+From: Thomas Gleixner <tglx@linutronix.de>
+Date: Tue, 6 Mar 2012 23:18:54 +0100
+Subject: genirq: Clear action->thread_mask if IRQ_ONESHOT is not set
+
+From: Thomas Gleixner <tglx@linutronix.de>
+
+commit 52abb700e16a9aa4cbc03f3d7f80206cbbc80680 upstream.
+
+Xommit ac5637611(genirq: Unmask oneshot irqs when thread was not woken)
+fails to unmask when a !IRQ_ONESHOT threaded handler is handled by
+handle_level_irq.
+
+This happens because thread_mask is or'ed unconditionally in
+irq_wake_thread(), but for !IRQ_ONESHOT interrupts never cleared. So
+the check for !desc->thread_active fails and keeps the interrupt
+disabled.
+
+Keep the thread_mask zero for !IRQ_ONESHOT interrupts.
+
+Document the thread_mask magic while at it.
+
+Reported-and-tested-by: Sven Joachim <svenjoac@gmx.de>
+Reported-and-tested-by: Stefan Lippers-Hollmann <s.l-h@gmx.de>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ kernel/irq/manage.c | 44 ++++++++++++++++++++++++++++++++++++++------
+ 1 file changed, 38 insertions(+), 6 deletions(-)
+
+--- a/kernel/irq/manage.c
++++ b/kernel/irq/manage.c
+@@ -976,6 +976,11 @@ __setup_irq(unsigned int irq, struct irq
+
+ /* add new interrupt at end of irq queue */
+ do {
++ /*
++ * Or all existing action->thread_mask bits,
++ * so we can find the next zero bit for this
++ * new action.
++ */
+ thread_mask |= old->thread_mask;
+ old_ptr = &old->next;
+ old = *old_ptr;
+@@ -984,14 +989,41 @@ __setup_irq(unsigned int irq, struct irq
+ }
+
+ /*
+- * Setup the thread mask for this irqaction. Unlikely to have
+- * 32 resp 64 irqs sharing one line, but who knows.
++ * Setup the thread mask for this irqaction for ONESHOT. For
++ * !ONESHOT irqs the thread mask is 0 so we can avoid a
++ * conditional in irq_wake_thread().
+ */
+- if (new->flags & IRQF_ONESHOT && thread_mask == ~0UL) {
+- ret = -EBUSY;
+- goto out_mask;
++ if (new->flags & IRQF_ONESHOT) {
++ /*
++ * Unlikely to have 32 resp 64 irqs sharing one line,
++ * but who knows.
++ */
++ if (thread_mask == ~0UL) {
++ ret = -EBUSY;
++ goto out_mask;
++ }
++ /*
++ * The thread_mask for the action is or'ed to
++ * desc->thread_active to indicate that the
++ * IRQF_ONESHOT thread handler has been woken, but not
++ * yet finished. The bit is cleared when a thread
++ * completes. When all threads of a shared interrupt
++ * line have completed desc->threads_active becomes
++ * zero and the interrupt line is unmasked. See
++ * handle.c:irq_wake_thread() for further information.
++ *
++ * If no thread is woken by primary (hard irq context)
++ * interrupt handlers, then desc->threads_active is
++ * also checked for zero to unmask the irq line in the
++ * affected hard irq flow handlers
++ * (handle_[fasteoi|level]_irq).
++ *
++ * The new action gets the first zero bit of
++ * thread_mask assigned. See the loop above which or's
++ * all existing action->thread_mask bits.
++ */
++ new->thread_mask = 1 << ffz(thread_mask);
+ }
+- new->thread_mask = 1 << ffz(thread_mask);
+
+ if (!shared) {
+ init_waitqueue_head(&desc->wait_for_threads);
--- /dev/null
+From 371528caec553785c37f73fa3926ea0de84f986f Mon Sep 17 00:00:00 2001
+From: Anton Vorontsov <anton.vorontsov@linaro.org>
+Date: Fri, 24 Feb 2012 05:14:46 +0400
+Subject: mm: memcg: Correct unregistring of events attached to the same eventfd
+
+From: Anton Vorontsov <anton.vorontsov@linaro.org>
+
+commit 371528caec553785c37f73fa3926ea0de84f986f upstream.
+
+There is an issue when memcg unregisters events that were attached to
+the same eventfd:
+
+- On the first call mem_cgroup_usage_unregister_event() removes all
+ events attached to a given eventfd, and if there were no events left,
+ thresholds->primary would become NULL;
+
+- Since there were several events registered, cgroups core will call
+ mem_cgroup_usage_unregister_event() again, but now kernel will oops,
+ as the function doesn't expect that threshold->primary may be NULL.
+
+That's a good question whether mem_cgroup_usage_unregister_event()
+should actually remove all events in one go, but nowadays it can't
+do any better as cftype->unregister_event callback doesn't pass
+any private event-associated cookie. So, let's fix the issue by
+simply checking for threshold->primary.
+
+FWIW, w/o the patch the following oops may be observed:
+
+ BUG: unable to handle kernel NULL pointer dereference at 0000000000000004
+ IP: [<ffffffff810be32c>] mem_cgroup_usage_unregister_event+0x9c/0x1f0
+ Pid: 574, comm: kworker/0:2 Not tainted 3.3.0-rc4+ #9 Bochs Bochs
+ RIP: 0010:[<ffffffff810be32c>] [<ffffffff810be32c>] mem_cgroup_usage_unregister_event+0x9c/0x1f0
+ RSP: 0018:ffff88001d0b9d60 EFLAGS: 00010246
+ Process kworker/0:2 (pid: 574, threadinfo ffff88001d0b8000, task ffff88001de91cc0)
+ Call Trace:
+ [<ffffffff8107092b>] cgroup_event_remove+0x2b/0x60
+ [<ffffffff8103db94>] process_one_work+0x174/0x450
+ [<ffffffff8103e413>] worker_thread+0x123/0x2d0
+
+Signed-off-by: Anton Vorontsov <anton.vorontsov@linaro.org>
+Acked-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
+Cc: Kirill A. Shutemov <kirill@shutemov.name>
+Cc: Michal Hocko <mhocko@suse.cz>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ mm/memcontrol.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/mm/memcontrol.c
++++ b/mm/memcontrol.c
+@@ -4558,6 +4558,9 @@ static void mem_cgroup_usage_unregister_
+ */
+ BUG_ON(!thresholds);
+
++ if (!thresholds->primary)
++ goto unlock;
++
+ usage = mem_cgroup_usage(memcg, type == _MEMSWAP);
+
+ /* Check if a threshold crossed before removing */
+@@ -4606,7 +4609,7 @@ swap_buffers:
+
+ /* To be sure that nobody uses thresholds */
+ synchronize_rcu();
+-
++unlock:
+ mutex_unlock(&memcg->thresholds_lock);
+ }
+
--- /dev/null
+From 5b6b0ad6e572b32a641116aaa5f897ffebe31e44 Mon Sep 17 00:00:00 2001
+From: Sascha Hauer <s.hauer@pengutronix.de>
+Date: Fri, 17 Feb 2012 11:51:49 +0100
+Subject: mmc: sdhci-esdhc-imx: fix for mmc cards on i.MX5
+
+From: Sascha Hauer <s.hauer@pengutronix.de>
+
+commit 5b6b0ad6e572b32a641116aaa5f897ffebe31e44 upstream.
+
+On i.MX53 we have to write a special SDHCI_CMD_ABORTCMD to the
+SDHCI_TRANSFER_MODE register during a MMC_STOP_TRANSMISSION
+command. This works for SD cards. However, with MMC cards
+the MMC_SET_BLOCK_COUNT command is used instead, but this
+needs the same handling. Fix MMC cards by testing for the
+MMC_SET_BLOCK_COUNT command aswell. Tested on a custom i.MX53
+board with a Transcend MMC+ card and eMMC.
+
+The kernel started used MMC_SET_BLOCK_COUNT in 3.0, so this
+is a regression for these boards introduced in 3.0; it should
+go to 3.0/3.1/3.2-stable.
+
+Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
+Acked-by: Shawn Guo <shawn.guo@linaro.org>
+Signed-off-by: Chris Ball <cjb@laptop.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/mmc/host/sdhci-esdhc-imx.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+--- a/drivers/mmc/host/sdhci-esdhc-imx.c
++++ b/drivers/mmc/host/sdhci-esdhc-imx.c
+@@ -139,8 +139,9 @@ static void esdhc_writew_le(struct sdhci
+ imx_data->scratchpad = val;
+ return;
+ case SDHCI_COMMAND:
+- if ((host->cmd->opcode == MMC_STOP_TRANSMISSION)
+- && (imx_data->flags & ESDHC_FLAG_MULTIBLK_NO_INT))
++ if ((host->cmd->opcode == MMC_STOP_TRANSMISSION ||
++ host->cmd->opcode == MMC_SET_BLOCK_COUNT) &&
++ (imx_data->flags & ESDHC_FLAG_MULTIBLK_NO_INT))
+ val |= SDHCI_CMD_ABORTCMD;
+ writel(val << 16 | imx_data->scratchpad,
+ host->ioaddr + SDHCI_TRANSFER_MODE);
--- /dev/null
+From ee932bf9acb2e2c6a309e808000f24856330e3f9 Mon Sep 17 00:00:00 2001
+From: Scott Talbert <talbert@techie.net>
+Date: Tue, 21 Feb 2012 13:06:00 +0000
+Subject: Move Logitech Harmony 900 from cdc_ether to zaurus
+
+From: Scott Talbert <talbert@techie.net>
+
+commit ee932bf9acb2e2c6a309e808000f24856330e3f9 upstream.
+
+In the current kernel implementation, the Logitech Harmony 900 remote
+control is matched to the cdc_ether driver through the generic
+USB_CDC_SUBCLASS_MDLM entry. However, this device appears to be of the
+pseudo-MDLM (Belcarra) type, rather than the standard one. This patch
+blacklists the Harmony 900 from the cdc_ether driver and whitelists it for
+the pseudo-MDLM driver in zaurus.
+
+Signed-off-by: Scott Talbert <talbert@techie.net>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/net/usb/cdc_ether.c | 7 +++++++
+ drivers/net/usb/zaurus.c | 7 +++++++
+ 2 files changed, 14 insertions(+)
+
+--- a/drivers/net/usb/cdc_ether.c
++++ b/drivers/net/usb/cdc_ether.c
+@@ -570,6 +570,13 @@ static const struct usb_device_id produc
+ .driver_info = (unsigned long)&wwan_info,
+ },
+
++/* Logitech Harmony 900 - uses the pseudo-MDLM (BLAN) driver */
++{
++ USB_DEVICE_AND_INTERFACE_INFO(0x046d, 0xc11f, USB_CLASS_COMM,
++ USB_CDC_SUBCLASS_MDLM, USB_CDC_PROTO_NONE),
++ .driver_info = 0,
++},
++
+ /*
+ * WHITELIST!!!
+ *
+--- a/drivers/net/usb/zaurus.c
++++ b/drivers/net/usb/zaurus.c
+@@ -349,6 +349,13 @@ static const struct usb_device_id produc
+ ZAURUS_MASTER_INTERFACE,
+ .driver_info = OLYMPUS_MXL_INFO,
+ },
++
++/* Logitech Harmony 900 - uses the pseudo-MDLM (BLAN) driver */
++{
++ USB_DEVICE_AND_INTERFACE_INFO(0x046d, 0xc11f, USB_CLASS_COMM,
++ USB_CDC_SUBCLASS_MDLM, USB_CDC_PROTO_NONE),
++ .driver_info = (unsigned long) &bogus_mdlm_info,
++},
+ { }, // END
+ };
+ MODULE_DEVICE_TABLE(usb, products);
--- /dev/null
+From b94cfaf6685d691dc3fab023cf32f65e9b7be09c Mon Sep 17 00:00:00 2001
+From: David Howells <dhowells@redhat.com>
+Date: Thu, 23 Feb 2012 13:51:00 +0000
+Subject: NOMMU: Don't need to clear vm_mm when deleting a VMA
+
+From: David Howells <dhowells@redhat.com>
+
+commit b94cfaf6685d691dc3fab023cf32f65e9b7be09c upstream.
+
+Don't clear vm_mm in a deleted VMA as it's unnecessary and might
+conceivably break the filesystem or driver VMA close routine.
+
+Reported-by: Al Viro <viro@zeniv.linux.org.uk>
+Signed-off-by: David Howells <dhowells@redhat.com>
+Acked-by: Al Viro <viro@zeniv.linux.org.uk>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ mm/nommu.c | 2 --
+ 1 file changed, 2 deletions(-)
+
+--- a/mm/nommu.c
++++ b/mm/nommu.c
+@@ -780,8 +780,6 @@ static void delete_vma_from_mm(struct vm
+
+ if (vma->vm_next)
+ vma->vm_next->vm_prev = vma->vm_prev;
+-
+- vma->vm_mm = NULL;
+ }
+
+ /*
regset-prevent-null-pointer-reference-on-readonly-regsets.patch
regset-return-efault-not-eio-on-host-side-memory-fault.patch
mfd-fix-acpi-conflict-check.patch
+genirq-clear-action-thread_mask-if-irq_oneshot-is-not-set.patch
+arm-s3c24xx-dma-resume-regression-fix.patch
+move-logitech-harmony-900-from-cdc_ether-to-zaurus.patch
+alpha-fix-32-64-bit-bug-in-futex-support.patch
+mmc-sdhci-esdhc-imx-fix-for-mmc-cards-on-i.mx5.patch
+mm-memcg-correct-unregistring-of-events-attached-to-the-same-eventfd.patch
+nommu-don-t-need-to-clear-vm_mm-when-deleting-a-vma.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
