--- /dev/null
+From efb9e0f4f43780f0ae0c6428d66bd03e805c7539 Mon Sep 17 00:00:00 2001
+From: "Denis V. Lunev" <den@openvz.org>
+Date: Thu, 30 Jan 2014 15:20:30 +0400
+Subject: ata: enable quirk from jmicron JMB350 for JMB394
+
+From: "Denis V. Lunev" <den@openvz.org>
+
+commit efb9e0f4f43780f0ae0c6428d66bd03e805c7539 upstream.
+
+Without the patch the kernel generates the following error.
+
+ ata11.15: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
+ ata11.15: Port Multiplier vendor mismatch '0x197b' != '0x123'
+ ata11.15: PMP revalidation failed (errno=-19)
+ ata11.15: failed to recover PMP after 5 tries, giving up
+
+This patch helps to bypass this error and the device becomes
+functional.
+
+Signed-off-by: Denis V. Lunev <den@openvz.org>
+Signed-off-by: Tejun Heo <tj@kernel.org>
+Cc: <linux-ide@vger.kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/ata/libata-pmp.c | 7 +++++--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
+
+--- a/drivers/ata/libata-pmp.c
++++ b/drivers/ata/libata-pmp.c
+@@ -447,8 +447,11 @@ static void sata_pmp_quirks(struct ata_p
+ * otherwise. Don't try hard to recover it.
+ */
+ ap->pmp_link[ap->nr_pmp_links - 1].flags |= ATA_LFLAG_NO_RETRY;
+- } else if (vendor == 0x197b && devid == 0x2352) {
+- /* chip found in Thermaltake BlackX Duet, jmicron JMB350? */
++ } else if (vendor == 0x197b && (devid == 0x2352 || devid == 0x0325)) {
++ /*
++ * 0x2352: found in Thermaltake BlackX Duet, jmicron JMB350?
++ * 0x0325: jmicron JMB394.
++ */
+ ata_for_each_link(link, ap, EDGE) {
+ /* SRST breaks detection and disks get misclassified
+ * LPM disabled to avoid potential problems
--- /dev/null
+From 26e61e8939b1fe8729572dabe9a9e97d930dd4f6 Mon Sep 17 00:00:00 2001
+From: Peter Zijlstra <peterz@infradead.org>
+Date: Fri, 21 Feb 2014 16:03:12 +0100
+Subject: perf/x86: Fix event scheduling
+
+From: Peter Zijlstra <peterz@infradead.org>
+
+commit 26e61e8939b1fe8729572dabe9a9e97d930dd4f6 upstream.
+
+Vince "Super Tester" Weaver reported a new round of syscall fuzzing (Trinity) failures,
+with perf WARN_ON()s triggering. He also provided traces of the failures.
+
+This is I think the relevant bit:
+
+ > pec_1076_warn-2804 [000] d... 147.926153: x86_pmu_disable: x86_pmu_disable
+ > pec_1076_warn-2804 [000] d... 147.926153: x86_pmu_state: Events: {
+ > pec_1076_warn-2804 [000] d... 147.926156: x86_pmu_state: 0: state: .R config: ffffffffffffffff ( (null))
+ > pec_1076_warn-2804 [000] d... 147.926158: x86_pmu_state: 33: state: AR config: 0 (ffff88011ac99800)
+ > pec_1076_warn-2804 [000] d... 147.926159: x86_pmu_state: }
+ > pec_1076_warn-2804 [000] d... 147.926160: x86_pmu_state: n_events: 1, n_added: 0, n_txn: 1
+ > pec_1076_warn-2804 [000] d... 147.926161: x86_pmu_state: Assignment: {
+ > pec_1076_warn-2804 [000] d... 147.926162: x86_pmu_state: 0->33 tag: 1 config: 0 (ffff88011ac99800)
+ > pec_1076_warn-2804 [000] d... 147.926163: x86_pmu_state: }
+ > pec_1076_warn-2804 [000] d... 147.926166: collect_events: Adding event: 1 (ffff880119ec8800)
+
+So we add the insn:p event (fd[23]).
+
+At this point we should have:
+
+ n_events = 2, n_added = 1, n_txn = 1
+
+ > pec_1076_warn-2804 [000] d... 147.926170: collect_events: Adding event: 0 (ffff8800c9e01800)
+ > pec_1076_warn-2804 [000] d... 147.926172: collect_events: Adding event: 4 (ffff8800cbab2c00)
+
+We try and add the {BP,cycles,br_insn} group (fd[3], fd[4], fd[15]).
+These events are 0:cycles and 4:br_insn, the BP event isn't x86_pmu so
+that's not visible.
+
+ group_sched_in()
+ pmu->start_txn() /* nop - BP pmu */
+ event_sched_in()
+ event->pmu->add()
+
+So here we should end up with:
+
+ 0: n_events = 3, n_added = 2, n_txn = 2
+ 4: n_events = 4, n_added = 3, n_txn = 3
+
+But seeing the below state on x86_pmu_enable(), the must have failed,
+because the 0 and 4 events aren't there anymore.
+
+Looking at group_sched_in(), since the BP is the leader, its
+event_sched_in() must have succeeded, for otherwise we would not have
+seen the sibling adds.
+
+But since neither 0 or 4 are in the below state; their event_sched_in()
+must have failed; but I don't see why, the complete state: 0,0,1:p,4
+fits perfectly fine on a core2.
+
+However, since we try and schedule 4 it means the 0 event must have
+succeeded! Therefore the 4 event must have failed, its failure will
+have put group_sched_in() into the fail path, which will call:
+
+ event_sched_out()
+ event->pmu->del()
+
+on 0 and the BP event.
+
+Now x86_pmu_del() will reduce n_events; but it will not reduce n_added;
+giving what we see below:
+
+ n_event = 2, n_added = 2, n_txn = 2
+
+ > pec_1076_warn-2804 [000] d... 147.926177: x86_pmu_enable: x86_pmu_enable
+ > pec_1076_warn-2804 [000] d... 147.926177: x86_pmu_state: Events: {
+ > pec_1076_warn-2804 [000] d... 147.926179: x86_pmu_state: 0: state: .R config: ffffffffffffffff ( (null))
+ > pec_1076_warn-2804 [000] d... 147.926181: x86_pmu_state: 33: state: AR config: 0 (ffff88011ac99800)
+ > pec_1076_warn-2804 [000] d... 147.926182: x86_pmu_state: }
+ > pec_1076_warn-2804 [000] d... 147.926184: x86_pmu_state: n_events: 2, n_added: 2, n_txn: 2
+ > pec_1076_warn-2804 [000] d... 147.926184: x86_pmu_state: Assignment: {
+ > pec_1076_warn-2804 [000] d... 147.926186: x86_pmu_state: 0->33 tag: 1 config: 0 (ffff88011ac99800)
+ > pec_1076_warn-2804 [000] d... 147.926188: x86_pmu_state: 1->0 tag: 1 config: 1 (ffff880119ec8800)
+ > pec_1076_warn-2804 [000] d... 147.926188: x86_pmu_state: }
+ > pec_1076_warn-2804 [000] d... 147.926190: x86_pmu_enable: S0: hwc->idx: 33, hwc->last_cpu: 0, hwc->last_tag: 1 hwc->state: 0
+
+So the problem is that x86_pmu_del(), when called from a
+group_sched_in() that fails (for whatever reason), and without x86_pmu
+TXN support (because the leader is !x86_pmu), will corrupt the n_added
+state.
+
+Reported-and-Tested-by: Vince Weaver <vincent.weaver@maine.edu>
+Signed-off-by: Peter Zijlstra <peterz@infradead.org>
+Cc: Paul Mackerras <paulus@samba.org>
+Cc: Steven Rostedt <rostedt@goodmis.org>
+Cc: Stephane Eranian <eranian@google.com>
+Cc: Dave Jones <davej@redhat.com>
+Link: http://lkml.kernel.org/r/20140221150312.GF3104@twins.programming.kicks-ass.net
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kernel/cpu/perf_event.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/arch/x86/kernel/cpu/perf_event.c
++++ b/arch/x86/kernel/cpu/perf_event.c
+@@ -1165,6 +1165,9 @@ static void x86_pmu_del(struct perf_even
+ for (i = 0; i < cpuc->n_events; i++) {
+ if (event == cpuc->event_list[i]) {
+
++ if (i >= cpuc->n_events - cpuc->n_added)
++ --cpuc->n_added;
++
+ if (x86_pmu.put_event_constraints)
+ x86_pmu.put_event_constraints(cpuc, event);
+
--- /dev/null
+From f5295bd8ea8a65dc5eac608b151386314cb978f1 Mon Sep 17 00:00:00 2001
+From: Laurent Dufour <ldufour@linux.vnet.ibm.com>
+Date: Mon, 24 Feb 2014 17:30:55 +0100
+Subject: powerpc/crashdump : Fix page frame number check in copy_oldmem_page
+
+From: Laurent Dufour <ldufour@linux.vnet.ibm.com>
+
+commit f5295bd8ea8a65dc5eac608b151386314cb978f1 upstream.
+
+In copy_oldmem_page, the current check using max_pfn and min_low_pfn to
+decide if the page is backed or not, is not valid when the memory layout is
+not continuous.
+
+This happens when running as a QEMU/KVM guest, where RTAS is mapped higher
+in the memory. In that case max_pfn points to the end of RTAS, and a hole
+between the end of the kdump kernel and RTAS is not backed by PTEs. As a
+consequence, the kdump kernel is crashing in copy_oldmem_page when accessing
+in a direct way the pages in that hole.
+
+This fix relies on the memblock's service memblock_is_region_memory to
+check if the read page is part or not of the directly accessible memory.
+
+Signed-off-by: Laurent Dufour <ldufour@linux.vnet.ibm.com>
+Tested-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
+Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/powerpc/kernel/crash_dump.c | 8 +++++---
+ 1 file changed, 5 insertions(+), 3 deletions(-)
+
+--- a/arch/powerpc/kernel/crash_dump.c
++++ b/arch/powerpc/kernel/crash_dump.c
+@@ -108,17 +108,19 @@ ssize_t copy_oldmem_page(unsigned long p
+ size_t csize, unsigned long offset, int userbuf)
+ {
+ void *vaddr;
++ phys_addr_t paddr;
+
+ if (!csize)
+ return 0;
+
+ csize = min_t(size_t, csize, PAGE_SIZE);
++ paddr = pfn << PAGE_SHIFT;
+
+- if ((min_low_pfn < pfn) && (pfn < max_pfn)) {
+- vaddr = __va(pfn << PAGE_SHIFT);
++ if (memblock_is_region_memory(paddr, csize)) {
++ vaddr = __va(paddr);
+ csize = copy_oldmem_vaddr(vaddr, buf, csize, offset, userbuf);
+ } else {
+- vaddr = __ioremap(pfn << PAGE_SHIFT, PAGE_SIZE, 0);
++ vaddr = __ioremap(paddr, PAGE_SIZE, 0);
+ csize = copy_oldmem_vaddr(vaddr, buf, csize, offset, userbuf);
+ iounmap(vaddr);
+ }
--- /dev/null
+From 41dd03a94c7d408d2ef32530545097f7d1befe5c Mon Sep 17 00:00:00 2001
+From: Tony Breeds <tony@bakeyournoodle.com>
+Date: Thu, 20 Feb 2014 21:13:52 +1100
+Subject: powerpc/le: Ensure that the 'stop-self' RTAS token is handled correctly
+
+From: Tony Breeds <tony@bakeyournoodle.com>
+
+commit 41dd03a94c7d408d2ef32530545097f7d1befe5c upstream.
+
+Currently we're storing a host endian RTAS token in
+rtas_stop_self_args.token. We then pass that directly to rtas. This is
+fine on big endian however on little endian the token is not what we
+expect.
+
+This will typically result in hitting:
+ panic("Alas, I survived.\n");
+
+To fix this we always use the stop-self token in host order and always
+convert it to be32 before passing this to rtas.
+
+Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
+Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/powerpc/platforms/pseries/hotplug-cpu.c | 22 +++++++++++-----------
+ 1 file changed, 11 insertions(+), 11 deletions(-)
+
+--- a/arch/powerpc/platforms/pseries/hotplug-cpu.c
++++ b/arch/powerpc/platforms/pseries/hotplug-cpu.c
+@@ -34,12 +34,7 @@
+ #include "offline_states.h"
+
+ /* This version can't take the spinlock, because it never returns */
+-static struct rtas_args rtas_stop_self_args = {
+- .token = RTAS_UNKNOWN_SERVICE,
+- .nargs = 0,
+- .nret = 1,
+- .rets = &rtas_stop_self_args.args[0],
+-};
++static int rtas_stop_self_token = RTAS_UNKNOWN_SERVICE;
+
+ static DEFINE_PER_CPU(enum cpu_state_vals, preferred_offline_state) =
+ CPU_STATE_OFFLINE;
+@@ -92,15 +87,20 @@ void set_default_offline_state(int cpu)
+
+ static void rtas_stop_self(void)
+ {
+- struct rtas_args *args = &rtas_stop_self_args;
++ struct rtas_args args = {
++ .token = cpu_to_be32(rtas_stop_self_token),
++ .nargs = 0,
++ .nret = 1,
++ .rets = &args.args[0],
++ };
+
+ local_irq_disable();
+
+- BUG_ON(args->token == RTAS_UNKNOWN_SERVICE);
++ BUG_ON(rtas_stop_self_token == RTAS_UNKNOWN_SERVICE);
+
+ printk("cpu %u (hwid %u) Ready to die...\n",
+ smp_processor_id(), hard_smp_processor_id());
+- enter_rtas(__pa(args));
++ enter_rtas(__pa(&args));
+
+ panic("Alas, I survived.\n");
+ }
+@@ -383,10 +383,10 @@ static int __init pseries_cpu_hotplug_in
+ }
+ }
+
+- rtas_stop_self_args.token = rtas_token("stop-self");
++ rtas_stop_self_token = rtas_token("stop-self");
+ qcss_tok = rtas_token("query-cpu-stopped-state");
+
+- if (rtas_stop_self_args.token == RTAS_UNKNOWN_SERVICE ||
++ if (rtas_stop_self_token == RTAS_UNKNOWN_SERVICE ||
+ qcss_tok == RTAS_UNKNOWN_SERVICE) {
+ printk(KERN_INFO "CPU Hotplug not supported by firmware "
+ "- disabling.\n");
--- /dev/null
+From 9f9c47f00ce99329b1a82e2ac4f70f0fe3db549c Mon Sep 17 00:00:00 2001
+From: Tejun Heo <tj@kernel.org>
+Date: Mon, 3 Feb 2014 10:42:07 -0500
+Subject: sata_sil: apply MOD15WRITE quirk to TOSHIBA MK2561GSYN
+
+From: Tejun Heo <tj@kernel.org>
+
+commit 9f9c47f00ce99329b1a82e2ac4f70f0fe3db549c upstream.
+
+It's a bit odd to see a newer device showing mod15write; however, the
+reported behavior is highly consistent and other factors which could
+contribute seem to have been verified well enough. Also, both
+sata_sil itself and the drive are fairly outdated at this point making
+the risk of this change fairly low. It is possible, probably likely,
+that other drive models in the same family have the same problem;
+however, for now, let's just add the specific model which was tested.
+
+Signed-off-by: Tejun Heo <tj@kernel.org>
+Reported-by: matson <lists-matsonpa@luxsci.me>
+References: http://lkml.kernel.org/g/201401211912.s0LJCk7F015058@rs103.luxsci.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/ata/sata_sil.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/ata/sata_sil.c
++++ b/drivers/ata/sata_sil.c
+@@ -157,6 +157,7 @@ static const struct sil_drivelist {
+ { "ST380011ASL", SIL_QUIRK_MOD15WRITE },
+ { "ST3120022ASL", SIL_QUIRK_MOD15WRITE },
+ { "ST3160021ASL", SIL_QUIRK_MOD15WRITE },
++ { "TOSHIBA MK2561GSYN", SIL_QUIRK_MOD15WRITE },
+ { "Maxtor 4D060H3", SIL_QUIRK_UDMA5MAX },
+ { }
+ };
asoc-sta32x-fix-wrong-enum-for-limiter2-release-rate.patch
asoc-sta32x-fix-array-access-overflow.patch
asoc-wm8958-dsp-fix-firmware-block-loading.patch
+sunrpc-fix-races-in-xs_nospace.patch
+powerpc-le-ensure-that-the-stop-self-rtas-token-is-handled-correctly.patch
+powerpc-crashdump-fix-page-frame-number-check-in-copy_oldmem_page.patch
+perf-x86-fix-event-scheduling.patch
+ata-enable-quirk-from-jmicron-jmb350-for-jmb394.patch
+sata_sil-apply-mod15write-quirk-to-toshiba-mk2561gsyn.patch
--- /dev/null
+From 06ea0bfe6e6043cb56a78935a19f6f8ebc636226 Mon Sep 17 00:00:00 2001
+From: Trond Myklebust <trond.myklebust@primarydata.com>
+Date: Tue, 11 Feb 2014 09:15:54 -0500
+Subject: SUNRPC: Fix races in xs_nospace()
+
+From: Trond Myklebust <trond.myklebust@primarydata.com>
+
+commit 06ea0bfe6e6043cb56a78935a19f6f8ebc636226 upstream.
+
+When a send failure occurs due to the socket being out of buffer space,
+we call xs_nospace() in order to have the RPC task wait until the
+socket has drained enough to make it worth while trying again.
+The current patch fixes a race in which the socket is drained before
+we get round to setting up the machinery in xs_nospace(), and which
+is reported to cause hangs.
+
+Link: http://lkml.kernel.org/r/20140210170315.33dfc621@notabene.brown
+Fixes: a9a6b52ee1ba (SUNRPC: Don't start the retransmission timer...)
+Reported-by: Neil Brown <neilb@suse.com>
+Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ net/sunrpc/xprtsock.c | 6 +++++-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+--- a/net/sunrpc/xprtsock.c
++++ b/net/sunrpc/xprtsock.c
+@@ -501,6 +501,7 @@ static int xs_nospace(struct rpc_task *t
+ struct rpc_rqst *req = task->tk_rqstp;
+ struct rpc_xprt *xprt = req->rq_xprt;
+ struct sock_xprt *transport = container_of(xprt, struct sock_xprt, xprt);
++ struct sock *sk = transport->inet;
+ int ret = -EAGAIN;
+
+ dprintk("RPC: %5u xmit incomplete (%u left of %u)\n",
+@@ -518,7 +519,7 @@ static int xs_nospace(struct rpc_task *t
+ * window size
+ */
+ set_bit(SOCK_NOSPACE, &transport->sock->flags);
+- transport->inet->sk_write_pending++;
++ sk->sk_write_pending++;
+ /* ...and wait for more buffer space */
+ xprt_wait_for_buffer_space(task, xs_nospace_callback);
+ }
+@@ -528,6 +529,9 @@ static int xs_nospace(struct rpc_task *t
+ }
+
+ spin_unlock_bh(&xprt->transport_lock);
++
++ /* Race breaker in case memory is freed before above code is called */
++ sk->sk_write_space(sk);
+ return ret;
+ }
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
