From cb18dd13ba001419689fd024c71faf6e58afbd30 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Mon, 3 Mar 2014 17:50:10 -0800 Subject: [PATCH] 3.4-stable patches added patches: ata-enable-quirk-from-jmicron-jmb350-for-jmb394.patch perf-x86-fix-event-scheduling.patch powerpc-crashdump-fix-page-frame-number-check-in-copy_oldmem_page.patch powerpc-le-ensure-that-the-stop-self-rtas-token-is-handled-correctly.patch sata_sil-apply-mod15write-quirk-to-toshiba-mk2561gsyn.patch sunrpc-fix-races-in-xs_nospace.patch --- ...quirk-from-jmicron-jmb350-for-jmb394.patch | 44 +++++++ queue-3.4/perf-x86-fix-event-scheduling.patch | 116 ++++++++++++++++++ ...ame-number-check-in-copy_oldmem_page.patch | 56 +++++++++ ...self-rtas-token-is-handled-correctly.patch | 81 ++++++++++++ ...d15write-quirk-to-toshiba-mk2561gsyn.patch | 36 ++++++ queue-3.4/series | 6 + .../sunrpc-fix-races-in-xs_nospace.patch | 55 +++++++++ 7 files changed, 394 insertions(+) create mode 100644 queue-3.4/ata-enable-quirk-from-jmicron-jmb350-for-jmb394.patch create mode 100644 queue-3.4/perf-x86-fix-event-scheduling.patch create mode 100644 queue-3.4/powerpc-crashdump-fix-page-frame-number-check-in-copy_oldmem_page.patch create mode 100644 queue-3.4/powerpc-le-ensure-that-the-stop-self-rtas-token-is-handled-correctly.patch create mode 100644 queue-3.4/sata_sil-apply-mod15write-quirk-to-toshiba-mk2561gsyn.patch create mode 100644 queue-3.4/sunrpc-fix-races-in-xs_nospace.patch diff --git a/queue-3.4/ata-enable-quirk-from-jmicron-jmb350-for-jmb394.patch b/queue-3.4/ata-enable-quirk-from-jmicron-jmb350-for-jmb394.patch new file mode 100644 index 00000000000..96826346f30 --- /dev/null +++ b/queue-3.4/ata-enable-quirk-from-jmicron-jmb350-for-jmb394.patch @@ -0,0 +1,44 @@ +From efb9e0f4f43780f0ae0c6428d66bd03e805c7539 Mon Sep 17 00:00:00 2001 +From: "Denis V. Lunev" +Date: Thu, 30 Jan 2014 15:20:30 +0400 +Subject: ata: enable quirk from jmicron JMB350 for JMB394 + +From: "Denis V. Lunev" + +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 +Signed-off-by: Tejun Heo +Cc: +Signed-off-by: Greg Kroah-Hartman + +--- + 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 diff --git a/queue-3.4/perf-x86-fix-event-scheduling.patch b/queue-3.4/perf-x86-fix-event-scheduling.patch new file mode 100644 index 00000000000..3a6bec19a84 --- /dev/null +++ b/queue-3.4/perf-x86-fix-event-scheduling.patch @@ -0,0 +1,116 @@ +From 26e61e8939b1fe8729572dabe9a9e97d930dd4f6 Mon Sep 17 00:00:00 2001 +From: Peter Zijlstra +Date: Fri, 21 Feb 2014 16:03:12 +0100 +Subject: perf/x86: Fix event scheduling + +From: Peter Zijlstra + +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 +Signed-off-by: Peter Zijlstra +Cc: Paul Mackerras +Cc: Steven Rostedt +Cc: Stephane Eranian +Cc: Dave Jones +Link: http://lkml.kernel.org/r/20140221150312.GF3104@twins.programming.kicks-ass.net +Signed-off-by: Ingo Molnar +Signed-off-by: Greg Kroah-Hartman + +--- + 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); + diff --git a/queue-3.4/powerpc-crashdump-fix-page-frame-number-check-in-copy_oldmem_page.patch b/queue-3.4/powerpc-crashdump-fix-page-frame-number-check-in-copy_oldmem_page.patch new file mode 100644 index 00000000000..ea02d133ae2 --- /dev/null +++ b/queue-3.4/powerpc-crashdump-fix-page-frame-number-check-in-copy_oldmem_page.patch @@ -0,0 +1,56 @@ +From f5295bd8ea8a65dc5eac608b151386314cb978f1 Mon Sep 17 00:00:00 2001 +From: Laurent Dufour +Date: Mon, 24 Feb 2014 17:30:55 +0100 +Subject: powerpc/crashdump : Fix page frame number check in copy_oldmem_page + +From: Laurent Dufour + +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 +Tested-by: Mahesh Salgaonkar +Signed-off-by: Benjamin Herrenschmidt +Signed-off-by: Greg Kroah-Hartman + +--- + 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); + } diff --git a/queue-3.4/powerpc-le-ensure-that-the-stop-self-rtas-token-is-handled-correctly.patch b/queue-3.4/powerpc-le-ensure-that-the-stop-self-rtas-token-is-handled-correctly.patch new file mode 100644 index 00000000000..d58e93c1ee8 --- /dev/null +++ b/queue-3.4/powerpc-le-ensure-that-the-stop-self-rtas-token-is-handled-correctly.patch @@ -0,0 +1,81 @@ +From 41dd03a94c7d408d2ef32530545097f7d1befe5c Mon Sep 17 00:00:00 2001 +From: Tony Breeds +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 + +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 +Signed-off-by: Benjamin Herrenschmidt +Signed-off-by: Greg Kroah-Hartman + +--- + 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"); diff --git a/queue-3.4/sata_sil-apply-mod15write-quirk-to-toshiba-mk2561gsyn.patch b/queue-3.4/sata_sil-apply-mod15write-quirk-to-toshiba-mk2561gsyn.patch new file mode 100644 index 00000000000..ec9148cf876 --- /dev/null +++ b/queue-3.4/sata_sil-apply-mod15write-quirk-to-toshiba-mk2561gsyn.patch @@ -0,0 +1,36 @@ +From 9f9c47f00ce99329b1a82e2ac4f70f0fe3db549c Mon Sep 17 00:00:00 2001 +From: Tejun Heo +Date: Mon, 3 Feb 2014 10:42:07 -0500 +Subject: sata_sil: apply MOD15WRITE quirk to TOSHIBA MK2561GSYN + +From: Tejun Heo + +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 +Reported-by: matson +References: http://lkml.kernel.org/g/201401211912.s0LJCk7F015058@rs103.luxsci.com +Signed-off-by: Greg Kroah-Hartman + +--- + 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 }, + { } + }; diff --git a/queue-3.4/series b/queue-3.4/series index ecb658264dc..ddc0e2e57be 100644 --- a/queue-3.4/series +++ b/queue-3.4/series @@ -21,3 +21,9 @@ asoc-wm8770-fix-wrong-number-of-enum-items.patch 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 diff --git a/queue-3.4/sunrpc-fix-races-in-xs_nospace.patch b/queue-3.4/sunrpc-fix-races-in-xs_nospace.patch new file mode 100644 index 00000000000..f3945cc1bd1 --- /dev/null +++ b/queue-3.4/sunrpc-fix-races-in-xs_nospace.patch @@ -0,0 +1,55 @@ +From 06ea0bfe6e6043cb56a78935a19f6f8ebc636226 Mon Sep 17 00:00:00 2001 +From: Trond Myklebust +Date: Tue, 11 Feb 2014 09:15:54 -0500 +Subject: SUNRPC: Fix races in xs_nospace() + +From: Trond Myklebust + +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 +Signed-off-by: Trond Myklebust +Signed-off-by: Greg Kroah-Hartman + +--- + 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; + } + -- 2.47.3