Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1509398 > unrolled thread

[PATCH 4.8 000/140] 4.8.5-stable review

Started byGreg Kroah-Hartman <gregkh@linuxfoundation.org>
First post2016-10-26 15:30 +0200
Last post2016-10-26 23:50 +0200
Articles 18 on this page of 38 — 3 participants

Back to article view | Back to linux.kernel


Contents

  [PATCH 4.8 000/140] 4.8.5-stable review Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-10-26 15:30 +0200
    [PATCH 4.8 058/140] zfcp: fix payload trace length for SAN request&response Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-10-26 15:30 +0200
    [PATCH 4.8 043/140] powerpc/mm: Update FORCE_MAX_ZONEORDER range to allow hugetlb w/4K Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-10-26 15:30 +0200
    [PATCH 4.8 065/140] [media] mb86a20s: fix demod settings Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-10-26 15:30 +0200
    [PATCH 4.8 076/140] NFSD: fix corruption in notifier registration Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-10-26 15:30 +0200
    [PATCH 4.8 009/140] ath10k: fix copy engine 5 destination ring stuck Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-10-26 15:30 +0200
    [PATCH 4.8 044/140] powerpc/64: Fix incorrect return value from __copy_tofrom_user Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-10-26 15:30 +0200
    [PATCH 4.8 042/140] powerpc/powernv: Use CPU-endian PEST in pnv_pci_dump_p7ioc_diag_data() Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-10-26 15:30 +0200
    [PATCH 4.8 045/140] powerpc/pseries: Fix stack corruption in htpe code Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-10-26 15:30 +0200
    [PATCH 4.8 064/140] [media] mb86a20s: fix the locking logic Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-10-26 15:30 +0200
    [PATCH 4.8 007/140] spi: spidev_test: Fix buffer overflow in unescape() Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-10-26 15:30 +0200
    [PATCH 4.8 073/140] Input: elantech - force needed quirks on Fujitsu H760 Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-10-26 15:30 +0200
    [PATCH 4.8 050/140] zfcp: fix fc_host port_type with NPIV Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-10-26 15:30 +0200
    [PATCH 4.8 049/140] ubi: Deal with interrupted erasures in WL Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-10-26 15:30 +0200
    [PATCH 4.8 040/140] powerpc/eeh: Null check uses of eeh_pe_bus_get Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-10-26 15:30 +0200
    [PATCH 4.8 052/140] zfcp: close window with unblocked rport during rport gone Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-10-26 15:30 +0200
    [PATCH 4.8 038/140] powerpc/vdso64: Use double word compare on pointers Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-10-26 15:30 +0200
    [PATCH 4.8 047/140] IB/srp: Fix infinite loop when FMR sg[0].offset != 0 Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-10-26 15:30 +0200
    [PATCH 4.8 060/140] scsi: zfcp: spin_lock_irqsave() is not nestable Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-10-26 15:30 +0200
    [PATCH 4.8 071/140] MIPS: ptrace: Fix regs_return_value for kernel context Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-10-26 15:30 +0200
    [PATCH 4.8 054/140] zfcp: restore: Dont use 0 to indicate invalid LUN in rec trace Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-10-26 15:30 +0200
    [PATCH 4.8 019/140] cpufreq: intel_pstate: Fix unsafe HWP MSR access Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-10-26 15:40 +0200
    [PATCH 4.8 023/140] parisc: Fix kernel memory layout regarding position of __gp Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-10-26 15:40 +0200
    [PATCH 4.8 018/140] cpufreq: skip invalid entries when searching the frequency Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-10-26 15:40 +0200
    [PATCH 4.8 015/140] platform: dont return 0 from platform_get_irq[_byname]() on error Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-10-26 15:40 +0200
    [PATCH 4.8 036/140] dm crypt: fix crash on exit Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-10-26 15:40 +0200
    [PATCH 4.8 022/140] parisc: Fix self-detected CPU stall warnings on Mako machines Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-10-26 15:40 +0200
    [PATCH 4.8 025/140] pstore/ramoops: fixup driver removal Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-10-26 15:40 +0200
    [PATCH 4.8 021/140] parisc: Increase KERNEL_INITIAL_SIZE for 32-bit SMP kernels Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-10-26 15:40 +0200
    [PATCH 4.8 030/140] perf intel-pt: Fix estimated timestamps for cycle-accurate mode Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-10-26 15:40 +0200
    [PATCH 4.8 034/140] dm rq: take request_queue lock while clearing QUEUE_FLAG_STOPPED Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-10-26 15:40 +0200
    [PATCH 4.8 017/140] cpufreq: conservative: Fix next frequency selection Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-10-26 15:40 +0200
    [PATCH 4.8 005/140] clk: imx6: initialize GPU clocks Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-10-26 15:40 +0200
    [PATCH 4.8 028/140] pstore/ram: Use memcpy_fromio() to save old buffer Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-10-26 15:40 +0200
    [PATCH 4.8 031/140] perf intel-pt: Fix MTC timestamp calculation for large MTC periods Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-10-26 15:40 +0200
    [PATCH 4.8 033/140] dm: return correct error code in dm_resume()s retry loop Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-10-26 15:40 +0200
    Re: [PATCH 4.8 000/140] 4.8.5-stable review Shuah Khan <shuah.kh@samsung.com> - 2016-10-26 20:50 +0200
    Re: [PATCH 4.8 000/140] 4.8.5-stable review Guenter Roeck <linux@roeck-us.net> - 2016-10-26 23:50 +0200

Page 2 of 2 — ← Prev page 1 [2]


#1509421 — [PATCH 4.8 054/140] zfcp: restore: Dont use 0 to indicate invalid LUN in rec trace

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2016-10-26 15:30 +0200
Subject[PATCH 4.8 054/140] zfcp: restore: Dont use 0 to indicate invalid LUN in rec trace
Message-ID<swwrh-4gI-67@gated-at.bofh.it>
In reply to#1509398
4.8-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Steffen Maier <maier@linux.vnet.ibm.com>

commit 0102a30a6ff60f4bb4c07358ca3b1f92254a6c25 upstream.

