From eafe89fa99669d1946876f79415cdcf15b22d56d Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Wed, 7 Mar 2012 09:54:53 -0800 Subject: [PATCH] 3.0-stable patches added patches: alpha-fix-32-64-bit-bug-in-futex-support.patch arm-s3c24xx-dma-resume-regression-fix.patch genirq-clear-action-thread_mask-if-irq_oneshot-is-not-set.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 move-logitech-harmony-900-from-cdc_ether-to-zaurus.patch nommu-don-t-need-to-clear-vm_mm-when-deleting-a-vma.patch --- ...a-fix-32-64-bit-bug-in-futex-support.patch | 84 +++++++++++++++++ ...rm-s3c24xx-dma-resume-regression-fix.patch | 33 +++++++ ...hread_mask-if-irq_oneshot-is-not-set.patch | 94 +++++++++++++++++++ ...-events-attached-to-the-same-eventfd.patch | 71 ++++++++++++++ ...esdhc-imx-fix-for-mmc-cards-on-i.mx5.patch | 44 +++++++++ ...harmony-900-from-cdc_ether-to-zaurus.patch | 57 +++++++++++ ...d-to-clear-vm_mm-when-deleting-a-vma.patch | 33 +++++++ queue-3.0/series | 7 ++ 8 files changed, 423 insertions(+) create mode 100644 queue-3.0/alpha-fix-32-64-bit-bug-in-futex-support.patch create mode 100644 queue-3.0/arm-s3c24xx-dma-resume-regression-fix.patch create mode 100644 queue-3.0/genirq-clear-action-thread_mask-if-irq_oneshot-is-not-set.patch create mode 100644 queue-3.0/mm-memcg-correct-unregistring-of-events-attached-to-the-same-eventfd.patch create mode 100644 queue-3.0/mmc-sdhci-esdhc-imx-fix-for-mmc-cards-on-i.mx5.patch create mode 100644 queue-3.0/move-logitech-harmony-900-from-cdc_ether-to-zaurus.patch create mode 100644 queue-3.0/nommu-don-t-need-to-clear-vm_mm-when-deleting-a-vma.patch diff --git a/queue-3.0/alpha-fix-32-64-bit-bug-in-futex-support.patch b/queue-3.0/alpha-fix-32-64-bit-bug-in-futex-support.patch new file mode 100644 index 00000000000..b97bc06358e --- /dev/null +++ b/queue-3.0/alpha-fix-32-64-bit-bug-in-futex-support.patch @@ -0,0 +1,84 @@ +From 62aca403657fe30e5235c5331e9871e676d9ea0a Mon Sep 17 00:00:00 2001 +From: Andrew Morton +Date: Mon, 5 Mar 2012 14:59:19 -0800 +Subject: alpha: fix 32/64-bit bug in futex support + +From: Andrew Morton + +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 +: : 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 +Tested-by: Michael Cree +Acked-by: Phil Carmody +Cc: Richard Henderson +Cc: Michel Lespinasse +Cc: Ivan Kokshaysky +Reviewed-by: Matt Turner +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + 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; diff --git a/queue-3.0/arm-s3c24xx-dma-resume-regression-fix.patch b/queue-3.0/arm-s3c24xx-dma-resume-regression-fix.patch new file mode 100644 index 00000000000..1a976c2675a --- /dev/null +++ b/queue-3.0/arm-s3c24xx-dma-resume-regression-fix.patch @@ -0,0 +1,33 @@ +From e39d40c65dfd8390b50c03482ae9e289b8a8f351 Mon Sep 17 00:00:00 2001 +From: Gusakov Andrey +Date: Sat, 3 Mar 2012 07:32:36 +0900 +Subject: ARM: S3C24XX: DMA resume regression fix + +From: Gusakov Andrey + +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 +Reviewed-by: Heiko Stuebner +Signed-off-by: Kukjin Kim +Signed-off-by: Greg Kroah-Hartman + +--- + 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); + } + diff --git a/queue-3.0/genirq-clear-action-thread_mask-if-irq_oneshot-is-not-set.patch b/queue-3.0/genirq-clear-action-thread_mask-if-irq_oneshot-is-not-set.patch new file mode 100644 index 00000000000..a09ae84502e --- /dev/null +++ b/queue-3.0/genirq-clear-action-thread_mask-if-irq_oneshot-is-not-set.patch @@ -0,0 +1,94 @@ +From 52abb700e16a9aa4cbc03f3d7f80206cbbc80680 Mon Sep 17 00:00:00 2001 +From: Thomas Gleixner +Date: Tue, 6 Mar 2012 23:18:54 +0100 +Subject: genirq: Clear action->thread_mask if IRQ_ONESHOT is not set + +From: Thomas Gleixner + +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 +Reported-and-tested-by: Stefan Lippers-Hollmann +Signed-off-by: Thomas Gleixner +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + 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); diff --git a/queue-3.0/mm-memcg-correct-unregistring-of-events-attached-to-the-same-eventfd.patch b/queue-3.0/mm-memcg-correct-unregistring-of-events-attached-to-the-same-eventfd.patch new file mode 100644 index 00000000000..71ef045f4f8 --- /dev/null +++ b/queue-3.0/mm-memcg-correct-unregistring-of-events-attached-to-the-same-eventfd.patch @@ -0,0 +1,71 @@ +From 371528caec553785c37f73fa3926ea0de84f986f Mon Sep 17 00:00:00 2001 +From: Anton Vorontsov +Date: Fri, 24 Feb 2012 05:14:46 +0400 +Subject: mm: memcg: Correct unregistring of events attached to the same eventfd + +From: Anton Vorontsov + +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: [] mem_cgroup_usage_unregister_event+0x9c/0x1f0 + Pid: 574, comm: kworker/0:2 Not tainted 3.3.0-rc4+ #9 Bochs Bochs + RIP: 0010:[] [] mem_cgroup_usage_unregister_event+0x9c/0x1f0 + RSP: 0018:ffff88001d0b9d60 EFLAGS: 00010246 + Process kworker/0:2 (pid: 574, threadinfo ffff88001d0b8000, task ffff88001de91cc0) + Call Trace: + [] cgroup_event_remove+0x2b/0x60 + [] process_one_work+0x174/0x450 + [] worker_thread+0x123/0x2d0 + +Signed-off-by: Anton Vorontsov +Acked-by: KAMEZAWA Hiroyuki +Cc: Kirill A. Shutemov +Cc: Michal Hocko +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + 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); + } + diff --git a/queue-3.0/mmc-sdhci-esdhc-imx-fix-for-mmc-cards-on-i.mx5.patch b/queue-3.0/mmc-sdhci-esdhc-imx-fix-for-mmc-cards-on-i.mx5.patch new file mode 100644 index 00000000000..02bd0b4fe8d --- /dev/null +++ b/queue-3.0/mmc-sdhci-esdhc-imx-fix-for-mmc-cards-on-i.mx5.patch @@ -0,0 +1,44 @@ +From 5b6b0ad6e572b32a641116aaa5f897ffebe31e44 Mon Sep 17 00:00:00 2001 +From: Sascha Hauer +Date: Fri, 17 Feb 2012 11:51:49 +0100 +Subject: mmc: sdhci-esdhc-imx: fix for mmc cards on i.MX5 + +From: Sascha Hauer + +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 +Acked-by: Shawn Guo +Signed-off-by: Chris Ball +Signed-off-by: Greg Kroah-Hartman + +--- + 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); diff --git a/queue-3.0/move-logitech-harmony-900-from-cdc_ether-to-zaurus.patch b/queue-3.0/move-logitech-harmony-900-from-cdc_ether-to-zaurus.patch new file mode 100644 index 00000000000..ffa6d9755a5 --- /dev/null +++ b/queue-3.0/move-logitech-harmony-900-from-cdc_ether-to-zaurus.patch @@ -0,0 +1,57 @@ +From ee932bf9acb2e2c6a309e808000f24856330e3f9 Mon Sep 17 00:00:00 2001 +From: Scott Talbert +Date: Tue, 21 Feb 2012 13:06:00 +0000 +Subject: Move Logitech Harmony 900 from cdc_ether to zaurus + +From: Scott Talbert + +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 +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman + +--- + 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); diff --git a/queue-3.0/nommu-don-t-need-to-clear-vm_mm-when-deleting-a-vma.patch b/queue-3.0/nommu-don-t-need-to-clear-vm_mm-when-deleting-a-vma.patch new file mode 100644 index 00000000000..c584454eb22 --- /dev/null +++ b/queue-3.0/nommu-don-t-need-to-clear-vm_mm-when-deleting-a-vma.patch @@ -0,0 +1,33 @@ +From b94cfaf6685d691dc3fab023cf32f65e9b7be09c Mon Sep 17 00:00:00 2001 +From: David Howells +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 + +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 +Signed-off-by: David Howells +Acked-by: Al Viro +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + 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; + } + + /* diff --git a/queue-3.0/series b/queue-3.0/series index d90ed1ecad5..ce4f1e1f943 100644 --- a/queue-3.0/series +++ b/queue-3.0/series @@ -16,3 +16,10 @@ alsa-hda-always-set-hp-pin-in-unsol-handler-for-stac-idt-codecs.patch 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 -- 2.47.3