Skip to contentSkip to conversation

4.0.7-stable review

PATCH In review Greg Kroah-Hartman 4 participants 22 messages Jun 27, 2015 Stable branch

lore
Share & tools
lore

Greg Kroah-Hartman

author maintainer
#0 lore raw

cover 4.0.7-stable review

This is the start of the stable review cycle for the 4.0.7 release. There are 22 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 Mon Jun 29 01:08:46 UTC 2015. 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.0.7-rc1.gz

and the diffstat can be found below.

thanks,

greg k-h

-------------
Pseudo-Shortlog of commits:

Greg Kroah-Hartman <[email protected]>

    Linux 4.0.7-rc1

Sam Bobroff <[email protected]>
powerpc/powernv: Restore non-volatile CRs after nap

Peter Antoine <[email protected]>
drm/i915: Avoid GPU hang when coming out of s3 or s4

Junichi Nomura <[email protected]>
dm: fix NULL pointer when clone_and_map_rq returns !DM_MAPIO_REMAPPED

Eugene Shatokhin <[email protected]>
kprobes/x86: Return correct length in __copy_instruction()

Krzysztof Kozlowski <[email protected]>
ARM: EXYNOS: Fix failed second suspend on Exynos4

Alexey Sokolov <[email protected]>
cdc-acm: Add support of ATOL FPrint fiscal printers

Rafał Miłecki <[email protected]>

    b43: fix support for 14e4:4321 PCI dev with BCM4321 chipset

Dmitry Tunin <[email protected]>

    ath3k: add support of 13d3:3474 AR3012 device

Dmitry Tunin <[email protected]>

    ath3k: Add support of 0489:e076 AR3012 device

Michel Dänzer <[email protected]>
drm/radeon: Add RADEON_INFO_VA_UNMAP_WORKING query

Jani Nikula <[email protected]>
Revert "drm/i915: Don't skip request retirement if the active list is empty"

Chris Wilson <[email protected]>

    drm/i915: Always reset vma->ggtt_view.pages cache on unbinding

Adam Jackson <[email protected]>
drm/mgag200: Reject non-character-cell-aligned mode widths

Sagi Grimberg <[email protected]>
iser-target: Fix possible use-after-free

Sagi Grimberg <[email protected]>
iser-target: Fix variable-length response error completion

Steven Rostedt <[email protected]>
tracing: Have filter check for balanced ops

Hui Wang <[email protected]>
ALSA: hda - adding a DAC/pin preference map for a HP Envy TS machine

Nicolas Ferre <[email protected]>
clk: at91: fix h32mx prototype inclusion in pmc header

Boris Brezillon <[email protected]>
clk: at91: pll: fix input range validity check

Radim Krčmář <[email protected]>
KVM: x86: fix lapic.timer_mode on restore

Steve Cornelius <[email protected]>
crypto: caam - fix RNG buffer cache alignment

Steve Cornelius <[email protected]>
crypto: caam - improve initalization for context state saves

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

Diffstat:

 Makefile                                |  4 ++--
 arch/arm/mach-exynos/common.h           |  2 ++
 arch/arm/mach-exynos/exynos.c           | 27 +++++++++++++++++++++++
 arch/arm/mach-exynos/platsmp.c          | 39 ++-------------------------------
 arch/arm/mach-exynos/suspend.c          |  3 +++
 arch/powerpc/kernel/idle_power7.S       |  2 ++
 arch/x86/kernel/kprobes/core.c          |  9 +++++---
 arch/x86/kvm/lapic.c                    | 26 +++++++++++++---------
 drivers/bluetooth/ath3k.c               |  4 ++++
 drivers/bluetooth/btusb.c               |  2 ++
 drivers/clk/at91/clk-pll.c              | 12 ++++++++--
 drivers/clk/at91/pmc.h                  |  2 +-
 drivers/crypto/caam/caamhash.c          |  2 ++
 drivers/crypto/caam/caamrng.c           |  2 +-
 drivers/gpu/drm/i915/i915_drv.c         | 13 ++++++++---
 drivers/gpu/drm/i915/i915_gem.c         |  5 ++++-
 drivers/gpu/drm/mgag200/mgag200_mode.c  |  5 +++++
 drivers/gpu/drm/radeon/radeon_kms.c     |  3 +++
 drivers/infiniband/ulp/isert/ib_isert.c |  7 ++++--
 drivers/md/dm.c                         |  4 ++--
 drivers/net/wireless/b43/main.c         |  4 ++++
 drivers/usb/class/cdc-acm.c             |  9 ++++++++
 drivers/usb/class/cdc-acm.h             |  1 +
 include/uapi/drm/radeon_drm.h           |  1 +
 kernel/trace/trace_events_filter.c      | 11 ++++++++--
 sound/pci/hda/patch_sigmatel.c          | 25 +++++++++++++++++++++
 26 files changed, 158 insertions(+), 66 deletions(-)
author maintainer
#1 lore raw

PATCH 1/22 crypto: caam - improve initalization for context state saves

4.0-stable review patch. If anyone has any objections, please let me know.

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

From: Steve Cornelius <[email protected]>

commit 6fd4b15603124c1b56e03db29b41ec39d8a077b9 upstream.

Multiple function in asynchronous hashing use a saved-state block, a.k.a. struct caam_hash_state, which holds a stash of information between requests (init/update/final). Certain values in this state block are loaded for processing using an inline-if, and when this is done, the potential for uninitialized data can pose conflicts. Therefore, this patch improves initialization of state data to prevent false assignments using uninitialized data in the state block.

This patch addresses the following traceback, originating in ahash_final_ctx(), although a problem like this could certainly exhibit other symptoms:

