From: Greg Kroah-Hartman Date: Wed, 16 Mar 2011 20:33:33 +0000 (-0700) Subject: .38 patches X-Git-Tag: v2.6.37.5~12 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=8a2c11bbc50b008cff90c0547a93f034f11cd5ab;p=thirdparty%2Fkernel%2Fstable-queue.git .38 patches --- diff --git a/queue-2.6.38/ahci-ahci-mode-sata-patch-for-intel-patsburg-sata-raid-controller.patch b/queue-2.6.38/ahci-ahci-mode-sata-patch-for-intel-patsburg-sata-raid-controller.patch new file mode 100644 index 00000000000..7217f0da666 --- /dev/null +++ b/queue-2.6.38/ahci-ahci-mode-sata-patch-for-intel-patsburg-sata-raid-controller.patch @@ -0,0 +1,29 @@ +From 64a3903d0885879ba8706a8bcf71c5e3e7664db2 Mon Sep 17 00:00:00 2001 +From: Seth Heasley +Date: Fri, 11 Mar 2011 11:57:42 -0800 +Subject: ahci: AHCI mode SATA patch for Intel Patsburg SATA RAID controller + +From: Seth Heasley + +commit 64a3903d0885879ba8706a8bcf71c5e3e7664db2 upstream. + +This patch adds an updated SATA RAID DeviceID for the Intel Patsburg PCH. + +Signed-off-by: Seth Heasley +Signed-off-by: Jeff Garzik +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/ata/ahci.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/ata/ahci.c ++++ b/drivers/ata/ahci.c +@@ -260,6 +260,7 @@ static const struct pci_device_id ahci_p + { PCI_VDEVICE(INTEL, 0x1d02), board_ahci }, /* PBG AHCI */ + { PCI_VDEVICE(INTEL, 0x1d04), board_ahci }, /* PBG RAID */ + { PCI_VDEVICE(INTEL, 0x1d06), board_ahci }, /* PBG RAID */ ++ { PCI_VDEVICE(INTEL, 0x2826), board_ahci }, /* PBG RAID */ + { PCI_VDEVICE(INTEL, 0x2323), board_ahci }, /* DH89xxCC AHCI */ + + /* JMicron 360/1/3/5/6, match class to avoid IDE function */ diff --git a/queue-2.6.38/ahci-recognize-marvell-88se9125-pcie-sata-6.0-gb-s-controller.patch b/queue-2.6.38/ahci-recognize-marvell-88se9125-pcie-sata-6.0-gb-s-controller.patch new file mode 100644 index 00000000000..245989799d1 --- /dev/null +++ b/queue-2.6.38/ahci-recognize-marvell-88se9125-pcie-sata-6.0-gb-s-controller.patch @@ -0,0 +1,30 @@ +From 467b41c688c79d1b5e076fbdf082f9cd5d6a000c Mon Sep 17 00:00:00 2001 +From: Per Jessen +Date: Tue, 8 Feb 2011 13:54:32 +0100 +Subject: ahci: recognize Marvell 88se9125 PCIe SATA 6.0 Gb/s controller + +From: Per Jessen + +commit 467b41c688c79d1b5e076fbdf082f9cd5d6a000c upstream. + +Recognize Marvell 88SE9125 PCIe SATA 6.0 Gb/s controller. + +Signed-off-by: Per Jessen +Signed-off-by: Jeff Garzik +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/ata/ahci.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/drivers/ata/ahci.c ++++ b/drivers/ata/ahci.c +@@ -384,6 +384,8 @@ static const struct pci_device_id ahci_p + .class = PCI_CLASS_STORAGE_SATA_AHCI, + .class_mask = 0xffffff, + .driver_data = board_ahci_yes_fbs }, /* 88se9128 */ ++ { PCI_DEVICE(0x1b4b, 0x9125), ++ .driver_data = board_ahci_yes_fbs }, /* 88se9125 */ + + /* Promise */ + { PCI_VDEVICE(PROMISE, 0x3f20), board_ahci }, /* PDC42819 */ diff --git a/queue-2.6.38/ib-cm-bump-reference-count-on-cm_id-before-invoking-callback.patch b/queue-2.6.38/ib-cm-bump-reference-count-on-cm_id-before-invoking-callback.patch new file mode 100644 index 00000000000..38694c2ab96 --- /dev/null +++ b/queue-2.6.38/ib-cm-bump-reference-count-on-cm_id-before-invoking-callback.patch @@ -0,0 +1,42 @@ +From 29963437a48475036353b95ab142bf199adb909e Mon Sep 17 00:00:00 2001 +From: Sean Hefty +Date: Wed, 23 Feb 2011 08:17:40 -0800 +Subject: IB/cm: Bump reference count on cm_id before invoking callback + +From: Sean Hefty + +commit 29963437a48475036353b95ab142bf199adb909e upstream. + +When processing a SIDR REQ, the ib_cm allocates a new cm_id. The +refcount of the cm_id is initialized to 1. However, cm_process_work +will decrement the refcount after invoking all callbacks. The result +is that the cm_id will end up with refcount set to 0 by the end of the +sidr req handler. + +If a user tries to destroy the cm_id, the destruction will proceed, +under the incorrect assumption that no other threads are referencing +the cm_id. This can lead to a crash when the cm callback thread tries +to access the cm_id. + +This problem was noticed as part of a larger investigation with kernel +crashes in the rdma_cm when running on a real time OS. + +Signed-off-by: Sean Hefty +Acked-by: Doug Ledford +Signed-off-by: Roland Dreier +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/infiniband/core/cm.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/infiniband/core/cm.c ++++ b/drivers/infiniband/core/cm.c +@@ -2989,6 +2989,7 @@ static int cm_sidr_req_handler(struct cm + goto out; /* No match. */ + } + atomic_inc(&cur_cm_id_priv->refcount); ++ atomic_inc(&cm_id_priv->refcount); + spin_unlock_irq(&cm.lock); + + cm_id_priv->id.cm_handler = cur_cm_id_priv->id.cm_handler; diff --git a/queue-2.6.38/increase-osf-partition-limit-from-8-to-18.patch b/queue-2.6.38/increase-osf-partition-limit-from-8-to-18.patch new file mode 100644 index 00000000000..d9a868ec483 --- /dev/null +++ b/queue-2.6.38/increase-osf-partition-limit-from-8-to-18.patch @@ -0,0 +1,38 @@ +From 34d211a2d5df4984a35b18d8ccacbe1d10abb067 Mon Sep 17 00:00:00 2001 +From: Linus Torvalds +Date: Wed, 16 Mar 2011 08:04:07 -0700 +Subject: Increase OSF partition limit from 8 to 18 + +From: Linus Torvalds + +commit 34d211a2d5df4984a35b18d8ccacbe1d10abb067 upstream. + +It turns out that while a maximum of 8 partitions may be what people +"should" have had, you can actually fit up to 18 entries(*) in a sector. + +And some people clearly were taking advantage of that, like Michael +Cree, who had ten partitions on one of his OSF disks. + +(*) The OSF partition data starts at byte offset 64 in the first sector, + and the array of 16-byte partition entries start at offset 148 in + the on-disk partition structure. + +Reported-by: Michael Cree +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + fs/partitions/osf.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/fs/partitions/osf.c ++++ b/fs/partitions/osf.c +@@ -10,7 +10,7 @@ + #include "check.h" + #include "osf.h" + +-#define MAX_OSF_PARTITIONS 8 ++#define MAX_OSF_PARTITIONS 18 + + int osf_partition(struct parsed_partitions *state) + { diff --git a/queue-2.6.38/libata-fix-hotplug-for-drivers-which-don-t-implement-lpm.patch b/queue-2.6.38/libata-fix-hotplug-for-drivers-which-don-t-implement-lpm.patch new file mode 100644 index 00000000000..6d9c50e3d4a --- /dev/null +++ b/queue-2.6.38/libata-fix-hotplug-for-drivers-which-don-t-implement-lpm.patch @@ -0,0 +1,39 @@ +From eb0e85e36b971ec31610eda7e3ff5c11c1c44785 Mon Sep 17 00:00:00 2001 +From: Tejun Heo +Date: Thu, 24 Feb 2011 19:30:37 +0100 +Subject: libata: fix hotplug for drivers which don't implement LPM + +From: Tejun Heo + +commit eb0e85e36b971ec31610eda7e3ff5c11c1c44785 upstream. + +ata_eh_analyze_serror() suppresses hotplug notifications if LPM is +being used because LPM generates spurious hotplug events. It compared +whether link->lpm_policy was different from ATA_LPM_MAX_POWER to +determine whether LPM is enabled; however, this is incorrect as for +drivers which don't implement LPM, lpm_policy is always +ATA_LPM_UNKNOWN. This disabled hotplug detection for all drivers +which don't implement LPM. + +Fix it by comparing whether lpm_policy is greater than +ATA_LPM_MAX_POWER. + +Signed-off-by: Tejun Heo +Signed-off-by: Jeff Garzik +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/ata/libata-eh.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/ata/libata-eh.c ++++ b/drivers/ata/libata-eh.c +@@ -1618,7 +1618,7 @@ static void ata_eh_analyze_serror(struct + * host links. For disabled PMP links, only N bit is + * considered as X bit is left at 1 for link plugging. + */ +- if (link->lpm_policy != ATA_LPM_MAX_POWER) ++ if (link->lpm_policy > ATA_LPM_MAX_POWER) + hotplug_mask = 0; /* hotplug doesn't work w/ LPM */ + else if (!(link->flags & ATA_LFLAG_DISABLED) || ata_is_host_link(link)) + hotplug_mask = SERR_PHYRDY_CHG | SERR_DEV_XCHG; diff --git a/queue-2.6.38/microblaze-fix-dev-zero-corruption-from-__clear_user.patch b/queue-2.6.38/microblaze-fix-dev-zero-corruption-from-__clear_user.patch new file mode 100644 index 00000000000..c6a0037cd2e --- /dev/null +++ b/queue-2.6.38/microblaze-fix-dev-zero-corruption-from-__clear_user.patch @@ -0,0 +1,50 @@ +From 6f3946b421395ff853bc0bcdab9c26b50ebbba8f Mon Sep 17 00:00:00 2001 +From: Steven J. Magnani +Date: Thu, 10 Feb 2011 12:12:13 -0600 +Subject: microblaze: Fix /dev/zero corruption from __clear_user() + +From: Steven J. Magnani + +commit 6f3946b421395ff853bc0bcdab9c26b50ebbba8f upstream. + +A userland read of more than PAGE_SIZE bytes from /dev/zero results in +(a) not all of the bytes returned being zero, and +(b) memory corruption due to zeroing of bytes beyond the user buffer. + +This is caused by improper constraints on the assembly __clear_user function. +The constrints don't indicate to the compiler that the pointer argument is +modified. Since the function is inline, this results in double-incrementing +of the pointer when __clear_user() is invoked through a multi-page read() of +/dev/zero. + +Signed-off-by: Steven J. Magnani +Acked-by: Michal Simek +Signed-off-by: Greg Kroah-Hartman + +--- + arch/microblaze/include/asm/uaccess.h | 8 ++++---- + 1 file changed, 4 insertions(+), 4 deletions(-) + +--- a/arch/microblaze/include/asm/uaccess.h ++++ b/arch/microblaze/include/asm/uaccess.h +@@ -120,16 +120,16 @@ static inline unsigned long __must_check + { + /* normal memset with two words to __ex_table */ + __asm__ __volatile__ ( \ +- "1: sb r0, %2, r0;" \ ++ "1: sb r0, %1, r0;" \ + " addik %0, %0, -1;" \ + " bneid %0, 1b;" \ +- " addik %2, %2, 1;" \ ++ " addik %1, %1, 1;" \ + "2: " \ + __EX_TABLE_SECTION \ + ".word 1b,2b;" \ + ".previous;" \ +- : "=r"(n) \ +- : "0"(n), "r"(to) ++ : "=r"(n), "=r"(to) \ ++ : "0"(n), "1"(to) + ); + return n; + } diff --git a/queue-2.6.38/rdma-cma-fix-crash-in-request-handlers.patch b/queue-2.6.38/rdma-cma-fix-crash-in-request-handlers.patch new file mode 100644 index 00000000000..a007f5a828b --- /dev/null +++ b/queue-2.6.38/rdma-cma-fix-crash-in-request-handlers.patch @@ -0,0 +1,131 @@ +From 25ae21a10112875763c18b385624df713a288a05 Mon Sep 17 00:00:00 2001 +From: Sean Hefty +Date: Wed, 23 Feb 2011 08:11:32 -0800 +Subject: RDMA/cma: Fix crash in request handlers + +From: Sean Hefty + +commit 25ae21a10112875763c18b385624df713a288a05 upstream. + +Doug Ledford and Red Hat reported a crash when running the rdma_cm on +a real-time OS. The crash has the following call trace: + + cm_process_work + cma_req_handler + cma_disable_callback + rdma_create_id + kzalloc + init_completion + cma_get_net_info + cma_save_net_info + cma_any_addr + cma_zero_addr + rdma_translate_ip + rdma_copy_addr + cma_acquire_dev + rdma_addr_get_sgid + ib_find_cached_gid + cma_attach_to_dev + ucma_event_handler + kzalloc + ib_copy_ah_attr_to_user + cma_comp + +[ preempted ] + + cma_write + copy_from_user + ucma_destroy_id + copy_from_user + _ucma_find_context + ucma_put_ctx + ucma_free_ctx + rdma_destroy_id + cma_exch + cma_cancel_operation + rdma_node_get_transport + + rt_mutex_slowunlock + bad_area_nosemaphore + oops_enter + +They were able to reproduce the crash multiple times with the +following details: + + Crash seems to always happen on the: + mutex_unlock(&conn_id->handler_mutex); + as conn_id looks to have been freed during this code path. + +An examination of the code shows that a race exists in the request +handlers. When a new connection request is received, the rdma_cm +allocates a new connection identifier. This identifier has a single +reference count on it. If a user calls rdma_destroy_id() from another +thread after receiving a callback, rdma_destroy_id will proceed to +destroy the id and free the associated memory. However, the request +handlers may still be in the process of running. When control returns +to the request handlers, they can attempt to access the newly created +identifiers. + +Fix this by holding a reference on the newly created rdma_cm_id until +the request handler is through accessing it. + +Signed-off-by: Sean Hefty +Acked-by: Doug Ledford +Signed-off-by: Roland Dreier +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/infiniband/core/cma.c | 15 +++++++++++++++ + 1 file changed, 15 insertions(+) + +--- a/drivers/infiniband/core/cma.c ++++ b/drivers/infiniband/core/cma.c +@@ -1210,6 +1210,11 @@ static int cma_req_handler(struct ib_cm_ + cm_id->context = conn_id; + cm_id->cm_handler = cma_ib_handler; + ++ /* ++ * Protect against the user destroying conn_id from another thread ++ * until we're done accessing it. ++ */ ++ atomic_inc(&conn_id->refcount); + ret = conn_id->id.event_handler(&conn_id->id, &event); + if (!ret) { + /* +@@ -1222,8 +1227,10 @@ static int cma_req_handler(struct ib_cm_ + ib_send_cm_mra(cm_id, CMA_CM_MRA_SETTING, NULL, 0); + mutex_unlock(&lock); + mutex_unlock(&conn_id->handler_mutex); ++ cma_deref_id(conn_id); + goto out; + } ++ cma_deref_id(conn_id); + + /* Destroy the CM ID by returning a non-zero value. */ + conn_id->cm_id.ib = NULL; +@@ -1425,17 +1432,25 @@ static int iw_conn_req_handler(struct iw + event.param.conn.private_data_len = iw_event->private_data_len; + event.param.conn.initiator_depth = attr.max_qp_init_rd_atom; + event.param.conn.responder_resources = attr.max_qp_rd_atom; ++ ++ /* ++ * Protect against the user destroying conn_id from another thread ++ * until we're done accessing it. ++ */ ++ atomic_inc(&conn_id->refcount); + ret = conn_id->id.event_handler(&conn_id->id, &event); + if (ret) { + /* User wants to destroy the CM ID */ + conn_id->cm_id.iw = NULL; + cma_exch(conn_id, CMA_DESTROYING); + mutex_unlock(&conn_id->handler_mutex); ++ cma_deref_id(conn_id); + rdma_destroy_id(&conn_id->id); + goto out; + } + + mutex_unlock(&conn_id->handler_mutex); ++ cma_deref_id(conn_id); + + out: + if (dev) diff --git a/queue-2.6.38/series b/queue-2.6.38/series index 7005341f1a9..3344f9bc268 100644 --- a/queue-2.6.38/series +++ b/queue-2.6.38/series @@ -3,3 +3,12 @@ vfs-fix-the-nfs-sillyrename-regression-in-kernel-2.6.38.patch ftrace-fix-memory-leak-with-function-graph-and-cpu-hotplug.patch x86-fix-panic-when-handling-mem-invalid-param.patch x86-emit-mem-nopentium-ignored-warning-when-not-supported.patch +ahci-ahci-mode-sata-patch-for-intel-patsburg-sata-raid-controller.patch +ahci-recognize-marvell-88se9125-pcie-sata-6.0-gb-s-controller.patch +libata-fix-hotplug-for-drivers-which-don-t-implement-lpm.patch +rdma-cma-fix-crash-in-request-handlers.patch +increase-osf-partition-limit-from-8-to-18.patch +ib-cm-bump-reference-count-on-cm_id-before-invoking-callback.patch +x86-quirk-fix-sb600-revision-check.patch +microblaze-fix-dev-zero-corruption-from-__clear_user.patch +x86-stop_machine_text_poke-should-issue-sync_core.patch diff --git a/queue-2.6.38/x86-quirk-fix-sb600-revision-check.patch b/queue-2.6.38/x86-quirk-fix-sb600-revision-check.patch new file mode 100644 index 00000000000..8de56eb801a --- /dev/null +++ b/queue-2.6.38/x86-quirk-fix-sb600-revision-check.patch @@ -0,0 +1,49 @@ +From 1d3e09a304e6c4e004ca06356578b171e8735d3c Mon Sep 17 00:00:00 2001 +From: Andreas Herrmann +Date: Tue, 15 Mar 2011 15:31:37 +0100 +Subject: x86, quirk: Fix SB600 revision check + +From: Andreas Herrmann + +commit 1d3e09a304e6c4e004ca06356578b171e8735d3c upstream. + +Commit 7f74f8f28a2bd9db9404f7d364e2097a0c42cc12 +(x86 quirk: Fix polarity for IRQ0 pin2 override on SB800 +systems) introduced a regression. It removed some SB600 specific +code to determine the revision ID without adapting a +corresponding revision ID check for SB600. + +See this mail thread: + + http://marc.info/?l=linux-kernel&m=129980296006380&w=2 + +This patch adapts the corresponding check to cover all SB600 +revisions. + +Tested-by: Wang Lei +Signed-off-by: Andreas Herrmann +Cc: Andrew Morton +LKML-Reference: <20110315143137.GD29499@alberich.amd.com> +Signed-off-by: Ingo Molnar +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kernel/early-quirks.c | 7 ++++++- + 1 file changed, 6 insertions(+), 1 deletion(-) + +--- a/arch/x86/kernel/early-quirks.c ++++ b/arch/x86/kernel/early-quirks.c +@@ -159,7 +159,12 @@ static void __init ati_bugs_contd(int nu + if (rev >= 0x40) + acpi_fix_pin2_polarity = 1; + +- if (rev > 0x13) ++ /* ++ * SB600: revisions 0x11, 0x12, 0x13, 0x14, ... ++ * SB700: revisions 0x39, 0x3a, ... ++ * SB800: revisions 0x40, 0x41, ... ++ */ ++ if (rev >= 0x39) + return; + + if (acpi_use_timer_override) diff --git a/queue-2.6.38/x86-stop_machine_text_poke-should-issue-sync_core.patch b/queue-2.6.38/x86-stop_machine_text_poke-should-issue-sync_core.patch new file mode 100644 index 00000000000..8efcb6386ef --- /dev/null +++ b/queue-2.6.38/x86-stop_machine_text_poke-should-issue-sync_core.patch @@ -0,0 +1,70 @@ +From 0e00f7aed6af21fc09b2a94d28bc34e449bd3a53 Mon Sep 17 00:00:00 2001 +From: Mathieu Desnoyers +Date: Thu, 3 Mar 2011 11:01:37 -0500 +Subject: x86: stop_machine_text_poke() should issue sync_core() + +From: Mathieu Desnoyers + +commit 0e00f7aed6af21fc09b2a94d28bc34e449bd3a53 upstream. + +Intel Archiecture Software Developer's Manual section 7.1.3 specifies that a +core serializing instruction such as "cpuid" should be executed on _each_ core +before the new instruction is made visible. + +Failure to do so can lead to unspecified behavior (Intel XMC erratas include +General Protection Fault in the list), so we should avoid this at all cost. + +This problem can affect modified code executed by interrupt handlers after +interrupt are re-enabled at the end of stop_machine, because no core serializing +instruction is executed between the code modification and the moment interrupts +are reenabled. + +Because stop_machine_text_poke performs the text modification from the first CPU +decrementing stop_machine_first, modified code executed in thread context is +also affected by this problem. To explain why, we have to split the CPUs in two +categories: the CPU that initiates the text modification (calls text_poke_smp) +and all the others. The scheduler, executed on all other CPUs after +stop_machine, issues an "iret" core serializing instruction, and therefore +handles core serialization for all these CPUs. However, the text modification +initiator can continue its execution on the same thread and access the modified +text without any scheduler call. Given that the CPU that initiates the code +modification is not guaranteed to be the one actually performing the code +modification, it falls into the XMC errata. + +Q: Isn't this executed from an IPI handler, which will return with IRET (a + serializing instruction) anyway? +A: No, now stop_machine uses per-cpu workqueue, so that handler will be + executed from worker threads. There is no iret anymore. + +Signed-off-by: Mathieu Desnoyers +LKML-Reference: <20110303160137.GB1590@Krystal> +Reviewed-by: Masami Hiramatsu +Cc: Arjan van de Ven +Cc: Peter Zijlstra +Cc: Steven Rostedt +Cc: Andrew Morton +Cc: Andi Kleen +Cc: Frederic Weisbecker +Signed-off-by: H. Peter Anvin +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kernel/alternative.c | 7 ++++++- + 1 file changed, 6 insertions(+), 1 deletion(-) + +--- a/arch/x86/kernel/alternative.c ++++ b/arch/x86/kernel/alternative.c +@@ -620,7 +620,12 @@ static int __kprobes stop_machine_text_p + flush_icache_range((unsigned long)p->addr, + (unsigned long)p->addr + p->len); + } +- ++ /* ++ * Intel Archiecture Software Developer's Manual section 7.1.3 specifies ++ * that a core serializing instruction such as "cpuid" should be ++ * executed on _each_ core before the new instruction is made visible. ++ */ ++ sync_core(); + return 0; + } +