--- /dev/null
+From a4a461a6df6c0481d5a3d61660ed97f5b539cf16 Mon Sep 17 00:00:00 2001
+From: Seth Heasley <seth.heasley@intel.com>
+Date: Mon, 10 Jan 2011 12:57:17 -0800
+Subject: ahci: AHCI mode SATA patch for Intel DH89xxCC DeviceIDs
+
+From: Seth Heasley <seth.heasley@intel.com>
+
+commit a4a461a6df6c0481d5a3d61660ed97f5b539cf16 upstream.
+
+This patch adds the AHCI-mode SATA DeviceID for the Intel DH89xxCC PCH.
+
+Signed-off-by: Seth Heasley <seth.heasley@intel.com>
+Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ 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, 0x2323), board_ahci }, /* DH89xxCC AHCI */
+
+ /* JMicron 360/1/3/5/6, match class to avoid IDE function */
+ { PCI_VENDOR_ID_JMICRON, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
--- /dev/null
+From 64a3903d0885879ba8706a8bcf71c5e3e7664db2 Mon Sep 17 00:00:00 2001
+From: Seth Heasley <seth.heasley@intel.com>
+Date: Fri, 11 Mar 2011 11:57:42 -0800
+Subject: ahci: AHCI mode SATA patch for Intel Patsburg SATA RAID controller
+
+From: Seth Heasley <seth.heasley@intel.com>
+
+commit 64a3903d0885879ba8706a8bcf71c5e3e7664db2 upstream.
+
+This patch adds an updated SATA RAID DeviceID for the Intel Patsburg PCH.
+
+Signed-off-by: Seth Heasley <seth.heasley@intel.com>
+Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ 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 */
--- /dev/null
+From 467b41c688c79d1b5e076fbdf082f9cd5d6a000c Mon Sep 17 00:00:00 2001
+From: Per Jessen <per@computer.org>
+Date: Tue, 8 Feb 2011 13:54:32 +0100
+Subject: ahci: recognize Marvell 88se9125 PCIe SATA 6.0 Gb/s controller
+
+From: Per Jessen <per@computer.org>
+
+commit 467b41c688c79d1b5e076fbdf082f9cd5d6a000c upstream.
+
+Recognize Marvell 88SE9125 PCIe SATA 6.0 Gb/s controller.
+
+Signed-off-by: Per Jessen <per@computer.org>
+Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/ata/ahci.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/ata/ahci.c
++++ b/drivers/ata/ahci.c
+@@ -380,6 +380,8 @@ static const struct pci_device_id ahci_p
+ { PCI_VDEVICE(MARVELL, 0x6121), board_ahci_mv }, /* 6121 */
+ { PCI_DEVICE(0x1b4b, 0x9123),
+ .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 */
--- /dev/null
+From 29963437a48475036353b95ab142bf199adb909e Mon Sep 17 00:00:00 2001
+From: Sean Hefty <sean.hefty@intel.com>
+Date: Wed, 23 Feb 2011 08:17:40 -0800
+Subject: IB/cm: Bump reference count on cm_id before invoking callback
+
+From: Sean Hefty <sean.hefty@intel.com>
+
+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 <sean.hefty@intel.com>
+Acked-by: Doug Ledford <dledford@redhat.com>
+Signed-off-by: Roland Dreier <roland@purestorage.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ 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;
--- /dev/null
+From 34d211a2d5df4984a35b18d8ccacbe1d10abb067 Mon Sep 17 00:00:00 2001
+From: Linus Torvalds <torvalds@linux-foundation.org>
+Date: Wed, 16 Mar 2011 08:04:07 -0700
+Subject: Increase OSF partition limit from 8 to 18
+
+From: Linus Torvalds <torvalds@linux-foundation.org>
+
+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 <mcree@orcon.net.nz>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ 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)
+ {
--- /dev/null
+From eb0e85e36b971ec31610eda7e3ff5c11c1c44785 Mon Sep 17 00:00:00 2001
+From: Tejun Heo <tj@kernel.org>
+Date: Thu, 24 Feb 2011 19:30:37 +0100
+Subject: libata: fix hotplug for drivers which don't implement LPM
+
+From: Tejun Heo <tj@kernel.org>
+
+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 <tj@kernel.org>
+Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ 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;
--- /dev/null
+From 6f3946b421395ff853bc0bcdab9c26b50ebbba8f Mon Sep 17 00:00:00 2001
+From: Steven J. Magnani <steve@digidescorp.com>
+Date: Thu, 10 Feb 2011 12:12:13 -0600
+Subject: microblaze: Fix /dev/zero corruption from __clear_user()
+
+From: Steven J. Magnani <steve@digidescorp.com>
+
+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 <steve@digidescorp.com>
+Acked-by: Michal Simek <monstr@monstr.eu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ 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;
+ }
--- /dev/null
+From 25ae21a10112875763c18b385624df713a288a05 Mon Sep 17 00:00:00 2001
+From: Sean Hefty <sean.hefty@intel.com>
+Date: Wed, 23 Feb 2011 08:11:32 -0800
+Subject: RDMA/cma: Fix crash in request handlers
+
+From: Sean Hefty <sean.hefty@intel.com>
+
+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 <sean.hefty@intel.com>
+Acked-by: Doug Ledford <dledford@redhat.com>
+Signed-off-by: Roland Dreier <roland@purestorage.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ 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)
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-recognize-marvell-88se9125-pcie-sata-6.0-gb-s-controller.patch
+ahci-ahci-mode-sata-patch-for-intel-dh89xxcc-deviceids.patch
+ahci-ahci-mode-sata-patch-for-intel-patsburg-sata-raid-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
--- /dev/null
+From 1d3e09a304e6c4e004ca06356578b171e8735d3c Mon Sep 17 00:00:00 2001
+From: Andreas Herrmann <andreas.herrmann3@amd.com>
+Date: Tue, 15 Mar 2011 15:31:37 +0100
+Subject: x86, quirk: Fix SB600 revision check
+
+From: Andreas Herrmann <andreas.herrmann3@amd.com>
+
+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 <f3d27b@gmail.com>
+Signed-off-by: Andreas Herrmann <andreas.herrmann3@amd.com>
+Cc: Andrew Morton <akpm@linux-foundation.org>
+LKML-Reference: <20110315143137.GD29499@alberich.amd.com>
+Signed-off-by: Ingo Molnar <mingo@elte.hu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ 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)
--- /dev/null
+From 0e00f7aed6af21fc09b2a94d28bc34e449bd3a53 Mon Sep 17 00:00:00 2001
+From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
+Date: Thu, 3 Mar 2011 11:01:37 -0500
+Subject: x86: stop_machine_text_poke() should issue sync_core()
+
+From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
+
+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 <mathieu.desnoyers@efficios.com>
+LKML-Reference: <20110303160137.GB1590@Krystal>
+Reviewed-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
+Cc: Arjan van de Ven <arjan@infradead.org>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Steven Rostedt <rostedt@goodmis.org>
+Cc: Andrew Morton <akpm@linux-foundation.org>
+Cc: Andi Kleen <andi@firstfloor.org>
+Cc: Frederic Weisbecker <fweisbec@gmail.com>
+Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ 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
+@@ -417,7 +417,12 @@ int alternatives_text_reserved(void *sta
+ return 1;
+ }
+ }
+-
++ /*
++ * 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;
+ }
+ #endif
projects / thirdparty / kernel / stable-queue.git / commitdiff