bring back
commit d21e9daa63e009ce5b87bbcaa6d11ce48e07bbbe
("[SCSI] zfcp: Dont use 0 to indicate invalid LUN in rec trace")
which was lost with
commit ae0904f60fab7cb20c48d32eefdd735e478b91fb
("[SCSI] zfcp: Redesign of the debug tracing for recovery actions.")

Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
Fixes: ae0904f60fab ("[SCSI] zfcp: Redesign of the debug tracing for recovery actions.")
Reviewed-by: Benjamin Block <bblock@linux.vnet.ibm.com>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/s390/scsi/zfcp_dbf.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/s390/scsi/zfcp_dbf.c
+++ b/drivers/s390/scsi/zfcp_dbf.c
@@ -241,7 +241,8 @@ static void zfcp_dbf_set_common(struct z
 	if (sdev) {
 		rec->lun_status = atomic_read(&sdev_to_zfcp(sdev)->status);
 		rec->lun = zfcp_scsi_dev_lun(sdev);
-	}
+	} else
+		rec->lun = ZFCP_DBF_INVALID_LUN;
 }
 
 /**

[toc] | [prev] | [next] | [standalone]


#1509422 — [PATCH 4.8 019/140] cpufreq: intel_pstate: Fix unsafe HWP MSR access

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2016-10-26 15:40 +0200
Subject[PATCH 4.8 019/140] cpufreq: intel_pstate: Fix unsafe HWP MSR access
Message-ID<swwAV-4k7-1@gated-at.bofh.it>
In reply to#1509398
4.8-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>

commit f9f4872df6e1801572949f8a370c886122d4b6da upstream.

This is a requirement that MSR MSR_PM_ENABLE must be set to 0x01 before
reading MSR_HWP_CAPABILITIES on a given CPU. If cpufreq init() is
scheduled on a CPU which is not same as policy->cpu or migrates to a
different CPU before calling msr read for MSR_HWP_CAPABILITIES, it
is possible that MSR_PM_ENABLE was not to set to 0x01 on that CPU.
This will cause GP fault. So like other places in this path
rdmsrl_on_cpu should be used instead of rdmsrl.

Moreover the scope of MSR_HWP_CAPABILITIES is on per thread basis, so it
should be read from the same CPU, for which MSR MSR_HWP_REQUEST is
getting set.

dmesg dump or warning:

[   22.014488] WARNING: CPU: 139 PID: 1 at arch/x86/mm/extable.c:50 ex_handler_rdmsr_unsafe+0x68/0x70
[   22.014492] unchecked MSR access error: RDMSR from 0x771
[   22.014493] Modules linked in:
[   22.014507] CPU: 139 PID: 1 Comm: swapper/0 Not tainted 4.7.5+ #1
...
...
[   22.014516] Call Trace:
[   22.014542]  [<ffffffff813d7dd1>] dump_stack+0x63/0x82
[   22.014558]  [<ffffffff8107bc8b>] __warn+0xcb/0xf0
[   22.014561]  [<ffffffff8107bcff>] warn_slowpath_fmt+0x4f/0x60
[   22.014563]  [<ffffffff810676f8>] ex_handler_rdmsr_unsafe+0x68/0x70
[   22.014564]  [<ffffffff810677d9>] fixup_exception+0x39/0x50
[   22.014604]  [<ffffffff8102e400>] do_general_protection+0x80/0x150
[   22.014610]  [<ffffffff817f9ec8>] general_protection+0x28/0x30
[   22.014635]  [<ffffffff81687940>] ? get_target_pstate_use_performance+0xb0/0xb0
[   22.014642]  [<ffffffff810600c7>] ? native_read_msr+0x7/0x40
[   22.014657]  [<ffffffff81688123>] intel_pstate_hwp_set+0x23/0x130
[   22.014660]  [<ffffffff81688406>] intel_pstate_set_policy+0x1b6/0x340
[   22.014662]  [<ffffffff816829bb>] cpufreq_set_policy+0xeb/0x2c0
[   22.014664]  [<ffffffff81682f39>] cpufreq_init_policy+0x79/0xe0
[   22.014666]  [<ffffffff81682cb0>] ? cpufreq_update_policy+0x120/0x120
[   22.014669]  [<ffffffff816833a6>] cpufreq_online+0x406/0x820
[   22.014671]  [<ffffffff8168381f>] cpufreq_add_dev+0x5f/0x90
[   22.014717]  [<ffffffff81530ac8>] subsys_interface_register+0xb8/0x100
[   22.014719]  [<ffffffff816821bc>] cpufreq_register_driver+0x14c/0x210
[   22.014749]  [<ffffffff81fe1d90>] intel_pstate_init+0x39d/0x4d5
[   22.014751]  [<ffffffff81fe13f2>] ? cpufreq_gov_dbs_init+0x12/0x12

Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/cpufreq/intel_pstate.c |   10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -556,12 +556,12 @@ static void intel_pstate_hwp_set(const s
 	int min, hw_min, max, hw_max, cpu, range, adj_range;
 	u64 value, cap;
 
-	rdmsrl(MSR_HWP_CAPABILITIES, cap);
-	hw_min = HWP_LOWEST_PERF(cap);
-	hw_max = HWP_HIGHEST_PERF(cap);
-	range = hw_max - hw_min;
-
 	for_each_cpu(cpu, cpumask) {
+		rdmsrl_on_cpu(cpu, MSR_HWP_CAPABILITIES, &cap);
+		hw_min = HWP_LOWEST_PERF(cap);
+		hw_max = HWP_HIGHEST_PERF(cap);
+		range = hw_max - hw_min;
+
 		rdmsrl_on_cpu(cpu, MSR_HWP_REQUEST, &value);
 		adj_range = limits->min_perf_pct * range / 100;
 		min = hw_min + adj_range;

[toc] | [prev] | [next] | [standalone]


#1509423 — [PATCH 4.8 023/140] parisc: Fix kernel memory layout regarding position of __gp

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2016-10-26 15:40 +0200
Subject[PATCH 4.8 023/140] parisc: Fix kernel memory layout regarding position of __gp
Message-ID<swwAV-4k7-3@gated-at.bofh.it>
In reply to#1509398
4.8-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Helge Deller <deller@gmx.de>

commit f8850abb7ba68229838014b3409460e576751c6d upstream.

Architecturally we need to keep __gp below 0x1000000.

But because of ftrace and tracepoint support, the RO_DATA_SECTION now gets much
bigger than it was before. By moving the linkage tables before RO_DATA_SECTION
we can avoid that __gp gets positioned at a too high address.

Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/parisc/kernel/vmlinux.lds.S |    7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

--- a/arch/parisc/kernel/vmlinux.lds.S
+++ b/arch/parisc/kernel/vmlinux.lds.S
@@ -89,8 +89,9 @@ SECTIONS
 	/* Start of data section */
 	_sdata = .;
 
-	RO_DATA_SECTION(8)
-
+	/* Architecturally we need to keep __gp below 0x1000000 and thus
+	 * in front of RO_DATA_SECTION() which stores lots of tracepoint
+	 * and ftrace symbols. */
 #ifdef CONFIG_64BIT
 	. = ALIGN(16);
 	/* Linkage tables */
@@ -105,6 +106,8 @@ SECTIONS
 	}
 #endif
 
