From 57b79c72d68f92fbbef6cc65ca3526cfbe1c461b Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Mon, 3 Mar 2014 17:47:51 -0800 Subject: [PATCH] 3.10-stable patches added patches: ahci-disable-ncq-on-samsung-pci-e-ssds-on-macbooks.patch ata-enable-quirk-from-jmicron-jmb350-for-jmb394.patch cpufreq-powernow-k8-initialize-per-cpu-data-structures-properly.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 x86-dma-mapping-fix-gfp_atomic-macro-usage.patch --- ...cq-on-samsung-pci-e-ssds-on-macbooks.patch | 59 +++++++++ ...quirk-from-jmicron-jmb350-for-jmb394.patch | 44 +++++++ ...ize-per-cpu-data-structures-properly.patch | 78 ++++++++++++ .../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.10/series | 9 ++ .../sunrpc-fix-races-in-xs_nospace.patch | 55 +++++++++ ...a-mapping-fix-gfp_atomic-macro-usage.patch | 35 ++++++ 10 files changed, 569 insertions(+) create mode 100644 queue-3.10/ahci-disable-ncq-on-samsung-pci-e-ssds-on-macbooks.patch create mode 100644 queue-3.10/ata-enable-quirk-from-jmicron-jmb350-for-jmb394.patch create mode 100644 queue-3.10/cpufreq-powernow-k8-initialize-per-cpu-data-structures-properly.patch create mode 100644 queue-3.10/perf-x86-fix-event-scheduling.patch create mode 100644 queue-3.10/powerpc-crashdump-fix-page-frame-number-check-in-copy_oldmem_page.patch create mode 100644 queue-3.10/powerpc-le-ensure-that-the-stop-self-rtas-token-is-handled-correctly.patch create mode 100644 queue-3.10/sata_sil-apply-mod15write-quirk-to-toshiba-mk2561gsyn.patch create mode 100644 queue-3.10/sunrpc-fix-races-in-xs_nospace.patch create mode 100644 queue-3.10/x86-dma-mapping-fix-gfp_atomic-macro-usage.patch diff --git a/queue-3.10/ahci-disable-ncq-on-samsung-pci-e-ssds-on-macbooks.patch b/queue-3.10/ahci-disable-ncq-on-samsung-pci-e-ssds-on-macbooks.patch new file mode 100644 index 00000000000..42ba8d931b0 --- /dev/null +++ b/queue-3.10/ahci-disable-ncq-on-samsung-pci-e-ssds-on-macbooks.patch @@ -0,0 +1,59 @@ +From 67809f85d31eac600f6b28defa5386c9d2a13b1d Mon Sep 17 00:00:00 2001 +From: Levente Kurusa +Date: Tue, 18 Feb 2014 10:22:17 -0500 +Subject: ahci: disable NCQ on Samsung pci-e SSDs on macbooks + +From: Levente Kurusa + +commit 67809f85d31eac600f6b28defa5386c9d2a13b1d upstream. + +Samsung's pci-e SSDs with device ID 0x1600 which are found on some +macbooks time out on NCQ commands. Blacklist NCQ on the device so +that the affected machines can at least boot. + +Original-patch-by: Levente Kurusa +Signed-off-by: Tejun Heo +Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=60731 +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/ata/ahci.c | 14 ++++++++++++++ + 1 file changed, 14 insertions(+) + +--- a/drivers/ata/ahci.c ++++ b/drivers/ata/ahci.c +@@ -61,6 +61,7 @@ enum board_ids { + /* board IDs by feature in alphabetical order */ + board_ahci, + board_ahci_ign_iferr, ++ board_ahci_noncq, + board_ahci_nosntf, + board_ahci_yes_fbs, + +@@ -119,6 +120,13 @@ static const struct ata_port_info ahci_p + .udma_mask = ATA_UDMA6, + .port_ops = &ahci_ops, + }, ++ [board_ahci_noncq] = { ++ AHCI_HFLAGS (AHCI_HFLAG_NO_NCQ), ++ .flags = AHCI_FLAG_COMMON, ++ .pio_mask = ATA_PIO4, ++ .udma_mask = ATA_UDMA6, ++ .port_ops = &ahci_ops, ++ }, + [board_ahci_nosntf] = { + AHCI_HFLAGS (AHCI_HFLAG_NO_SNTF), + .flags = AHCI_FLAG_COMMON, +@@ -450,6 +458,12 @@ static const struct pci_device_id ahci_p + { PCI_VDEVICE(ASMEDIA, 0x0611), board_ahci }, /* ASM1061 */ + { PCI_VDEVICE(ASMEDIA, 0x0612), board_ahci }, /* ASM1062 */ + ++ /* ++ * Samsung SSDs found on some macbooks. NCQ times out. ++ * https://bugzilla.kernel.org/show_bug.cgi?id=60731 ++ */ ++ { PCI_VDEVICE(SAMSUNG, 0x1600), board_ahci_noncq }, ++ + /* Enmotus */ + { PCI_DEVICE(0x1c44, 0x8000), board_ahci }, + diff --git a/queue-3.10/ata-enable-quirk-from-jmicron-jmb350-for-jmb394.patch b/queue-3.10/ata-enable-quirk-from-jmicron-jmb350-for-jmb394.patch new file mode 100644 index 00000000000..96826346f30 --- /dev/null +++ b/queue-3.10/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.10/cpufreq-powernow-k8-initialize-per-cpu-data-structures-properly.patch b/queue-3.10/cpufreq-powernow-k8-initialize-per-cpu-data-structures-properly.patch new file mode 100644 index 00000000000..02ab3b99907 --- /dev/null +++ b/queue-3.10/cpufreq-powernow-k8-initialize-per-cpu-data-structures-properly.patch @@ -0,0 +1,78 @@ +From c3274763bfc3bf1ececa269ed6e6c4d7ec1c3e5e Mon Sep 17 00:00:00 2001 +From: "Srivatsa S. Bhat" +Date: Mon, 17 Feb 2014 16:18:21 +0530 +Subject: cpufreq: powernow-k8: Initialize per-cpu data-structures properly + +From: "Srivatsa S. Bhat" + +commit c3274763bfc3bf1ececa269ed6e6c4d7ec1c3e5e upstream. + +The powernow-k8 driver maintains a per-cpu data-structure called +powernow_data that is used to perform the frequency transitions. +It initializes this data structure only for the policy->cpu. So, +accesses to this data structure by other CPUs results in various +problems because they would have been uninitialized. + +Specifically, if a cpu (!= policy->cpu) invokes the drivers' ->get() +function, it returns 0 as the KHz value, since its per-cpu memory +doesn't point to anything valid. This causes problems during +suspend/resume since cpufreq_update_policy() tries to enforce this +(0 KHz) as the current frequency of the CPU, and this madness gets +propagated to adjust_jiffies() as well. Eventually, lots of things +start breaking down, including the r8169 ethernet card, in one +particularly interesting case reported by Pierre Ossman. + +Fix this by initializing the per-cpu data-structures of all the CPUs +in the policy appropriately. + +References: https://bugzilla.kernel.org/show_bug.cgi?id=70311 +Reported-by: Pierre Ossman +Signed-off-by: Srivatsa S. Bhat +Acked-by: Viresh Kumar +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/cpufreq/powernow-k8.c | 10 +++++++--- + 1 file changed, 7 insertions(+), 3 deletions(-) + +--- a/drivers/cpufreq/powernow-k8.c ++++ b/drivers/cpufreq/powernow-k8.c +@@ -1100,7 +1100,7 @@ static int __cpuinit powernowk8_cpu_init + { + struct powernow_k8_data *data; + struct init_on_cpu init_on_cpu; +- int rc; ++ int rc, cpu; + + smp_call_function_single(pol->cpu, check_supported_cpu, &rc, 1); + if (rc) +@@ -1169,7 +1169,9 @@ static int __cpuinit powernowk8_cpu_init + pr_debug("cpu_init done, current fid 0x%x, vid 0x%x\n", + data->currfid, data->currvid); + +- per_cpu(powernow_data, pol->cpu) = data; ++ /* Point all the CPUs in this policy to the same data */ ++ for_each_cpu(cpu, pol->cpus) ++ per_cpu(powernow_data, cpu) = data; + + return 0; + +@@ -1184,6 +1186,7 @@ err_out: + static int powernowk8_cpu_exit(struct cpufreq_policy *pol) + { + struct powernow_k8_data *data = per_cpu(powernow_data, pol->cpu); ++ int cpu; + + if (!data) + return -EINVAL; +@@ -1194,7 +1197,8 @@ static int powernowk8_cpu_exit(struct cp + + kfree(data->powernow_table); + kfree(data); +- per_cpu(powernow_data, pol->cpu) = NULL; ++ for_each_cpu(cpu, pol->cpus) ++ per_cpu(powernow_data, cpu) = NULL; + + return 0; + } diff --git a/queue-3.10/perf-x86-fix-event-scheduling.patch b/queue-3.10/perf-x86-fix-event-scheduling.patch new file mode 100644 index 00000000000..3a6bec19a84 --- /dev/null +++ b/queue-3.10/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.10/powerpc-crashdump-fix-page-frame-number-check-in-copy_oldmem_page.patch b/queue-3.10/powerpc-crashdump-fix-page-frame-number-check-in-copy_oldmem_page.patch new file mode 100644 index 00000000000..ea02d133ae2 --- /dev/null +++ b/queue-3.10/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.10/powerpc-le-ensure-that-the-stop-self-rtas-token-is-handled-correctly.patch b/queue-3.10/powerpc-le-ensure-that-the-stop-self-rtas-token-is-handled-correctly.patch new file mode 100644 index 00000000000..c0208a92261 --- /dev/null +++ b/queue-3.10/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"); + } +@@ -391,10 +391,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.10/sata_sil-apply-mod15write-quirk-to-toshiba-mk2561gsyn.patch b/queue-3.10/sata_sil-apply-mod15write-quirk-to-toshiba-mk2561gsyn.patch new file mode 100644 index 00000000000..ec9148cf876 --- /dev/null +++ b/queue-3.10/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.10/series b/queue-3.10/series index eb04c117362..4dfb21df6c9 100644 --- a/queue-3.10/series +++ b/queue-3.10/series @@ -49,3 +49,12 @@ asoc-sta32x-fix-cache-sync.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 +ahci-disable-ncq-on-samsung-pci-e-ssds-on-macbooks.patch +x86-dma-mapping-fix-gfp_atomic-macro-usage.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 +cpufreq-powernow-k8-initialize-per-cpu-data-structures-properly.patch diff --git a/queue-3.10/sunrpc-fix-races-in-xs_nospace.patch b/queue-3.10/sunrpc-fix-races-in-xs_nospace.patch new file mode 100644 index 00000000000..b8dfaae9a69 --- /dev/null +++ b/queue-3.10/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 +@@ -502,6 +502,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", +@@ -519,7 +520,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); + } +@@ -529,6 +530,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; + } + diff --git a/queue-3.10/x86-dma-mapping-fix-gfp_atomic-macro-usage.patch b/queue-3.10/x86-dma-mapping-fix-gfp_atomic-macro-usage.patch new file mode 100644 index 00000000000..4207161bc9a --- /dev/null +++ b/queue-3.10/x86-dma-mapping-fix-gfp_atomic-macro-usage.patch @@ -0,0 +1,35 @@ +From c091c71ad2218fc50a07b3d1dab85783f3b77efd Mon Sep 17 00:00:00 2001 +From: Marek Szyprowski +Date: Fri, 24 Jan 2014 14:49:58 +0100 +Subject: x86: dma-mapping: fix GFP_ATOMIC macro usage + +From: Marek Szyprowski + +commit c091c71ad2218fc50a07b3d1dab85783f3b77efd upstream. + +GFP_ATOMIC is not a single gfp flag, but a macro which expands to the other +flags, where meaningful is the LACK of __GFP_WAIT flag. To check if caller +wants to perform an atomic allocation, the code must test for a lack of the +__GFP_WAIT flag. This patch fixes the issue introduced in v3.5-rc1. + +Signed-off-by: Marek Szyprowski +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kernel/pci-dma.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +--- a/arch/x86/kernel/pci-dma.c ++++ b/arch/x86/kernel/pci-dma.c +@@ -100,8 +100,10 @@ void *dma_generic_alloc_coherent(struct + flag |= __GFP_ZERO; + again: + page = NULL; +- if (!(flag & GFP_ATOMIC)) ++ /* CMA can be used only in the context which permits sleeping */ ++ if (flag & __GFP_WAIT) + page = dma_alloc_from_contiguous(dev, count, get_order(size)); ++ /* fallback */ + if (!page) + page = alloc_pages_node(dev_to_node(dev), flag, get_order(size)); + if (!page) -- 2.47.3