kernel BUG at arch/arm/mm/dma-mapping.c:465!

Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = 80004000
[00000000] *pgd=00000000
Internal error: Oops: 805 [#1] PREEMPT SMP
Modules linked in:
CPU: 0    Not tainted  (3.0.15-01752-gdd441b9-dirty #40)
PC is at __bug+0x1c/0x28
LR is at __bug+0x18/0x28
pc : [<80043240>]    lr : [<8004323c>]    psr: 60000013

sp : e423fd98 ip : 60000013 fp : 0000001c
r10: e4191b84 r9 : 00000020 r8 : 00000009
r7 : 88005038 r6 : 00000001 r5 : 2d676572 r4 : e4191a60 r3 : 00000000 r2 : 00000001 r1 : 60000093 r0 : 00000033
Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel
Control: 10c53c7d Table: 1000404a DAC: 00000015 Process cryptomgr_test (pid: 1306, stack limit = 0xe423e2f0)

Stack: (0xe423fd98 to 0xe4240000)

fd80: 11807fd1 80048544
fda0: 88005000 e4191a00 e5178040 8039dda0 00000000 00000014 2d676572 e4191008
fdc0: 88005018 e4191a60 00100100 e4191a00 00000000 8039ce0c e423fea8 00000007
fde0: e4191a00 e4227000 e5178000 8039ce18 e419183c 80203808 80a94a44 00000006
fe00: 00000000 80207180 00000000 00000006 e423ff08 00000000 00000007 e5178000
fe20: e41918a4 80a949b4 8c4844e2 00000000 00000049 74227000 8c4844e2 00000e90
fe40: 0000000e 74227e90 ffff8c58 80ac29e0 e423fed4 8006a350 8c81625c e423ff5c
fe60: 00008576 e4002500 00000003 00030010 e4002500 00000003 e5180000 e4002500
fe80: e5178000 800e6d24 007fffff 00000000 00000010 e4001280 e4002500 60000013
fea0: 000000d0 804df078 00000000 00000000 00000000 00000000 00000000 00000000
fec0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
fee0: 00000000 00000000 e4227000 e4226000 e4753000 e4752000 e40a5000 e40a4000
ff00: e41e7000 e41e6000 00000000 00000000 00000000 e423ff14 e423ff14 00000000
ff20: 00000400 804f9080 e5178000 e4db0b40 00000000 e4db0b80 0000047c 00000400
ff40: 00000000 8020758c 00000400 ffffffff 0000008a 00000000 e4db0b40 80206e00
ff60: e4049dbc 00000000 00000000 00000003 e423ffa4 80062978 e41a8bfc 00000000
ff80: 00000000 e4049db4 00000013 e4049db0 00000013 00000000 00000000 00000000
ffa0: e4db0b40 e4db0b40 80204cbc 00000013 00000000 00000000 00000000 80204cfc
ffc0: e4049da0 80089544 80040a40 00000000 e4db0b40 00000000 00000000 00000000
ffe0: e423ffe0 e423ffe0 e4049da0 800894c4 80040a40 80040a40 00000000 00000000 [<80043240>] (__bug+0x1c/0x28) from [<80048544>] (___dma_single_dev_to_cpu+0x84) [<80048544>] (___dma_single_dev_to_cpu+0x84/0x94) from [<8039dda0>] (ahash_fina) [<8039dda0>] (ahash_final_ctx+0x180/0x428) from [<8039ce18>] (ahash_final+0xc/0) [<8039ce18>] (ahash_final+0xc/0x10) from [<80203808>] (crypto_ahash_op+0x28/0xc) [<80203808>] (crypto_ahash_op+0x28/0xc0) from [<80207180>] (test_hash+0x214/0x5) [<80207180>] (test_hash+0x214/0x5b8) from [<8020758c>] (alg_test_hash+0x68/0x8c) [<8020758c>] (alg_test_hash+0x68/0x8c) from [<80206e00>] (alg_test+0x7c/0x1b8) [<80206e00>] (alg_test+0x7c/0x1b8) from [<80204cfc>] (cryptomgr_test+0x40/0x48) [<80204cfc>] (cryptomgr_test+0x40/0x48) from [<80089544>] (kthread+0x80/0x88) [<80089544>] (kthread+0x80/0x88) from [<80040a40>] (kernel_thread_exit+0x0/0x8)

Code: e59f0010 e1a01003 eb126a8d e3a03000 (e5833000)
---[ end trace d52a403a1d1eaa86 ]---
---
 drivers/crypto/caam/caamhash.c |    2 ++
 1 file changed, 2 insertions(+)
drivers/crypto/caam/caamhash.c +2 -0
@@ -1543,6 +1543,8 @@ static int ahash_init(struct ahash_reque
 
 	state->current_buf = 0;
 	state->buf_dma = 0;
+	state->buflen_0 = 0;
+	state->buflen_1 = 0;
 
 	return 0;
 }
author maintainer
#2 lore raw

PATCH 2/22 crypto: caam - fix RNG buffer cache alignment

In reply to Greg Kroah-Hartman

4.0-stable review patch. If anyone has any objections, please let me know.

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

From: Steve Cornelius <[email protected]>

commit 412c98c1bef65fe7589f1300e93735d96130307c upstream.

The hwrng output buffers (2) are cast inside of a a struct (caam_rng_ctx) allocated in one DMA-tagged region. While the kernel's heap allocator should place the overall struct on a cacheline aligned boundary, the 2 buffers contained within may not necessarily align. Consenquently, the ends of unaligned buffers may not fully flush, and if so, stale data will be left behind, resulting in small repeating patterns.

This fix aligns the buffers inside the struct.

Note that not all of the data inside caam_rng_ctx necessarily needs to be DMA-tagged, only the buffers themselves require this. However, a fix would incur the expense of error-handling bloat in the case of allocation failure.

---
 drivers/crypto/caam/caamrng.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/crypto/caam/caamrng.c +1 -1
@@ -56,7 +56,7 @@
 
 /* Buffer, its dma address and lock */
 struct buf_data {
-	u8 buf[RN_BUF_SIZE];
+	u8 buf[RN_BUF_SIZE] ____cacheline_aligned;
 	dma_addr_t addr;
 	struct completion filled;
 	u32 hw_desc[DESC_JOB_O_LEN];
author maintainer
#3 lore raw

PATCH 4/22 clk: at91: pll: fix input range validity check

In reply to Greg Kroah-Hartman

4.0-stable review patch. If anyone has any objections, please let me know.

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

From: Boris Brezillon <[email protected]>

commit 6c7b03e1aef2e92176435f4fa562cc483422d20f upstream.

The PLL impose a certain input range to work correctly, but it appears that this input range does not apply on the input clock (or parent clock) but on the input clock after it has passed the PLL divisor.
Fix the implementation accordingly.

---
 drivers/clk/at91/clk-pll.c |   12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)
drivers/clk/at91/clk-pll.c +10 -2
@@ -173,8 +173,7 @@ static long clk_pll_get_best_div_mul(str
 	int i = 0;
 
 	/* Check if parent_rate is a valid input rate */
-	if (parent_rate < characteristics->input.min ||
-	    parent_rate > characteristics->input.max)
+	if (parent_rate < characteristics->input.min)
 		return -ERANGE;
 
 	/*
@@ -187,6 +186,15 @@ static long clk_pll_get_best_div_mul(str
 	if (!mindiv)
 		mindiv = 1;
 
+	if (parent_rate > characteristics->input.max) {
+		tmpdiv = DIV_ROUND_UP(parent_rate, characteristics->input.max);
+		if (tmpdiv > PLL_DIV_MAX)
+			return -ERANGE;
+
+		if (tmpdiv > mindiv)
+			mindiv = tmpdiv;
+	}
+
 	/*
 	 * Calculate the maximum divider which is limited by PLL register
 	 * layout (limited by the MUL or DIV field size).
author maintainer
#4 lore raw

PATCH 5/22 clk: at91: fix h32mx prototype inclusion in pmc header

In reply to Greg Kroah-Hartman

4.0-stable review patch. If anyone has any objections, please let me know.

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

From: Nicolas Ferre <[email protected]>

commit 28df9c2fb6f896179fcffd5a3f5a86e2d1dff0a5 upstream.

Trivial fix that prevents to compile this pmc clock driver if h32mx clock is present but smd clock isn't.

Fixes bcc5fd49a0fd ("clk: at91: add a driver for the h32mx clock")
---
 drivers/clk/at91/pmc.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/clk/at91/pmc.h +1 -1
@@ -121,7 +121,7 @@ extern void __init of_at91sam9x5_clk_smd
 					       struct at91_pmc *pmc);
 #endif
 
-#if defined(CONFIG_HAVE_AT91_SMD)
+#if defined(CONFIG_HAVE_AT91_H32MX)
 extern void __init of_sama5d4_clk_h32mx_setup(struct device_node *np,
 					      struct at91_pmc *pmc);
 #endif
author maintainer
#5 lore raw

PATCH 6/22 ALSA: hda - adding a DAC/pin preference map for a HP Envy TS machine

In reply to Greg Kroah-Hartman

4.0-stable review patch. If anyone has any objections, please let me know.

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

From: Hui Wang <[email protected]>

commit 6ab42ff44864d26e8e498b8ac655d24ee389d267 upstream.

On a HP Envy TouchSmart laptop, there are 2 speakers (main speaker and subwoofer speaker), 1 headphone and 2 DACs, without this fixup, the headphone will be assigned to a DAC and the 2 speakers will be assigned to another DAC, this assignment makes the surround-2.1 channels invalid.

To fix it, here using a DAC/pin preference map to bind the main speaker to 1 DAC and the subwoofer speaker will be assigned to another DAC.

---
 sound/pci/hda/patch_sigmatel.c |   25 +++++++++++++++++++++++++
 1 file changed, 25 insertions(+)
sound/pci/hda/patch_sigmatel.c +25 -0
@@ -100,6 +100,7 @@ enum {
 	STAC_HP_ENVY_BASS,
 	STAC_HP_BNB13_EQ,
 	STAC_HP_ENVY_TS_BASS,
+	STAC_HP_ENVY_TS_DAC_BIND,
 	STAC_92HD83XXX_GPIO10_EAPD,
 	STAC_92HD83XXX_MODELS
 };
@@ -2170,6 +2171,22 @@ static void stac92hd83xxx_fixup_gpio10_e
 	spec->eapd_switch = 0;
 }
 
+static void hp_envy_ts_fixup_dac_bind(struct hda_codec *codec,
+					    const struct hda_fixup *fix,
+					    int action)
+{
+	struct sigmatel_spec *spec = codec->spec;
+	static hda_nid_t preferred_pairs[] = {
+		0xd, 0x13,
+		0
+	};
+
+	if (action != HDA_FIXUP_ACT_PRE_PROBE)
+		return;
+
+	spec->gen.preferred_dacs = preferred_pairs;
+}
+
 static const struct hda_verb hp_bnb13_eq_verbs[] = {
 	/* 44.1KHz base */
 	{ 0x22, 0x7A6, 0x3E },
@@ -2685,6 +2702,12 @@ static const struct hda_fixup stac92hd83
 			{}
 		},
 	},
+	[STAC_HP_ENVY_TS_DAC_BIND] = {
+		.type = HDA_FIXUP_FUNC,
+		.v.func = hp_envy_ts_fixup_dac_bind,
+		.chained = true,
+		.chain_id = STAC_HP_ENVY_TS_BASS,
+	},
 	[STAC_92HD83XXX_GPIO10_EAPD] = {
 		.type = HDA_FIXUP_FUNC,
 		.v.func = stac92hd83xxx_fixup_gpio10_eapd,
@@ -2763,6 +2786,8 @@ static const struct snd_pci_quirk stac92
 			  "HP bNB13", STAC_HP_BNB13_EQ),
 	SND_PCI_QUIRK(PCI_VENDOR_ID_HP, 0x190e,
 			  "HP ENVY TS", STAC_HP_ENVY_TS_BASS),
+	SND_PCI_QUIRK(PCI_VENDOR_ID_HP, 0x1967,
+			  "HP ENVY TS", STAC_HP_ENVY_TS_DAC_BIND),
 	SND_PCI_QUIRK(PCI_VENDOR_ID_HP, 0x1940,
 			  "HP bNB13", STAC_HP_BNB13_EQ),
 	SND_PCI_QUIRK(PCI_VENDOR_ID_HP, 0x1941,
author maintainer
#6 lore raw

PATCH 7/22 tracing: Have filter check for balanced ops

In reply to Greg Kroah-Hartman

4.0-stable review patch. If anyone has any objections, please let me know.

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

From: Steven Rostedt <[email protected]>

commit 2cf30dc180cea808077f003c5116388183e54f9e upstream.

When the following filter is used it causes a warning to trigger:

 # cd /sys/kernel/debug/tracing
 # echo "((dev==1)blocks==2)" > events/ext4/ext4_truncate_exit/filter
-bash: echo: write error: Invalid argument
 # cat events/ext4/ext4_truncate_exit/filter
((dev==1)blocks==2)
^
parse_error: No error
 ------------[ cut here ]------------
 WARNING: CPU: 2 PID: 1223 at kernel/trace/trace_events_filter.c:1640 replace_preds+0x3c5/0x990()
 Modules linked in: bnep lockd grace bluetooth  ...
 CPU: 3 PID: 1223 Comm: bash Tainted: G        W       4.1.0-rc3-test+ #450
 Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01 v02.05 05/07/2012
  0000000000000668 ffff8800c106bc98 ffffffff816ed4f9 ffff88011ead0cf0
  0000000000000000 ffff8800c106bcd8 ffffffff8107fb07 ffffffff8136b46c
  ffff8800c7d81d48 ffff8800d4c2bc00 ffff8800d4d4f920 00000000ffffffea
 Call Trace:
  [<ffffffff816ed4f9>] dump_stack+0x4c/0x6e
  [<ffffffff8107fb07>] warn_slowpath_common+0x97/0xe0
  [<ffffffff8136b46c>] ? _kstrtoull+0x2c/0x80
  [<ffffffff8107fb6a>] warn_slowpath_null+0x1a/0x20
  [<ffffffff81159065>] replace_preds+0x3c5/0x990
  [<ffffffff811596b2>] create_filter+0x82/0xb0
  [<ffffffff81159944>] apply_event_filter+0xd4/0x180
  [<ffffffff81152bbf>] event_filter_write+0x8f/0x120
  [<ffffffff811db2a8>] __vfs_write+0x28/0xe0
  [<ffffffff811dda43>] ? __sb_start_write+0x53/0xf0
  [<ffffffff812e51e0>] ? security_file_permission+0x30/0xc0
  [<ffffffff811dc408>] vfs_write+0xb8/0x1b0
  [<ffffffff811dc72f>] SyS_write+0x4f/0xb0
  [<ffffffff816f5217>] system_call_fastpath+0x12/0x6a
 ---[ end trace e11028bd95818dcd ]---

Worse yet, reading the error message (the filter again) it says that there was no error, when there clearly was. The issue is that the code that checks the input does not check for balanced ops. That is, having an op between a closed parenthesis and the next token.

This would only cause a warning, and fail out before doing any real harm, but it should still not caues a warning, and the error reported should work:

 # cd /sys/kernel/debug/tracing
 # echo "((dev==1)blocks==2)" > events/ext4/ext4_truncate_exit/filter
-bash: echo: write error: Invalid argument
 # cat events/ext4/ext4_truncate_exit/filter
((dev==1)blocks==2)
^
parse_error: Meaningless filter expression

And give no kernel warning.

---
 kernel/trace/trace_events_filter.c |   11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)
kernel/trace/trace_events_filter.c +9 -2
@@ -1369,19 +1369,26 @@ static int check_preds(struct filter_par
 {
 	int n_normal_preds = 0, n_logical_preds = 0;
 	struct postfix_elt *elt;
+	int cnt = 0;
 
 	list_for_each_entry(elt, &ps->postfix, list) {
-		if (elt->op == OP_NONE)
+		if (elt->op == OP_NONE) {
+			cnt++;
 			continue;
+		}
 
 		if (elt->op == OP_AND || elt->op == OP_OR) {
 			n_logical_preds++;
+			cnt--;
 			continue;
 		}
+		if (elt->op != OP_NOT)
+			cnt--;
 		n_normal_preds++;
+		WARN_ON_ONCE(cnt < 0);
 	}
 
-	if (!n_normal_preds || n_logical_preds >= n_normal_preds) {
+	if (cnt != 1 || !n_normal_preds || n_logical_preds >= n_normal_preds) {
 		parse_error(ps, FILT_ERR_INVALID_FILTER, 0);
 		return -EINVAL;
 	}
author maintainer
#7 lore raw

PATCH 8/22 iser-target: Fix variable-length response error completion

In reply to Greg Kroah-Hartman

4.0-stable review patch. If anyone has any objections, please let me know.

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

From: Sagi Grimberg <[email protected]>

commit 9253e667ab50fd4611a60e1cdd6a6e05a1d91cf1 upstream.

Since commit "2426bd456a6 target: Report correct response ..." we might get a command with data_size that does not fit to the number of allocated data sg elements. Given that we rely on cmd t_data_nents which might be different than the data_size, we sometimes receive local length error completion. The correct approach would be to take the command data_size into account when constructing the ib sg_list.

---
 drivers/infiniband/ulp/isert/ib_isert.c |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/infiniband/ulp/isert/ib_isert.c +4 -2
@@ -2316,7 +2316,6 @@ isert_build_rdma_wr(struct isert_conn *i
 	page_off = offset % PAGE_SIZE;
 
 	send_wr->sg_list = ib_sge;
-	send_wr->num_sge = sg_nents;
 	send_wr->wr_id = (uintptr_t)&isert_cmd->tx_desc;
 	/*
 	 * Perform mapping of TCM scatterlist memory ib_sge dma_addr.
@@ -2336,14 +2335,17 @@ isert_build_rdma_wr(struct isert_conn *i
 			  ib_sge->addr, ib_sge->length, ib_sge->lkey);
 		page_off = 0;
 		data_left -= ib_sge->length;
+		if (!data_left)
+			break;
 		ib_sge++;
 		isert_dbg("Incrementing ib_sge pointer to %p\n", ib_sge);
 	}
 
+	send_wr->num_sge = ++i;
 	isert_dbg("Set outgoing sg_list: %p num_sg: %u from TCM SGLs\n",
 		  send_wr->sg_list, send_wr->num_sge);
 
-	return sg_nents;
+	return send_wr->num_sge;
 }
 
 static int
author maintainer
#8 lore raw

PATCH 9/22 iser-target: Fix possible use-after-free

In reply to Greg Kroah-Hartman

4.0-stable review patch. If anyone has any objections, please let me know.

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

From: Sagi Grimberg <[email protected]>

commit 524630d5824c7a75aab568c6bd1423fd748cd3bb upstream.

iser connection termination process happens in 2 stages:
- isert_wait_conn:
- resumes rdma disconnect
- wait for session commands
- wait for flush completions (post a marked wr to signal we are done)
- wait for logout completion
- queue work for connection cleanup (depends on disconnected/timewait events)
- isert_free_conn
- last reference put on the connection

In case we are terminating during IOs, we might be posting send/recv requests after we posted the last work request which might lead to a use-after-free condition in isert_handle_wc.
After we posted the last wr in isert_wait_conn we are guaranteed that no successful completions will follow (meaning no new work request posts may happen) but other flush errors might still come. So before we put the last reference on the connection, we repeat the process of posting a marked work request (isert_wait4flush) in order to make sure all pending completions were flushed.

---
 drivers/infiniband/ulp/isert/ib_isert.c |    1 +
 1 file changed, 1 insertion(+)
drivers/infiniband/ulp/isert/ib_isert.c +1 -0
@@ -3313,6 +3313,7 @@ static void isert_free_conn(struct iscsi
 {
 	struct isert_conn *isert_conn = conn->context;
 
+	isert_wait4flush(isert_conn);
 	isert_put_conn(isert_conn);
 }
 
author maintainer
#9 lore raw

PATCH 10/22 drm/mgag200: Reject non-character-cell-aligned mode widths

In reply to Greg Kroah-Hartman

4.0-stable review patch. If anyone has any objections, please let me know.

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

From: Adam Jackson <[email protected]>

commit 25161084b1c1b0c29948f6f77266a35f302196b7 upstream.

Turns out 1366x768 does not in fact work on this hardware.

---
 drivers/gpu/drm/mgag200/mgag200_mode.c |    5 +++++
 1 file changed, 5 insertions(+)
drivers/gpu/drm/mgag200/mgag200_mode.c +5 -0
@@ -1526,6 +1526,11 @@ static int mga_vga_mode_valid(struct drm
 		return MODE_BANDWIDTH;
 	}
 
+	if ((mode->hdisplay % 8) != 0 || (mode->hsync_start % 8) != 0 ||
+	    (mode->hsync_end % 8) != 0 || (mode->htotal % 8) != 0) {
+		return MODE_H_ILLEGAL;
+	}
+
 	if (mode->crtc_hdisplay > 2048 || mode->crtc_hsync_start > 4096 ||
 	    mode->crtc_hsync_end > 4096 || mode->crtc_htotal > 4096 ||
 	    mode->crtc_vdisplay > 2048 || mode->crtc_vsync_start > 4096 ||
author maintainer
#10 lore raw

PATCH 11/22 drm/i915: Always reset vma->ggtt_view.pages cache on unbinding

In reply to Greg Kroah-Hartman

4.0-stable review patch. If anyone has any objections, please let me know.

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

From: Chris Wilson <[email protected]>

commit 016a65a39170c3cdca09a6ac343ff4f124668b45 upstream.

With the introduction of multiple views of an obj in the same vm, each vma was taught to cache its copy of the pages (so that different views could have different page arrangements). However, this missed decoupling those vma->ggtt_view.pages when the vma released its reference on the obj->pages. As we don't always free the vma, this leads to a possible scenario (e.g. execbuffer interrupted by the shrinker) where the vma points to a stale obj->pages, and explodes.

Fixes regression from commit fe14d5f4e5468c5b80a24f1a64abcbe116143670

Author: Tvrtko Ursulin <[email protected]>
Date:   Wed Dec 10 17:27:58 2014 +0000

drm/i915: Infrastructure for supporting different GGTT views per object

Tvrtko says, if someone else will be confused how this can happen, key is the reservation execbuffer path. That puts the VMA on the exec_list which prevents i915_vma_unbind and i915_gem_vma_destroy from fully destroying the VMA. So the VMA is left existing as an empty object in the list - unbound and disassociated with the backing store. Kind of a cached memory object. And then re-using it needs to clear the cached pages pointer which is fixed above.

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1227892

Cc Tvrtko Ursulin <[email protected]>
Cc Daniel Vetter <[email protected]>
Cc Michel Thierry <[email protected]>
[Jani: Added Tvrtko's explanation to commit message.]
---
 drivers/gpu/drm/i915/i915_gem.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/i915/i915_gem.c +1 -1
@@ -3088,8 +3088,8 @@ int i915_vma_unbind(struct i915_vma *vma
 		} else if (vma->ggtt_view.pages) {
 			sg_free_table(vma->ggtt_view.pages);
 			kfree(vma->ggtt_view.pages);
-			vma->ggtt_view.pages = NULL;
 		}
+		vma->ggtt_view.pages = NULL;
 	}
 
 	drm_mm_remove_node(&vma->node);
author maintainer
#11 lore raw

PATCH 14/22 ath3k: Add support of 0489:e076 AR3012 device

In reply to Greg Kroah-Hartman

4.0-stable review patch. If anyone has any objections, please let me know.

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

From: Dmitry Tunin <[email protected]>

commit 692c062e7c282164fd7cda68077f79dafd176eaf upstream.

This device requires new firmware files
AthrBT_0x11020100.dfu and ramps_0x11020100_40.dfu added to
/lib/firmware/ar3k/ that are not included in linux-firmware yet.

T: Bus=03 Lev=01 Prnt=01 Port=09 Cnt=06 Dev#= 7 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0489 ProdID=e076 Rev= 0.01
C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms
E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms
I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms
I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms
I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms
I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms

---
 drivers/bluetooth/ath3k.c |    2 ++
 drivers/bluetooth/btusb.c |    1 +
 2 files changed, 3 insertions(+)
drivers/bluetooth/ath3k.c +2 -0
@@ -80,6 +80,7 @@ static const struct usb_device_id ath3k_
 	{ USB_DEVICE(0x0489, 0xe057) },
 	{ USB_DEVICE(0x0489, 0xe056) },
 	{ USB_DEVICE(0x0489, 0xe05f) },
+	{ USB_DEVICE(0x0489, 0xe076) },
 	{ USB_DEVICE(0x0489, 0xe078) },
 	{ USB_DEVICE(0x04c5, 0x1330) },
 	{ USB_DEVICE(0x04CA, 0x3004) },
@@ -135,6 +136,7 @@ static const struct usb_device_id ath3k_
 	{ USB_DEVICE(0x0489, 0xe056), .driver_info = BTUSB_ATH3012 },
 	{ USB_DEVICE(0x0489, 0xe057), .driver_info = BTUSB_ATH3012 },
 	{ USB_DEVICE(0x0489, 0xe05f), .driver_info = BTUSB_ATH3012 },
+	{ USB_DEVICE(0x0489, 0xe076), .driver_info = BTUSB_ATH3012 },
 	{ USB_DEVICE(0x0489, 0xe078), .driver_info = BTUSB_ATH3012 },
 	{ USB_DEVICE(0x04c5, 0x1330), .driver_info = BTUSB_ATH3012 },
 	{ USB_DEVICE(0x04ca, 0x3004), .driver_info = BTUSB_ATH3012 },
drivers/bluetooth/btusb.c +1 -0
@@ -174,6 +174,7 @@ static const struct usb_device_id blackl
 	{ USB_DEVICE(0x0489, 0xe056), .driver_info = BTUSB_ATH3012 },
 	{ USB_DEVICE(0x0489, 0xe057), .driver_info = BTUSB_ATH3012 },
 	{ USB_DEVICE(0x0489, 0xe05f), .driver_info = BTUSB_ATH3012 },
+	{ USB_DEVICE(0x0489, 0xe076), .driver_info = BTUSB_ATH3012 },
 	{ USB_DEVICE(0x0489, 0xe078), .driver_info = BTUSB_ATH3012 },
 	{ USB_DEVICE(0x04c5, 0x1330), .driver_info = BTUSB_ATH3012 },
 	{ USB_DEVICE(0x04ca, 0x3004), .driver_info = BTUSB_ATH3012 },
author maintainer
#12 lore raw

PATCH 15/22 ath3k: add support of 13d3:3474 AR3012 device

In reply to Greg Kroah-Hartman

4.0-stable review patch. If anyone has any objections, please let me know.

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

From: Dmitry Tunin <[email protected]>

commit 0d0cef6183aec0fb6d0c9f00a09ff51ee086bbe2 upstream.

This device requires new firmware files
AthrBT_0x11020100.dfu and ramps_0x11020100_40.dfu added to
/lib/firmware/ar3k/ that are not included in linux-firmware yet.

T: Bus=01 Lev=01 Prnt=01 Port=04 Cnt=01 Dev#= 4 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=13d3 ProdID=3474 Rev=00.01
C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb

---
 drivers/bluetooth/ath3k.c |    2 ++
 drivers/bluetooth/btusb.c |    1 +
 2 files changed, 3 insertions(+)
drivers/bluetooth/ath3k.c +2 -0
@@ -112,6 +112,7 @@ static const struct usb_device_id ath3k_
 	{ USB_DEVICE(0x13d3, 0x3408) },
 	{ USB_DEVICE(0x13d3, 0x3423) },
 	{ USB_DEVICE(0x13d3, 0x3432) },
+	{ USB_DEVICE(0x13d3, 0x3474) },
 
 	/* Atheros AR5BBU12 with sflash firmware */
 	{ USB_DEVICE(0x0489, 0xE02C) },
@@ -168,6 +169,7 @@ static const struct usb_device_id ath3k_
 	{ USB_DEVICE(0x13d3, 0x3408), .driver_info = BTUSB_ATH3012 },
 	{ USB_DEVICE(0x13d3, 0x3423), .driver_info = BTUSB_ATH3012 },
 	{ USB_DEVICE(0x13d3, 0x3432), .driver_info = BTUSB_ATH3012 },
+	{ USB_DEVICE(0x13d3, 0x3474), .driver_info = BTUSB_ATH3012 },
 
 	/* Atheros AR5BBU22 with sflash firmware */
 	{ USB_DEVICE(0x0489, 0xE036), .driver_info = BTUSB_ATH3012 },
drivers/bluetooth/btusb.c +1 -0
@@ -206,6 +206,7 @@ static const struct usb_device_id blackl
 	{ USB_DEVICE(0x13d3, 0x3408), .driver_info = BTUSB_ATH3012 },
 	{ USB_DEVICE(0x13d3, 0x3423), .driver_info = BTUSB_ATH3012 },
 	{ USB_DEVICE(0x13d3, 0x3432), .driver_info = BTUSB_ATH3012 },
+	{ USB_DEVICE(0x13d3, 0x3474), .driver_info = BTUSB_ATH3012 },
 
 	/* Atheros AR5BBU12 with sflash firmware */
 	{ USB_DEVICE(0x0489, 0xe02c), .driver_info = BTUSB_IGNORE },
author maintainer
#13 lore raw

PATCH 17/22 cdc-acm: Add support of ATOL FPrint fiscal printers

In reply to Greg Kroah-Hartman

4.0-stable review patch. If anyone has any objections, please let me know.

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

From: Alexey Sokolov <[email protected]>

commit 15bf722e6f6c0b884521a0363204532e849deb7f upstream.

ATOL FPrint fiscal printers require usb_clear_halt to be executed to work properly. Add quirk to fix the issue.

---
 drivers/usb/class/cdc-acm.c |    9 +++++++++
 drivers/usb/class/cdc-acm.h |    1 +
 2 files changed, 10 insertions(+)
drivers/usb/class/cdc-acm.c +9 -0
@@ -1468,6 +1468,11 @@ skip_countries:
 		goto alloc_fail8;
 	}
 
+	if (quirks & CLEAR_HALT_CONDITIONS) {
+		usb_clear_halt(usb_dev, usb_rcvbulkpipe(usb_dev, epread->bEndpointAddress));
+		usb_clear_halt(usb_dev, usb_sndbulkpipe(usb_dev, epwrite->bEndpointAddress));
+	}
+
 	return 0;
 alloc_fail8:
 	if (acm->country_codes) {
@@ -1747,6 +1752,10 @@ static const struct usb_device_id acm_id
 	.driver_info = NO_UNION_NORMAL, /* reports zero length descriptor */
 	},
 
+	{ USB_DEVICE(0x2912, 0x0001), /* ATOL FPrint */
+	.driver_info = CLEAR_HALT_CONDITIONS,
+	},
+
 	/* Nokia S60 phones expose two ACM channels. The first is
 	 * a modem and is picked up by the standard AT-command
 	 * information below. The second is 'vendor-specific' but
drivers/usb/class/cdc-acm.h +1 -0
@@ -133,3 +133,4 @@ struct acm {
 #define NO_DATA_INTERFACE		BIT(4)
 #define IGNORE_DEVICE			BIT(5)
 #define QUIRK_CONTROL_LINE_STATE	BIT(6)
+#define CLEAR_HALT_CONDITIONS		BIT(7)
author maintainer
#14 lore raw

PATCH 18/22 ARM: EXYNOS: Fix failed second suspend on Exynos4

In reply to Greg Kroah-Hartman

4.0-stable review patch. If anyone has any objections, please let me know.

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

From: Krzysztof Kozlowski <[email protected]>

commit 6f024978e74bda616b27183adee029b65eb27032 upstream.

On Exynos4412 boards (Trats2, Odroid U3) after enabling L2 cache in 56b60b8bce4a ("ARM: 8265/1: dts: exynos4: Add nodes for L2 cache controller") the second suspend to RAM failed. First suspend worked fine but the next one hang just after powering down of secondary CPUs (system consumed energy as it would be running but was not responsive).

The issue was caused by enabling delayed reset assertion for CPU0 just after issuing power down of cores. This was introduced for Exynos4 in 13cfa6c4f7fa ("ARM: EXYNOS: Fix CPU idle clock down after CPU off").

The whole behavior is not well documented but after checking with vendor code this should be done like this (on Exynos4):
1. Enable delayed reset assertion when system is running (for all CPUs).
2. Disable delayed reset assertion before suspending the system. This can be done after powering off secondary CPUs.
3. Re-enable the delayed reset assertion when system is resumed.

Fixes 13cfa6c4f7fa ("ARM: EXYNOS: Fix CPU idle clock down after CPU off")
---
 arch/arm/mach-exynos/common.h  |    2 ++
 arch/arm/mach-exynos/exynos.c  |   27 +++++++++++++++++++++++++++
 arch/arm/mach-exynos/platsmp.c |   39 ++-------------------------------------
 arch/arm/mach-exynos/suspend.c |    3 +++
 4 files changed, 34 insertions(+), 37 deletions(-)
arch/arm/mach-exynos/common.h +2 -0
@@ -153,6 +153,8 @@ extern void exynos_enter_aftr(void);
 
 extern struct cpuidle_exynos_data cpuidle_coupled_exynos_data;
 
+extern void exynos_set_delayed_reset_assertion(bool enable);
+
 extern void s5p_init_cpu(void __iomem *cpuid_addr);
 extern unsigned int samsung_rev(void);
 extern void __iomem *cpu_boot_reg_base(void);
arch/arm/mach-exynos/exynos.c +27 -0
@@ -166,6 +166,33 @@ static void __init exynos_init_io(void)
 	exynos_map_io();
 }
 
+/*
+ * Set or clear the USE_DELAYED_RESET_ASSERTION option. Used by smp code
+ * and suspend.
+ *
+ * This is necessary only on Exynos4 SoCs. When system is running
+ * USE_DELAYED_RESET_ASSERTION should be set so the ARM CLK clock down
+ * feature could properly detect global idle state when secondary CPU is
+ * powered down.
+ *
+ * However this should not be set when such system is going into suspend.
+ */
+void exynos_set_delayed_reset_assertion(bool enable)
+{
+	if (soc_is_exynos4()) {
+		unsigned int tmp, core_id;
+
+		for (core_id = 0; core_id < num_possible_cpus(); core_id++) {
+			tmp = pmu_raw_readl(EXYNOS_ARM_CORE_OPTION(core_id));
+			if (enable)
+				tmp |= S5P_USE_DELAYED_RESET_ASSERTION;
+			else
+				tmp &= ~(S5P_USE_DELAYED_RESET_ASSERTION);
+			pmu_raw_writel(tmp, EXYNOS_ARM_CORE_OPTION(core_id));
+		}
+	}
+}
+
 static const struct of_device_id exynos_dt_pmu_match[] = {
 	{ .compatible = "samsung,exynos3250-pmu" },
 	{ .compatible = "samsung,exynos4210-pmu" },
arch/arm/mach-exynos/platsmp.c +2 -37
@@ -34,30 +34,6 @@
 
 extern void exynos4_secondary_startup(void);
 
-/*
- * Set or clear the USE_DELAYED_RESET_ASSERTION option, set on Exynos4 SoCs
- * during hot-(un)plugging CPUx.
- *
- * The feature can be cleared safely during first boot of secondary CPU.
- *
- * Exynos4 SoCs require setting USE_DELAYED_RESET_ASSERTION during powering
- * down a CPU so the CPU idle clock down feature could properly detect global
- * idle state when CPUx is off.
- */
-static void exynos_set_delayed_reset_assertion(u32 core_id, bool enable)
-{
-	if (soc_is_exynos4()) {
-		unsigned int tmp;
-
-		tmp = pmu_raw_readl(EXYNOS_ARM_CORE_OPTION(core_id));
-		if (enable)
-			tmp |= S5P_USE_DELAYED_RESET_ASSERTION;
-		else
-			tmp &= ~(S5P_USE_DELAYED_RESET_ASSERTION);
-		pmu_raw_writel(tmp, EXYNOS_ARM_CORE_OPTION(core_id));
-	}
-}
-
 #ifdef CONFIG_HOTPLUG_CPU
 static inline void cpu_leave_lowpower(u32 core_id)
 {
@@ -73,8 +49,6 @@ static inline void cpu_leave_lowpower(u3
 	  : "=&r" (v)
 	  : "Ir" (CR_C), "Ir" (0x40)
 	  : "cc");
-
-	 exynos_set_delayed_reset_assertion(core_id, false);
 }
 
 static inline void platform_do_lowpower(unsigned int cpu, int *spurious)
@@ -87,14 +61,6 @@ static inline void platform_do_lowpower(
 		/* Turn the CPU off on next WFI instruction. */
 		exynos_cpu_power_down(core_id);
 
-		/*
-		 * Exynos4 SoCs require setting
-		 * USE_DELAYED_RESET_ASSERTION so the CPU idle
-		 * clock down feature could properly detect
-		 * global idle state when CPUx is off.
-		 */
-		exynos_set_delayed_reset_assertion(core_id, true);
-
 		wfi();
 
 		if (pen_release == core_id) {
@@ -354,9 +320,6 @@ static int exynos_boot_secondary(unsigne
 		udelay(10);
 	}
 
-	/* No harm if this is called during first boot of secondary CPU */
-	exynos_set_delayed_reset_assertion(core_id, false);
-
 	/*
 	 * now the secondary core is starting up let it run its
 	 * calibrations, then wait for it to finish
@@ -403,6 +366,8 @@ static void __init exynos_smp_prepare_cp
 
 	exynos_sysram_init();
 
+	exynos_set_delayed_reset_assertion(true);
+
 	if (read_cpuid_part() == ARM_CPU_PART_CORTEX_A9)
 		scu_enable(scu_base_addr());
 
arch/arm/mach-exynos/suspend.c +3 -0
@@ -235,6 +235,8 @@ static void exynos_pm_enter_sleep_mode(v
 
 static void exynos_pm_prepare(void)
 {
+	exynos_set_delayed_reset_assertion(false);
+
 	/* Set wake-up mask registers */
 	exynos_pm_set_wakeup_mask();
 
@@ -383,6 +385,7 @@ early_wakeup:
 
 	/* Clear SLEEP mode set in INFORM1 */
 	pmu_raw_writel(0x0, S5P_INFORM1);
+	exynos_set_delayed_reset_assertion(true);
 }
 
 static void exynos3250_pm_resume(void)
author maintainer
#15 lore raw

PATCH 19/22 kprobes/x86: Return correct length in __copy_instruction()

In reply to Greg Kroah-Hartman

4.0-stable review patch. If anyone has any objections, please let me know.

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

From: Eugene Shatokhin <[email protected]>

commit c80e5c0c23ce2282476fdc64c4b5e3d3a40723fd upstream.

On x86-64, __copy_instruction() always returns 0 (error) if the instruction uses %rip-relative addressing. This is because kernel_insn_init() is called the second time for 'insn' instance in such cases and sets all its fields to 0.

Because of this, trying to place a kprobe on such instruction will fail, register_kprobe() will return -EINVAL.

This patch fixes the problem.

---
 arch/x86/kernel/kprobes/core.c |    9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)
arch/x86/kernel/kprobes/core.c +6 -3
@@ -354,6 +354,7 @@ int __copy_instruction(u8 *dest, u8 *src
 {
 	struct insn insn;
 	kprobe_opcode_t buf[MAX_INSN_SIZE];
+	int length;
 	unsigned long recovered_insn =
 		recover_probed_instruction(buf, (unsigned long)src);
 
@@ -361,16 +362,18 @@ int __copy_instruction(u8 *dest, u8 *src
 		return 0;
 	kernel_insn_init(&insn, (void *)recovered_insn, MAX_INSN_SIZE);
 	insn_get_length(&insn);
+	length = insn.length;
+
 	/* Another subsystem puts a breakpoint, failed to recover */
 	if (insn.opcode.bytes[0] == BREAKPOINT_INSTRUCTION)
 		return 0;
-	memcpy(dest, insn.kaddr, insn.length);
+	memcpy(dest, insn.kaddr, length);
 
 #ifdef CONFIG_X86_64
 	if (insn_rip_relative(&insn)) {
 		s64 newdisp;
 		u8 *disp;
-		kernel_insn_init(&insn, dest, insn.length);
+		kernel_insn_init(&insn, dest, length);
 		insn_get_displacement(&insn);
 		/*
 		 * The copied instruction uses the %rip-relative addressing
@@ -394,7 +397,7 @@ int __copy_instruction(u8 *dest, u8 *src
 		*(s32 *) disp = (s32) newdisp;
 	}
 #endif
-	return insn.length;
+	return length;
 }
 
 static int arch_copy_kprobe(struct kprobe *p)
author maintainer
#16 lore raw

PATCH 20/22 dm: fix NULL pointer when clone_and_map_rq returns !DM_MAPIO_REMAPPED

In reply to Greg Kroah-Hartman

4.0-stable review patch. If anyone has any objections, please let me know.

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

From: Junichi Nomura <[email protected]>

commit 3a1407559a593d4360af12dd2df5296bf8eb0d28 upstream.

When stacking request-based DM on blk_mq device, request cloning and remapping are done in a single call to target's clone_and_map_rq(). The clone is allocated and valid only if clone_and_map_rq() returns DM_MAPIO_REMAPPED.

The "IS_ERR(clone)" check in map_request() does not cover all the !DM_MAPIO_REMAPPED cases that are possible (E.g. if underlying devices are not ready or unavailable, clone_and_map_rq() may return DM_MAPIO_REQUEUE without ever having established an ERR_PTR). Fix this by explicitly checking for a return that is not DM_MAPIO_REMAPPED in map_request().

Without this fix, DM core may call setup_clone() for a NULL clone and oops like this:

   BUG: unable to handle kernel NULL pointer dereference at 0000000000000068
   IP: [<ffffffff81227525>] blk_rq_prep_clone+0x7d/0x137
   ...
   CPU: 2 PID: 5793 Comm: kdmwork-253:3 Not tainted 4.0.0-nm #1
   ...
   Call Trace:
    [<ffffffffa01d1c09>] map_tio_request+0xa9/0x258 [dm_mod]
    [<ffffffff81071de9>] kthread_worker_fn+0xfd/0x150
    [<ffffffff81071cec>] ? kthread_parkme+0x24/0x24
    [<ffffffff81071cec>] ? kthread_parkme+0x24/0x24
    [<ffffffff81071fdd>] kthread+0xe6/0xee
    [<ffffffff81093a59>] ? put_lock_stats+0xe/0x20
    [<ffffffff81071ef7>] ? __init_kthread_worker+0x5b/0x5b
    [<ffffffff814c2d98>] ret_from_fork+0x58/0x90
    [<ffffffff81071ef7>] ? __init_kthread_worker+0x5b/0x5b
Fixes e5863d9ad ("dm: allocate requests in target when stacking on blk-mq devices")
---
 drivers/md/dm.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/md/dm.c +2 -2
@@ -1889,8 +1889,8 @@ static int map_request(struct dm_target
 			dm_kill_unmapped_request(rq, r);
 			return r;
 		}
-		if (IS_ERR(clone))
-			return DM_MAPIO_REQUEUE;
+		if (r != DM_MAPIO_REMAPPED)
+			return r;
 		if (setup_clone(clone, rq, tio, GFP_KERNEL)) {
 			/* -ENOMEM */
 			ti->type->release_clone_rq(clone);
author maintainer
#17 lore raw

PATCH 21/22 drm/i915: Avoid GPU hang when coming out of s3 or s4

In reply to Greg Kroah-Hartman

4.0-stable review patch. If anyone has any objections, please let me know.

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

From: Peter Antoine <[email protected]>

commit 364aece01a2dd748fc36a1e8bf52ef639b0857bd upstream.

This patch fixes a timing issue that causes a GPU hang when the system comes out of power saving.

During pm_resume, We are submitting batchbuffers before enabling Interrupts this is causing us to miss the context switch interrupt, and in consequence intel_execlists_handle_ctx_events is not triggered.

This patch is based on a patch from Deepak S <[email protected]> from another platform.

The patch fixes an issue introduced by:
commit e7778be1eab918274f79603d7c17b3ec8be77386 drm/i915: Fix startup failure in LRC mode after recent init changes

The above patch added a call to init_context() to fix an issue introduced by a previous patch. But, it then opened up a small timing window for the batches being added by the init_context (basically setting up the context) to complete before the interrupts have been turned on, thus hanging the GPU.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89600

[Jani: fixed typo in subject, massaged the comments a bit]
---
 drivers/gpu/drm/i915/i915_drv.c |   13 ++++++++++---
 1 file changed, 10 insertions(+), 3 deletions(-)
drivers/gpu/drm/i915/i915_drv.c +10 -3
@@ -693,6 +693,16 @@ static int i915_drm_resume(struct drm_de
 		intel_init_pch_refclk(dev);
 		drm_mode_config_reset(dev);
 
+		/*
+		 * Interrupts have to be enabled before any batches are run.
+		 * If not the GPU will hang. i915_gem_init_hw() will initiate
+		 * batches to update/restore the context.
+		 *
+		 * Modeset enabling in intel_modeset_init_hw() also needs
+		 * working interrupts.
+		 */
+		intel_runtime_pm_enable_interrupts(dev_priv);
+
 		mutex_lock(&dev->struct_mutex);
 		if (i915_gem_init_hw(dev)) {
 			DRM_ERROR("failed to re-initialize GPU, declaring wedged!\n");
@@ -700,9 +710,6 @@ static int i915_drm_resume(struct drm_de
 		}
 		mutex_unlock(&dev->struct_mutex);
 
-		/* We need working interrupts for modeset enabling ... */
-		intel_runtime_pm_enable_interrupts(dev_priv);
-
 		intel_modeset_init_hw(dev);
 
 		spin_lock_irq(&dev_priv->irq_lock);
author maintainer
#18 lore raw

PATCH 22/22 powerpc/powernv: Restore non-volatile CRs after nap

In reply to Greg Kroah-Hartman

4.0-stable review patch. If anyone has any objections, please let me know.

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

From: Sam Bobroff <[email protected]>

commit 0aab3747091db309b8a484cfd382a41644552aa3 upstream.

Patches 7cba160ad "powernv/cpuidle: Redesign idle states management" and 77b54e9f2 "powernv/powerpc: Add winkle support for offline cpus" use non-volatile condition registers (cr2, cr3 and cr4) early in the system reset interrupt handler (system_reset_pSeries()) before it has been determined if state loss has occurred. If state loss has not occurred, control returns via the power7_wakeup_noloss() path which does not restore those condition registers, leaving them corrupted.

Fix this by restoring the condition registers in the power7_wakeup_noloss() case.

This is apparent when running a KVM guest on hardware that does not support winkle or sleep and the guest makes use of secondary threads. In practice this means Power7 machines, though some early unreleased Power8 machines may also be susceptible.

The secondary CPUs are taken off line before the guest is started and they call pnv_smp_cpu_kill_self(). This checks support for sleep states (in this case there is no support) and power7_nap() is called.

When the CPU is woken, power7_nap() returns and because the CPU is still off line, the main while loop executes again. The sleep states support test is executed again, but because the tested values cannot have changed, the compiler has optimized the test away and instead we rely on the result of the first test, which has been left in cr3 and/or cr4. With the result overwritten, the wrong branch is taken and power7_winkle() is called on a CPU that does not support it, leading to it stalling.

Fixes 7cba160ad789 ("powernv/cpuidle: Redesign idle states management")
Fixes 77b54e9f213f ("powernv/powerpc: Add winkle support for offline cpus")
[mpe: Massage change log a bit more]
Cc Greg Kurz <[email protected]>
---
 arch/powerpc/kernel/idle_power7.S |    2 ++
 1 file changed, 2 insertions(+)
arch/powerpc/kernel/idle_power7.S +2 -0
@@ -500,9 +500,11 @@ BEGIN_FTR_SECTION
 	CHECK_HMI_INTERRUPT
 END_FTR_SECTION_IFSET(CPU_FTR_HVMODE)
 	ld	r1,PACAR1(r13)
+	ld	r6,_CCR(r1)
 	ld	r4,_MSR(r1)
 	ld	r5,_NIP(r1)
 	addi	r1,r1,INT_FRAME_SIZE
+	mtcr	r6
 	mtspr	SPRN_SRR1,r4
 	mtspr	SPRN_SRR0,r5
 	rfid
#19 lore raw
In reply to Greg Kroah-Hartman
Quoted 8 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.0.7 release. There are 22 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 Mon Jun 29 01:08:46 UTC 2015. Anything received after that time might be too late.

Quoted 8 lines

The whole patch series can be found in one patch at:

	kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.0.7-rc1.gz

and the diffstat can be found below.

thanks,

greg k-h

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

thanks,
-- Shuah

Signature · 5 lines
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America (Silicon Valley)
[email protected] | (970) 217-8978
#20 lore raw
In reply to Greg Kroah-Hartman
Quoted 8 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.0.7 release. There are 22 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 Mon Jun 29 01:08:46 UTC 2015. Anything received after that time might be too late.

Build results:

	total: 124 pass: 124 fail: 0
Qemu test results:
	total: 30 pass: 30 fail: 0

Details are available at http://server.roeck-us.net:8010/builders.

Guenter

#21 lore raw
In reply to Greg Kroah-Hartman
Quoted 4 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.0.7 release. There are 22 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.

Compiled and booted on x86_32. No errors in dmesg.

regards
sudip