+	RO_DATA_SECTION(8)
+
 	/* unwind info */
 	.PARISC.unwind : {
 		__start___unwind = .;

[toc] | [prev] | [next] | [standalone]


#1509424 — [PATCH 4.8 018/140] cpufreq: skip invalid entries when searching the frequency

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2016-10-26 15:40 +0200
Subject[PATCH 4.8 018/140] cpufreq: skip invalid entries when searching the frequency
Message-ID<swwAV-4k7-5@gated-at.bofh.it>
In reply to#1509398
4.8-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Aaro Koskinen <aaro.koskinen@iki.fi>

commit 899bb6642f2a2f2cd3f77abd6c5a14550e3b37e6 upstream.

Skip invalid entries when searching the frequency. This fixes cpufreq
at least on loongson2 MIPS board.

Fixes: da0c6dc00c69 (cpufreq: Handle sorted frequency tables more efficiently)
Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 include/linux/cpufreq.h |  104 ++++++++++++++++++++++++------------------------
 1 file changed, 52 insertions(+), 52 deletions(-)

--- a/include/linux/cpufreq.h
+++ b/include/linux/cpufreq.h
@@ -639,19 +639,19 @@ static inline int cpufreq_table_find_ind
 					      unsigned int target_freq)
 {
 	struct cpufreq_frequency_table *table = policy->freq_table;
+	struct cpufreq_frequency_table *pos, *best = table - 1;
 	unsigned int freq;
-	int i, best = -1;
 
-	for (i = 0; table[i].frequency != CPUFREQ_TABLE_END; i++) {
-		freq = table[i].frequency;
+	cpufreq_for_each_valid_entry(pos, table) {
+		freq = pos->frequency;
 
 		if (freq >= target_freq)
-			return i;
+			return pos - table;
 
-		best = i;
+		best = pos;
 	}
 
-	return best;
+	return best - table;
 }
 
 /* Find lowest freq at or above target in a table in descending order */
@@ -659,28 +659,28 @@ static inline int cpufreq_table_find_ind
 					      unsigned int target_freq)
 {
 	struct cpufreq_frequency_table *table = policy->freq_table;
+	struct cpufreq_frequency_table *pos, *best = table - 1;
 	unsigned int freq;
-	int i, best = -1;
 
-	for (i = 0; table[i].frequency != CPUFREQ_TABLE_END; i++) {
-		freq = table[i].frequency;
+	cpufreq_for_each_valid_entry(pos, table) {
+		freq = pos->frequency;
 
 		if (freq == target_freq)
-			return i;
+			return pos - table;
 
 		if (freq > target_freq) {
-			best = i;
+			best = pos;
 			continue;
 		}
 
 		/* No freq found above target_freq */
-		if (best == -1)
-			return i;
+		if (best == table - 1)
+			return pos - table;
 
-		return best;
+		return best - pos;
 	}
 
-	return best;
+	return best - pos;
 }
 
 /* Works only on sorted freq-tables */
@@ -700,28 +700,28 @@ static inline int cpufreq_table_find_ind
 					      unsigned int target_freq)
 {
 	struct cpufreq_frequency_table *table = policy->freq_table;
+	struct cpufreq_frequency_table *pos, *best = table - 1;
 	unsigned int freq;
-	int i, best = -1;
 
-	for (i = 0; table[i].frequency != CPUFREQ_TABLE_END; i++) {
-		freq = table[i].frequency;
+	cpufreq_for_each_valid_entry(pos, table) {
+		freq = pos->frequency;
 
 		if (freq == target_freq)
-			return i;
+			return pos - table;
 
 		if (freq < target_freq) {
-			best = i;
+			best = pos;
 			continue;
 		}
 
 		/* No freq found below target_freq */
-		if (best == -1)
-			return i;
+		if (best == table - 1)
+			return pos - table;
 
-		return best;
+		return best - table;
 	}
 
-	return best;
+	return best - table;
 }
 
 /* Find highest freq at or below target in a table in descending order */
@@ -729,19 +729,19 @@ static inline int cpufreq_table_find_ind
 					      unsigned int target_freq)
 {
 	struct cpufreq_frequency_table *table = policy->freq_table;
+	struct cpufreq_frequency_table *pos, *best = table - 1;
 	unsigned int freq;
-	int i, best = -1;
 
-	for (i = 0; table[i].frequency != CPUFREQ_TABLE_END; i++) {
-		freq = table[i].frequency;
+	cpufreq_for_each_valid_entry(pos, table) {
+		freq = pos->frequency;
 
 		if (freq <= target_freq)
-			return i;
+			return pos - table;
 
-		best = i;
+		best = pos;
 	}
 
-	return best;
+	return best - table;
 }
 
 /* Works only on sorted freq-tables */
@@ -761,32 +761,32 @@ static inline int cpufreq_table_find_ind
 					      unsigned int target_freq)
 {
 	struct cpufreq_frequency_table *table = policy->freq_table;
+	struct cpufreq_frequency_table *pos, *best = table - 1;
 	unsigned int freq;
-	int i, best = -1;
 
-	for (i = 0; table[i].frequency != CPUFREQ_TABLE_END; i++) {
-		freq = table[i].frequency;
+	cpufreq_for_each_valid_entry(pos, table) {
+		freq = pos->frequency;
 
 		if (freq == target_freq)
-			return i;
+			return pos - table;
 
 		if (freq < target_freq) {
-			best = i;
+			best = pos;
 			continue;
 		}
 
 		/* No freq found below target_freq */
-		if (best == -1)
-			return i;
+		if (best == table - 1)
+			return pos - table;
 
 		/* Choose the closest freq */
-		if (target_freq - table[best].frequency > freq - target_freq)
-			return i;
+		if (target_freq - best->frequency > freq - target_freq)
+			return pos - table;
 
-		return best;
+		return best - table;
 	}
 
-	return best;
+	return best - table;
 }
 
 /* Find closest freq to target in a table in descending order */
@@ -794,32 +794,32 @@ static inline int cpufreq_table_find_ind
 					      unsigned int target_freq)
 {
 	struct cpufreq_frequency_table *table = policy->freq_table;
+	struct cpufreq_frequency_table *pos, *best = table - 1;
 	unsigned int freq;
-	int i, best = -1;
 
-	for (i = 0; table[i].frequency != CPUFREQ_TABLE_END; i++) {
-		freq = table[i].frequency;
+	cpufreq_for_each_valid_entry(pos, table) {
+		freq = pos->frequency;
 
 		if (freq == target_freq)
-			return i;
+			return pos - table;
 
 		if (freq > target_freq) {
-			best = i;
+			best = pos;
 			continue;
 		}
 
 		/* No freq found above target_freq */
-		if (best == -1)
-			return i;
+		if (best == table - 1)
+			return pos - table;
 
 		/* Choose the closest freq */
-		if (table[best].frequency - target_freq > target_freq - freq)
-			return i;
+		if (best->frequency - target_freq > target_freq - freq)
+			return pos - table;
 
-		return best;
+		return best - table;
 	}
 
-	return best;
+	return best - table;
 }
 
 /* Works only on sorted freq-tables */

[toc] | [prev] | [next] | [standalone]


#1509425 — [PATCH 4.8 015/140] platform: dont return 0 from platform_get_irq[_byname]() on error

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2016-10-26 15:40 +0200
Subject[PATCH 4.8 015/140] platform: dont return 0 from platform_get_irq[_byname]() on error
Message-ID<swwAV-4k7-9@gated-at.bofh.it>
In reply to#1509398
4.8-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>

commit e330b9a6bb35dc7097a4f02cb1ae7b6f96df92af upstream.

of_irq_get[_byname]() return 0 iff  irq_create_of_mapping() call fails.
Returning both  error code and 0 on failure is a sign of a misdesigned API,
it makes the failure check unnecessarily complex and error prone. We should
rely  on the platform IRQ resource in this case, not return 0,  especially
as 0 can be  a valid  IRQ resource too...

Fixes: aff008ad813c ("platform_get_irq: Revert to platform_get_resource if of_irq_get fails")
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/base/platform.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -97,7 +97,7 @@ int platform_get_irq(struct platform_dev
 		int ret;
 
 		ret = of_irq_get(dev->dev.of_node, num);
-		if (ret >= 0 || ret == -EPROBE_DEFER)
+		if (ret > 0 || ret == -EPROBE_DEFER)
 			return ret;
 	}
 
@@ -175,7 +175,7 @@ int platform_get_irq_byname(struct platf
 		int ret;
 
 		ret = of_irq_get_byname(dev->dev.of_node, name);
-		if (ret >= 0 || ret == -EPROBE_DEFER)
+		if (ret > 0 || ret == -EPROBE_DEFER)
 			return ret;
 	}
 

[toc] | [prev] | [next] | [standalone]


#1509426 — [PATCH 4.8 036/140] dm crypt: fix crash on exit

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2016-10-26 15:40 +0200
Subject[PATCH 4.8 036/140] dm crypt: fix crash on exit
Message-ID<swwAV-4k7-25@gated-at.bofh.it>
In reply to#1509398
4.8-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Rabin Vincent <rabinv@axis.com>

commit f659b10087daaf4ce0087c3f6aec16746be9628f upstream.

As the documentation for kthread_stop() says, "if threadfn() may call
do_exit() itself, the caller must ensure task_struct can't go away".
dm-crypt does not ensure this and therefore crashes when crypt_dtr()
calls kthread_stop().  The crash is trivially reproducible by adding a
delay before the call to kthread_stop() and just opening and closing a
dm-crypt device.

 general protection fault: 0000 [#1] PREEMPT SMP
 CPU: 0 PID: 533 Comm: cryptsetup Not tainted 4.8.0-rc7+ #7
 task: ffff88003bd0df40 task.stack: ffff8800375b4000
 RIP: 0010: kthread_stop+0x52/0x300
 Call Trace:
  crypt_dtr+0x77/0x120
  dm_table_destroy+0x6f/0x120
  __dm_destroy+0x130/0x250
  dm_destroy+0x13/0x20
  dev_remove+0xe6/0x120
  ? dev_suspend+0x250/0x250
  ctl_ioctl+0x1fc/0x530
  ? __lock_acquire+0x24f/0x1b10
  dm_ctl_ioctl+0x13/0x20
  do_vfs_ioctl+0x91/0x6a0
  ? ____fput+0xe/0x10
  ? entry_SYSCALL_64_fastpath+0x5/0xbd
  ? trace_hardirqs_on_caller+0x151/0x1e0
  SyS_ioctl+0x41/0x70
  entry_SYSCALL_64_fastpath+0x1f/0xbd

This problem was introduced by bcbd94ff481e ("dm crypt: fix a possible
hang due to race condition on exit").

Looking at the description of that patch (excerpted below), it seems
like the problem it addresses can be solved by just using
set_current_state instead of __set_current_state, since we obviously
need the memory barrier.

| dm crypt: fix a possible hang due to race condition on exit
|
| A kernel thread executes __set_current_state(TASK_INTERRUPTIBLE),
| __add_wait_queue, spin_unlock_irq and then tests kthread_should_stop().
| It is possible that the processor reorders memory accesses so that
| kthread_should_stop() is executed before __set_current_state().  If
| such reordering happens, there is a possible race on thread
| termination: [...]

So this patch just reverts the aforementioned patch and changes the
__set_current_state(TASK_INTERRUPTIBLE) to set_current_state(...).  This
fixes the crash and should also fix the potential hang.

Fixes: bcbd94ff481e ("dm crypt: fix a possible hang due to race condition on exit")
Cc: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Rabin Vincent <rabinv@axis.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/md/dm-crypt.c |   24 ++++++++++--------------
 1 file changed, 10 insertions(+), 14 deletions(-)

--- a/drivers/md/dm-crypt.c
+++ b/drivers/md/dm-crypt.c
@@ -113,8 +113,7 @@ struct iv_tcw_private {
  * and encrypts / decrypts at the same time.
  */
 enum flags { DM_CRYPT_SUSPENDED, DM_CRYPT_KEY_VALID,
-	     DM_CRYPT_SAME_CPU, DM_CRYPT_NO_OFFLOAD,
-	     DM_CRYPT_EXIT_THREAD};
+	     DM_CRYPT_SAME_CPU, DM_CRYPT_NO_OFFLOAD };
 
 /*
  * The fields in here must be read only after initialization.
@@ -1207,18 +1206,20 @@ continue_locked:
 		if (!RB_EMPTY_ROOT(&cc->write_tree))
 			goto pop_from_list;
 
-		if (unlikely(test_bit(DM_CRYPT_EXIT_THREAD, &cc->flags))) {
-			spin_unlock_irq(&cc->write_thread_wait.lock);
-			break;
-		}
-
-		__set_current_state(TASK_INTERRUPTIBLE);
+		set_current_state(TASK_INTERRUPTIBLE);
 		__add_wait_queue(&cc->write_thread_wait, &wait);
 
 		spin_unlock_irq(&cc->write_thread_wait.lock);
 
+		if (unlikely(kthread_should_stop())) {
+			set_task_state(current, TASK_RUNNING);
+			remove_wait_queue(&cc->write_thread_wait, &wait);
+			break;
+		}
+
 		schedule();
 
+		set_task_state(current, TASK_RUNNING);
 		spin_lock_irq(&cc->write_thread_wait.lock);
 		__remove_wait_queue(&cc->write_thread_wait, &wait);
 		goto continue_locked;
@@ -1533,13 +1534,8 @@ static void crypt_dtr(struct dm_target *
 	if (!cc)
 		return;
 
-	if (cc->write_thread) {
-		spin_lock_irq(&cc->write_thread_wait.lock);
-		set_bit(DM_CRYPT_EXIT_THREAD, &cc->flags);
-		wake_up_locked(&cc->write_thread_wait);
-		spin_unlock_irq(&cc->write_thread_wait.lock);
+	if (cc->write_thread)
 		kthread_stop(cc->write_thread);
-	}
 
 	if (cc->io_queue)
 		destroy_workqueue(cc->io_queue);

[toc] | [prev] | [next] | [standalone]


#1509428 — [PATCH 4.8 022/140] parisc: Fix self-detected CPU stall warnings on Mako machines

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2016-10-26 15:40 +0200
Subject[PATCH 4.8 022/140] parisc: Fix self-detected CPU stall warnings on Mako machines
Message-ID<swwAV-4k7-13@gated-at.bofh.it>
In reply to#1509398
4.8-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Helge Deller <deller@gmx.de>

commit 92420bd0d01f040bbf754e1d090be49ca6a1c8d6 upstream.

The config option HAVE_UNSTABLE_SCHED_CLOCK is set automatically when compiling
for SMP. There is no need to clear the stable-clock flag via
clear_sched_clock_stable() when starting secondary CPUs, and even worse,
clearing it triggers wrong self-detected CPU stall warnings on 64bit Mako
machines.

Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/parisc/kernel/time.c |    6 ------
 1 file changed, 6 deletions(-)

--- a/arch/parisc/kernel/time.c
+++ b/arch/parisc/kernel/time.c
@@ -226,12 +226,6 @@ void __init start_cpu_itimer(void)
 	unsigned int cpu = smp_processor_id();
 	unsigned long next_tick = mfctl(16) + clocktick;
 
-#if defined(CONFIG_HAVE_UNSTABLE_SCHED_CLOCK) && defined(CONFIG_64BIT)
-	/* With multiple 64bit CPUs online, the cr16's are not syncronized. */
-	if (cpu != 0)
-		clear_sched_clock_stable();
-#endif
-
 	mtctl(next_tick, 16);		/* kick off Interval Timer (CR16) */
 
 	per_cpu(cpu_data, cpu).it_value = next_tick;

[toc] | [prev] | [next] | [standalone]


#1509430 — [PATCH 4.8 025/140] pstore/ramoops: fixup driver removal

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2016-10-26 15:40 +0200
Subject[PATCH 4.8 025/140] pstore/ramoops: fixup driver removal
Message-ID<swwAV-4k7-21@gated-at.bofh.it>
In reply to#1509398
4.8-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>

commit 4407de74df18ed405cc5998990004c813ccfdbde upstream.

A basic rmmod ramoops segfaults. Let's see why.

Since commit 34f0ec82e0a9 ("pstore: Correct the max_dump_cnt clearing of
ramoops") sets ->max_dump_cnt to zero before looping over ->przs but we
didn't use it before that either.

And since commit ee1d267423a1 ("pstore: add pstore unregister") we free
that memory on rmmod.

But even then, we looped until a NULL pointer or ERR. I don't see where
it is ensured that the last member is NULL. Let's try this instead:
simply error recovery and free. Clean up in error case where resources
were allocated. And then, in the free path, rely on ->max_dump_cnt in
the free path.

Cc: Anton Vorontsov <anton@enomsg.org>
Cc: Colin Cross <ccross@android.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Acked-by: Namhyung Kim <namhyung@kernel.org>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 fs/pstore/ram.c |   17 ++++++++++++-----
 1 file changed, 12 insertions(+), 5 deletions(-)

--- a/fs/pstore/ram.c
+++ b/fs/pstore/ram.c
@@ -377,13 +377,14 @@ static void ramoops_free_przs(struct ram
 {
 	int i;
 
-	cxt->max_dump_cnt = 0;
 	if (!cxt->przs)
 		return;
 
-	for (i = 0; !IS_ERR_OR_NULL(cxt->przs[i]); i++)
+	for (i = 0; i < cxt->max_dump_cnt; i++)
 		persistent_ram_free(cxt->przs[i]);
+
 	kfree(cxt->przs);
+	cxt->max_dump_cnt = 0;
 }
 
 static int ramoops_init_przs(struct device *dev, struct ramoops_context *cxt,
@@ -408,7 +409,7 @@ static int ramoops_init_przs(struct devi
 			     GFP_KERNEL);
 	if (!cxt->przs) {
 		dev_err(dev, "failed to initialize a prz array for dumps\n");
-		goto fail_prz;
+		goto fail_mem;
 	}
 
 	for (i = 0; i < cxt->max_dump_cnt; i++) {
@@ -419,6 +420,11 @@ static int ramoops_init_przs(struct devi
 			err = PTR_ERR(cxt->przs[i]);
 			dev_err(dev, "failed to request mem region (0x%zx@0x%llx): %d\n",
 				cxt->record_size, (unsigned long long)*paddr, err);
+
+			while (i > 0) {
+				i--;
+				persistent_ram_free(cxt->przs[i]);
+			}
 			goto fail_prz;
 		}
 		*paddr += cxt->record_size;
@@ -426,7 +432,9 @@ static int ramoops_init_przs(struct devi
 
 	return 0;
 fail_prz:
-	ramoops_free_przs(cxt);
+	kfree(cxt->przs);
+fail_mem:
+	cxt->max_dump_cnt = 0;
 	return err;
 }
 
@@ -659,7 +667,6 @@ static int ramoops_remove(struct platfor
 	struct ramoops_context *cxt = &oops_cxt;
 
 	pstore_unregister(&cxt->pstore);
-	cxt->max_dump_cnt = 0;
 
 	kfree(cxt->pstore.buf);
 	cxt->pstore.bufsize = 0;

[toc] | [prev] | [next] | [standalone]


#1509433 — [PATCH 4.8 021/140] parisc: Increase KERNEL_INITIAL_SIZE for 32-bit SMP kernels

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2016-10-26 15:40 +0200
Subject[PATCH 4.8 021/140] parisc: Increase KERNEL_INITIAL_SIZE for 32-bit SMP kernels
Message-ID<swwAW-4k7-33@gated-at.bofh.it>
In reply to#1509398
4.8-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Helge Deller <deller@gmx.de>

commit 690d097c00c88fa9d93d198591e184164b1d8c20 upstream.

Increase the initial kernel default page mapping size for SMP kernels to 32MB
and add a runtime check which panics early if the kernel is bigger than the
initial mapping size.

This fixes boot crashes of 32bit SMP kernels. Due to the introduction of huge
page support in kernel 4.4 and it's required initial kernel layout in memory, a
32bit SMP kernel usually got bigger (in layout, not size) than 16MB.

Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/parisc/include/asm/pgtable.h |    2 +-
 arch/parisc/kernel/setup.c        |    8 ++++++++
 2 files changed, 9 insertions(+), 1 deletion(-)

--- a/arch/parisc/include/asm/pgtable.h
+++ b/arch/parisc/include/asm/pgtable.h
@@ -83,7 +83,7 @@ static inline void purge_tlb_entries(str
 	printk("%s:%d: bad pgd %08lx.\n", __FILE__, __LINE__, (unsigned long)pgd_val(e))
 
 /* This is the size of the initially mapped kernel memory */
-#ifdef CONFIG_64BIT
+#if defined(CONFIG_64BIT) || defined(CONFIG_SMP)
 #define KERNEL_INITIAL_ORDER	25	/* 1<<25 = 32MB */
 #else
 #define KERNEL_INITIAL_ORDER	24	/* 1<<24 = 16MB */
--- a/arch/parisc/kernel/setup.c
+++ b/arch/parisc/kernel/setup.c
@@ -38,6 +38,7 @@
 #include <linux/export.h>
 
 #include <asm/processor.h>
+#include <asm/sections.h>
 #include <asm/pdc.h>
 #include <asm/led.h>
 #include <asm/machdep.h>	/* for pa7300lc_init() proto */
@@ -140,6 +141,13 @@ void __init setup_arch(char **cmdline_p)
 #endif
 	printk(KERN_CONT ".\n");
 
+	/*
+	 * Check if initial kernel page mappings are sufficient.
+	 * panic early if not, else we may access kernel functions
+	 * and variables which can't be reached.
+	 */
+	if (__pa((unsigned long) &_end) >= KERNEL_INITIAL_SIZE)
+		panic("KERNEL_INITIAL_ORDER too small!");
 
 	pdc_console_init();
 

[toc] | [prev] | [next] | [standalone]


#1509434 — [PATCH 4.8 030/140] perf intel-pt: Fix estimated timestamps for cycle-accurate mode

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2016-10-26 15:40 +0200
Subject[PATCH 4.8 030/140] perf intel-pt: Fix estimated timestamps for cycle-accurate mode
Message-ID<swwAW-4k7-35@gated-at.bofh.it>
In reply to#1509398
4.8-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Adrian Hunter <adrian.hunter@intel.com>

commit 51ee6481fa8e879cc942bcc1b0af713e158b7a98 upstream.

In cycle-accurate mode, timestamps can be calculated from CYC packets.
The decoder also estimates timestamps based on the number of
instructions since the last timestamp. For that to work in
cycle-accurate mode, the instruction count needs to be reset to zero
when a timestamp is calculated from a CYC packet, but that wasn't
happening, so fix it.

Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Link: http://lkml.kernel.org/r/1475062896-22274-1-git-send-email-adrian.hunter@intel.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 tools/perf/util/intel-pt-decoder/intel-pt-decoder.c |    2 ++
 1 file changed, 2 insertions(+)

--- a/tools/perf/util/intel-pt-decoder/intel-pt-decoder.c
+++ b/tools/perf/util/intel-pt-decoder/intel-pt-decoder.c
@@ -1323,6 +1323,8 @@ static void intel_pt_calc_cyc_timestamp(
 			     timestamp, decoder->timestamp);
 	else
 		decoder->timestamp = timestamp;
+
+	decoder->timestamp_insn_cnt = 0;
 }
 
 /* Walk PSB+ packets when already in sync. */

[toc] | [prev] | [next] | [standalone]


#1509435 — [PATCH 4.8 034/140] dm rq: take request_queue lock while clearing QUEUE_FLAG_STOPPED

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2016-10-26 15:40 +0200
Subject[PATCH 4.8 034/140] dm rq: take request_queue lock while clearing QUEUE_FLAG_STOPPED
Message-ID<swwAW-4k7-47@gated-at.bofh.it>
In reply to#1509398
4.8-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Mike Snitzer <snitzer@redhat.com>

commit 9dbeaeabacb26260d1621fe58f0f6fdedc8860d4 upstream.

Every call of queue_flag_clear_unlocked() after block device
initialization has finished is wrong if blk_cleanup_queue() can be
called concurrently.  Convert queue_flag_clear_unlocked() into
queue_flag_clear() and protect it by the block layer queue lock.

Also, factor out dm_mq_start_queue().

Reported-by: Bart Van Assche <bart.vanassche@sandisk.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/md/dm-rq.c |   19 ++++++++++++++-----
 1 file changed, 14 insertions(+), 5 deletions(-)

--- a/drivers/md/dm-rq.c
+++ b/drivers/md/dm-rq.c
@@ -73,15 +73,24 @@ static void dm_old_start_queue(struct re
 	spin_unlock_irqrestore(q->queue_lock, flags);
 }
 
+static void dm_mq_start_queue(struct request_queue *q)
+{
+	unsigned long flags;
+
+	spin_lock_irqsave(q->queue_lock, flags);
+	queue_flag_clear(QUEUE_FLAG_STOPPED, q);
+	spin_unlock_irqrestore(q->queue_lock, flags);
+
+	blk_mq_start_stopped_hw_queues(q, true);
+	blk_mq_kick_requeue_list(q);
+}
+
 void dm_start_queue(struct request_queue *q)
 {
 	if (!q->mq_ops)
 		dm_old_start_queue(q);
-	else {
-		queue_flag_clear_unlocked(QUEUE_FLAG_STOPPED, q);
-		blk_mq_start_stopped_hw_queues(q, true);
-		blk_mq_kick_requeue_list(q);
-	}
+	else
+		dm_mq_start_queue(q);
 }
 
 static void dm_old_stop_queue(struct request_queue *q)

[toc] | [prev] | [next] | [standalone]


#1509437 — [PATCH 4.8 017/140] cpufreq: conservative: Fix next frequency selection

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2016-10-26 15:40 +0200
Subject[PATCH 4.8 017/140] cpufreq: conservative: Fix next frequency selection
Message-ID<swwAW-4k7-43@gated-at.bofh.it>
In reply to#1509398
4.8-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

commit abb6627910a1e783c8e034b35b7c80e5e7f98f41 upstream.

Commit d352cf47d93e (cpufreq: conservative: Do not use transition
notifications) overlooked the case when the "frequency step" used
by the conservative governor is small relative to the distances
between the available frequencies and broke the algorithm by
using policy->cur instead of the previously requested frequency
when computing the next one.

As a result, the governor may not be able to go outside of a narrow
range between two consecutive available frequencies.

Fix the problem by making the governor save the previously requested
frequency and select the next one relative that value (unless it is
out of range, in which case policy->cur will be used instead).

Fixes: d352cf47d93e (cpufreq: conservative: Do not use transition notifications)
Link: https://bugzilla.kernel.org/show_bug.cgi?id=177171
Reported-and-tested-by: Aleksey Rybalkin <aleksey@rybalkin.org>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/cpufreq/cpufreq_conservative.c |   19 ++++++++++++++++---
 1 file changed, 16 insertions(+), 3 deletions(-)

--- a/drivers/cpufreq/cpufreq_conservative.c
+++ b/drivers/cpufreq/cpufreq_conservative.c
@@ -17,6 +17,7 @@
 struct cs_policy_dbs_info {
 	struct policy_dbs_info policy_dbs;
 	unsigned int down_skip;
+	unsigned int requested_freq;
 };
 
 static inline struct cs_policy_dbs_info *to_dbs_info(struct policy_dbs_info *policy_dbs)
@@ -61,6 +62,7 @@ static unsigned int cs_dbs_timer(struct
 {
 	struct policy_dbs_info *policy_dbs = policy->governor_data;
 	struct cs_policy_dbs_info *dbs_info = to_dbs_info(policy_dbs);
+	unsigned int requested_freq = dbs_info->requested_freq;
 	struct dbs_data *dbs_data = policy_dbs->dbs_data;
 	struct cs_dbs_tuners *cs_tuners = dbs_data->tuners;
 	unsigned int load = dbs_update(policy);
@@ -72,10 +74,16 @@ static unsigned int cs_dbs_timer(struct
 	if (cs_tuners->freq_step == 0)
 		goto out;
 
+	/*
+	 * If requested_freq is out of range, it is likely that the limits
+	 * changed in the meantime, so fall back to current frequency in that
+	 * case.
+	 */
+	if (requested_freq > policy->max || requested_freq < policy->min)
+		requested_freq = policy->cur;
+
 	/* Check for frequency increase */
 	if (load > dbs_data->up_threshold) {
-		unsigned int requested_freq = policy->cur;
-
 		dbs_info->down_skip = 0;
 
 		/* if we are already at full speed then break out early */
@@ -83,8 +91,11 @@ static unsigned int cs_dbs_timer(struct
 			goto out;
 
 		requested_freq += get_freq_target(cs_tuners, policy);
+		if (requested_freq > policy->max)
+			requested_freq = policy->max;
 
 		__cpufreq_driver_target(policy, requested_freq, CPUFREQ_RELATION_H);
+		dbs_info->requested_freq = requested_freq;
 		goto out;
 	}
 
@@ -95,7 +106,7 @@ static unsigned int cs_dbs_timer(struct
 
 	/* Check for frequency decrease */
 	if (load < cs_tuners->down_threshold) {
-		unsigned int freq_target, requested_freq = policy->cur;
+		unsigned int freq_target;
 		/*
 		 * if we cannot reduce the frequency anymore, break out early
 		 */
@@ -109,6 +120,7 @@ static unsigned int cs_dbs_timer(struct
 			requested_freq = policy->min;
 
 		__cpufreq_driver_target(policy, requested_freq, CPUFREQ_RELATION_L);
+		dbs_info->requested_freq = requested_freq;
 	}
 
  out:
@@ -287,6 +299,7 @@ static void cs_start(struct cpufreq_poli
 	struct cs_policy_dbs_info *dbs_info = to_dbs_info(policy->governor_data);
 
 	dbs_info->down_skip = 0;
+	dbs_info->requested_freq = policy->cur;
 }
 
 static struct dbs_governor cs_governor = {

[toc] | [prev] | [next] | [standalone]


#1509438 — [PATCH 4.8 005/140] clk: imx6: initialize GPU clocks

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2016-10-26 15:40 +0200
Subject[PATCH 4.8 005/140] clk: imx6: initialize GPU clocks
Message-ID<swwAW-4k7-37@gated-at.bofh.it>
In reply to#1509398
4.8-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Lucas Stach <l.stach@pengutronix.de>

commit d8846023aed1293e54d33499558fc2aa2b2f393f upstream.

Initialize the GPU clock muxes to sane inputs. Until now they have
not been changed from their default values, which means that both
GPU3D shader and GPU2D core were fed by clock inputs whose rates
exceed the maximium allowed frequency of the cores by as much as
200MHz.

This fixes a severe GPU stability issue on i.MX6DL.

Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Acked-by: Shawn Guo <shawnguo@kernel.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/clk/imx/clk-imx6q.c |   18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

--- a/drivers/clk/imx/clk-imx6q.c
+++ b/drivers/clk/imx/clk-imx6q.c
@@ -629,6 +629,24 @@ static void __init imx6q_clocks_init(str
 	if (IS_ENABLED(CONFIG_PCI_IMX6))
 		clk_set_parent(clk[IMX6QDL_CLK_LVDS1_SEL], clk[IMX6QDL_CLK_SATA_REF_100M]);
 
+	/*
+	 * Initialize the GPU clock muxes, so that the maximum specified clock
+	 * rates for the respective SoC are not exceeded.
+	 */
+	if (clk_on_imx6dl()) {
+		clk_set_parent(clk[IMX6QDL_CLK_GPU3D_CORE_SEL],
+			       clk[IMX6QDL_CLK_PLL2_PFD1_594M]);
+		clk_set_parent(clk[IMX6QDL_CLK_GPU2D_CORE_SEL],
+			       clk[IMX6QDL_CLK_PLL2_PFD1_594M]);
+	} else if (clk_on_imx6q()) {
+		clk_set_parent(clk[IMX6QDL_CLK_GPU3D_CORE_SEL],
+			       clk[IMX6QDL_CLK_MMDC_CH0_AXI]);
+		clk_set_parent(clk[IMX6QDL_CLK_GPU3D_SHADER_SEL],
+			       clk[IMX6QDL_CLK_PLL2_PFD1_594M]);
+		clk_set_parent(clk[IMX6QDL_CLK_GPU2D_CORE_SEL],
+			       clk[IMX6QDL_CLK_PLL3_USB_OTG]);
+	}
+
 	imx_register_uart_clocks(uart_clks);
 }
 CLK_OF_DECLARE(imx6q, "fsl,imx6q-ccm", imx6q_clocks_init);

[toc] | [prev] | [next] | [standalone]


#1509440 — [PATCH 4.8 028/140] pstore/ram: Use memcpy_fromio() to save old buffer

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2016-10-26 15:40 +0200
Subject[PATCH 4.8 028/140] pstore/ram: Use memcpy_fromio() to save old buffer
Message-ID<swwAW-4k7-49@gated-at.bofh.it>
In reply to#1509398
4.8-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Andrew Bresticker <abrestic@chromium.org>

commit d771fdf94180de2bd811ac90cba75f0f346abf8d upstream.

The ramoops buffer may be mapped as either I/O memory or uncached
memory.  On ARM64, this results in a device-type (strongly-ordered)
mapping.  Since unnaligned accesses to device-type memory will
generate an alignment fault (regardless of whether or not strict
alignment checking is enabled), it is not safe to use memcpy().
memcpy_fromio() is guaranteed to only use aligned accesses, so use
that instead.

Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Signed-off-by: Enric Balletbo Serra <enric.balletbo@collabora.com>
Reviewed-by: Puneet Kumar <puneetster@chromium.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 fs/pstore/ram_core.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/fs/pstore/ram_core.c
+++ b/fs/pstore/ram_core.c
@@ -286,8 +286,8 @@ void persistent_ram_save_old(struct pers
 	}
 
 	prz->old_log_size = size;
-	memcpy(prz->old_log, &buffer->data[start], size - start);
-	memcpy(prz->old_log + size - start, &buffer->data[0], start);
+	memcpy_fromio(prz->old_log, &buffer->data[start], size - start);
+	memcpy_fromio(prz->old_log + size - start, &buffer->data[0], start);
 }
 
 int notrace persistent_ram_write(struct persistent_ram_zone *prz,

[toc] | [prev] | [next] | [standalone]


#1509441 — [PATCH 4.8 031/140] perf intel-pt: Fix MTC timestamp calculation for large MTC periods

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2016-10-26 15:40 +0200
Subject[PATCH 4.8 031/140] perf intel-pt: Fix MTC timestamp calculation for large MTC periods
Message-ID<swwAW-4k7-55@gated-at.bofh.it>
In reply to#1509398
4.8-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Adrian Hunter <adrian.hunter@intel.com>

commit 3bccbe20f6d188ce7b00326e776b745cfd35b10a upstream.

The MTC packet provides a 8-bit slice of CTC which is related to TSC by
the TMA packet, however the TMA packet only provides the lower 16 bits
of CTC.  If mtc_shift > 8 then some of the MTC bits are not in the CTC
provided by the TMA packet. Fix-up the last_mtc calculated from the TMA
packet by copying the missing bits from the current MTC assuming the
least difference between the two, and that the current MTC comes after
last_mtc.

Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Link: http://lkml.kernel.org/r/1475062896-22274-2-git-send-email-adrian.hunter@intel.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 tools/perf/util/intel-pt-decoder/intel-pt-decoder.c |   36 ++++++++++++++++++++
 1 file changed, 36 insertions(+)

--- a/tools/perf/util/intel-pt-decoder/intel-pt-decoder.c
+++ b/tools/perf/util/intel-pt-decoder/intel-pt-decoder.c
@@ -89,6 +89,7 @@ struct intel_pt_decoder {
 	bool pge;
 	bool have_tma;
 	bool have_cyc;
+	bool fixup_last_mtc;
 	uint64_t pos;
 	uint64_t last_ip;
 	uint64_t ip;
@@ -584,10 +585,31 @@ struct intel_pt_calc_cyc_to_tsc_info {
 	uint64_t        tsc_timestamp;
 	uint64_t        timestamp;
 	bool            have_tma;
+	bool            fixup_last_mtc;
 	bool            from_mtc;
 	double          cbr_cyc_to_tsc;
 };
 
+/*
+ * MTC provides a 8-bit slice of CTC but the TMA packet only provides the lower
+ * 16 bits of CTC. If mtc_shift > 8 then some of the MTC bits are not in the CTC
+ * provided by the TMA packet. Fix-up the last_mtc calculated from the TMA
+ * packet by copying the missing bits from the current MTC assuming the least
+ * difference between the two, and that the current MTC comes after last_mtc.
+ */
+static void intel_pt_fixup_last_mtc(uint32_t mtc, int mtc_shift,
+				    uint32_t *last_mtc)
+{
+	uint32_t first_missing_bit = 1U << (16 - mtc_shift);
+	uint32_t mask = ~(first_missing_bit - 1);
+
+	*last_mtc |= mtc & mask;
+	if (*last_mtc >= mtc) {
+		*last_mtc -= first_missing_bit;
+		*last_mtc &= 0xff;
+	}
+}
+
 static int intel_pt_calc_cyc_cb(struct intel_pt_pkt_info *pkt_info)
 {
 	struct intel_pt_decoder *decoder = pkt_info->decoder;
@@ -617,6 +639,11 @@ static int intel_pt_calc_cyc_cb(struct i
 			return 0;
 
 		mtc = pkt_info->packet.payload;
+		if (decoder->mtc_shift > 8 && data->fixup_last_mtc) {
+			data->fixup_last_mtc = false;
+			intel_pt_fixup_last_mtc(mtc, decoder->mtc_shift,
+						&data->last_mtc);
+		}
 		if (mtc > data->last_mtc)
 			mtc_delta = mtc - data->last_mtc;
 		else
@@ -685,6 +712,7 @@ static int intel_pt_calc_cyc_cb(struct i
 
 		data->ctc_delta = 0;
 		data->have_tma = true;
+		data->fixup_last_mtc = true;
 
 		return 0;
 
@@ -751,6 +779,7 @@ static void intel_pt_calc_cyc_to_tsc(str
 		.tsc_timestamp  = decoder->tsc_timestamp,
 		.timestamp      = decoder->timestamp,
 		.have_tma       = decoder->have_tma,
+		.fixup_last_mtc = decoder->fixup_last_mtc,
 		.from_mtc       = from_mtc,
 		.cbr_cyc_to_tsc = 0,
 	};
@@ -1241,6 +1270,7 @@ static void intel_pt_calc_tma(struct int
 	}
 	decoder->ctc_delta = 0;
 	decoder->have_tma = true;
+	decoder->fixup_last_mtc = true;
 	intel_pt_log("CTC timestamp " x64_fmt " last MTC %#x  CTC rem %#x\n",
 		     decoder->ctc_timestamp, decoder->last_mtc, ctc_rem);
 }
@@ -1255,6 +1285,12 @@ static void intel_pt_calc_mtc_timestamp(
 
 	mtc = decoder->packet.payload;
 
+	if (decoder->mtc_shift > 8 && decoder->fixup_last_mtc) {
+		decoder->fixup_last_mtc = false;
+		intel_pt_fixup_last_mtc(mtc, decoder->mtc_shift,
+					&decoder->last_mtc);
+	}
+
 	if (mtc > decoder->last_mtc)
 		mtc_delta = mtc - decoder->last_mtc;
 	else

[toc] | [prev] | [next] | [standalone]


#1509442 — [PATCH 4.8 033/140] dm: return correct error code in dm_resume()s retry loop

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2016-10-26 15:40 +0200
Subject[PATCH 4.8 033/140] dm: return correct error code in dm_resume()s retry loop
Message-ID<swwAW-4k7-57@gated-at.bofh.it>
In reply to#1509398
4.8-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Minfei Huang <mnghuan@gmail.com>

commit 8dc23658b7aaa8b6b0609c81c8ad75e98b612801 upstream.

dm_resume() will return success (0) rather than -EINVAL if
!dm_suspended_md() upon retry within dm_resume().

Reset the error code at the start of dm_resume()'s retry loop.
Also, remove a useless assignment at the end of dm_resume().

Fixes: ffcc393641 ("dm: enhance internal suspend and resume interface")
Signed-off-by: Minfei Huang <mnghuan@gmail.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/md/dm.c |    5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

--- a/drivers/md/dm.c
+++ b/drivers/md/dm.c
@@ -2254,10 +2254,11 @@ static int __dm_resume(struct mapped_dev
 
 int dm_resume(struct mapped_device *md)
 {
-	int r = -EINVAL;
+	int r;
 	struct dm_table *map = NULL;
 
 retry:
+	r = -EINVAL;
 	mutex_lock_nested(&md->suspend_lock, SINGLE_DEPTH_NESTING);
 
 	if (!dm_suspended_md(md))
@@ -2281,8 +2282,6 @@ retry:
 		goto out;
 
 	clear_bit(DMF_SUSPENDED, &md->flags);
-
-	r = 0;
 out:
 	mutex_unlock(&md->suspend_lock);
 

[toc] | [prev] | [next] | [standalone]


#1509697

FromShuah Khan <shuah.kh@samsung.com>
Date2016-10-26 20:50 +0200
Message-ID<swBqV-7E5-1@gated-at.bofh.it>
In reply to#1509398
On 10/26/2016 06:21 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.8.5 release.
> There are 140 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Fri Oct 28 12:21:58 UTC 2016.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
> 	kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.8.5-rc1.gz
> or in the git tree and branch at:
>   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.8.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah

-- 
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America(Silicon Valley)
shuah.kh@samsung.com

[toc] | [prev] | [next] | [standalone]


#1509872

FromGuenter Roeck <linux@roeck-us.net>
Date2016-10-26 23:50 +0200
Message-ID<swEf8-11E-7@gated-at.bofh.it>
In reply to#1509398
On Wed, Oct 26, 2016 at 02:21:00PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.8.5 release.
> There are 140 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Fri Oct 28 12:21:58 UTC 2016.
> Anything received after that time might be too late.
> 

Build results:
	total: 149 pass: 149 fail: 0
Qemu test results:
	total: 113 pass: 113 fail: 0

Details are available at http://kerneltests.org/builders.

Guenter

[toc] | [prev] | [standalone]


Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.kernel


csiph-web