Skip to contentSkip to conversation

4.14.73-stable review

PATCH In review Greg Kroah-Hartman 7 participants 77 messages Sep 27, 2018 – Sep 28, 2018

Subsystems (2)
lore
Share & tools
lore
author maintainer
#5 lore raw

PATCH 5/64 pppoe: fix reception of frames with no mac header

In reply to Greg Kroah-Hartman

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

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

From: Guillaume Nault <[email protected]>

[ Upstream commit 8540827ebac6b654ab2f69c8fbce9e4fbd6304a0 ]

pppoe_rcv() needs to look back at the Ethernet header in order to lookup the PPPoE session. Therefore we need to ensure that the mac header is big enough to contain an Ethernet header. Otherwise eth_hdr(skb)->h_source might access invalid data.

==================================================================

BUG: KMSAN: uninit-value in __get_item drivers/net/ppp/pppoe.c:172 [inline]
BUG: KMSAN: uninit-value in get_item drivers/net/ppp/pppoe.c:236 [inline]
BUG: KMSAN: uninit-value in pppoe_rcv+0xcef/0x10e0 drivers/net/ppp/pppoe.c:450
CPU: 0 PID: 4543 Comm: syz-executor355 Not tainted 4.16.0+ #87
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google
01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:17 [inline]
 dump_stack+0x185/0x1d0 lib/dump_stack.c:53
 kmsan_report+0x142/0x240 mm/kmsan/kmsan.c:1067
 __msan_warning_32+0x6c/0xb0 mm/kmsan/kmsan_instr.c:683
 __get_item drivers/net/ppp/pppoe.c:172 [inline]
 get_item drivers/net/ppp/pppoe.c:236 [inline]
 pppoe_rcv+0xcef/0x10e0 drivers/net/ppp/pppoe.c:450
 __netif_receive_skb_core+0x47df/0x4a90 net/core/dev.c:4562
 __netif_receive_skb net/core/dev.c:4627 [inline]
 netif_receive_skb_internal+0x49d/0x630 net/core/dev.c:4701
 netif_receive_skb+0x230/0x240 net/core/dev.c:4725
 tun_rx_batched drivers/net/tun.c:1555 [inline]
 tun_get_user+0x740f/0x7c60 drivers/net/tun.c:1962
 tun_chr_write_iter+0x1d4/0x330 drivers/net/tun.c:1990
 call_write_iter include/linux/fs.h:1782 [inline]
 new_sync_write fs/read_write.c:469 [inline]
 __vfs_write+0x7fb/0x9f0 fs/read_write.c:482
 vfs_write+0x463/0x8d0 fs/read_write.c:544
 SYSC_write+0x172/0x360 fs/read_write.c:589
 SyS_write+0x55/0x80 fs/read_write.c:581
 do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
 entry_SYSCALL_64_after_hwframe+0x3d/0xa2
RIP: 0033:0x4447c9
RSP: 002b:00007fff64c8fc28 EFLAGS: 00000297 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00000000004447c9
RDX: 000000000000fd87 RSI: 0000000020000600 RDI: 0000000000000004
RBP: 00000000006cf018 R08: 00007fff64c8fda8 R09: 00007fff00006bda
R10: 0000000000005fe7 R11: 0000000000000297 R12: 00000000004020d0
R13: 0000000000402160 R14: 0000000000000000 R15: 0000000000000000

Uninit was created at:

 kmsan_save_stack_with_flags mm/kmsan/kmsan.c:278 [inline]
 kmsan_internal_poison_shadow+0xb8/0x1b0 mm/kmsan/kmsan.c:188
 kmsan_kmalloc+0x94/0x100 mm/kmsan/kmsan.c:314
 kmsan_slab_alloc+0x11/0x20 mm/kmsan/kmsan.c:321
 slab_post_alloc_hook mm/slab.h:445 [inline]
 slab_alloc_node mm/slub.c:2737 [inline]
 __kmalloc_node_track_caller+0xaed/0x11c0 mm/slub.c:4369
 __kmalloc_reserve net/core/skbuff.c:138 [inline]
 __alloc_skb+0x2cf/0x9f0 net/core/skbuff.c:206
 alloc_skb include/linux/skbuff.h:984 [inline]
 alloc_skb_with_frags+0x1d4/0xb20 net/core/skbuff.c:5234
 sock_alloc_send_pskb+0xb56/0x1190 net/core/sock.c:2085
 tun_alloc_skb drivers/net/tun.c:1532 [inline]
 tun_get_user+0x2242/0x7c60 drivers/net/tun.c:1829
 tun_chr_write_iter+0x1d4/0x330 drivers/net/tun.c:1990
 call_write_iter include/linux/fs.h:1782 [inline]
 new_sync_write fs/read_write.c:469 [inline]
 __vfs_write+0x7fb/0x9f0 fs/read_write.c:482
 vfs_write+0x463/0x8d0 fs/read_write.c:544
 SYSC_write+0x172/0x360 fs/read_write.c:589
 SyS_write+0x55/0x80 fs/read_write.c:581
 do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
 entry_SYSCALL_64_after_hwframe+0x3d/0xa2
==================================================================
Fixes 224cf5ad14c0 ("ppp: Move the PPP drivers")
Reported-by [email protected]
---
 drivers/net/ppp/pppoe.c |    3 +++
 1 file changed, 3 insertions(+)
drivers/net/ppp/pppoe.c +3 -0
@@ -429,6 +429,9 @@ static int pppoe_rcv(struct sk_buff *skb
 	if (!skb)
 		goto out;
 
+	if (skb_mac_header_len(skb) < ETH_HLEN)
+		goto drop;
+
 	if (!pskb_may_pull(skb, sizeof(struct pppoe_hdr)))
 		goto drop;
 
author maintainer
#6 lore raw

PATCH 6/64 qmi_wwan: set DTR for modems in forced USB2 mode

In reply to Greg Kroah-Hartman

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

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

From: "Bj�rn Mork" <[email protected]>

[ Upstream commit 922005c7f50e7f4b2a6dbc182e9c575b4f92396b ]

Recent firmware revisions have added the ability to force these modems to USB2 mode, hiding their SuperSpeed capabilities from the host. The driver has been using the SuperSpeed capability, as shown by the bcdUSB field of the device descriptor, to detect the need to enable the DTR quirk. This method fails when the modems are forced to USB2 mode by the modem firmware.

Fix by unconditionally enabling the DTR quirk for the affected device IDs.

---
 drivers/net/usb/qmi_wwan.c |   14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)
drivers/net/usb/qmi_wwan.c +7 -7
@@ -1205,13 +1205,13 @@ static const struct usb_device_id produc
 	{QMI_FIXED_INTF(0x1199, 0x9061, 8)},	/* Sierra Wireless Modem */
 	{QMI_FIXED_INTF(0x1199, 0x9063, 8)},	/* Sierra Wireless EM7305 */
 	{QMI_FIXED_INTF(0x1199, 0x9063, 10)},	/* Sierra Wireless EM7305 */
-	{QMI_FIXED_INTF(0x1199, 0x9071, 8)},	/* Sierra Wireless MC74xx */
-	{QMI_FIXED_INTF(0x1199, 0x9071, 10)},	/* Sierra Wireless MC74xx */
-	{QMI_FIXED_INTF(0x1199, 0x9079, 8)},	/* Sierra Wireless EM74xx */
-	{QMI_FIXED_INTF(0x1199, 0x9079, 10)},	/* Sierra Wireless EM74xx */
-	{QMI_FIXED_INTF(0x1199, 0x907b, 8)},	/* Sierra Wireless EM74xx */
-	{QMI_FIXED_INTF(0x1199, 0x907b, 10)},	/* Sierra Wireless EM74xx */
-	{QMI_FIXED_INTF(0x1199, 0x9091, 8)},	/* Sierra Wireless EM7565 */
+	{QMI_QUIRK_SET_DTR(0x1199, 0x9071, 8)},	/* Sierra Wireless MC74xx */
+	{QMI_QUIRK_SET_DTR(0x1199, 0x9071, 10)},/* Sierra Wireless MC74xx */
+	{QMI_QUIRK_SET_DTR(0x1199, 0x9079, 8)},	/* Sierra Wireless EM74xx */
+	{QMI_QUIRK_SET_DTR(0x1199, 0x9079, 10)},/* Sierra Wireless EM74xx */
+	{QMI_QUIRK_SET_DTR(0x1199, 0x907b, 8)},	/* Sierra Wireless EM74xx */
+	{QMI_QUIRK_SET_DTR(0x1199, 0x907b, 10)},/* Sierra Wireless EM74xx */
+	{QMI_QUIRK_SET_DTR(0x1199, 0x9091, 8)},	/* Sierra Wireless EM7565 */
 	{QMI_FIXED_INTF(0x1bbb, 0x011e, 4)},	/* Telekom Speedstick LTE II (Alcatel One Touch L100V LTE) */
 	{QMI_FIXED_INTF(0x1bbb, 0x0203, 2)},	/* Alcatel L800MA */
 	{QMI_FIXED_INTF(0x2357, 0x0201, 4)},	/* TP-LINK HSUPA Modem MA180 */
author maintainer
#10 lore raw

PATCH 10/64 net/sched: act_sample: fix NULL dereference in the data path

In reply to Greg Kroah-Hartman

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

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

From: Davide Caratti <[email protected]>

[ Upstream commit 34043d250f51368f214aed7f54c2dc29c819a8c7 ]

Matteo reported the following splat, testing the datapath of TC 'sample':

 BUG: KASAN: null-ptr-deref in tcf_sample_act+0xc4/0x310
 Read of size 8 at addr 0000000000000000 by task nc/433

 CPU: 0 PID: 433 Comm: nc Not tainted 4.19.0-rc3-kvm #17
 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS ?-20180531_142017-buildhw-08.phx2.fedoraproject.org-1.fc28 04/01/2014
 Call Trace:
  kasan_report.cold.6+0x6c/0x2fa
  tcf_sample_act+0xc4/0x310
  ? dev_hard_start_xmit+0x117/0x180
  tcf_action_exec+0xa3/0x160
  tcf_classify+0xdd/0x1d0
  htb_enqueue+0x18e/0x6b0
  ? deref_stack_reg+0x7a/0xb0
  ? htb_delete+0x4b0/0x4b0
  ? unwind_next_frame+0x819/0x8f0
  ? entry_SYSCALL_64_after_hwframe+0x44/0xa9
  __dev_queue_xmit+0x722/0xca0
  ? unwind_get_return_address_ptr+0x50/0x50
  ? netdev_pick_tx+0xe0/0xe0
  ? save_stack+0x8c/0xb0
  ? kasan_kmalloc+0xbe/0xd0
  ? __kmalloc_track_caller+0xe4/0x1c0
  ? __kmalloc_reserve.isra.45+0x24/0x70
  ? __alloc_skb+0xdd/0x2e0
  ? sk_stream_alloc_skb+0x91/0x3b0
  ? tcp_sendmsg_locked+0x71b/0x15a0
  ? tcp_sendmsg+0x22/0x40
  ? __sys_sendto+0x1b0/0x250
  ? __x64_sys_sendto+0x6f/0x80
  ? do_syscall_64+0x5d/0x150
  ? entry_SYSCALL_64_after_hwframe+0x44/0xa9
  ? __sys_sendto+0x1b0/0x250
  ? __x64_sys_sendto+0x6f/0x80
  ? do_syscall_64+0x5d/0x150
  ? entry_SYSCALL_64_after_hwframe+0x44/0xa9
  ip_finish_output2+0x495/0x590
  ? ip_copy_metadata+0x2e0/0x2e0
  ? skb_gso_validate_network_len+0x6f/0x110
  ? ip_finish_output+0x174/0x280
  __tcp_transmit_skb+0xb17/0x12b0
  ? __tcp_select_window+0x380/0x380
  tcp_write_xmit+0x913/0x1de0
  ? __sk_mem_schedule+0x50/0x80
  tcp_sendmsg_locked+0x49d/0x15a0
  ? tcp_rcv_established+0x8da/0xa30
  ? tcp_set_state+0x220/0x220
  ? clear_user+0x1f/0x50
  ? iov_iter_zero+0x1ae/0x590
  ? __fget_light+0xa0/0xe0
  tcp_sendmsg+0x22/0x40
  __sys_sendto+0x1b0/0x250
  ? __ia32_sys_getpeername+0x40/0x40
  ? _copy_to_user+0x58/0x70
  ? poll_select_copy_remaining+0x176/0x200
  ? __pollwait+0x1c0/0x1c0
  ? ktime_get_ts64+0x11f/0x140
  ? kern_select+0x108/0x150
  ? core_sys_select+0x360/0x360
  ? vfs_read+0x127/0x150
  ? kernel_write+0x90/0x90
  __x64_sys_sendto+0x6f/0x80
  do_syscall_64+0x5d/0x150
  entry_SYSCALL_64_after_hwframe+0x44/0xa9
 RIP: 0033:0x7fefef2b129d
 Code: ff ff ff ff eb b6 0f 1f 80 00 00 00 00 48 8d 05 51 37 0c 00 41 89 ca 8b 00 85 c0 75 20 45 31 c9 45 31 c0 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 6b f3 c3 66 0f 1f 84 00 00 00 00 00 41 56 41
 RSP: 002b:00007fff2f5350c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
 RAX: ffffffffffffffda RBX: 000056118d60c120 RCX: 00007fefef2b129d
 RDX: 0000000000002000 RSI: 000056118d629320 RDI: 0000000000000003
 RBP: 000056118d530370 R08: 0000000000000000 R09: 0000000000000000
 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000002000
 R13: 000056118d5c2a10 R14: 000056118d5c2a10 R15: 000056118d5303b8

tcf_sample_act() tried to update its per-cpu stats, but tcf_sample_init() forgot to allocate them, because tcf_idr_create() was called with a wrong value of 'cpustats'. Setting it to true proved to fix the reported crash.

Fixes 65a206c01e8e ("net/sched: Change act_api and act_xxx modules to use IDR")
Fixes 5c5670fae430 ("net/sched: Introduce sample tc action")
---
 net/sched/act_sample.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
net/sched/act_sample.c +1 -1
@@ -64,7 +64,7 @@ static int tcf_sample_init(struct net *n
 
 	if (!exists) {
 		ret = tcf_idr_create(tn, parm->index, est, a,
-				     &act_sample_ops, bind, false);
+				     &act_sample_ops, bind, true);
 		if (ret)
 			return ret;
 		ret = ACT_P_CREATED;
author maintainer
#11 lore raw

PATCH 11/64 tls: dont copy the key out of tls12_crypto_info_aes_gcm_128

In reply to Greg Kroah-Hartman

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

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

From: Sabrina Dubroca <[email protected]>

[ Upstream commit 7cba09c6d5bc73ebbd25a353742d9ddb7a713b95 ]

There's no need to copy the key to an on-stack buffer before calling crypto_aead_setkey().

Fixes 3c4d7559159b ("tls: kernel TLS support")
---
 net/tls/tls_sw.c |    5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)
net/tls/tls_sw.c +1 -4
@@ -661,7 +661,6 @@ static void tls_sw_free_resources(struct
 
 int tls_set_sw_offload(struct sock *sk, struct tls_context *ctx)
 {
-	char keyval[TLS_CIPHER_AES_GCM_128_KEY_SIZE];
 	struct tls_crypto_info *crypto_info;
 	struct tls12_crypto_info_aes_gcm_128 *gcm_128_info;
 	struct tls_sw_context *sw_ctx;
@@ -753,9 +752,7 @@ int tls_set_sw_offload(struct sock *sk,
 
 	ctx->push_pending_record = tls_sw_push_pending_record;
 
-	memcpy(keyval, gcm_128_info->key, TLS_CIPHER_AES_GCM_128_KEY_SIZE);
-
-	rc = crypto_aead_setkey(sw_ctx->aead_send, keyval,
+	rc = crypto_aead_setkey(sw_ctx->aead_send, gcm_128_info->key,
 				TLS_CIPHER_AES_GCM_128_KEY_SIZE);
 	if (rc)
 		goto free_aead;
author maintainer
#13 lore raw

PATCH 13/64 tls: clear key material from kernel memory when do_tls_setsockopt_conf fails

In reply to Greg Kroah-Hartman

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

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

From: Sabrina Dubroca <[email protected]>

[ Upstream commit c844eb46b7d43c2cf760169df5ae1d5b033af338 ]

Fixes 3c4d7559159b ("tls: kernel TLS support")
---
 net/tls/tls_main.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
net/tls/tls_main.c +1 -1
@@ -425,7 +425,7 @@ static int do_tls_setsockopt_tx(struct s
 	goto out;
 
 err_crypto_info:
-	memset(crypto_info, 0, sizeof(*crypto_info));
+	memzero_explicit(crypto_info, sizeof(union tls_crypto_context));
 out:
 	return rc;
 }
author maintainer
#16 lore raw

PATCH 16/64 ASoC: cs4265: fix MMTLR Data switch control

In reply to Greg Kroah-Hartman

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

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

From: Sébastien Szymanski <[email protected]>

commit 90a3b7f8aba3011badacd6d8121e03aa24ac79d1 upstream.

The MMTLR bit is in the CS4265_SPDIF_CTL2 register at address 0x12 bit 0 and not at address 0x0 bit 1. Fix this.

---
 sound/soc/codecs/cs4265.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
sound/soc/codecs/cs4265.c +2 -2
@@ -157,8 +157,8 @@ static const struct snd_kcontrol_new cs4
 	SOC_SINGLE("Validity Bit Control Switch", CS4265_SPDIF_CTL2,
 				3, 1, 0),
 	SOC_ENUM("SPDIF Mono/Stereo", spdif_mono_stereo_enum),
-	SOC_SINGLE("MMTLR Data Switch", 0,
-				1, 1, 0),
+	SOC_SINGLE("MMTLR Data Switch", CS4265_SPDIF_CTL2,
+				0, 1, 0),
 	SOC_ENUM("Mono Channel Select", spdif_mono_select_enum),
 	SND_SOC_BYTES("C Data Buffer", CS4265_C_DATA_BUFF, 24),
 };
author maintainer
#19 lore raw

PATCH 19/64 ALSA: bebob: use address returned by kmalloc() instead of kernel stack for streaming DMA mapping

In reply to Greg Kroah-Hartman

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

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

From: Takashi Sakamoto <[email protected]>

commit 493626f2d87a74e6dbea1686499ed6e7e600484e upstream.

When executing 'fw_run_transaction()' with 'TCODE_WRITE_BLOCK_REQUEST', an address of 'payload' argument is used for streaming DMA mapping by 'firewire_ohci' module if 'size' argument is larger than 8 byte. Although in this case the address should not be on kernel stack, current implementation of ALSA bebob driver uses data in kernel stack for a cue to boot M-Audio devices. This often brings unexpected result, especially for a case of CONFIG_VMAP_STACK=y.

This commit fixes the bug.

Reference: https://bugzilla.kernel.org/show_bug.cgi?id=201021
Reference: https://forum.manjaro.org/t/firewire-m-audio-410-driver-wont-load-firmware/51165

Fixes a2b2a7798fb6('ALSA: bebob: Send a cue to load firmware for M-Audio Firewire series')
Cc <[email protected]> # v3.16+
---
 sound/firewire/bebob/bebob_maudio.c |   24 ++++++++++++++----------
 1 file changed, 14 insertions(+), 10 deletions(-)
sound/firewire/bebob/bebob_maudio.c +14 -10
@@ -96,17 +96,13 @@ int snd_bebob_maudio_load_firmware(struc
 	struct fw_device *device = fw_parent_device(unit);
 	int err, rcode;
 	u64 date;
-	__le32 cues[3] = {
-		cpu_to_le32(MAUDIO_BOOTLOADER_CUE1),
-		cpu_to_le32(MAUDIO_BOOTLOADER_CUE2),
-		cpu_to_le32(MAUDIO_BOOTLOADER_CUE3)
-	};
+	__le32 *cues;
 
 	/* check date of software used to build */
 	err = snd_bebob_read_block(unit, INFO_OFFSET_SW_DATE,
 				   &date, sizeof(u64));
 	if (err < 0)
-		goto end;
+		return err;
 	/*
 	 * firmware version 5058 or later has date later than "20070401", but
 	 * 'date' is not null-terminated.
@@ -114,20 +110,28 @@ int snd_bebob_maudio_load_firmware(struc
 	if (date < 0x3230303730343031LL) {
 		dev_err(&unit->device,
 			"Use firmware version 5058 or later\n");
-		err = -ENOSYS;
-		goto end;
+		return -ENXIO;
 	}
 
+	cues = kmalloc_array(3, sizeof(*cues), GFP_KERNEL);
+	if (!cues)
+		return -ENOMEM;
+
+	cues[0] = cpu_to_le32(MAUDIO_BOOTLOADER_CUE1);
+	cues[1] = cpu_to_le32(MAUDIO_BOOTLOADER_CUE2);
+	cues[2] = cpu_to_le32(MAUDIO_BOOTLOADER_CUE3);
+
 	rcode = fw_run_transaction(device->card, TCODE_WRITE_BLOCK_REQUEST,
 				   device->node_id, device->generation,
 				   device->max_speed, BEBOB_ADDR_REG_REQ,
-				   cues, sizeof(cues));
+				   cues, 3 * sizeof(*cues));
+	kfree(cues);
 	if (rcode != RCODE_COMPLETE) {
 		dev_err(&unit->device,
 			"Failed to send a cue to load firmware\n");
 		err = -EIO;
 	}
-end:
+
 	return err;
 }
 
author maintainer
#20 lore raw

PATCH 20/64 ALSA: emu10k1: fix possible info leak to userspace on SNDRV_EMU10K1_IOCTL_INFO

In reply to Greg Kroah-Hartman

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

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

From: Willy Tarreau <[email protected]>

commit 49434c6c575d2008c0abbc93e615019f39e01252 upstream.

snd_emu10k1_fx8010_ioctl(SNDRV_EMU10K1_IOCTL_INFO) allocates memory using kmalloc() and partially fills it by calling snd_emu10k1_fx8010_info() before returning the resulting structure to userspace, leaving uninitialized holes. Let's just use kzalloc() here.

---
 sound/pci/emu10k1/emufx.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
sound/pci/emu10k1/emufx.c +1 -1
@@ -2547,7 +2547,7 @@ static int snd_emu10k1_fx8010_ioctl(stru
 		emu->support_tlv = 1;
 		return put_user(SNDRV_EMU10K1_VERSION, (int __user *)argp);
 	case SNDRV_EMU10K1_IOCTL_INFO:
-		info = kmalloc(sizeof(*info), GFP_KERNEL);
+		info = kzalloc(sizeof(*info), GFP_KERNEL);
 		if (!info)
 			return -ENOMEM;
 		snd_emu10k1_fx8010_info(emu, info);
author maintainer
#21 lore raw

PATCH 21/64 ALSA: fireface: fix memory leak in ff400_switch_fetching_mode()

In reply to Greg Kroah-Hartman

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

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

From: Takashi Sakamoto <[email protected]>

commit 36f3a6e02c143a7e9e4e143e416371f67bc1fae6 upstream.

An allocated memory forgets to be released.

Fixes 76fdb3a9e13 ('ALSA: fireface: add support for Fireface 400')
Cc <[email protected]> # 4.12+
---
 sound/firewire/fireface/ff-protocol-ff400.c |    9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)
sound/firewire/fireface/ff-protocol-ff400.c +6 -3
@@ -146,6 +146,7 @@ static int ff400_switch_fetching_mode(st
 {
 	__le32 *reg;
 	int i;
+	int err;
 
 	reg = kzalloc(sizeof(__le32) * 18, GFP_KERNEL);
 	if (reg == NULL)
@@ -163,9 +164,11 @@ static int ff400_switch_fetching_mode(st
 			reg[i] = cpu_to_le32(0x00000001);
 	}
 
-	return snd_fw_transaction(ff->unit, TCODE_WRITE_BLOCK_REQUEST,
-				  FF400_FETCH_PCM_FRAMES, reg,
-				  sizeof(__le32) * 18, 0);
+	err = snd_fw_transaction(ff->unit, TCODE_WRITE_BLOCK_REQUEST,
+				 FF400_FETCH_PCM_FRAMES, reg,
+				 sizeof(__le32) * 18, 0);
+	kfree(reg);
+	return err;
 }
 
 static void ff400_dump_sync_status(struct snd_ff *ff,
author maintainer
#23 lore raw

PATCH 23/64 ALSA: firewire-tascam: fix memory leak of private data

In reply to Greg Kroah-Hartman

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

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

From: Takashi Sakamoto <[email protected]>

commit 8d28277c065a974873c6781d44b7bcdcd8fb4e8a upstream.

Although private data of sound card instance is usually allocated in the tail of the instance, drivers in ALSA firewire stack allocate the private data before allocating the instance. In this case, the private data should be released explicitly at .private_free callback of the instance.

This commit fixes memory leak following to the above design.

Fixes b610386c8afb ('ALSA: firewire-tascam: deleyed registration of sound card')
Cc <[email protected]> # v4.7+
---
 sound/firewire/tascam/tascam.c |    1 +
 1 file changed, 1 insertion(+)
sound/firewire/tascam/tascam.c +1 -0
@@ -93,6 +93,7 @@ static void tscm_free(struct snd_tscm *t
 	fw_unit_put(tscm->unit);
 
 	mutex_destroy(&tscm->mutex);
+	kfree(tscm);
 }
 
 static void tscm_card_free(struct snd_card *card)
author maintainer
#26 lore raw

PATCH 26/64 ALSA: oxfw: fix memory leak of discovered stream formats at error path

In reply to Greg Kroah-Hartman

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

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

From: Takashi Sakamoto <[email protected]>

commit 1064bc685d359f549f91c2d5f111965a9284f328 upstream.

After finishing discover of stream formats, ALSA OXFW driver has memory leak of allocated memory object at error path.

This commit releases the memory object at the error path.

Fixes 6c29230e2a5f ('ALSA: oxfw: delayed registration of sound card')
Cc <[email protected]> # v4.7+
---
 sound/firewire/oxfw/oxfw.c |    7 +++++++
 1 file changed, 7 insertions(+)
sound/firewire/oxfw/oxfw.c +7 -0
@@ -213,6 +213,7 @@ static int detect_quirks(struct snd_oxfw
 static void do_registration(struct work_struct *work)
 {
 	struct snd_oxfw *oxfw = container_of(work, struct snd_oxfw, dwork.work);
+	int i;
 	int err;
 
 	if (oxfw->registered)
@@ -275,6 +276,12 @@ error:
 	snd_oxfw_stream_destroy_simplex(oxfw, &oxfw->rx_stream);
 	if (oxfw->has_output)
 		snd_oxfw_stream_destroy_simplex(oxfw, &oxfw->tx_stream);
+	for (i = 0; i < SND_OXFW_STREAM_FORMAT_ENTRIES; ++i) {
+		kfree(oxfw->tx_stream_formats[i]);
+		oxfw->tx_stream_formats[i] = NULL;
+		kfree(oxfw->rx_stream_formats[i]);
+		oxfw->rx_stream_formats[i] = NULL;
+	}
 	snd_card_free(oxfw->card);
 	kfree(oxfw->spec);
 	oxfw->spec = NULL;
author maintainer
#27 lore raw

PATCH 27/64 ALSA: oxfw: fix memory leak of private data

In reply to Greg Kroah-Hartman

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

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

From: Takashi Sakamoto <[email protected]>

commit 498fe23aad8e3b5a9554f55719c537603b4476ea upstream.

Although private data of sound card instance is usually allocated in the tail of the instance, drivers in ALSA firewire stack allocate the private data before allocating the instance. In this case, the private data should be released explicitly at .private_free callback of the instance.

This commit fixes memory leak following to the above design.

Fixes 6c29230e2a5f ('ALSA: oxfw: delayed registration of sound card')
Cc <[email protected]> # v4.7+
---
 sound/firewire/oxfw/oxfw.c |    1 +
 1 file changed, 1 insertion(+)
sound/firewire/oxfw/oxfw.c +1 -0
@@ -136,6 +136,7 @@ static void oxfw_free(struct snd_oxfw *o
 
 	kfree(oxfw->spec);
 	mutex_destroy(&oxfw->mutex);
+	kfree(oxfw);
 }
 
 /*
author maintainer
#29 lore raw

PATCH 29/64 xen/netfront: dont bug in case of too many frags

In reply to Greg Kroah-Hartman

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

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

From: Juergen Gross <[email protected]>

commit ad4f15dc2c70b1de5e0a64d27335962fbc9cf71c upstream.

Commit 57f230ab04d291 ("xen/netfront: raise max number of slots in xennet_get_responses()") raised the max number of allowed slots by one. This seems to be problematic in some configurations with netback using a larger MAX_SKB_FRAGS value (e.g. old Linux kernel with MAX_SKB_FRAGS defined as 18 instead of nowadays 17).

Instead of BUG_ON() in this case just fall back to retransmission.

Fixes 57f230ab04d291 ("xen/netfront: raise max number of slots in xennet_get_responses()")
---
 drivers/net/xen-netfront.c |    8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)
drivers/net/xen-netfront.c +7 -1
@@ -907,7 +907,11 @@ static RING_IDX xennet_fill_frags(struct
 			BUG_ON(pull_to <= skb_headlen(skb));
 			__pskb_pull_tail(skb, pull_to - skb_headlen(skb));
 		}
-		BUG_ON(skb_shinfo(skb)->nr_frags >= MAX_SKB_FRAGS);
+		if (unlikely(skb_shinfo(skb)->nr_frags >= MAX_SKB_FRAGS)) {
+			queue->rx.rsp_cons = ++cons;
+			kfree_skb(nskb);
+			return ~0U;
+		}
 
 		skb_add_rx_frag(skb, skb_shinfo(skb)->nr_frags,
 				skb_frag_page(nfrag),
@@ -1044,6 +1048,8 @@ err:
 		skb->len += rx->status;
 
 		i = xennet_fill_frags(queue, skb, &tmpq);
+		if (unlikely(i == ~0U))
+			goto err;
 
 		if (rx->flags & XEN_NETRXF_csum_blank)
 			skb->ip_summed = CHECKSUM_PARTIAL;
author maintainer
#31 lore raw

PATCH 31/64 spi: fix IDR collision on systems with both fixed and dynamic SPI bus numbers

In reply to Greg Kroah-Hartman

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

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

From: Kirill Kapranov <[email protected]>

commit 1a4327fbf4554d5b78d75b19a13d40d6de220159 upstream.

On systems where some controllers get a dynamic ID assigned and some have a fixed number (e.g. from ACPI tables), the current implementation might run into an IDR collision: in case of a fixed bus number is gotten by a driver (but not marked busy in IDR tree) and a driver with dynamic bus number gets the same ID and predictably fails.

Fix this by means of checking-in fixed IDsin IDR as far as dynamic ones at the moment of the controller registration.

Fixes 9b61e302210e (spi: Pick spi bus number from Linux idr or spi alias)
---
 drivers/spi/spi.c |    9 +++++++++
 1 file changed, 9 insertions(+)
drivers/spi/spi.c +9 -0
@@ -2135,6 +2135,15 @@ int spi_register_controller(struct spi_c
 		if (WARN(id < 0, "couldn't get idr"))
 			return id;
 		ctlr->bus_num = id;
+	} else {
+		/* devices with a fixed bus num must check-in with the num */
+		mutex_lock(&board_lock);
+		id = idr_alloc(&spi_master_idr, ctlr, ctlr->bus_num,
+			ctlr->bus_num + 1, GFP_KERNEL);
+		mutex_unlock(&board_lock);
+		if (WARN(id < 0, "couldn't get idr"))
+			return id == -ENOSPC ? -EBUSY : id;
+		ctlr->bus_num = id;
 	}
 	INIT_LIST_HEAD(&ctlr->queue);
 	spin_lock_init(&ctlr->queue_lock);
author maintainer
#34 lore raw

PATCH 34/64 mm: shmem.c: Correctly annotate new inodes for lockdep

In reply to Greg Kroah-Hartman

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

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

From: Joel Fernandes (Google) <[email protected]>

commit b45d71fb89ab8adfe727b9d0ee188ed58582a647 upstream.

Directories and inodes don't necessarily need to be in the same lockdep class. For ex, hugetlbfs splits them out too to prevent false positives in lockdep. Annotate correctly after new inode creation. If its a directory inode, it will be put into a different class.

This should fix a lockdep splat reported by syzbot:

Quoted 77 lines

======================================================
WARNING: possible circular locking dependency detected 4.18.0-rc8-next-20180810+ #36 Not tainted
------------------------------------------------------
syz-executor900/4483 is trying to acquire lock:
00000000d2bfc8fe (&sb->s_type->i_mutex_key#9){++++}, at: inode_lock include/linux/fs.h:765 [inline]
00000000d2bfc8fe (&sb->s_type->i_mutex_key#9){++++}, at:
shmem_fallocate+0x18b/0x12e0 mm/shmem.c:2602

but task is already holding lock:
0000000025208078 (ashmem_mutex){+.+.}, at: ashmem_shrink_scan+0xb4/0x630 drivers/staging/android/ashmem.c:448

which lock already depends on the new lock.

-> #2 (ashmem_mutex){+.+.}:

       __mutex_lock_common kernel/locking/mutex.c:925 [inline]
       __mutex_lock+0x171/0x1700 kernel/locking/mutex.c:1073
       mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:1088
       ashmem_mmap+0x55/0x520 drivers/staging/android/ashmem.c:361
       call_mmap include/linux/fs.h:1844 [inline]
       mmap_region+0xf27/0x1c50 mm/mmap.c:1762
       do_mmap+0xa10/0x1220 mm/mmap.c:1535
       do_mmap_pgoff include/linux/mm.h:2298 [inline]
       vm_mmap_pgoff+0x213/0x2c0 mm/util.c:357
       ksys_mmap_pgoff+0x4da/0x660 mm/mmap.c:1585
       __do_sys_mmap arch/x86/kernel/sys_x86_64.c:100 [inline]
       __se_sys_mmap arch/x86/kernel/sys_x86_64.c:91 [inline]
       __x64_sys_mmap+0xe9/0x1b0 arch/x86/kernel/sys_x86_64.c:91
       do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe

-> #1 (&mm->mmap_sem){++++}:

       __might_fault+0x155/0x1e0 mm/memory.c:4568
       _copy_to_user+0x30/0x110 lib/usercopy.c:25
       copy_to_user include/linux/uaccess.h:155 [inline]
       filldir+0x1ea/0x3a0 fs/readdir.c:196
       dir_emit_dot include/linux/fs.h:3464 [inline]
       dir_emit_dots include/linux/fs.h:3475 [inline]
       dcache_readdir+0x13a/0x620 fs/libfs.c:193
       iterate_dir+0x48b/0x5d0 fs/readdir.c:51
       __do_sys_getdents fs/readdir.c:231 [inline]
       __se_sys_getdents fs/readdir.c:212 [inline]
       __x64_sys_getdents+0x29f/0x510 fs/readdir.c:212
       do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe

-> #0 (&sb->s_type->i_mutex_key#9){++++}:

       lock_acquire+0x1e4/0x540 kernel/locking/lockdep.c:3924
       down_write+0x8f/0x130 kernel/locking/rwsem.c:70
       inode_lock include/linux/fs.h:765 [inline]
       shmem_fallocate+0x18b/0x12e0 mm/shmem.c:2602
       ashmem_shrink_scan+0x236/0x630 drivers/staging/android/ashmem.c:455
       ashmem_ioctl+0x3ae/0x13a0 drivers/staging/android/ashmem.c:797
       vfs_ioctl fs/ioctl.c:46 [inline]
       file_ioctl fs/ioctl.c:501 [inline]
       do_vfs_ioctl+0x1de/0x1720 fs/ioctl.c:685
       ksys_ioctl+0xa9/0xd0 fs/ioctl.c:702
       __do_sys_ioctl fs/ioctl.c:709 [inline]
       __se_sys_ioctl fs/ioctl.c:707 [inline]
       __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:707
       do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe

other info that might help us debug this:

Chain exists of:
  &sb->s_type->i_mutex_key#9 --> &mm->mmap_sem --> ashmem_mutex

 Possible unsafe locking scenario:
       CPU0                    CPU1
       ----                    ----
  lock(ashmem_mutex);
                               lock(&mm->mmap_sem);
                               lock(ashmem_mutex);
Quoted 7 lines

lock(&sb->s_type->i_mutex_key#9);

*** DEADLOCK ***

1 lock held by syz-executor900/4483:
#0: 0000000025208078 (ashmem_mutex){+.+.}, at:
ashmem_shrink_scan+0xb4/0x630 drivers/staging/android/ashmem.c:448

---
 mm/shmem.c |    2 ++
 1 file changed, 2 insertions(+)
mm/shmem.c +2 -0
@@ -2207,6 +2207,8 @@ static struct inode *shmem_get_inode(str
 			mpol_shared_policy_init(&info->policy, NULL);
 			break;
 		}
+
+		lockdep_annotate_inode_mutex_key(inode);
 	} else
 		shmem_free_inode(sb);
 	return inode;
author maintainer
#39 lore raw

PATCH 39/64 Revert "ubifs: xattr: Dont operate on deleted inodes"

In reply to Greg Kroah-Hartman

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

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

From: Richard Weinberger <[email protected]>

commit f061c1cc404a618858a77aea233fde0aeaad2f2d upstream.

This reverts commit 11a6fc3dc743e22fb50f2196ec55bee5140d3c52. UBIFS wants to assert that xattr operations are only issued on files with positive link count. The said patch made this operations return -ENOENT for unlinked files such that the asserts will no longer trigger. This was wrong since xattr operations are perfectly fine on unlinked files.
Instead the assertions need to be fixed/removed.

Fixes 11a6fc3dc743 ("ubifs: xattr: Don't operate on deleted inodes")
---
 fs/ubifs/xattr.c |   24 ------------------------
 1 file changed, 24 deletions(-)
fs/ubifs/xattr.c +0 -24
@@ -152,12 +152,6 @@ static int create_xattr(struct ubifs_inf
 	ui->data_len = size;
 
 	mutex_lock(&host_ui->ui_mutex);
-
-	if (!host->i_nlink) {
-		err = -ENOENT;
-		goto out_noent;
-	}
-
 	host->i_ctime = current_time(host);
 	host_ui->xattr_cnt += 1;
 	host_ui->xattr_size += CALC_DENT_SIZE(fname_len(nm));
@@ -189,7 +183,6 @@ out_cancel:
 	host_ui->xattr_size -= CALC_XATTR_BYTES(size);
 	host_ui->xattr_names -= fname_len(nm);
 	host_ui->flags &= ~UBIFS_CRYPT_FL;
-out_noent:
 	mutex_unlock(&host_ui->ui_mutex);
 out_free:
 	make_bad_inode(inode);
@@ -241,12 +234,6 @@ static int change_xattr(struct ubifs_inf
 	mutex_unlock(&ui->ui_mutex);
 
 	mutex_lock(&host_ui->ui_mutex);
-
-	if (!host->i_nlink) {
-		err = -ENOENT;
-		goto out_noent;
-	}
-
 	host->i_ctime = current_time(host);
 	host_ui->xattr_size -= CALC_XATTR_BYTES(old_size);
 	host_ui->xattr_size += CALC_XATTR_BYTES(size);
@@ -268,7 +255,6 @@ static int change_xattr(struct ubifs_inf
 out_cancel:
 	host_ui->xattr_size -= CALC_XATTR_BYTES(size);
 	host_ui->xattr_size += CALC_XATTR_BYTES(old_size);
-out_noent:
 	mutex_unlock(&host_ui->ui_mutex);
 	make_bad_inode(inode);
 out_free:
@@ -497,12 +483,6 @@ static int remove_xattr(struct ubifs_inf
 		return err;
 
 	mutex_lock(&host_ui->ui_mutex);
-
-	if (!host->i_nlink) {
-		err = -ENOENT;
-		goto out_noent;
-	}
-
 	host->i_ctime = current_time(host);
 	host_ui->xattr_cnt -= 1;
 	host_ui->xattr_size -= CALC_DENT_SIZE(fname_len(nm));
@@ -522,7 +502,6 @@ out_cancel:
 	host_ui->xattr_size += CALC_DENT_SIZE(fname_len(nm));
 	host_ui->xattr_size += CALC_XATTR_BYTES(ui->data_len);
 	host_ui->xattr_names += fname_len(nm);
-out_noent:
 	mutex_unlock(&host_ui->ui_mutex);
 	ubifs_release_budget(c, &req);
 	make_bad_inode(inode);
@@ -562,9 +541,6 @@ static int ubifs_xattr_remove(struct ino
 
 	ubifs_assert(inode_is_locked(host));
 
-	if (!host->i_nlink)
-		return -ENOENT;
-
 	if (fname_len(&nm) > UBIFS_MAX_NLEN)
 		return -ENAMETOOLONG;
 
author maintainer
#40 lore raw

PATCH 40/64 ocfs2: fix ocfs2 read block panic

In reply to Greg Kroah-Hartman

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

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

From: Junxiao Bi <[email protected]>

commit 234b69e3e089d850a98e7b3145bd00e9b52b1111 upstream.

While reading block, it is possible that io error return due to underlying storage issue, in this case, BH_NeedsValidate was left in the buffer head. Then when reading the very block next time, if it was already linked into journal, that will trigger the following panic.

[203748.702517] kernel BUG at fs/ocfs2/buffer_head_io.c:342!
[203748.702533] invalid opcode: 0000 [#1] SMP
[203748.702561] Modules linked in: ocfs2 ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm ocfs2_nodemanager ocfs2_stackglue configfs sunrpc dm_switch dm_queue_length dm_multipath bonding be2iscsi iscsi_boot_sysfs bnx2i cnic uio cxgb4i iw_cxgb4 cxgb4 cxgb3i libcxgbi iw_cxgb3 cxgb3 mdio ib_iser rdma_cm ib_cm iw_cm ib_sa ib_mad ib_core ib_addr ipv6 iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ipmi_devintf iTCO_wdt iTCO_vendor_support dcdbas ipmi_ssif i2c_core ipmi_si ipmi_msghandler acpi_pad pcspkr sb_edac edac_core lpc_ich mfd_core shpchp sg tg3 ptp pps_core ext4 jbd2 mbcache2 sr_mod cdrom sd_mod ahci libahci megaraid_sas wmi dm_mirror dm_region_hash dm_log dm_mod
[203748.703024] CPU: 7 PID: 38369 Comm: touch Not tainted 4.1.12-124.18.6.el6uek.x86_64 #2
[203748.703045] Hardware name: Dell Inc. PowerEdge R620/0PXXHP, BIOS 2.5.2 01/28/2015
[203748.703067] task: ffff880768139c00 ti: ffff88006ff48000 task.ti: ffff88006ff48000
[203748.703088] RIP: 0010:[<ffffffffa05e9f09>]  [<ffffffffa05e9f09>] ocfs2_read_blocks+0x669/0x7f0 [ocfs2]
[203748.703130] RSP: 0018:ffff88006ff4b818  EFLAGS: 00010206
[203748.703389] RAX: 0000000008620029 RBX: ffff88006ff4b910 RCX: 0000000000000000
[203748.703885] RDX: 0000000000000001 RSI: 0000000000000000 RDI: 00000000023079fe
[203748.704382] RBP: ffff88006ff4b8d8 R08: 0000000000000000 R09: ffff8807578c25b0
[203748.704877] R10: 000000000f637376 R11: 000000003030322e R12: 0000000000000000
[203748.705373] R13: ffff88006ff4b910 R14: ffff880732fe38f0 R15: 0000000000000000
[203748.705871] FS:  00007f401992c700(0000) GS:ffff880bfebc0000(0000) knlGS:0000000000000000
[203748.706370] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[203748.706627] CR2: 00007f4019252440 CR3: 00000000a621e000 CR4: 0000000000060670
[203748.707124] Stack:
[203748.707371]  ffff88006ff4b828 ffffffffa0609f52 ffff88006ff4b838 0000000000000001
[203748.707885]  0000000000000000 0000000000000000 ffff880bf67c3800 ffffffffa05eca00
[203748.708399]  00000000023079ff ffffffff81c58b80 0000000000000000 0000000000000000
[203748.708915] Call Trace:
[203748.709175]  [<ffffffffa0609f52>] ? ocfs2_inode_cache_io_unlock+0x12/0x20 [ocfs2]
[203748.709680]  [<ffffffffa05eca00>] ? ocfs2_empty_dir_filldir+0x80/0x80 [ocfs2]
[203748.710185]  [<ffffffffa05ec0cb>] ocfs2_read_dir_block_direct+0x3b/0x200 [ocfs2]
[203748.710691]  [<ffffffffa05f0fbf>] ocfs2_prepare_dx_dir_for_insert.isra.57+0x19f/0xf60 [ocfs2]
[203748.711204]  [<ffffffffa065660f>] ? ocfs2_metadata_cache_io_unlock+0x1f/0x30 [ocfs2]
[203748.711716]  [<ffffffffa05f4f3a>] ocfs2_prepare_dir_for_insert+0x13a/0x890 [ocfs2]
[203748.712227]  [<ffffffffa05f442e>] ? ocfs2_check_dir_for_entry+0x8e/0x140 [ocfs2]
[203748.712737]  [<ffffffffa061b2f2>] ocfs2_mknod+0x4b2/0x1370 [ocfs2]
[203748.713003]  [<ffffffffa061c385>] ocfs2_create+0x65/0x170 [ocfs2]
[203748.713263]  [<ffffffff8121714b>] vfs_create+0xdb/0x150
[203748.713518]  [<ffffffff8121b225>] do_last+0x815/0x1210
[203748.713772]  [<ffffffff812192e9>] ? path_init+0xb9/0x450
[203748.714123]  [<ffffffff8121bca0>] path_openat+0x80/0x600
[203748.714378]  [<ffffffff811bcd45>] ? handle_pte_fault+0xd15/0x1620
[203748.714634]  [<ffffffff8121d7ba>] do_filp_open+0x3a/0xb0
[203748.714888]  [<ffffffff8122a767>] ? __alloc_fd+0xa7/0x130
[203748.715143]  [<ffffffff81209ffc>] do_sys_open+0x12c/0x220
[203748.715403]  [<ffffffff81026ddb>] ? syscall_trace_enter_phase1+0x11b/0x180
[203748.715668]  [<ffffffff816f0c9f>] ? system_call_after_swapgs+0xe9/0x190
[203748.715928]  [<ffffffff8120a10e>] SyS_open+0x1e/0x20
[203748.716184]  [<ffffffff816f0d5e>] system_call_fastpath+0x18/0xd7
[203748.716440] Code: 00 00 48 8b 7b 08 48 83 c3 10 45 89 f8 44 89 e1 44 89 f2 4c 89 ee e8 07 06 11 e1 48 8b 03 48 85 c0 75 df 8b 5d c8 e9 4d fa ff ff <0f> 0b 48 8b 7d a0 e8 dc c6 06 00 48 b8 00 00 00 00 00 00 00 10
[203748.717505] RIP  [<ffffffffa05e9f09>] ocfs2_read_blocks+0x669/0x7f0 [ocfs2]
[203748.717775]  RSP <ffff88006ff4b818>

Joesph ever reported a similar panic.

---
 fs/ocfs2/buffer_head_io.c |    1 +
 1 file changed, 1 insertion(+)
fs/ocfs2/buffer_head_io.c +1 -0
@@ -342,6 +342,7 @@ int ocfs2_read_blocks(struct ocfs2_cachi
 				 * for this bh as it's not marked locally
 				 * uptodate. */
 				status = -EIO;
+				clear_buffer_needs_validate(bh);
 				put_bh(bh);
 				bhs[i] = NULL;
 				continue;
author maintainer
#46 lore raw

PATCH 46/64 drm/vc4: Fix the "no scaling" case on multi-planar YUV formats

In reply to Greg Kroah-Hartman

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

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

From: Boris Brezillon <[email protected]>

commit 658d8cbd07dae22ccecf49399e18c609c4e85c53 upstream.

When there's no scaling requested ->is_unity should be true no matter the format.

Also, when no scaling is requested and we have a multi-planar YUV format, we should leave ->y_scaling[0] to VC4_SCALING_NONE and only set ->x_scaling[0] to VC4_SCALING_PPF.

Doing this fixes an hardly visible artifact (seen when using modetest and a rather big overlay plane in YUV420).

---
 drivers/gpu/drm/vc4/vc4_plane.c |   25 ++++++++++++-------------
 1 file changed, 12 insertions(+), 13 deletions(-)
drivers/gpu/drm/vc4/vc4_plane.c +12 -13
@@ -329,6 +329,9 @@ static int vc4_plane_setup_clipping_and_
 	vc4_state->y_scaling[0] = vc4_get_scaling_mode(vc4_state->src_h[0],
 						       vc4_state->crtc_h);
 
+	vc4_state->is_unity = (vc4_state->x_scaling[0] == VC4_SCALING_NONE &&
+			       vc4_state->y_scaling[0] == VC4_SCALING_NONE);
+
 	if (num_planes > 1) {
 		vc4_state->is_yuv = true;
 
@@ -344,24 +347,17 @@ static int vc4_plane_setup_clipping_and_
 			vc4_get_scaling_mode(vc4_state->src_h[1],
 					     vc4_state->crtc_h);
 
-		/* YUV conversion requires that scaling be enabled,
-		 * even on a plane that's otherwise 1:1.  Choose TPZ
-		 * for simplicity.
+		/* YUV conversion requires that horizontal scaling be enabled,
+		 * even on a plane that's otherwise 1:1. Looks like only PPF
+		 * works in that case, so let's pick that one.
 		 */
-		if (vc4_state->x_scaling[0] == VC4_SCALING_NONE)
-			vc4_state->x_scaling[0] = VC4_SCALING_TPZ;
-		if (vc4_state->y_scaling[0] == VC4_SCALING_NONE)
-			vc4_state->y_scaling[0] = VC4_SCALING_TPZ;
+		if (vc4_state->is_unity)
+			vc4_state->x_scaling[0] = VC4_SCALING_PPF;
 	} else {
 		vc4_state->x_scaling[1] = VC4_SCALING_NONE;
 		vc4_state->y_scaling[1] = VC4_SCALING_NONE;
 	}
 
-	vc4_state->is_unity = (vc4_state->x_scaling[0] == VC4_SCALING_NONE &&
-			       vc4_state->y_scaling[0] == VC4_SCALING_NONE &&
-			       vc4_state->x_scaling[1] == VC4_SCALING_NONE &&
-			       vc4_state->y_scaling[1] == VC4_SCALING_NONE);
-
 	/* No configuring scaling on the cursor plane, since it gets
 	   non-vblank-synced updates, and scaling requires requires
 	   LBM changes which have to be vblank-synced.
@@ -639,7 +635,10 @@ static int vc4_plane_mode_set(struct drm
 		vc4_dlist_write(vc4_state, SCALER_CSC2_ITR_R_601_5);
 	}
 
-	if (!vc4_state->is_unity) {
+	if (vc4_state->x_scaling[0] != VC4_SCALING_NONE ||
+	    vc4_state->x_scaling[1] != VC4_SCALING_NONE ||
+	    vc4_state->y_scaling[0] != VC4_SCALING_NONE ||
+	    vc4_state->y_scaling[1] != VC4_SCALING_NONE) {
 		/* LBM Base Address. */
 		if (vc4_state->y_scaling[0] != VC4_SCALING_NONE ||
 		    vc4_state->y_scaling[1] != VC4_SCALING_NONE) {
author maintainer
#48 lore raw

PATCH 48/64 drm/amdgpu: add new polaris pci id

In reply to Greg Kroah-Hartman

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

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

From: Alex Deucher <[email protected]>

commit 30f3984ede683b98a4e8096e200df78bf0609b4f upstream.

Add new pci id.

---
 drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c |   14 ++++++++------
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c |    1 +
 2 files changed, 9 insertions(+), 6 deletions(-)
drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c +8 -6
@@ -715,12 +715,14 @@ static int amdgpu_cgs_get_firmware_info(
 				break;
 			case CHIP_POLARIS10:
 				if (type == CGS_UCODE_ID_SMU) {
-					if ((adev->pdev->device == 0x67df) &&
-					    ((adev->pdev->revision == 0xe0) ||
-					     (adev->pdev->revision == 0xe3) ||
-					     (adev->pdev->revision == 0xe4) ||
-					     (adev->pdev->revision == 0xe5) ||
-					     (adev->pdev->revision == 0xe7) ||
+					if (((adev->pdev->device == 0x67df) &&
+					     ((adev->pdev->revision == 0xe0) ||
+					      (adev->pdev->revision == 0xe3) ||
+					      (adev->pdev->revision == 0xe4) ||
+					      (adev->pdev->revision == 0xe5) ||
+					      (adev->pdev->revision == 0xe7) ||
+					      (adev->pdev->revision == 0xef))) ||
+					    ((adev->pdev->device == 0x6fdf) &&
 					     (adev->pdev->revision == 0xef))) {
 						info->is_kicker = true;
 						strcpy(fw_name, "amdgpu/polaris10_k_smc.bin");
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c +1 -0
@@ -500,6 +500,7 @@ static const struct pci_device_id pciidl
 	{0x1002, 0x67CA, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_POLARIS10},
 	{0x1002, 0x67CC, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_POLARIS10},
 	{0x1002, 0x67CF, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_POLARIS10},
+	{0x1002, 0x6FDF, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_POLARIS10},
 	/* Polaris12 */
 	{0x1002, 0x6980, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_POLARIS12},
 	{0x1002, 0x6981, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_POLARIS12},
author maintainer
#52 lore raw

PATCH 50/64 tty: vt_ioctl: fix potential Spectre v1

In reply to Greg Kroah-Hartman

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

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

From: Gustavo A. R. Silva <[email protected]>

commit e97267cb4d1ee01ca0929638ec0fcbb0904f903d upstream.

vsa.console is indirectly controlled by user-space, hence leading to a potential exploitation of the Spectre variant 1 vulnerability.

This issue was detected with the help of Smatch:

drivers/tty/vt/vt_ioctl.c:711 vt_ioctl() warn: potential spectre issue 'vc_cons' [r]

Fix this by sanitizing vsa.console before using it to index vc_cons

Notice that given that speculation windows are large, the policy is to kill the speculation on the first load and not worry if it can be completed with a dependent load/store [1].

[1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2

---
 drivers/tty/vt/vt_ioctl.c |    4 ++++
 1 file changed, 4 insertions(+)
drivers/tty/vt/vt_ioctl.c +4 -0
@@ -32,6 +32,8 @@
 #include <asm/io.h>
 #include <linux/uaccess.h>
 
+#include <linux/nospec.h>
+
 #include <linux/kbd_kern.h>
 #include <linux/vt_kern.h>
 #include <linux/kbd_diacr.h>
@@ -700,6 +702,8 @@ int vt_ioctl(struct tty_struct *tty,
 		if (vsa.console == 0 || vsa.console > MAX_NR_CONSOLES)
 			ret = -ENXIO;
 		else {
+			vsa.console = array_index_nospec(vsa.console,
+							 MAX_NR_CONSOLES + 1);
 			vsa.console--;
 			console_lock();
 			ret = vc_allocate(vsa.console);
author maintainer
#60 lore raw

PATCH 58/64 ext4: show test_dummy_encryption mount option in /proc/mounts

In reply to Greg Kroah-Hartman

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

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

From: Eric Biggers <[email protected]>

commit 338affb548c243d2af25b1ca628e67819350de6b upstream.

When in effect, add "test_dummy_encryption" to _ext4_show_options() so that it is shown in /proc/mounts and other relevant procfs files.

---
 fs/ext4/super.c |    2 ++
 1 file changed, 2 insertions(+)
fs/ext4/super.c +2 -0
@@ -2085,6 +2085,8 @@ static int _ext4_show_options(struct seq
 		SEQ_OPTS_PRINT("max_dir_size_kb=%u", sbi->s_max_dir_size_kb);
 	if (test_opt(sb, DATA_ERR_ABORT))
 		SEQ_OPTS_PUTS("data_err=abort");
+	if (DUMMY_ENCRYPTION_ENABLED(sbi))
+		SEQ_OPTS_PUTS("test_dummy_encryption");
 
 	ext4_show_quota_options(seq, sb);
 	return 0;
author maintainer
#62 lore raw

PATCH 60/64 PCI: aardvark: Size bridges before resources allocation

In reply to Greg Kroah-Hartman

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

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

From: Zachary Zhang <[email protected]>

commit 91a2968e245d6ba616db37001fa1a043078b1a65 upstream.

The PCIE I/O and MEM resource allocation mechanism is that root bus goes through the following steps:

1. Check PCI bridges' range and computes I/O and Mem base/limits.

2. Sort all subordinate devices I/O and MEM resource requirements and allocate the resources and writes/updates subordinate devices' requirements to PCI bridges I/O and Mem MEM/limits registers.

Currently, PCI Aardvark driver only handles the second step and lacks the first step, so there is an I/O and MEM resource allocation failure when using a PCI switch. This commit fixes that by sizing bridges before doing the resource allocation.

Fixes 8c39d710363c1 ("PCI: aardvark: Add Aardvark PCI host controller

driver")

---
 drivers/pci/host/pci-aardvark.c |    1 +
 1 file changed, 1 insertion(+)
drivers/pci/host/pci-aardvark.c +1 -0
@@ -954,6 +954,7 @@ static int advk_pcie_probe(struct platfo
 
 	bus = bridge->bus;
 
+	pci_bus_size_bridges(bus);
 	pci_bus_assign_resources(bus);
 
 	list_for_each_entry(child, &bus->children, node)
author maintainer
#65 lore raw

PATCH 63/64 tick/nohz: Prevent bogus softirq pending warning

In reply to Greg Kroah-Hartman

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

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

From: Thomas Gleixner <[email protected]>

Commit 0a0e0829f990 ("nohz: Fix missing tick reprogram when interrupting an inline softirq") got backported to stable trees and now causes the NOHZ softirq pending warning to trigger. It's not an upstream issue as the NOHZ update logic has been changed there.

The problem is when a softirq disabled section gets interrupted and on return from interrupt the tick/nohz state is evaluated, which then can observe pending soft interrupts. These soft interrupts are legitimately pending because they cannot be processed as long as soft interrupts are disabled and the interrupted code will correctly process them when soft interrupts are reenabled.

Add a check for softirqs disabled to the pending check to prevent the warning.

Cc Frederic Weisbecker <[email protected]>
Cc Ingo Molnar <[email protected]>
Cc Anna-Maria Gleixner <[email protected]>
Fixes 2d898915ccf4838c ("nohz: Fix missing tick reprogram when interrupting an inline softirq")
---
 kernel/time/tick-sched.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
kernel/time/tick-sched.c +1 -1
@@ -908,7 +908,7 @@ static bool can_stop_idle_tick(int cpu,
 	if (unlikely(local_softirq_pending() && cpu_online(cpu))) {
 		static int ratelimit;
 
-		if (ratelimit < 10 &&
+		if (ratelimit < 10 && !in_softirq() &&
 		    (local_softirq_pending() & SOFTIRQ_STOP_IDLE_MASK)) {
 			pr_warn("NOHZ: local_softirq_pending %02x\n",
 				(unsigned int) local_softirq_pending());
author maintainer
#1 lore raw

PATCH 1/64 gso_segment: Reset skb->mac_len after modifying network header

In reply to Greg Kroah-Hartman

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

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

From: "Toke H�iland-J�rgensen" <[email protected]>

[ Upstream commit c56cae23c6b167acc68043c683c4573b80cbcc2c ]

When splitting a GSO segment that consists of encapsulated packets, the skb->mac_len of the segments can end up being set wrong, causing packet drops in particular when using act_mirred and ifb interfaces in combination with a qdisc that splits GSO packets.

This happens because at the time skb_segment() is called, network_header will point to the inner header, throwing off the calculation in skb_reset_mac_len(). The network_header is subsequently adjust by the outer IP gso_segment handlers, but they don't set the mac_len.

Fix this by adding skb_reset_mac_len() calls to both the IPv4 and IPv6 gso_segment handlers, after they modify the network_header.

Many thanks to Eric Dumazet for his help in identifying the cause of the bug.

---
 net/ipv4/af_inet.c     |    1 +
 net/ipv6/ip6_offload.c |    1 +
 2 files changed, 2 insertions(+)
net/ipv4/af_inet.c +1 -0
@@ -1307,6 +1307,7 @@ struct sk_buff *inet_gso_segment(struct
 		if (encap)
 			skb_reset_inner_headers(skb);
 		skb->network_header = (u8 *)iph - skb->head;
+		skb_reset_mac_len(skb);
 	} while ((skb = skb->next));
 
 out:
net/ipv6/ip6_offload.c +1 -0
@@ -113,6 +113,7 @@ static struct sk_buff *ipv6_gso_segment(
 			payload_len = skb->len - nhoff - sizeof(*ipv6h);
 		ipv6h->payload_len = htons(payload_len);
 		skb->network_header = (u8 *)ipv6h - skb->head;
+		skb_reset_mac_len(skb);
 
 		if (udpfrag) {
 			int err = ip6_find_1stfragopt(skb, &prevhdr);
author maintainer
#12 lore raw

PATCH 12/64 tls: zero the crypto information from tls_context before freeing

In reply to Greg Kroah-Hartman

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

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

From: Sabrina Dubroca <[email protected]>

[ Upstream commit 86029d10af18381814881d6cce2dd6872163b59f ]

This contains key material in crypto_send_aes_gcm_128 and crypto_recv_aes_gcm_128.

Introduce union tls_crypto_context, and replace the two identical unions directly embedded in struct tls_context with it. We can then use this union to clean up the memory in the new tls_ctx_free() function.

Fixes 3c4d7559159b ("tls: kernel TLS support")
---
 include/net/tls.h  |   14 ++++++++------
 net/tls/tls_main.c |   15 ++++++++++++---
 net/tls/tls_sw.c   |    2 +-
 3 files changed, 21 insertions(+), 10 deletions(-)
include/net/tls.h +8 -6
@@ -79,11 +79,13 @@ enum {
 	TLS_PENDING_CLOSED_RECORD
 };
 
+union tls_crypto_context {
+	struct tls_crypto_info info;
+	struct tls12_crypto_info_aes_gcm_128 aes_gcm_128;
+};
+
 struct tls_context {
-	union {
-		struct tls_crypto_info crypto_send;
-		struct tls12_crypto_info_aes_gcm_128 crypto_send_aes_gcm_128;
-	};
+	union tls_crypto_context crypto_send;
 
 	void *priv_ctx;
 
@@ -208,8 +210,8 @@ static inline void tls_fill_prepend(stru
 	 * size KTLS_DTLS_HEADER_SIZE + KTLS_DTLS_NONCE_EXPLICIT_SIZE
 	 */
 	buf[0] = record_type;
-	buf[1] = TLS_VERSION_MINOR(ctx->crypto_send.version);
-	buf[2] = TLS_VERSION_MAJOR(ctx->crypto_send.version);
+	buf[1] = TLS_VERSION_MINOR(ctx->crypto_send.info.version);
+	buf[2] = TLS_VERSION_MAJOR(ctx->crypto_send.info.version);
 	/* we can use IV for nonce explicit according to spec */
 	buf[3] = pkt_len >> 8;
 	buf[4] = pkt_len & 0xFF;
net/tls/tls_main.c +12 -3
@@ -218,6 +218,15 @@ static void tls_write_space(struct sock
 	ctx->sk_write_space(sk);
 }
 
+static void tls_ctx_free(struct tls_context *ctx)
+{
+	if (!ctx)
+		return;
+
+	memzero_explicit(&ctx->crypto_send, sizeof(ctx->crypto_send));
+	kfree(ctx);
+}
+
 static void tls_sk_proto_close(struct sock *sk, long timeout)
 {
 	struct tls_context *ctx = tls_get_ctx(sk);
@@ -246,7 +255,7 @@ static void tls_sk_proto_close(struct so
 	kfree(ctx->iv);
 
 	sk_proto_close = ctx->sk_proto_close;
-	kfree(ctx);
+	tls_ctx_free(ctx);
 
 	release_sock(sk);
 	sk_proto_close(sk, timeout);
@@ -274,7 +283,7 @@ static int do_tls_getsockopt_tx(struct s
 	}
 
 	/* get user crypto info */
-	crypto_info = &ctx->crypto_send;
+	crypto_info = &ctx->crypto_send.info;
 
 	if (!TLS_CRYPTO_INFO_READY(crypto_info)) {
 		rc = -EBUSY;
@@ -371,7 +380,7 @@ static int do_tls_setsockopt_tx(struct s
 	}
 
 	/* get user crypto info */
-	crypto_info = &ctx->crypto_send;
+	crypto_info = &ctx->crypto_send.info;
 
 	/* Currently we don't support set crypto info more than one time */
 	if (TLS_CRYPTO_INFO_READY(crypto_info)) {
net/tls/tls_sw.c +1 -1
@@ -687,7 +687,7 @@ int tls_set_sw_offload(struct sock *sk,
 	ctx->priv_ctx = (struct tls_offload_context *)sw_ctx;
 	ctx->free_resources = tls_sw_free_resources;
 
-	crypto_info = &ctx->crypto_send;
+	crypto_info = &ctx->crypto_send.info;
 	switch (crypto_info->cipher_type) {
 	case TLS_CIPHER_AES_GCM_128: {
 		nonce_size = TLS_CIPHER_AES_GCM_128_IV_SIZE;
author maintainer
#14 lore raw

PATCH 14/64 NFC: Fix possible memory corruption when handling SHDLC I-Frame commands

In reply to Greg Kroah-Hartman

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

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

From: Suren Baghdasaryan <[email protected]>

commit 674d9de02aa7d521ebdf66c3958758bdd9c64e11 upstream.

When handling SHDLC I-Frame commands "pipe" field used for indexing into an array should be checked before usage. If left unchecked it might access memory outside of the array of size NFC_HCI_MAX_PIPES(127).

Malformed NFC HCI frames could be injected by a malicious NFC device communicating with the device being attacked (remote attack vector), or even by an attacker with physical access to the I2C bus such that they could influence the data transfers on that bus (local attack vector). skb->data is controlled by the attacker and has only been sanitized in the most trivial ways (CRC check), therefore we can consider the create_info struct and all of its members to tainted. 'create_info->pipe' with max value of 255 (uint8) is used to take an offset of the hdev->pipes array of 127 elements which can lead to OOB write.

---
 net/nfc/hci/core.c |   10 ++++++++++
 1 file changed, 10 insertions(+)
net/nfc/hci/core.c +10 -0
@@ -209,6 +209,11 @@ void nfc_hci_cmd_received(struct nfc_hci
 		}
 		create_info = (struct hci_create_pipe_resp *)skb->data;
 
+		if (create_info->pipe >= NFC_HCI_MAX_PIPES) {
+			status = NFC_HCI_ANY_E_NOK;
+			goto exit;
+		}
+
 		/* Save the new created pipe and bind with local gate,
 		 * the description for skb->data[3] is destination gate id
 		 * but since we received this cmd from host controller, we
@@ -232,6 +237,11 @@ void nfc_hci_cmd_received(struct nfc_hci
 		}
 		delete_info = (struct hci_delete_pipe_noti *)skb->data;
 
+		if (delete_info->pipe >= NFC_HCI_MAX_PIPES) {
+			status = NFC_HCI_ANY_E_NOK;
+			goto exit;
+		}
+
 		hdev->pipes[delete_info->pipe].gate = NFC_HCI_INVALID_GATE;
 		hdev->pipes[delete_info->pipe].dest_host = NFC_HCI_INVALID_HOST;
 		break;
author maintainer
#15 lore raw

PATCH 15/64 NFC: Fix the number of pipes

In reply to Greg Kroah-Hartman

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

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

From: Suren Baghdasaryan <[email protected]>

commit e285d5bfb7e9785d289663baef252dd315e171f8 upstream.

According to ETSI TS 102 622 specification chapter 4.4 pipe identifier is 7 bits long which allows for 128 unique pipe IDs. Because NFC_HCI_MAX_PIPES is used as the number of pipes supported and not as the max pipe ID, its value should be 128 instead of 127.

nfc_hci_recv_from_llc extracts pipe ID from packet header using NFC_HCI_FRAGMENT(0x7F) mask which allows for pipe ID value of 127. Same happens when NCI_HCP_MSG_GET_PIPE() is being used. With pipes array having only 127 elements and pipe ID of 127 the OOB memory access will result.

---
 include/net/nfc/hci.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
include/net/nfc/hci.h +1 -1
@@ -87,7 +87,7 @@ struct nfc_hci_pipe {
  * According to specification 102 622 chapter 4.4 Pipes,
  * the pipe identifier is 7 bits long.
  */
-#define NFC_HCI_MAX_PIPES		127
+#define NFC_HCI_MAX_PIPES		128
 struct nfc_hci_init_data {
 	u8 gate_count;
 	struct nfc_hci_gate gates[NFC_HCI_MAX_CUSTOM_GATES];
author maintainer
#17 lore raw

PATCH 17/64 ASoC: rsnd: fixup not to call clk_get/set under non-atomic

In reply to Greg Kroah-Hartman

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

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

From: Jiada Wang <[email protected]>

commit 4d230d12710646788af581ba0155d83ab48b955c upstream.

Clocking operations clk_get/set_rate, are non-atomic, they shouldn't be called in soc_pcm_trigger() which is atomic.

Following issue was found due to execution of clk_get_rate() causes sleep in soc_pcm_trigger(), which shouldn't be blocked.

We can reproduce this issue by following
> enable CONFIG_DEBUG_ATOMIC_SLEEP=y
> compile, and boot
> mount -t debugfs none /sys/kernel/debug
> while true; do cat /sys/kernel/debug/clk/clk_summary > /dev/null; done & > while true; do aplay xxx; done

This patch adds support to .prepare callback, and moves non-atomic clocking operations to it. As .prepare is non-atomic, it is always called before trigger_start/trigger_stop.

	BUG: sleeping function called from invalid context at kernel/locking/mutex.c:620
	in_atomic(): 1, irqs_disabled(): 128, pid: 2242, name: aplay
	INFO: lockdep is turned off.
	irq event stamp: 5964
	hardirqs last enabled at (5963): [<ffff200008e59e40>] mutex_lock_nested+0x6e8/0x6f0
	hardirqs last disabled at (5964): [<ffff200008e623f0>] _raw_spin_lock_irqsave+0x24/0x68
	softirqs last enabled at (5502): [<ffff200008081838>] __do_softirq+0x560/0x10c0
	softirqs last disabled at (5495): [<ffff2000080c2e78>] irq_exit+0x160/0x25c
	Preemption disabled at:[ 62.904063] [<ffff200008be4d48>] snd_pcm_stream_lock+0xb4/0xc0
	CPU: 2 PID: 2242 Comm: aplay Tainted: G B C 4.9.54+ #186
	Hardware name: Renesas Salvator-X board based on r8a7795 (DT)
	Call trace:
	[<ffff20000808fe48>] dump_backtrace+0x0/0x37c
	[<ffff2000080901d8>] show_stack+0x14/0x1c
	[<ffff2000086f4458>] dump_stack+0xfc/0x154
	[<ffff2000081134a0>] ___might_sleep+0x57c/0x58c
	[<ffff2000081136b8>] __might_sleep+0x208/0x21c
	[<ffff200008e5980c>] mutex_lock_nested+0xb4/0x6f0
	[<ffff2000087cac74>] clk_prepare_lock+0xb0/0x184
	[<ffff2000087cb094>] clk_core_get_rate+0x14/0x54
	[<ffff2000087cb0f4>] clk_get_rate+0x20/0x34
	[<ffff20000113aa00>] rsnd_adg_ssi_clk_try_start+0x158/0x4f8 [snd_soc_rcar]
	[<ffff20000113da00>] rsnd_ssi_init+0x668/0x7a0 [snd_soc_rcar]
	[<ffff200001133ff4>] rsnd_soc_dai_trigger+0x4bc/0xcf8 [snd_soc_rcar]
	[<ffff200008c1af24>] soc_pcm_trigger+0x2a4/0x2d4
Fixes e7d850dd10f4 ("ASoC: rsnd: use mod base common method on SSI-parent")
[Kuninori: tidyup for upstream]
---
 sound/soc/sh/rcar/core.c |   11 +++++++++++
 sound/soc/sh/rcar/rsnd.h |    7 +++++++
 sound/soc/sh/rcar/ssi.c  |   16 ++++++++++------
 3 files changed, 28 insertions(+), 6 deletions(-)
sound/soc/sh/rcar/core.c +11 -0
@@ -925,12 +925,23 @@ static void rsnd_soc_dai_shutdown(struct
 	rsnd_dai_call(nolock_stop, io, priv);
 }
 
+static int rsnd_soc_dai_prepare(struct snd_pcm_substream *substream,
+				struct snd_soc_dai *dai)
+{
+	struct rsnd_priv *priv = rsnd_dai_to_priv(dai);
+	struct rsnd_dai *rdai = rsnd_dai_to_rdai(dai);
+	struct rsnd_dai_stream *io = rsnd_rdai_to_io(rdai, substream);
+
+	return rsnd_dai_call(prepare, io, priv);
+}
+
 static const struct snd_soc_dai_ops rsnd_soc_dai_ops = {
 	.startup	= rsnd_soc_dai_startup,
 	.shutdown	= rsnd_soc_dai_shutdown,
 	.trigger	= rsnd_soc_dai_trigger,
 	.set_fmt	= rsnd_soc_dai_set_fmt,
 	.set_tdm_slot	= rsnd_soc_set_dai_tdm_slot,
+	.prepare	= rsnd_soc_dai_prepare,
 };
 
 void rsnd_parse_connect_common(struct rsnd_dai *rdai,
sound/soc/sh/rcar/rsnd.h +7 -0
@@ -283,6 +283,9 @@ struct rsnd_mod_ops {
 	int (*nolock_stop)(struct rsnd_mod *mod,
 		    struct rsnd_dai_stream *io,
 		    struct rsnd_priv *priv);
+	int (*prepare)(struct rsnd_mod *mod,
+		       struct rsnd_dai_stream *io,
+		       struct rsnd_priv *priv);
 };
 
 struct rsnd_dai_stream;
@@ -312,6 +315,7 @@ struct rsnd_mod {
  * H	0: fallback
  * H	0: hw_params
  * H	0: pointer
+ * H	0: prepare
  */
 #define __rsnd_mod_shift_nolock_start	0
 #define __rsnd_mod_shift_nolock_stop	0
@@ -326,6 +330,7 @@ struct rsnd_mod {
 #define __rsnd_mod_shift_fallback	28 /* always called */
 #define __rsnd_mod_shift_hw_params	28 /* always called */
 #define __rsnd_mod_shift_pointer	28 /* always called */
+#define __rsnd_mod_shift_prepare	28 /* always called */
 
 #define __rsnd_mod_add_probe		0
 #define __rsnd_mod_add_remove		0
@@ -340,6 +345,7 @@ struct rsnd_mod {
 #define __rsnd_mod_add_fallback		0
 #define __rsnd_mod_add_hw_params	0
 #define __rsnd_mod_add_pointer		0
+#define __rsnd_mod_add_prepare		0
 
 #define __rsnd_mod_call_probe		0
 #define __rsnd_mod_call_remove		0
@@ -354,6 +360,7 @@ struct rsnd_mod {
 #define __rsnd_mod_call_pointer		0
 #define __rsnd_mod_call_nolock_start	0
 #define __rsnd_mod_call_nolock_stop	1
+#define __rsnd_mod_call_prepare		0
 
 #define rsnd_mod_to_priv(mod) ((mod)->priv)
 #define rsnd_mod_id(mod) ((mod) ? (mod)->id : -1)
sound/soc/sh/rcar/ssi.c +10 -6
@@ -280,7 +280,7 @@ static int rsnd_ssi_master_clk_start(str
 	if (rsnd_ssi_is_multi_slave(mod, io))
 		return 0;
 
-	if (ssi->usrcnt > 1) {
+	if (ssi->rate) {
 		if (ssi->rate != rate) {
 			dev_err(dev, "SSI parent/child should use same rate\n");
 			return -EINVAL;
@@ -482,7 +482,6 @@ static int rsnd_ssi_init(struct rsnd_mod
 			 struct rsnd_priv *priv)
 {
 	struct rsnd_ssi *ssi = rsnd_mod_to_ssi(mod);
-	int ret;
 
 	if (!rsnd_ssi_is_run_mods(mod, io))
 		return 0;
@@ -493,10 +492,6 @@ static int rsnd_ssi_init(struct rsnd_mod
 
 	rsnd_mod_power_on(mod);
 
-	ret = rsnd_ssi_master_clk_start(mod, io);
-	if (ret < 0)
-		return ret;
-
 	rsnd_ssi_config_init(mod, io);
 
 	rsnd_ssi_register_setup(mod);
@@ -847,6 +842,13 @@ static int rsnd_ssi_pointer(struct rsnd_
 	return 0;
 }
 
+static int rsnd_ssi_prepare(struct rsnd_mod *mod,
+			    struct rsnd_dai_stream *io,
+			    struct rsnd_priv *priv)
+{
+	return rsnd_ssi_master_clk_start(mod, io);
+}
+
 static struct rsnd_mod_ops rsnd_ssi_pio_ops = {
 	.name	= SSI_NAME,
 	.probe	= rsnd_ssi_common_probe,
@@ -859,6 +861,7 @@ static struct rsnd_mod_ops rsnd_ssi_pio_
 	.pointer= rsnd_ssi_pointer,
 	.pcm_new = rsnd_ssi_pcm_new,
 	.hw_params = rsnd_ssi_hw_params,
+	.prepare = rsnd_ssi_prepare,
 };
 
 static int rsnd_ssi_dma_probe(struct rsnd_mod *mod,
@@ -935,6 +938,7 @@ static struct rsnd_mod_ops rsnd_ssi_dma_
 	.pcm_new = rsnd_ssi_pcm_new,
 	.fallback = rsnd_ssi_fallback,
 	.hw_params = rsnd_ssi_hw_params,
+	.prepare = rsnd_ssi_prepare,
 };
 
 int rsnd_ssi_is_dma_mode(struct rsnd_mod *mod)
author maintainer
#18 lore raw

PATCH 18/64 ALSA: bebob: fix memory leak for M-Audio FW1814 and ProjectMix I/O at error path

In reply to Greg Kroah-Hartman

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

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

From: Takashi Sakamoto <[email protected]>

commit b1fbebd4164b3d170ad916dcd692cf843c9c065d upstream.

After allocating model-dependent data for M-Audio FW1814 and ProjectMix I/O, ALSA bebob driver has memory leak at error path.

This commit releases the allocated data at the error path.

Fixes 04a2c73c97eb('ALSA: bebob: delayed registration of sound card')
Cc <[email protected]> # v4.7+
---
 sound/firewire/bebob/bebob.c        |    2 ++
 sound/firewire/bebob/bebob_maudio.c |    4 ----
 2 files changed, 2 insertions(+), 4 deletions(-)
sound/firewire/bebob/bebob.c +2 -0
@@ -263,6 +263,8 @@ do_registration(struct work_struct *work
 error:
 	mutex_unlock(&devices_mutex);
 	snd_bebob_stream_destroy_duplex(bebob);
+	kfree(bebob->maudio_special_quirk);
+	bebob->maudio_special_quirk = NULL;
 	snd_card_free(bebob->card);
 	dev_info(&bebob->unit->device,
 		 "Sound card registration failed: %d\n", err);
sound/firewire/bebob/bebob_maudio.c +0 -4
@@ -290,10 +290,6 @@ snd_bebob_maudio_special_discover(struct
 		bebob->midi_output_ports = 2;
 	}
 end:
-	if (err < 0) {
-		kfree(params);
-		bebob->maudio_special_quirk = NULL;
-	}
 	mutex_unlock(&bebob->mutex);
 	return err;
 }
author maintainer
#2 lore raw

PATCH 2/64 ipv6: fix possible use-after-free in ip6_xmit()

In reply to Greg Kroah-Hartman

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

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

From: Eric Dumazet <[email protected]>

[ Upstream commit bbd6528d28c1b8e80832b3b018ec402b6f5c3215 ]

In the unlikely case ip6_xmit() has to call skb_realloc_headroom(), we need to call skb_set_owner_w() before consuming original skb, otherwise we risk a use-after-free.

Bring IPv6 in line with what we do in IPv4 to fix this.

Fixes 1da177e4c3f41 ("Linux-2.6.12-rc2")
---
 net/ipv6/ip6_output.c |    6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)
net/ipv6/ip6_output.c +2 -4
@@ -219,12 +219,10 @@ int ip6_xmit(const struct sock *sk, stru
 				kfree_skb(skb);
 				return -ENOBUFS;
 			}
+			if (skb->sk)
+				skb_set_owner_w(skb2, skb->sk);
 			consume_skb(skb);
 			skb = skb2;
-			/* skb_set_owner_w() changes sk->sk_wmem_alloc atomically,
-			 * it is safe to call in our context (socket lock not held)
-			 */
-			skb_set_owner_w(skb, (struct sock *)sk);
 		}
 		if (opt->opt_flen)
 			ipv6_push_frag_opts(skb, opt, &proto);
author maintainer
#22 lore raw

PATCH 22/64 ALSA: firewire-digi00x: fix memory leak of private data

In reply to Greg Kroah-Hartman

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

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

From: Takashi Sakamoto <[email protected]>

commit a49a83ab05e34edd6c71a4fbd062c9a7ba6d18aa upstream.

Although private data of sound card instance is usually allocated in the tail of the instance, drivers in ALSA firewire stack allocate the private data before allocating the instance. In this case, the private data should be released explicitly at .private_free callback of the instance.

This commit fixes memory leak following to the above design.

Fixes 86c8dd7f4da3 ('ALSA: firewire-digi00x: delayed registration of sound card')
Cc <[email protected]> # v4.7+
---
 sound/firewire/digi00x/digi00x.c |    1 +
 1 file changed, 1 insertion(+)
sound/firewire/digi00x/digi00x.c +1 -0
@@ -49,6 +49,7 @@ static void dg00x_free(struct snd_dg00x
 	fw_unit_put(dg00x->unit);
 
 	mutex_destroy(&dg00x->mutex);
+	kfree(dg00x);
 }
 
 static void dg00x_card_free(struct snd_card *card)
author maintainer
#24 lore raw

PATCH 24/64 ALSA: fireworks: fix memory leak of response buffer at error path

In reply to Greg Kroah-Hartman

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

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

From: Takashi Sakamoto <[email protected]>

commit c3b55e2ec9c76e7a0de2a0b1dc851fdc9440385b upstream.

After allocating memory object for response buffer, ALSA fireworks driver has leak of the memory object at error path.

This commit releases the object at the error path.

Fixes 7d3c1d5901aa('ALSA: fireworks: delayed registration of sound card')
Cc <[email protected]> # v4.7+
---
 sound/firewire/fireworks/fireworks.c |    2 ++
 1 file changed, 2 insertions(+)
sound/firewire/fireworks/fireworks.c +2 -0
@@ -301,6 +301,8 @@ error:
 	snd_efw_transaction_remove_instance(efw);
 	snd_efw_stream_destroy_duplex(efw);
 	snd_card_free(efw->card);
+	kfree(efw->resp_buf);
+	efw->resp_buf = NULL;
 	dev_info(&efw->unit->device,
 		 "Sound card registration failed: %d\n", err);
 }
author maintainer
#25 lore raw

PATCH 25/64 ALSA: oxfw: fix memory leak for model-dependent data at error path

In reply to Greg Kroah-Hartman

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

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

From: Takashi Sakamoto <[email protected]>

commit ce925f088b979537f22f9e05eb923ef9822ca139 upstream.

After allocating model-dependent data, ALSA OXFW driver has memory leak of the data at error path.

This commit releases the data at the error path.

Fixes 6c29230e2a5f ('ALSA: oxfw: delayed registration of sound card')
Cc <[email protected]> # v4.7+
---
 sound/firewire/oxfw/oxfw.c |    2 ++
 1 file changed, 2 insertions(+)
sound/firewire/oxfw/oxfw.c +2 -0
@@ -276,6 +276,8 @@ error:
 	if (oxfw->has_output)
 		snd_oxfw_stream_destroy_simplex(oxfw, &oxfw->tx_stream);
 	snd_card_free(oxfw->card);
+	kfree(oxfw->spec);
+	oxfw->spec = NULL;
 	dev_info(&oxfw->unit->device,
 		 "Sound card registration failed: %d\n", err);
 }
author maintainer
#3 lore raw

PATCH 3/64 net/appletalk: fix minor pointer leak to userspace in SIOCFINDIPDDPRT

In reply to Greg Kroah-Hartman

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

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

From: Willy Tarreau <[email protected]>

[ Upstream commit 9824dfae5741275473a23a7ed5756c7b6efacc9d ]

Fields ->dev and ->next of struct ipddp_route may be copied to userspace on the SIOCFINDIPDDPRT ioctl. This is only accessible to CAP_NET_ADMIN though. Let's manually copy the relevant fields instead of using memcpy().

---
 drivers/net/appletalk/ipddp.c |    8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)
drivers/net/appletalk/ipddp.c +6 -2
@@ -283,8 +283,12 @@ static int ipddp_ioctl(struct net_device
                 case SIOCFINDIPDDPRT:
 			spin_lock_bh(&ipddp_route_lock);
 			rp = __ipddp_find_route(&rcp);
-			if (rp)
-				memcpy(&rcp2, rp, sizeof(rcp2));
+			if (rp) {
+				memset(&rcp2, 0, sizeof(rcp2));
+				rcp2.ip    = rp->ip;
+				rcp2.at    = rp->at;
+				rcp2.flags = rp->flags;
+			}
 			spin_unlock_bh(&ipddp_route_lock);
 
 			if (rp) {
author maintainer
#4 lore raw

PATCH 4/64 net: hp100: fix always-true check for link up state

In reply to Greg Kroah-Hartman

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

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

From: Colin Ian King <[email protected]>

[ Upstream commit a7f38002fb69b44f8fc622ecb838665d0b8666af ]

The operation ~(p100_inb(VG_LAN_CFG_1) & HP100_LINK_UP) returns a value that is always non-zero and hence the wait for the link to drop always terminates prematurely. Fix this by using a logical not operator instead of a bitwise complement. This issue has been in the driver since pre-2.6.12-rc2.

Detected by CoverityScan, CID#114157 ("Logical vs. bitwise operator")

---
 drivers/net/ethernet/hp/hp100.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/ethernet/hp/hp100.c +1 -1
@@ -2634,7 +2634,7 @@ static int hp100_login_to_vg_hub(struct
 		/* Wait for link to drop */
 		time = jiffies + (HZ / 10);
 		do {
-			if (~(hp100_inb(VG_LAN_CFG_1) & HP100_LINK_UP_ST))
+			if (!(hp100_inb(VG_LAN_CFG_1) & HP100_LINK_UP_ST))
 				break;
 			if (!in_interrupt())
 				schedule_timeout_interruptible(1);
author maintainer
#7 lore raw

PATCH 7/64 udp4: fix IP_CMSG_CHECKSUM for connected sockets

In reply to Greg Kroah-Hartman

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

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

From: Paolo Abeni <[email protected]>

[ Upstream commit 2b5a921740a55c00223a797d075b9c77c42cb171 ]

commit 2abb7cdc0dc8 ("udp: Add support for doing checksum unnecessary conversion") left out the early demux path for connected sockets. As a result IP_CMSG_CHECKSUM gives wrong values for such socket when GRO is not enabled/available.

This change addresses the issue by moving the csum conversion to a common helper and using such helper in both the default and the early demux rx path.

Fixes 2abb7cdc0dc8 ("udp: Add support for doing checksum unnecessary conversion")
---
 net/ipv4/udp.c |   49 ++++++++++++++++++++++++++-----------------------
 1 file changed, 26 insertions(+), 23 deletions(-)
net/ipv4/udp.c +26 -23
@@ -2049,6 +2049,28 @@ static inline int udp4_csum_init(struct
 							 inet_compute_pseudo);
 }
 
+/* wrapper for udp_queue_rcv_skb tacking care of csum conversion and
+ * return code conversion for ip layer consumption
+ */
+static int udp_unicast_rcv_skb(struct sock *sk, struct sk_buff *skb,
+			       struct udphdr *uh)
+{
+	int ret;
+
+	if (inet_get_convert_csum(sk) && uh->check && !IS_UDPLITE(sk))
+		skb_checksum_try_convert(skb, IPPROTO_UDP, uh->check,
+					 inet_compute_pseudo);
+
+	ret = udp_queue_rcv_skb(sk, skb);
+
+	/* a return value > 0 means to resubmit the input, but
+	 * it wants the return to be -protocol, or 0
+	 */
+	if (ret > 0)
+		return -ret;
+	return 0;
+}
+
 /*
  *	All we need to do is get the socket, and then do a checksum.
  */
@@ -2095,14 +2117,9 @@ int __udp4_lib_rcv(struct sk_buff *skb,
 		if (unlikely(sk->sk_rx_dst != dst))
 			udp_sk_rx_dst_set(sk, dst);
 
-		ret = udp_queue_rcv_skb(sk, skb);
+		ret = udp_unicast_rcv_skb(sk, skb, uh);
 		sock_put(sk);
-		/* a return value > 0 means to resubmit the input, but
-		 * it wants the return to be -protocol, or 0
-		 */
-		if (ret > 0)
-			return -ret;
-		return 0;
+		return ret;
 	}
 
 	if (rt->rt_flags & (RTCF_BROADCAST|RTCF_MULTICAST))
@@ -2110,22 +2127,8 @@ int __udp4_lib_rcv(struct sk_buff *skb,
 						saddr, daddr, udptable, proto);
 
 	sk = __udp4_lib_lookup_skb(skb, uh->source, uh->dest, udptable);
-	if (sk) {
-		int ret;
-
-		if (inet_get_convert_csum(sk) && uh->check && !IS_UDPLITE(sk))
-			skb_checksum_try_convert(skb, IPPROTO_UDP, uh->check,
-						 inet_compute_pseudo);
-
-		ret = udp_queue_rcv_skb(sk, skb);
-
-		/* a return value > 0 means to resubmit the input, but
-		 * it wants the return to be -protocol, or 0
-		 */
-		if (ret > 0)
-			return -ret;
-		return 0;
-	}
+	if (sk)
+		return udp_unicast_rcv_skb(sk, skb, uh);
 
 	if (!xfrm4_policy_check(NULL, XFRM_POLICY_IN, skb))
 		goto drop;
author maintainer
#8 lore raw

PATCH 8/64 neighbour: confirm neigh entries when ARP packet is received

In reply to Greg Kroah-Hartman

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

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

From: Vasily Khoruzhick <[email protected]>

[ Upstream commit f0e0d04413fcce9bc76388839099aee93cd0d33b ]

Update 'confirmed' timestamp when ARP packet is received. It shouldn't affect locktime logic and anyway entry can be confirmed by any higher-layer protocol. Thus it makes sense to confirm it when ARP packet is received.

Fixes 77d7123342dc ("neighbour: update neigh timestamps iff update is effective")
---
 net/core/neighbour.c |   13 ++++++++-----
 1 file changed, 8 insertions(+), 5 deletions(-)
net/core/neighbour.c +8 -5
@@ -1174,6 +1174,12 @@ int neigh_update(struct neighbour *neigh
 		lladdr = neigh->ha;
 	}
 
+	/* Update confirmed timestamp for neighbour entry after we
+	 * received ARP packet even if it doesn't change IP to MAC binding.
+	 */
+	if (new & NUD_CONNECTED)
+		neigh->confirmed = jiffies;
+
 	/* If entry was valid and address is not changed,
 	   do not change entry state, if new one is STALE.
 	 */
@@ -1195,15 +1201,12 @@ int neigh_update(struct neighbour *neigh
 		}
 	}
 
-	/* Update timestamps only once we know we will make a change to the
+	/* Update timestamp only once we know we will make a change to the
 	 * neighbour entry. Otherwise we risk to move the locktime window with
 	 * noop updates and ignore relevant ARP updates.
 	 */
-	if (new != old || lladdr != neigh->ha) {
-		if (new & NUD_CONNECTED)
-			neigh->confirmed = jiffies;
+	if (new != old || lladdr != neigh->ha)
 		neigh->updated = jiffies;
-	}
 
 	if (new != old) {
 		neigh_del_timer(neigh);
author maintainer
#9 lore raw

PATCH 9/64 udp6: add missing checks on edumux packet processing

In reply to Greg Kroah-Hartman

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

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

From: Paolo Abeni <[email protected]>

[ Upstream commit eb63f2964dbe36f26deac77d3016791675821ded ]

Currently the UDPv6 early demux rx code path lacks some mandatory checks, already implemented into the normal RX code path - namely the checksum conversion and no_check6_rx check.

Similar to the previous commit, we move the common processing to an UDPv6 specific helper and call it from both edemux code path and normal code path. In respect to the UDPv4, we need to add an explicit check for non zero csum according to no_check6_rx value.

Fixes c9f2c1ae123a ("udp6: fix socket leak on early demux")
Fixes 2abb7cdc0dc8 ("udp: Add support for doing checksum unnecessary conversion")
---
 net/ipv6/udp.c |   65 ++++++++++++++++++++++++++++++++-------------------------
 1 file changed, 37 insertions(+), 28 deletions(-)
net/ipv6/udp.c +37 -28
@@ -780,6 +780,28 @@ static void udp6_sk_rx_dst_set(struct so
 	}
 }
 
+/* wrapper for udp_queue_rcv_skb tacking care of csum conversion and
+ * return code conversion for ip layer consumption
+ */
+static int udp6_unicast_rcv_skb(struct sock *sk, struct sk_buff *skb,
+				struct udphdr *uh)
+{
+	int ret;
+
+	if (inet_get_convert_csum(sk) && uh->check && !IS_UDPLITE(sk))
+		skb_checksum_try_convert(skb, IPPROTO_UDP, uh->check,
+					 ip6_compute_pseudo);
+
+	ret = udpv6_queue_rcv_skb(sk, skb);
+
+	/* a return value > 0 means to resubmit the input, but
+	 * it wants the return to be -protocol, or 0
+	 */
+	if (ret > 0)
+		return -ret;
+	return 0;
+}
+
 int __udp6_lib_rcv(struct sk_buff *skb, struct udp_table *udptable,
 		   int proto)
 {
@@ -831,13 +853,14 @@ int __udp6_lib_rcv(struct sk_buff *skb,
 		if (unlikely(sk->sk_rx_dst != dst))
 			udp6_sk_rx_dst_set(sk, dst);
 
-		ret = udpv6_queue_rcv_skb(sk, skb);
-		sock_put(sk);
+		if (!uh->check && !udp_sk(sk)->no_check6_rx) {
+			sock_put(sk);
+			goto report_csum_error;
+		}
 
-		/* a return value > 0 means to resubmit the input */
-		if (ret > 0)
-			return ret;
-		return 0;
+		ret = udp6_unicast_rcv_skb(sk, skb, uh);
+		sock_put(sk);
+		return ret;
 	}
 
 	/*
@@ -850,30 +873,13 @@ int __udp6_lib_rcv(struct sk_buff *skb,
 	/* Unicast */
 	sk = __udp6_lib_lookup_skb(skb, uh->source, uh->dest, udptable);
 	if (sk) {
-		int ret;
-
-		if (!uh->check && !udp_sk(sk)->no_check6_rx) {
-			udp6_csum_zero_error(skb);
-			goto csum_error;
-		}
-
-		if (inet_get_convert_csum(sk) && uh->check && !IS_UDPLITE(sk))
-			skb_checksum_try_convert(skb, IPPROTO_UDP, uh->check,
-						 ip6_compute_pseudo);
-
-		ret = udpv6_queue_rcv_skb(sk, skb);
-
-		/* a return value > 0 means to resubmit the input */
-		if (ret > 0)
-			return ret;
-
-		return 0;
+		if (!uh->check && !udp_sk(sk)->no_check6_rx)
+			goto report_csum_error;
+		return udp6_unicast_rcv_skb(sk, skb, uh);
 	}
 
-	if (!uh->check) {
-		udp6_csum_zero_error(skb);
-		goto csum_error;
-	}
+	if (!uh->check)
+		goto report_csum_error;
 
 	if (!xfrm6_policy_check(NULL, XFRM_POLICY_IN, skb))
 		goto discard;
@@ -894,6 +900,9 @@ short_packet:
 			    ulen, skb->len,
 			    daddr, ntohs(uh->dest));
 	goto discard;
+
+report_csum_error:
+	udp6_csum_zero_error(skb);
 csum_error:
 	__UDP6_INC_STATS(net, UDP_MIB_CSUMERRORS, proto == IPPROTO_UDPLITE);
 discard:

Greg Kroah-Hartman

author maintainer
#0 lore raw

cover 4.14.73-stable review

This is the start of the stable review cycle for the 4.14.73 release. There are 64 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 Sat Sep 29 09:02:21 UTC 2018. Anything received after that time might be too late.

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

	https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.73-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.14.y
and the diffstat can be found below.

thanks,

greg k-h

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

Greg Kroah-Hartman <[email protected]>

    Linux 4.14.73-rc1

Thomas Gleixner <[email protected]>
tick/nohz: Prevent bogus softirq pending warning

Steve Wise <[email protected]>
iw_cxgb4: only allow 1 flush on user qps

Nadav Amit <[email protected]>
vmw_balloon: include asm/io.h

Zachary Zhang <[email protected]>
PCI: aardvark: Size bridges before resources allocation

Steve Muckle <[email protected]>
sched/fair: Fix vruntime_normalized() for remote non-migration wakeup

Eric Biggers <[email protected]>
ext4: show test_dummy_encryption mount option in /proc/mounts

Li Dongyang <[email protected]>
ext4: don't mark mmp buffer head dirty

Theodore Ts'o <[email protected]>
ext4: fix online resizing for bigalloc file systems with a 1k block size

Theodore Ts'o <[email protected]>
ext4: fix online resize's handling of a too-small final block group

Theodore Ts'o <[email protected]>
ext4: recalucate superblock checksum after updating free blocks/inodes

Theodore Ts'o <[email protected]>
ext4: avoid arithemetic overflow that can trigger a BUG

Theodore Ts'o <[email protected]>
ext4: avoid divide by zero fault when deleting corrupted inline directories

Theodore Ts'o <[email protected]>
ext4: check to make sure the rename(2)'s destination is not freed

Gustavo A. R. Silva <[email protected]>
tty: vt_ioctl: fix potential Spectre v1

Lyude Paul <[email protected]>
drm/atomic: Use drm_drv_uses_atomic_modeset() for debugfs creation

Alex Deucher <[email protected]>
drm/amdgpu: add new polaris pci id

Emil Lundmark <[email protected]>
drm: udl: Destroy framebuffer only if it was initialized

Boris Brezillon <[email protected]>
drm/vc4: Fix the "no scaling" case on multi-planar YUV formats

Lyude Paul <[email protected]>
drm/nouveau/drm/nouveau: Prevent handling ACPI HPD events too early

Lyude Paul <[email protected]>
drm/nouveau/drm/nouveau: Use pm_runtime_get_noresume() in connector_detect()

Lyude Paul <[email protected]>
drm/nouveau/drm/nouveau: Fix bogus drm_kms_helper_poll_enable() placement

Lyude Paul <[email protected]>
drm/nouveau/drm/nouveau: Don't forget to cancel hpd_work on suspend/unload

Lyude Paul <[email protected]>
drm/nouveau: Fix deadlocks in nouveau_connector_detect()

Junxiao Bi <[email protected]>
ocfs2: fix ocfs2 read block panic

Richard Weinberger <[email protected]>
Revert "ubifs: xattr: Don't operate on deleted inodes"

Vincent Pelletier <[email protected]>
scsi: target: iscsi: Use bin2hex instead of a re-implementation

Vincent Pelletier <[email protected]>
scsi: target: iscsi: Use hex2bin instead of a re-implementation

Lubomir Rintel <[email protected]>
Revert "uapi/linux/keyctl.h: don't use C++ reserved keyword as a struct member name"

Greg Kroah-Hartman <[email protected]>
Revert "rpmsg: core: add support to power domains for devices"

Joel Fernandes (Google) <[email protected]>
mm: shmem.c: Correctly annotate new inodes for lockdep

Vaibhav Nagarnaik <[email protected]>
ring-buffer: Allow for rescheduling when removing pages

Mika Westerberg <[email protected]>
Revert "PCI: Add ACS quirk for Intel 300 series"

Kirill Kapranov <[email protected]>
spi: fix IDR collision on systems with both fixed and dynamic SPI bus numbers

Boris Ostrovsky <[email protected]>
xen/x86/vpmu: Zero struct pt_regs before calling into sample handling code

Juergen Gross <[email protected]>
xen/netfront: don't bug in case of too many frags

Mario Limonciello <[email protected]>
platform/x86: alienware-wmi: Correct a memory leak

Takashi Sakamoto <[email protected]>
ALSA: oxfw: fix memory leak of private data

Takashi Sakamoto <[email protected]>
ALSA: oxfw: fix memory leak of discovered stream formats at error path

Takashi Sakamoto <[email protected]>
ALSA: oxfw: fix memory leak for model-dependent data at error path

Takashi Sakamoto <[email protected]>
ALSA: fireworks: fix memory leak of response buffer at error path

Takashi Sakamoto <[email protected]>
ALSA: firewire-tascam: fix memory leak of private data

Takashi Sakamoto <[email protected]>

    ALSA: firewire-digi00x: fix memory leak of private data

Takashi Sakamoto <[email protected]>
ALSA: fireface: fix memory leak in ff400_switch_fetching_mode()

Willy Tarreau <[email protected]>
ALSA: emu10k1: fix possible info leak to userspace on SNDRV_EMU10K1_IOCTL_INFO

Takashi Sakamoto <[email protected]>
ALSA: bebob: use address returned by kmalloc() instead of kernel stack for streaming DMA mapping

Takashi Sakamoto <[email protected]>
ALSA: bebob: fix memory leak for M-Audio FW1814 and ProjectMix I/O at error path

Jiada Wang <[email protected]>
ASoC: rsnd: fixup not to call clk_get/set under non-atomic

Sébastien Szymanski <[email protected]>
ASoC: cs4265: fix MMTLR Data switch control

Suren Baghdasaryan <[email protected]>
NFC: Fix the number of pipes

Suren Baghdasaryan <[email protected]>
NFC: Fix possible memory corruption when handling SHDLC I-Frame commands

Sabrina Dubroca <[email protected]>
tls: clear key material from kernel memory when do_tls_setsockopt_conf fails

Sabrina Dubroca <[email protected]>
tls: zero the crypto information from tls_context before freeing

Sabrina Dubroca <[email protected]>
tls: don't copy the key out of tls12_crypto_info_aes_gcm_128

Davide Caratti <[email protected]>
net/sched: act_sample: fix NULL dereference in the data path

Paolo Abeni <[email protected]>
udp6: add missing checks on edumux packet processing

Vasily Khoruzhick <[email protected]>
neighbour: confirm neigh entries when ARP packet is received

Paolo Abeni <[email protected]>
udp4: fix IP_CMSG_CHECKSUM for connected sockets

Bjørn Mork <[email protected]>
qmi_wwan: set DTR for modems in forced USB2 mode

Guillaume Nault <[email protected]>
pppoe: fix reception of frames with no mac header

Colin Ian King <[email protected]>
net: hp100: fix always-true check for link up state

Willy Tarreau <[email protected]>
net/appletalk: fix minor pointer leak to userspace in SIOCFINDIPDDPRT

Eric Dumazet <[email protected]>
ipv6: fix possible use-after-free in ip6_xmit()

Toke Høiland-Jørgensen <[email protected]>

    gso_segment: Reset skb->mac_len after modifying network header

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

Diffstat:

 Makefile                                    |  4 +-
 arch/x86/xen/pmu.c                          |  2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c     | 14 ++++---
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c     |  1 +
 drivers/gpu/drm/drm_atomic.c                |  2 +-
 drivers/gpu/drm/drm_debugfs.c               |  2 +-
 drivers/gpu/drm/nouveau/nouveau_connector.c | 42 +++++++++++++++----
 drivers/gpu/drm/nouveau/nouveau_display.c   | 42 ++++++++++++++-----
 drivers/gpu/drm/nouveau/nouveau_display.h   |  2 +-
 drivers/gpu/drm/nouveau/nouveau_drm.c       |  2 +-
 drivers/gpu/drm/udl/udl_fb.c                |  8 ++--
 drivers/gpu/drm/vc4/vc4_plane.c             | 25 ++++++-----
 drivers/infiniband/hw/cxgb4/qp.c            |  6 +++
 drivers/misc/vmw_balloon.c                  |  1 +
 drivers/net/appletalk/ipddp.c               |  8 +++-
 drivers/net/ethernet/hp/hp100.c             |  2 +-
 drivers/net/ppp/pppoe.c                     |  3 ++
 drivers/net/usb/qmi_wwan.c                  | 14 +++----
 drivers/net/xen-netfront.c                  |  8 +++-
 drivers/pci/host/pci-aardvark.c             |  1 +
 drivers/pci/quirks.c                        |  6 ---
 drivers/platform/x86/alienware-wmi.c        |  1 +
 drivers/rpmsg/rpmsg_core.c                  |  7 ----
 drivers/spi/spi.c                           |  9 ++++
 drivers/target/iscsi/iscsi_target_auth.c    | 45 ++++++++------------
 drivers/tty/vt/vt_ioctl.c                   |  4 ++
 fs/ext4/dir.c                               | 20 ++++-----
 fs/ext4/ext4.h                              |  3 ++
 fs/ext4/inline.c                            |  4 +-
 fs/ext4/inode.c                             |  9 +++-
 fs/ext4/mmp.c                               |  1 -
 fs/ext4/namei.c                             |  6 +++
 fs/ext4/resize.c                            | 23 +++++++++-
 fs/ext4/super.c                             |  4 ++
 fs/ocfs2/buffer_head_io.c                   |  1 +
 fs/ubifs/xattr.c                            | 24 -----------
 include/net/nfc/hci.h                       |  2 +-
 include/net/tls.h                           | 14 ++++---
 include/uapi/linux/keyctl.h                 |  2 +-
 kernel/sched/fair.c                         |  3 +-
 kernel/time/tick-sched.c                    |  2 +-
 kernel/trace/ring_buffer.c                  |  2 +
 mm/shmem.c                                  |  2 +
 net/core/neighbour.c                        | 13 +++---
 net/ipv4/af_inet.c                          |  1 +
 net/ipv4/udp.c                              | 49 ++++++++++++----------
 net/ipv6/ip6_offload.c                      |  1 +
 net/ipv6/ip6_output.c                       |  6 +--
 net/ipv6/udp.c                              | 65 ++++++++++++++++-------------
 net/nfc/hci/core.c                          | 10 +++++
 net/sched/act_sample.c                      |  2 +-
 net/tls/tls_main.c                          | 17 ++++++--
 net/tls/tls_sw.c                            |  7 +---
 security/keys/dh.c                          |  2 +-
 sound/firewire/bebob/bebob.c                |  2 +
 sound/firewire/bebob/bebob_maudio.c         | 28 ++++++-------
 sound/firewire/digi00x/digi00x.c            |  1 +
 sound/firewire/fireface/ff-protocol-ff400.c |  9 ++--
 sound/firewire/fireworks/fireworks.c        |  2 +
 sound/firewire/oxfw/oxfw.c                  | 10 +++++
 sound/firewire/tascam/tascam.c              |  1 +
 sound/pci/emu10k1/emufx.c                   |  2 +-
 sound/soc/codecs/cs4265.c                   |  4 +-
 sound/soc/sh/rcar/core.c                    | 11 +++++
 sound/soc/sh/rcar/rsnd.h                    |  7 ++++
 sound/soc/sh/rcar/ssi.c                     | 16 ++++---
 66 files changed, 401 insertions(+), 248 deletions(-)
author maintainer
#36 lore raw

PATCH 36/64 Revert "uapi/linux/keyctl.h: dont use C++ reserved keyword as a struct member name"

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

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

From: Lubomir Rintel <[email protected]>

commit 8c0f9f5b309d627182d5da72a69246f58bde1026 upstream.

This changes UAPI, breaking iwd and libell:

ell/key.c: In function 'kernel_dh_compute':
ell/key.c:205:38: error: 'struct keyctl_dh_params' has no member named 'private'; did you mean 'dh_private'?
struct keyctl_dh_params params = { .private = private,
^~~~~~~
dh_private

This reverts commit 8a2336e549d385bb0b46880435b411df8d8200e8.

Fixes 8a2336e549d3 ("uapi/linux/keyctl.h: don't use C++ reserved keyword as a struct member name")
cc Randy Dunlap <[email protected]>
cc Mat Martineau <[email protected]>
cc Stephan Mueller <[email protected]>
cc James Morris <[email protected]>
cc "Serge E. Hallyn" <[email protected]>
cc Mat Martineau <[email protected]>
cc Andrew Morton <[email protected]>
cc Linus Torvalds <[email protected]>
---
 include/uapi/linux/keyctl.h |    2 +-
 security/keys/dh.c          |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)
include/uapi/linux/keyctl.h +1 -1
@@ -65,7 +65,7 @@
 
 /* keyctl structures */
 struct keyctl_dh_params {
-	__s32 dh_private;
+	__s32 private;
 	__s32 prime;
 	__s32 base;
 };
security/keys/dh.c +1 -1
@@ -307,7 +307,7 @@ long __keyctl_dh_compute(struct keyctl_d
 	}
 	dh_inputs.g_size = dlen;
 
-	dlen = dh_data_from_key(pcopy.dh_private, &dh_inputs.key);
+	dlen = dh_data_from_key(pcopy.private, &dh_inputs.key);
 	if (dlen < 0) {
 		ret = dlen;
 		goto out2;
author maintainer
#37 lore raw

PATCH 37/64 scsi: target: iscsi: Use hex2bin instead of a re-implementation

In reply to Greg Kroah-Hartman

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

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

From: Vincent Pelletier <[email protected]>

commit 1816494330a83f2a064499d8ed2797045641f92c upstream.

This change has the following effects, in order of descreasing importance:

1) Prevent a stack buffer overflow

2) Do not append an unnecessary NULL to an anyway binary buffer, which is writing one byte past client_digest when caller is:
chap_string_to_hex(client_digest, chap_r, strlen(chap_r));

The latter was found by KASAN (see below) when input value hes expected size (32 hex chars), and further analysis revealed a stack buffer overflow can happen when network-received value is longer, allowing an unauthenticated remote attacker to smash up to 17 bytes after destination buffer (16 bytes attacker-controlled and one null). As switching to hex2bin requires specifying destination buffer length, and does not internally append any null, it solves both issues.

This addresses CVE-2018-14633.

Beyond this:

- Validate received value length and check hex2bin accepted the input, to log this rejection reason instead of just failing authentication.

- Only log received CHAP_R and CHAP_C values once they passed sanity checks.

==================================================================

BUG: KASAN: stack-out-of-bounds in chap_string_to_hex+0x32/0x60 [iscsi_target_mod]
Write of size 1 at addr ffff8801090ef7c8 by task kworker/0:0/1021

CPU: 0 PID: 1021 Comm: kworker/0:0 Tainted: G           O      4.17.8kasan.sess.connops+ #2
Hardware name: To be filled by O.E.M. To be filled by O.E.M./Aptio CRB, BIOS 5.6.5 05/19/2014
Workqueue: events iscsi_target_do_login_rx [iscsi_target_mod]
Call Trace:
 dump_stack+0x71/0xac
 print_address_description+0x65/0x22e
 ? chap_string_to_hex+0x32/0x60 [iscsi_target_mod]
 kasan_report.cold.6+0x241/0x2fd
 chap_string_to_hex+0x32/0x60 [iscsi_target_mod]
 chap_server_compute_md5.isra.2+0x2cb/0x860 [iscsi_target_mod]
 ? chap_binaryhex_to_asciihex.constprop.5+0x50/0x50 [iscsi_target_mod]
 ? ftrace_caller_op_ptr+0xe/0xe
 ? __orc_find+0x6f/0xc0
 ? unwind_next_frame+0x231/0x850
 ? kthread+0x1a0/0x1c0
 ? ret_from_fork+0x35/0x40
 ? ret_from_fork+0x35/0x40
 ? iscsi_target_do_login_rx+0x3bc/0x4c0 [iscsi_target_mod]
 ? deref_stack_reg+0xd0/0xd0
 ? iscsi_target_do_login_rx+0x3bc/0x4c0 [iscsi_target_mod]
 ? is_module_text_address+0xa/0x11
 ? kernel_text_address+0x4c/0x110
 ? __save_stack_trace+0x82/0x100
 ? ret_from_fork+0x35/0x40
 ? save_stack+0x8c/0xb0
 ? 0xffffffffc1660000
 ? iscsi_target_do_login+0x155/0x8d0 [iscsi_target_mod]
 ? iscsi_target_do_login_rx+0x3bc/0x4c0 [iscsi_target_mod]
 ? process_one_work+0x35c/0x640
 ? worker_thread+0x66/0x5d0
 ? kthread+0x1a0/0x1c0
 ? ret_from_fork+0x35/0x40
 ? iscsi_update_param_value+0x80/0x80 [iscsi_target_mod]
 ? iscsit_release_cmd+0x170/0x170 [iscsi_target_mod]
 chap_main_loop+0x172/0x570 [iscsi_target_mod]
 ? chap_server_compute_md5.isra.2+0x860/0x860 [iscsi_target_mod]
 ? rx_data+0xd6/0x120 [iscsi_target_mod]
 ? iscsit_print_session_params+0xd0/0xd0 [iscsi_target_mod]
 ? cyc2ns_read_begin.part.2+0x90/0x90
 ? _raw_spin_lock_irqsave+0x25/0x50
 ? memcmp+0x45/0x70
 iscsi_target_do_login+0x875/0x8d0 [iscsi_target_mod]
 ? iscsi_target_check_first_request.isra.5+0x1a0/0x1a0 [iscsi_target_mod]
 ? del_timer+0xe0/0xe0
 ? memset+0x1f/0x40
 ? flush_sigqueue+0x29/0xd0
 iscsi_target_do_login_rx+0x3bc/0x4c0 [iscsi_target_mod]
 ? iscsi_target_nego_release+0x80/0x80 [iscsi_target_mod]
 ? iscsi_target_restore_sock_callbacks+0x130/0x130 [iscsi_target_mod]
 process_one_work+0x35c/0x640
 worker_thread+0x66/0x5d0
 ? flush_rcu_work+0x40/0x40
 kthread+0x1a0/0x1c0
 ? kthread_bind+0x30/0x30
 ret_from_fork+0x35/0x40

The buggy address belongs to the page:
page:ffffea0004243bc0 count:0 mapcount:0 mapping:0000000000000000 index:0x0
flags: 0x17fffc000000000()
raw: 017fffc000000000 0000000000000000 0000000000000000 00000000ffffffff
raw: ffffea0004243c20 ffffea0004243ba0 0000000000000000 0000000000000000
page dumped because: kasan: bad access detected

Memory state around the buggy address:
 ffff8801090ef680: f2 f2 f2 f2 f2 f2 f2 01 f2 f2 f2 f2 f2 f2 f2 00
 ffff8801090ef700: f2 f2 f2 f2 f2 f2 f2 00 02 f2 f2 f2 f2 f2 f2 00
>ffff8801090ef780: 00 f2 f2 f2 f2 f2 f2 00 00 f2 f2 f2 f2 f2 f2 00
                                              ^
 ffff8801090ef800: 00 f2 f2 f2 f2 f2 f2 00 00 00 00 02 f2 f2 f2 f2
 ffff8801090ef880: f2 f2 f2 00 00 00 00 00 00 00 00 f2 f2 f2 f2 00
==================================================================
---
 drivers/target/iscsi/iscsi_target_auth.c |   30 ++++++++++++++----------------
 1 file changed, 14 insertions(+), 16 deletions(-)
drivers/target/iscsi/iscsi_target_auth.c +14 -16
@@ -26,18 +26,6 @@
 #include "iscsi_target_nego.h"
 #include "iscsi_target_auth.h"
 
-static int chap_string_to_hex(unsigned char *dst, unsigned char *src, int len)
-{
-	int j = DIV_ROUND_UP(len, 2), rc;
-
-	rc = hex2bin(dst, src, j);
-	if (rc < 0)
-		pr_debug("CHAP string contains non hex digit symbols\n");
-
-	dst[j] = '\0';
-	return j;
-}
-
 static void chap_binaryhex_to_asciihex(char *dst, char *src, int src_len)
 {
 	int i;
@@ -248,9 +236,16 @@ static int chap_server_compute_md5(
 		pr_err("Could not find CHAP_R.\n");
 		goto out;
 	}
+	if (strlen(chap_r) != MD5_SIGNATURE_SIZE * 2) {
+		pr_err("Malformed CHAP_R\n");
+		goto out;
+	}
+	if (hex2bin(client_digest, chap_r, MD5_SIGNATURE_SIZE) < 0) {
+		pr_err("Malformed CHAP_R\n");
+		goto out;
+	}
 
 	pr_debug("[server] Got CHAP_R=%s\n", chap_r);
-	chap_string_to_hex(client_digest, chap_r, strlen(chap_r));
 
 	tfm = crypto_alloc_shash("md5", 0, 0);
 	if (IS_ERR(tfm)) {
@@ -349,9 +344,7 @@ static int chap_server_compute_md5(
 		pr_err("Could not find CHAP_C.\n");
 		goto out;
 	}
-	pr_debug("[server] Got CHAP_C=%s\n", challenge);
-	challenge_len = chap_string_to_hex(challenge_binhex, challenge,
-				strlen(challenge));
+	challenge_len = DIV_ROUND_UP(strlen(challenge), 2);
 	if (!challenge_len) {
 		pr_err("Unable to convert incoming challenge\n");
 		goto out;
@@ -360,6 +353,11 @@ static int chap_server_compute_md5(
 		pr_err("CHAP_C exceeds maximum binary size of 1024 bytes\n");
 		goto out;
 	}
+	if (hex2bin(challenge_binhex, challenge, challenge_len) < 0) {
+		pr_err("Malformed CHAP_C\n");
+		goto out;
+	}
+	pr_debug("[server] Got CHAP_C=%s\n", challenge);
 	/*
 	 * During mutual authentication, the CHAP_C generated by the
 	 * initiator must not match the original CHAP_C generated by
author maintainer
#38 lore raw

PATCH 38/64 scsi: target: iscsi: Use bin2hex instead of a re-implementation

In reply to Greg Kroah-Hartman

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

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

From: Vincent Pelletier <[email protected]>

commit 8c39e2699f8acb2e29782a834e56306da24937fe upstream.

---
 drivers/target/iscsi/iscsi_target_auth.c |   15 +++------------
 1 file changed, 3 insertions(+), 12 deletions(-)
drivers/target/iscsi/iscsi_target_auth.c +3 -12
@@ -26,15 +26,6 @@
 #include "iscsi_target_nego.h"
 #include "iscsi_target_auth.h"
 
-static void chap_binaryhex_to_asciihex(char *dst, char *src, int src_len)
-{
-	int i;
-
-	for (i = 0; i < src_len; i++) {
-		sprintf(&dst[i*2], "%02x", (int) src[i] & 0xff);
-	}
-}
-
 static int chap_gen_challenge(
 	struct iscsi_conn *conn,
 	int caller,
@@ -50,7 +41,7 @@ static int chap_gen_challenge(
 	ret = get_random_bytes_wait(chap->challenge, CHAP_CHALLENGE_LENGTH);
 	if (unlikely(ret))
 		return ret;
-	chap_binaryhex_to_asciihex(challenge_asciihex, chap->challenge,
+	bin2hex(challenge_asciihex, chap->challenge,
 				CHAP_CHALLENGE_LENGTH);
 	/*
 	 * Set CHAP_C, and copy the generated challenge into c_str.
@@ -289,7 +280,7 @@ static int chap_server_compute_md5(
 		goto out;
 	}
 
-	chap_binaryhex_to_asciihex(response, server_digest, MD5_SIGNATURE_SIZE);
+	bin2hex(response, server_digest, MD5_SIGNATURE_SIZE);
 	pr_debug("[server] MD5 Server Digest: %s\n", response);
 
 	if (memcmp(server_digest, client_digest, MD5_SIGNATURE_SIZE) != 0) {
@@ -411,7 +402,7 @@ static int chap_server_compute_md5(
 	/*
 	 * Convert response from binary hex to ascii hext.
 	 */
-	chap_binaryhex_to_asciihex(response, digest, MD5_SIGNATURE_SIZE);
+	bin2hex(response, digest, MD5_SIGNATURE_SIZE);
 	*nr_out_len += sprintf(nr_out_ptr + *nr_out_len, "CHAP_R=0x%s",
 			response);
 	*nr_out_len += 1;
author maintainer
#41 lore raw

PATCH 41/64 drm/nouveau: Fix deadlocks in nouveau_connector_detect()

In reply to Greg Kroah-Hartman

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

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

From: Lyude Paul <[email protected]>

commit 3e1a12754d4df5804bfca5dedf09d2ba291bdc2a upstream.

When we disable hotplugging on the GPU, we need to be able to synchronize with each connector's hotplug interrupt handler before the interrupt is finally disabled. This can be a problem however, since nouveau_connector_detect() currently grabs a runtime power reference when handling connector probing. This will deadlock the runtime suspend handler like so:

[  861.480896] INFO: task kworker/0:2:61 blocked for more than 120 seconds.
[  861.483290]       Tainted: G           O      4.18.0-rc6Lyude-Test+ #1
[  861.485158] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[  861.486332] kworker/0:2     D    0    61      2 0x80000000
[  861.487044] Workqueue: events nouveau_display_hpd_work [nouveau]
[  861.487737] Call Trace:
[  861.488394]  __schedule+0x322/0xaf0
[  861.489070]  schedule+0x33/0x90
[  861.489744]  rpm_resume+0x19c/0x850
[  861.490392]  ? finish_wait+0x90/0x90
[  861.491068]  __pm_runtime_resume+0x4e/0x90
[  861.491753]  nouveau_display_hpd_work+0x22/0x60 [nouveau]
[  861.492416]  process_one_work+0x231/0x620
[  861.493068]  worker_thread+0x44/0x3a0
[  861.493722]  kthread+0x12b/0x150
[  861.494342]  ? wq_pool_ids_show+0x140/0x140
[  861.494991]  ? kthread_create_worker_on_cpu+0x70/0x70
[  861.495648]  ret_from_fork+0x3a/0x50
[  861.496304] INFO: task kworker/6:2:320 blocked for more than 120 seconds.
[  861.496968]       Tainted: G           O      4.18.0-rc6Lyude-Test+ #1
[  861.497654] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[  861.498341] kworker/6:2     D    0   320      2 0x80000080
[  861.499045] Workqueue: pm pm_runtime_work
[  861.499739] Call Trace:
[  861.500428]  __schedule+0x322/0xaf0
[  861.501134]  ? wait_for_completion+0x104/0x190
[  861.501851]  schedule+0x33/0x90
[  861.502564]  schedule_timeout+0x3a5/0x590
[  861.503284]  ? mark_held_locks+0x58/0x80
[  861.503988]  ? _raw_spin_unlock_irq+0x2c/0x40
[  861.504710]  ? wait_for_completion+0x104/0x190
[  861.505417]  ? trace_hardirqs_on_caller+0xf4/0x190
[  861.506136]  ? wait_for_completion+0x104/0x190
[  861.506845]  wait_for_completion+0x12c/0x190
[  861.507555]  ? wake_up_q+0x80/0x80
[  861.508268]  flush_work+0x1c9/0x280
[  861.508990]  ? flush_workqueue_prep_pwqs+0x1b0/0x1b0
[  861.509735]  nvif_notify_put+0xb1/0xc0 [nouveau]
[  861.510482]  nouveau_display_fini+0xbd/0x170 [nouveau]
[  861.511241]  nouveau_display_suspend+0x67/0x120 [nouveau]
[  861.511969]  nouveau_do_suspend+0x5e/0x2d0 [nouveau]
[  861.512715]  nouveau_pmops_runtime_suspend+0x47/0xb0 [nouveau]
[  861.513435]  pci_pm_runtime_suspend+0x6b/0x180
[  861.514165]  ? pci_has_legacy_pm_support+0x70/0x70
[  861.514897]  __rpm_callback+0x7a/0x1d0
[  861.515618]  ? pci_has_legacy_pm_support+0x70/0x70
[  861.516313]  rpm_callback+0x24/0x80
[  861.517027]  ? pci_has_legacy_pm_support+0x70/0x70
[  861.517741]  rpm_suspend+0x142/0x6b0
[  861.518449]  pm_runtime_work+0x97/0xc0
[  861.519144]  process_one_work+0x231/0x620
[  861.519831]  worker_thread+0x44/0x3a0
[  861.520522]  kthread+0x12b/0x150
[  861.521220]  ? wq_pool_ids_show+0x140/0x140
[  861.521925]  ? kthread_create_worker_on_cpu+0x70/0x70
[  861.522622]  ret_from_fork+0x3a/0x50
[  861.523299] INFO: task kworker/6:0:1329 blocked for more than 120 seconds.
[  861.523977]       Tainted: G           O      4.18.0-rc6Lyude-Test+ #1
[  861.524644] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[  861.525349] kworker/6:0     D    0  1329      2 0x80000000
[  861.526073] Workqueue: events nvif_notify_work [nouveau]
[  861.526751] Call Trace:
[  861.527411]  __schedule+0x322/0xaf0
[  861.528089]  schedule+0x33/0x90
[  861.528758]  rpm_resume+0x19c/0x850
[  861.529399]  ? finish_wait+0x90/0x90
[  861.530073]  __pm_runtime_resume+0x4e/0x90
[  861.530798]  nouveau_connector_detect+0x7e/0x510 [nouveau]
[  861.531459]  ? ww_mutex_lock+0x47/0x80
[  861.532097]  ? ww_mutex_lock+0x47/0x80
[  861.532819]  ? drm_modeset_lock+0x88/0x130 [drm]
[  861.533481]  drm_helper_probe_detect_ctx+0xa0/0x100 [drm_kms_helper]
[  861.534127]  drm_helper_hpd_irq_event+0xa4/0x120 [drm_kms_helper]
[  861.534940]  nouveau_connector_hotplug+0x98/0x120 [nouveau]
[  861.535556]  nvif_notify_work+0x2d/0xb0 [nouveau]
[  861.536221]  process_one_work+0x231/0x620
[  861.536994]  worker_thread+0x44/0x3a0
[  861.537757]  kthread+0x12b/0x150
[  861.538463]  ? wq_pool_ids_show+0x140/0x140
[  861.539102]  ? kthread_create_worker_on_cpu+0x70/0x70
[  861.539815]  ret_from_fork+0x3a/0x50
[  861.540521]
               Showing all locks held in the system:
[  861.541696] 2 locks held by kworker/0:2/61:
[  861.542406]  #0: 000000002dbf8af5 ((wq_completion)"events"){+.+.}, at: process_one_work+0x1b3/0x620
[  861.543071]  #1: 0000000076868126 ((work_completion)(&drm->hpd_work)){+.+.}, at: process_one_work+0x1b3/0x620
[  861.543814] 1 lock held by khungtaskd/64:
[  861.544535]  #0: 0000000059db4b53 (rcu_read_lock){....}, at: debug_show_all_locks+0x23/0x185
[  861.545160] 3 locks held by kworker/6:2/320:
[  861.545896]  #0: 00000000d9e1bc59 ((wq_completion)"pm"){+.+.}, at: process_one_work+0x1b3/0x620
[  861.546702]  #1: 00000000c9f92d84 ((work_completion)(&dev->power.work)){+.+.}, at: process_one_work+0x1b3/0x620
[  861.547443]  #2: 000000004afc5de1 (drm_connector_list_iter){.+.+}, at: nouveau_display_fini+0x96/0x170 [nouveau]
[  861.548146] 1 lock held by dmesg/983:
[  861.548889] 2 locks held by zsh/1250:
[  861.549605]  #0: 00000000348e3cf6 (&tty->ldisc_sem){++++}, at: ldsem_down_read+0x37/0x40
[  861.550393]  #1: 000000007009a7a8 (&ldata->atomic_read_lock){+.+.}, at: n_tty_read+0xc1/0x870
[  861.551122] 6 locks held by kworker/6:0/1329:
[  861.551957]  #0: 000000002dbf8af5 ((wq_completion)"events"){+.+.}, at: process_one_work+0x1b3/0x620
[  861.552765]  #1: 00000000ddb499ad ((work_completion)(&notify->work)#2){+.+.}, at: process_one_work+0x1b3/0x620
[  861.553582]  #2: 000000006e013cbe (&dev->mode_config.mutex){+.+.}, at: drm_helper_hpd_irq_event+0x6c/0x120 [drm_kms_helper]
[  861.554357]  #3: 000000004afc5de1 (drm_connector_list_iter){.+.+}, at: drm_helper_hpd_irq_event+0x78/0x120 [drm_kms_helper]
[  861.555227]  #4: 0000000044f294d9 (crtc_ww_class_acquire){+.+.}, at: drm_helper_probe_detect_ctx+0x3d/0x100 [drm_kms_helper]
[  861.556133]  #5: 00000000db193642 (crtc_ww_class_mutex){+.+.}, at: drm_modeset_lock+0x4b/0x130 [drm]
[  861.557864] =============================================
[  861.559507] NMI backtrace for cpu 2
[  861.560363] CPU: 2 PID: 64 Comm: khungtaskd Tainted: G           O      4.18.0-rc6Lyude-Test+ #1
[  861.561197] Hardware name: LENOVO 20EQS64N0B/20EQS64N0B, BIOS N1EET78W (1.51 ) 05/18/2018
[  861.561948] Call Trace:
[  861.562757]  dump_stack+0x8e/0xd3
[  861.563516]  nmi_cpu_backtrace.cold.3+0x14/0x5a
[  861.564269]  ? lapic_can_unplug_cpu.cold.27+0x42/0x42
[  861.565029]  nmi_trigger_cpumask_backtrace+0xa1/0xae
[  861.565789]  arch_trigger_cpumask_backtrace+0x19/0x20
[  861.566558]  watchdog+0x316/0x580
[  861.567355]  kthread+0x12b/0x150
[  861.568114]  ? reset_hung_task_detector+0x20/0x20
[  861.568863]  ? kthread_create_worker_on_cpu+0x70/0x70
[  861.569598]  ret_from_fork+0x3a/0x50
[  861.570370] Sending NMI from CPU 2 to CPUs 0-1,3-7:
[  861.571426] NMI backtrace for cpu 6 skipped: idling at intel_idle+0x7f/0x120
[  861.571429] NMI backtrace for cpu 7 skipped: idling at intel_idle+0x7f/0x120
[  861.571432] NMI backtrace for cpu 3 skipped: idling at intel_idle+0x7f/0x120
[  861.571464] NMI backtrace for cpu 5 skipped: idling at intel_idle+0x7f/0x120
[  861.571467] NMI backtrace for cpu 0 skipped: idling at intel_idle+0x7f/0x120
[  861.571469] NMI backtrace for cpu 4 skipped: idling at intel_idle+0x7f/0x120
[  861.571472] NMI backtrace for cpu 1 skipped: idling at intel_idle+0x7f/0x120
[  861.572428] Kernel panic - not syncing: hung_task: blocked tasks

So: fix this by making it so that normal hotplug handling /only/ happens so long as the GPU is currently awake without any pending runtime PM requests. In the event that a hotplug occurs while the device is suspending or resuming, we can simply defer our response until the GPU is fully runtime resumed again.

Changes since v4:
- Use a new trick I came up with using pm_runtime_get() instead of the hackish junk we had before

---
 drivers/gpu/drm/nouveau/nouveau_connector.c |   22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)
drivers/gpu/drm/nouveau/nouveau_connector.c +22 -0
@@ -1120,6 +1120,26 @@ nouveau_connector_hotplug(struct nvif_no
 	const struct nvif_notify_conn_rep_v0 *rep = notify->data;
 	const char *name = connector->name;
 	struct nouveau_encoder *nv_encoder;
+	int ret;
+
+	ret = pm_runtime_get(drm->dev->dev);
+	if (ret == 0) {
+		/* We can't block here if there's a pending PM request
+		 * running, as we'll deadlock nouveau_display_fini() when it
+		 * calls nvif_put() on our nvif_notify struct. So, simply
+		 * defer the hotplug event until the device finishes resuming
+		 */
+		NV_DEBUG(drm, "Deferring HPD on %s until runtime resume\n",
+			 name);
+		schedule_work(&drm->hpd_work);
+
+		pm_runtime_put_noidle(drm->dev->dev);
+		return NVIF_NOTIFY_KEEP;
+	} else if (ret != 1 && ret != -EACCES) {
+		NV_WARN(drm, "HPD on %s dropped due to RPM failure: %d\n",
+			name, ret);
+		return NVIF_NOTIFY_DROP;
+	}
 
 	if (rep->mask & NVIF_NOTIFY_CONN_V0_IRQ) {
 		NV_DEBUG(drm, "service %s\n", name);
@@ -1137,6 +1157,8 @@ nouveau_connector_hotplug(struct nvif_no
 		drm_helper_hpd_irq_event(connector->dev);
 	}
 
+	pm_runtime_mark_last_busy(drm->dev->dev);
+	pm_runtime_put_autosuspend(drm->dev->dev);
 	return NVIF_NOTIFY_KEEP;
 }
 
author maintainer
#42 lore raw

PATCH 42/64 drm/nouveau/drm/nouveau: Dont forget to cancel hpd_work on suspend/unload

In reply to Greg Kroah-Hartman

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

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

From: Lyude Paul <[email protected]>

commit 2f7ca781fd382cf8dde73ed36dfdd93fd05b3332 upstream.

Currently, there's nothing in nouveau that actually cancels this work struct. So, cancel it on suspend/unload. Otherwise, if we're unlucky enough hpd_work might try to keep running up until the system is suspended.

---
 drivers/gpu/drm/nouveau/nouveau_display.c |    9 ++++++---
 drivers/gpu/drm/nouveau/nouveau_display.h |    2 +-
 drivers/gpu/drm/nouveau/nouveau_drm.c     |    2 +-
 3 files changed, 8 insertions(+), 5 deletions(-)
drivers/gpu/drm/nouveau/nouveau_display.c +6 -3
@@ -426,7 +426,7 @@ nouveau_display_init(struct drm_device *
 }
 
 void
-nouveau_display_fini(struct drm_device *dev, bool suspend)
+nouveau_display_fini(struct drm_device *dev, bool suspend, bool runtime)
 {
 	struct nouveau_display *disp = nouveau_display(dev);
 	struct nouveau_drm *drm = nouveau_drm(dev);
@@ -451,6 +451,9 @@ nouveau_display_fini(struct drm_device *
 	}
 	drm_connector_list_iter_end(&conn_iter);
 
+	if (!runtime)
+		cancel_work_sync(&drm->hpd_work);
+
 	drm_kms_helper_poll_disable(dev);
 	disp->fini(dev);
 }
@@ -640,11 +643,11 @@ nouveau_display_suspend(struct drm_devic
 			}
 		}
 
-		nouveau_display_fini(dev, true);
+		nouveau_display_fini(dev, true, runtime);
 		return 0;
 	}
 
-	nouveau_display_fini(dev, true);
+	nouveau_display_fini(dev, true, runtime);
 
 	list_for_each_entry(crtc, &dev->mode_config.crtc_list, head) {
 		struct nouveau_framebuffer *nouveau_fb;
drivers/gpu/drm/nouveau/nouveau_display.h +1 -1
@@ -64,7 +64,7 @@ nouveau_display(struct drm_device *dev)
 int  nouveau_display_create(struct drm_device *dev);
 void nouveau_display_destroy(struct drm_device *dev);
 int  nouveau_display_init(struct drm_device *dev);
-void nouveau_display_fini(struct drm_device *dev, bool suspend);
+void nouveau_display_fini(struct drm_device *dev, bool suspend, bool runtime);
 int  nouveau_display_suspend(struct drm_device *dev, bool runtime);
 void nouveau_display_resume(struct drm_device *dev, bool runtime);
 int  nouveau_display_vblank_enable(struct drm_device *, unsigned int);
drivers/gpu/drm/nouveau/nouveau_drm.c +1 -1
@@ -546,7 +546,7 @@ nouveau_drm_unload(struct drm_device *de
 	nouveau_debugfs_fini(drm);
 
 	if (dev->mode_config.num_crtc)
-		nouveau_display_fini(dev, false);
+		nouveau_display_fini(dev, false, false);
 	nouveau_display_destroy(dev);
 
 	nouveau_bios_takedown(dev);
author maintainer
#43 lore raw

PATCH 43/64 drm/nouveau/drm/nouveau: Fix bogus drm_kms_helper_poll_enable() placement

In reply to Greg Kroah-Hartman

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

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

From: Lyude Paul <[email protected]>

commit d77ef138ff572409ab93d492e5e6c826ee6fb21d upstream.

Turns out this part is my fault for not noticing when reviewing 9a2eba337cace ("drm/nouveau: Fix drm poll_helper handling"). Currently we call drm_kms_helper_poll_enable() from nouveau_display_hpd_work(). This makes basically no sense however, because that means we're calling drm_kms_helper_poll_enable() every time we schedule the hotplug detection work. This is also against the advice mentioned in drm_kms_helper_poll_enable()'s documentation:

Note that calls to enable and disable polling must be strictly ordered, which is automatically the case when they're only call from suspend/resume callbacks.

Of course, hotplugs can't really be ordered. They could even happen immediately after we called drm_kms_helper_poll_disable() in nouveau_display_fini(), which can lead to all sorts of issues.

Additionally; enabling polling /after/ we call drm_helper_hpd_irq_event() could also mean that we'd miss a hotplug event anyway, since drm_helper_hpd_irq_event() wouldn't bother trying to probe connectors so long as polling is disabled.

So; simply move this back into nouveau_display_init() again. The race condition that both of these patches attempted to work around has already been fixed properly in

d61a5c106351 ("drm/nouveau: Fix deadlock on runtime suspend")

Fixes 9a2eba337cace ("drm/nouveau: Fix drm poll_helper handling")
Cc Lukas Wunner <[email protected]>
Cc Peter Ujfalusi <[email protected]>
---
 drivers/gpu/drm/nouveau/nouveau_display.c |    7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)
drivers/gpu/drm/nouveau/nouveau_display.c +5 -2
@@ -356,8 +356,6 @@ nouveau_display_hpd_work(struct work_str
 	pm_runtime_get_sync(drm->dev->dev);
 
 	drm_helper_hpd_irq_event(drm->dev);
-	/* enable polling for external displays */
-	drm_kms_helper_poll_enable(drm->dev);
 
 	pm_runtime_mark_last_busy(drm->dev->dev);
 	pm_runtime_put_sync(drm->dev->dev);
@@ -412,6 +410,11 @@ nouveau_display_init(struct drm_device *
 	if (ret)
 		return ret;
 
+	/* enable connector detection and polling for connectors without HPD
+	 * support
+	 */
+	drm_kms_helper_poll_enable(dev);
+
 	/* enable hotplug interrupts */
 	drm_connector_list_iter_begin(dev, &conn_iter);
 	nouveau_for_each_non_mst_connector_iter(connector, &conn_iter) {
author maintainer
#44 lore raw

PATCH 44/64 drm/nouveau/drm/nouveau: Use pm_runtime_get_noresume() in connector_detect()

In reply to Greg Kroah-Hartman

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

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

From: Lyude Paul <[email protected]>

commit 6833fb1ec120bf078e1a527c573a09d4de286224 upstream.

It's true we can't resume the device from poll workers in nouveau_connector_detect(). We can however, prevent the autosuspend timer from elapsing immediately if it hasn't already without risking any sort of deadlock with the runtime suspend/resume operations. So do that instead of entirely avoiding grabbing a power reference.

---
 drivers/gpu/drm/nouveau/nouveau_connector.c |   20 +++++++++++---------
 1 file changed, 11 insertions(+), 9 deletions(-)
drivers/gpu/drm/nouveau/nouveau_connector.c +11 -9
@@ -570,12 +570,16 @@ nouveau_connector_detect(struct drm_conn
 		nv_connector->edid = NULL;
 	}
 
-	/* Outputs are only polled while runtime active, so acquiring a
-	 * runtime PM ref here is unnecessary (and would deadlock upon
-	 * runtime suspend because it waits for polling to finish).
+	/* Outputs are only polled while runtime active, so resuming the
+	 * device here is unnecessary (and would deadlock upon runtime suspend
+	 * because it waits for polling to finish). We do however, want to
+	 * prevent the autosuspend timer from elapsing during this operation
+	 * if possible.
 	 */
-	if (!drm_kms_helper_is_poll_worker()) {
-		ret = pm_runtime_get_sync(connector->dev->dev);
+	if (drm_kms_helper_is_poll_worker()) {
+		pm_runtime_get_noresume(dev->dev);
+	} else {
+		ret = pm_runtime_get_sync(dev->dev);
 		if (ret < 0 && ret != -EACCES)
 			return conn_status;
 	}
@@ -653,10 +657,8 @@ detect_analog:
 
  out:
 
-	if (!drm_kms_helper_is_poll_worker()) {
-		pm_runtime_mark_last_busy(connector->dev->dev);
-		pm_runtime_put_autosuspend(connector->dev->dev);
-	}
+	pm_runtime_mark_last_busy(dev->dev);
+	pm_runtime_put_autosuspend(dev->dev);
 
 	return conn_status;
 }
author maintainer
#45 lore raw

PATCH 45/64 drm/nouveau/drm/nouveau: Prevent handling ACPI HPD events too early

In reply to Greg Kroah-Hartman

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

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

From: Lyude Paul <[email protected]>

commit 79e765ad665da4b8aa7e9c878bd2fef837f6fea5 upstream.

On most systems with ACPI hotplugging support, it seems that we always receive a hotplug event once we re-enable EC interrupts even if the GPU hasn't even been resumed yet.

This can cause problems since even though we schedule hpd_work to handle connector reprobing for us, hpd_work synchronizes on pm_runtime_get_sync() to wait until the device is ready to perform reprobing. Since runtime suspend/resume callbacks are disabled before the PM core calls ->suspend(), any calls to pm_runtime_get_sync() during this period will grab a runtime PM ref and return immediately with -EACCES. Because we schedule hpd_work from our ACPI HPD handler, and hpd_work synchronizes on pm_runtime_get_sync(), this causes us to launch a connector reprobe immediately even if the GPU isn't actually resumed just yet. This causes various warnings in dmesg and occasionally, also prevents some displays connected to the dedicated GPU from coming back up after suspend. Example:

usb 1-4: USB disconnect, device number 14
usb 1-4.1: USB disconnect, device number 15

WARNING: CPU: 0 PID: 838 at drivers/gpu/drm/nouveau/include/nvkm/subdev/i2c.h:170 nouveau_dp_detect+0x17e/0x370 [nouveau]
CPU: 0 PID: 838 Comm: kworker/0:6 Not tainted 4.17.14-201.Lyude.bz1477182.V3.fc28.x86_64 #1
Hardware name: LENOVO 20EQS64N00/20EQS64N00, BIOS N1EET77W (1.50 ) 03/28/2018
Workqueue: events nouveau_display_hpd_work [nouveau]
RIP: 0010:nouveau_dp_detect+0x17e/0x370 [nouveau]
RSP: 0018:ffffa15143933cf0 EFLAGS: 00010293
RAX: 0000000000000000 RBX: ffff8cb4f656c400 RCX: 0000000000000000
RDX: ffffa1514500e4e4 RSI: ffffa1514500e4e4 RDI: 0000000001009002
RBP: ffff8cb4f4a8a800 R08: ffffa15143933cfd R09: ffffa15143933cfc
R10: 0000000000000000 R11: 0000000000000000 R12: ffff8cb4fb57a000
R13: ffff8cb4fb57a000 R14: ffff8cb4f4a8f800 R15: ffff8cb4f656c418
FS:  0000000000000000(0000) GS:ffff8cb51f400000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f78ec938000 CR3: 000000073720a003 CR4: 00000000003606f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 ? _cond_resched+0x15/0x30
 nouveau_connector_detect+0x2ce/0x520 [nouveau]
 ? _cond_resched+0x15/0x30
 ? ww_mutex_lock+0x12/0x40
 drm_helper_probe_detect_ctx+0x8b/0xe0 [drm_kms_helper]
 drm_helper_hpd_irq_event+0xa8/0x120 [drm_kms_helper]
 nouveau_display_hpd_work+0x2a/0x60 [nouveau]
 process_one_work+0x187/0x340
 worker_thread+0x2e/0x380
 ? pwq_unbound_release_workfn+0xd0/0xd0
 kthread+0x112/0x130
 ? kthread_create_worker_on_cpu+0x70/0x70
 ret_from_fork+0x35/0x40
Code: 4c 8d 44 24 0d b9 00 05 00 00 48 89 ef ba 09 00 00 00 be 01 00 00 00 e8 e1 09 f8 ff 85 c0 0f 85 b2 01 00 00 80 7c 24 0c 03 74 02 <0f> 0b 48 89 ef e8 b8 07 f8 ff f6 05 51 1b c8 ff 02 0f 84 72 ff
---[ end trace 55d811b38fc8e71a ]---

So, to fix this we attempt to grab a runtime PM reference in the ACPI handler itself asynchronously. If the GPU is already awake (it will have normal hotplugging at this point) or runtime PM callbacks are currently disabled on the device, we drop our reference without updating the autosuspend delay. We only schedule connector reprobes when we successfully managed to queue up a resume request with our asynchronous PM ref.

This also has the added benefit of preventing redundant connector reprobes from ACPI while the GPU is runtime resumed!

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1477182#c41

---
 drivers/gpu/drm/nouveau/nouveau_display.c |   26 ++++++++++++++++++++------
 1 file changed, 20 insertions(+), 6 deletions(-)
drivers/gpu/drm/nouveau/nouveau_display.c +20 -6
@@ -378,15 +378,29 @@ nouveau_display_acpi_ntfy(struct notifie
 {
 	struct nouveau_drm *drm = container_of(nb, typeof(*drm), acpi_nb);
 	struct acpi_bus_event *info = data;
+	int ret;
 
 	if (!strcmp(info->device_class, ACPI_VIDEO_CLASS)) {
 		if (info->type == ACPI_VIDEO_NOTIFY_PROBE) {
-			/*
-			 * This may be the only indication we receive of a
-			 * connector hotplug on a runtime suspended GPU,
-			 * schedule hpd_work to check.
-			 */
-			schedule_work(&drm->hpd_work);
+			ret = pm_runtime_get(drm->dev->dev);
+			if (ret == 1 || ret == -EACCES) {
+				/* If the GPU is already awake, or in a state
+				 * where we can't wake it up, it can handle
+				 * it's own hotplug events.
+				 */
+				pm_runtime_put_autosuspend(drm->dev->dev);
+			} else if (ret == 0) {
+				/* This may be the only indication we receive
+				 * of a connector hotplug on a runtime
+				 * suspended GPU, schedule hpd_work to check.
+				 */
+				NV_DEBUG(drm, "ACPI requested connector reprobe\n");
+				schedule_work(&drm->hpd_work);
+				pm_runtime_put_noidle(drm->dev->dev);
+			} else {
+				NV_WARN(drm, "Dropped ACPI reprobe event due to RPM error: %d\n",
+					ret);
+			}
 
 			/* acpi-video should not generate keypresses for this */
 			return NOTIFY_BAD;
author maintainer
#28 lore raw

PATCH 28/64 platform/x86: alienware-wmi: Correct a memory leak

In reply to Greg Kroah-Hartman

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

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

From: Mario Limonciello <[email protected]>

commit ff0e9f26288d2daee4950f42b37a3d3d30d36ec1 upstream.

An ACPI buffer that was allocated was not being freed after use.

---
 drivers/platform/x86/alienware-wmi.c |    1 +
 1 file changed, 1 insertion(+)
drivers/platform/x86/alienware-wmi.c +1 -0
@@ -519,6 +519,7 @@ static acpi_status alienware_wmax_comman
 		if (obj && obj->type == ACPI_TYPE_INTEGER)
 			*out_data = (u32) obj->integer.value;
 	}
+	kfree(output.pointer);
 	return status;
 
 }
author maintainer
#47 lore raw

PATCH 47/64 drm: udl: Destroy framebuffer only if it was initialized

In reply to Greg Kroah-Hartman

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

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

From: Emil Lundmark <[email protected]>

commit fcb74da1eb8edd3a4ef9b9724f88ed709d684227 upstream.

This fixes a NULL pointer dereference that can happen if the UDL driver is unloaded before the framebuffer is initialized. This can happen e.g. if the USB device is unplugged right after it was plugged in.

As explained by Stéphane Marchesin:

It happens when fbdev is disabled (which is the case for Chrome OS). Even though intialization of the fbdev part is optional (it's done in udlfb_create which is the callback for fb_probe()), the teardown isn't optional (udl_driver_unload -> udl_fbdev_cleanup -> udl_fbdev_destroy).

Note that udl_fbdev_cleanup *tries* to be conditional (you can see it does if (!udl->fbdev)) but that doesn't work, because udl->fbdev is always set during udl_fbdev_init.

---
 drivers/gpu/drm/udl/udl_fb.c |    8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)
drivers/gpu/drm/udl/udl_fb.c +5 -3
@@ -432,9 +432,11 @@ static void udl_fbdev_destroy(struct drm
 {
 	drm_fb_helper_unregister_fbi(&ufbdev->helper);
 	drm_fb_helper_fini(&ufbdev->helper);
-	drm_framebuffer_unregister_private(&ufbdev->ufb.base);
-	drm_framebuffer_cleanup(&ufbdev->ufb.base);
-	drm_gem_object_put_unlocked(&ufbdev->ufb.obj->base);
+	if (ufbdev->ufb.obj) {
+		drm_framebuffer_unregister_private(&ufbdev->ufb.base);
+		drm_framebuffer_cleanup(&ufbdev->ufb.base);
+		drm_gem_object_put_unlocked(&ufbdev->ufb.obj->base);
+	}
 }
 
 int udl_fbdev_init(struct drm_device *dev)
author maintainer
#49 lore raw

PATCH 49/64 drm/atomic: Use drm_drv_uses_atomic_modeset() for debugfs creation

In reply to Greg Kroah-Hartman

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

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

From: Lyude Paul <[email protected]>

commit 3c499ea0c662e2f38aafbd4f516b08aab8cfa0e5 upstream.

As pointed out by Daniel Vetter, we should be usinng drm_drv_uses_atomic_modeset() for determining whether or not we want to make the debugfs nodes for atomic instead of checking DRIVER_ATOMIC, as the former isn't an accurate representation of whether or not the driver is actually using atomic modesetting internally (even though it might not be exposing atomic capabilities).

---
 drivers/gpu/drm/drm_atomic.c  |    2 +-
 drivers/gpu/drm/drm_debugfs.c |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)
drivers/gpu/drm/drm_atomic.c +1 -1
@@ -1748,7 +1748,7 @@ static void __drm_state_dump(struct drm_
 	struct drm_connector *connector;
 	struct drm_connector_list_iter conn_iter;
 
-	if (!drm_core_check_feature(dev, DRIVER_ATOMIC))
+	if (!drm_drv_uses_atomic_modeset(dev))
 		return;
 
 	list_for_each_entry(plane, &config->plane_list, head) {
drivers/gpu/drm/drm_debugfs.c +1 -1
@@ -150,7 +150,7 @@ int drm_debugfs_init(struct drm_minor *m
 		return ret;
 	}
 
-	if (drm_core_check_feature(dev, DRIVER_ATOMIC)) {
+	if (drm_drv_uses_atomic_modeset(dev)) {
 		ret = drm_atomic_debugfs_init(minor);
 		if (ret) {
 			DRM_ERROR("Failed to create atomic debugfs files\n");
author maintainer
#30 lore raw

PATCH 30/64 xen/x86/vpmu: Zero struct pt_regs before calling into sample handling code

In reply to Greg Kroah-Hartman

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

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

From: Boris Ostrovsky <[email protected]>

commit 70513d58751d7c6c1a0133557b13089b9f2e3e66 upstream.

Otherwise we may leak kernel stack for events that sample user registers.

---
 arch/x86/xen/pmu.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
arch/x86/xen/pmu.c +1 -1
@@ -478,7 +478,7 @@ static void xen_convert_regs(const struc
 irqreturn_t xen_pmu_irq_handler(int irq, void *dev_id)
 {
 	int err, ret = IRQ_NONE;
-	struct pt_regs regs;
+	struct pt_regs regs = {0};
 	const struct xen_pmu_data *xenpmu_data = get_xenpmu_data();
 	uint8_t xenpmu_flags = get_xenpmu_flags();
 
author maintainer
#32 lore raw

PATCH 32/64 Revert "PCI: Add ACS quirk for Intel 300 series"

In reply to Greg Kroah-Hartman

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

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

From: Mika Westerberg <[email protected]>

commit 50ca031b51106b1b46162d4e9ecccb7edc95682f upstream.

This reverts f154a718e6cc ("PCI: Add ACS quirk for Intel 300 series").

It turns out that erratum "PCH PCIe* Controller Root Port (ACSCTLR) Appear As Read Only" has been fixed in 300 series chipsets, even though the datasheet [1] claims otherwise. To make ACS work properly on 300 series root ports, revert the faulty commit.

[1] https://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/300-series-c240-series-chipset-pch-spec-update.pdf

Fixes f154a718e6cc ("PCI: Add ACS quirk for Intel 300 series")
Cc [email protected] # v4.18+
---
 drivers/pci/quirks.c |    6 ------
 1 file changed, 6 deletions(-)
drivers/pci/quirks.c +0 -6
@@ -4388,11 +4388,6 @@ static int pci_quirk_qcom_rp_acs(struct
  *
  * 0x9d10-0x9d1b PCI Express Root port #{1-12}
  *
- * The 300 series chipset suffers from the same bug so include those root
- * ports here as well.
- *
- * 0xa32c-0xa343 PCI Express Root port #{0-24}
- *
  * [1] http://www.intel.com/content/www/us/en/chipsets/100-series-chipset-datasheet-vol-2.html
  * [2] http://www.intel.com/content/www/us/en/chipsets/100-series-chipset-datasheet-vol-1.html
  * [3] http://www.intel.com/content/www/us/en/chipsets/100-series-chipset-spec-update.html
@@ -4410,7 +4405,6 @@ static bool pci_quirk_intel_spt_pch_acs_
 	case 0xa110 ... 0xa11f: case 0xa167 ... 0xa16a: /* Sunrise Point */
 	case 0xa290 ... 0xa29f: case 0xa2e7 ... 0xa2ee: /* Union Point */
 	case 0x9d10 ... 0x9d1b: /* 7th & 8th Gen Mobile */
-	case 0xa32c ... 0xa343:				/* 300 series */
 		return true;
 	}
 
author maintainer
#33 lore raw

PATCH 33/64 ring-buffer: Allow for rescheduling when removing pages

In reply to Greg Kroah-Hartman

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

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

From: Vaibhav Nagarnaik <[email protected]>

commit 83f365554e47997ec68dc4eca3f5dce525cd15c3 upstream.

When reducing ring buffer size, pages are removed by scheduling a work item on each CPU for the corresponding CPU ring buffer. After the pages are removed from ring buffer linked list, the pages are free()d in a tight loop. The loop does not give up CPU until all pages are removed. In a worst case behavior, when lot of pages are to be freed, it can cause system stall.

After the pages are removed from the list, the free() can happen while the work is rescheduled. Call cond_resched() in the loop to prevent the system hangup.

Fixes 83f40318dab00 ("ring-buffer: Make removal of ring buffer pages atomic")
---
 kernel/trace/ring_buffer.c |    2 ++
 1 file changed, 2 insertions(+)
kernel/trace/ring_buffer.c +2 -0
@@ -1479,6 +1479,8 @@ rb_remove_pages(struct ring_buffer_per_c
 	tmp_iter_page = first_page;
 
 	do {
+		cond_resched();
+
 		to_remove_page = tmp_iter_page;
 		rb_inc_page(cpu_buffer, &tmp_iter_page);
 
author maintainer
#35 lore raw

PATCH 35/64 Revert "rpmsg: core: add support to power domains for devices"

In reply to Greg Kroah-Hartman

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

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

From: Greg Kroah-Hartman <[email protected]>

This reverts commit 1ed3a93072307265d6385031b72929a904b50f87 which is commit fe782affd0f440a4e60e2cc81b8f2eccb2923113 upstream

Rafael reports that this patch causes problems:
> -rc2 looks good. There is a problem on dragonboard during boot that was > introduced in v4.14.71 that I didn't notice last week. We'll bisect it > and report back later this week. dragonboard on the other branches (4.9, > 4.18, mainline) looks fine.

As Dan pointed out, during validation, we have bisected this issue on a dragonboard 410c (can't find root device) to the following commit for v4.14:

[1ed3a9307230] rpmsg: core: add support to power domains for devices

There is an on-going discussion on "[PATCH] rpmsg: core: add support to power domains for devices" about this patch having other dependencies and breaking something else on v4.14 as well.

so drop it.

Cc Srinivas Kandagatla <[email protected]>
Cc Bjorn Andersson <[email protected]>
Cc Sasha Levin <[email protected]>
---
 drivers/rpmsg/rpmsg_core.c |    7 -------
 1 file changed, 7 deletions(-)
drivers/rpmsg/rpmsg_core.c +0 -7
@@ -23,7 +23,6 @@
 #include <linux/module.h>
 #include <linux/rpmsg.h>
 #include <linux/of_device.h>
-#include <linux/pm_domain.h>
 #include <linux/slab.h>
 
 #include "rpmsg_internal.h"
@@ -419,10 +418,6 @@ static int rpmsg_dev_probe(struct device
 	struct rpmsg_endpoint *ept = NULL;
 	int err;
 
-	err = dev_pm_domain_attach(dev, true);
-	if (err)
-		goto out;
-
 	if (rpdrv->callback) {
 		strncpy(chinfo.name, rpdev->id.name, RPMSG_NAME_SIZE);
 		chinfo.src = rpdev->src;
@@ -464,8 +459,6 @@ static int rpmsg_dev_remove(struct devic
 
 	rpdrv->remove(rpdev);
 
-	dev_pm_domain_detach(dev, true);
-
 	if (rpdev->ept)
 		rpmsg_destroy_ept(rpdev->ept);
 
author maintainer
#54 lore raw

PATCH 52/64 ext4: avoid divide by zero fault when deleting corrupted inline directories

In reply to Greg Kroah-Hartman

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

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

From: Theodore Ts'o <[email protected]>

commit 4d982e25d0bdc83d8c64e66fdeca0b89240b3b85 upstream.

A specially crafted file system can trick empty_inline_dir() into reading past the last valid entry in a inline directory, and then run into the end of xattr marker. This will trigger a divide by zero fault. Fix this by using the size of the inline directory instead of dir->i_size.

Also clean up error reporting in __ext4_check_dir_entry so that the message is clearer and more understandable --- and avoids the division by zero trap if the size passed in is zero. (I'm not sure why we coded it that way in the first place; printing offset % size is actually more confusing and less useful.)

https://bugzilla.kernel.org/show_bug.cgi?id=200933

---
 fs/ext4/dir.c    |   20 +++++++++-----------
 fs/ext4/inline.c |    4 +++-
 2 files changed, 12 insertions(+), 12 deletions(-)
fs/ext4/dir.c +9 -11
@@ -75,7 +75,7 @@ int __ext4_check_dir_entry(const char *f
 	else if (unlikely(rlen < EXT4_DIR_REC_LEN(de->name_len)))
 		error_msg = "rec_len is too small for name_len";
 	else if (unlikely(((char *) de - buf) + rlen > size))
-		error_msg = "directory entry across range";
+		error_msg = "directory entry overrun";
 	else if (unlikely(le32_to_cpu(de->inode) >
 			le32_to_cpu(EXT4_SB(dir->i_sb)->s_es->s_inodes_count)))
 		error_msg = "inode out of bounds";
@@ -84,18 +84,16 @@ int __ext4_check_dir_entry(const char *f
 
 	if (filp)
 		ext4_error_file(filp, function, line, bh->b_blocknr,
-				"bad entry in directory: %s - offset=%u(%u), "
-				"inode=%u, rec_len=%d, name_len=%d",
-				error_msg, (unsigned) (offset % size),
-				offset, le32_to_cpu(de->inode),
-				rlen, de->name_len);
+				"bad entry in directory: %s - offset=%u, "
+				"inode=%u, rec_len=%d, name_len=%d, size=%d",
+				error_msg, offset, le32_to_cpu(de->inode),
+				rlen, de->name_len, size);
 	else
 		ext4_error_inode(dir, function, line, bh->b_blocknr,
-				"bad entry in directory: %s - offset=%u(%u), "
-				"inode=%u, rec_len=%d, name_len=%d",
-				error_msg, (unsigned) (offset % size),
-				offset, le32_to_cpu(de->inode),
-				rlen, de->name_len);
+				"bad entry in directory: %s - offset=%u, "
+				"inode=%u, rec_len=%d, name_len=%d, size=%d",
+				 error_msg, offset, le32_to_cpu(de->inode),
+				 rlen, de->name_len, size);
 
 	return 1;
 }
fs/ext4/inline.c +3 -1
@@ -1759,6 +1759,7 @@ bool empty_inline_dir(struct inode *dir,
 {
 	int err, inline_size;
 	struct ext4_iloc iloc;
+	size_t inline_len;
 	void *inline_pos;
 	unsigned int offset;
 	struct ext4_dir_entry_2 *de;
@@ -1786,8 +1787,9 @@ bool empty_inline_dir(struct inode *dir,
 		goto out;
 	}
 
+	inline_len = ext4_get_inline_size(dir);
 	offset = EXT4_INLINE_DOTDOT_SIZE;
-	while (offset < dir->i_size) {
+	while (offset < inline_len) {
 		de = ext4_get_inline_entry(dir, &iloc, offset,
 					   &inline_pos, &inline_size);
 		if (ext4_check_dir_entry(dir, NULL, de,
author maintainer
#63 lore raw

PATCH 61/64 vmw_balloon: include asm/io.h

In reply to Greg Kroah-Hartman

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

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

From: Nadav Amit <[email protected]>

commit a3b92ee6fc171d7c9d9b6b829b7fef169210440c upstream.

Fix a build error due to missing virt_to_phys()

Fixes f0a1bf29d821b ("vmw_balloon: fix inflation with batching")
Cc Xavier Deguillard <[email protected]>
---
 drivers/misc/vmw_balloon.c |    1 +
 1 file changed, 1 insertion(+)
drivers/misc/vmw_balloon.c +1 -0
@@ -45,6 +45,7 @@
 #include <linux/seq_file.h>
 #include <linux/vmw_vmci_defs.h>
 #include <linux/vmw_vmci_api.h>
+#include <linux/io.h>
 #include <asm/hypervisor.h>
 
 MODULE_AUTHOR("VMware, Inc.");
author maintainer
#64 lore raw

PATCH 62/64 iw_cxgb4: only allow 1 flush on user qps

In reply to Greg Kroah-Hartman

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

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

From: Steve Wise <[email protected]>

commit 308aa2b8f7b7db3332a7d41099fd37851fb793b2 upstream.

Once the qp has been flushed, it cannot be flushed again. The user qp flush logic wasn't enforcing it however. The bug can cause touch-after-free crashes like:

Unable to handle kernel paging request for data at address 0x000001ec
Faulting instruction address: 0xc008000016069100
Oops: Kernel access of bad area, sig: 11 [#1]
...
NIP [c008000016069100] flush_qp+0x80/0x480 [iw_cxgb4]
LR [c00800001606cd6c] c4iw_modify_qp+0x71c/0x11d0 [iw_cxgb4]
Call Trace:
[c00800001606cd6c] c4iw_modify_qp+0x71c/0x11d0 [iw_cxgb4]
[c00800001606e868] c4iw_ib_modify_qp+0x118/0x200 [iw_cxgb4]
[c0080000119eae80] ib_security_modify_qp+0xd0/0x3d0 [ib_core]
[c0080000119c4e24] ib_modify_qp+0xc4/0x2c0 [ib_core]
[c008000011df0284] iwcm_modify_qp_err+0x44/0x70 [iw_cm]
[c008000011df0fec] destroy_cm_id+0xcc/0x370 [iw_cm]
[c008000011ed4358] rdma_destroy_id+0x3c8/0x520 [rdma_cm]
[c0080000134b0540] ucma_close+0x90/0x1b0 [rdma_ucm]
[c000000000444da4] __fput+0xe4/0x2f0

So fix flush_qp() to only flush the wq once.

---
 drivers/infiniband/hw/cxgb4/qp.c |    6 ++++++
 1 file changed, 6 insertions(+)
drivers/infiniband/hw/cxgb4/qp.c +6 -0
@@ -1395,6 +1395,12 @@ static void flush_qp(struct c4iw_qp *qhp
 	schp = to_c4iw_cq(qhp->ibqp.send_cq);
 
 	if (qhp->ibqp.uobject) {
+
+		/* for user qps, qhp->wq.flushed is protected by qhp->mutex */
+		if (qhp->wq.flushed)
+			return;
+
+		qhp->wq.flushed = 1;
 		t4_set_wq_in_error(&qhp->wq);
 		t4_set_cq_in_error(&rchp->cq);
 		spin_lock_irqsave(&rchp->comp_handler_lock, flag);
author maintainer
#66 lore raw

PATCH 64/64 crypto: x86/aegis,morus - Do not require OSXSAVE for SSE2

In reply to Greg Kroah-Hartman

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

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

From: Ondrej Mosnacek <[email protected]>

commit 24568b47d48ec8c906fd0f589489a08b17e1edca upstream.

It turns out OSXSAVE needs to be checked only for AVX, not for SSE. Without this patch the affected modules refuse to load on CPUs with SSE2 but without AVX support.

Fixes 877ccce7cbe8 ("crypto: x86/aegis,morus - Fix and simplify CPUID checks")
Cc <[email protected]> # 4.18
arch/x86/crypto/aegis128-aesni-glue.c +0 -1
index acd11b3bf639..2a356b948720 100644
@@ -379,7 +379,6 @@ static int __init crypto_aegis128_aesni_module_init(void)
 {
 	if (!boot_cpu_has(X86_FEATURE_XMM2) ||
 	    !boot_cpu_has(X86_FEATURE_AES) ||
-	    !boot_cpu_has(X86_FEATURE_OSXSAVE) ||
 	    !cpu_has_xfeatures(XFEATURE_MASK_SSE, NULL))
 		return -ENODEV;
 
arch/x86/crypto/aegis128l-aesni-glue.c +0 -1
index 2071c3d1ae07..dbe8bb980da1 100644
@@ -379,7 +379,6 @@ static int __init crypto_aegis128l_aesni_module_init(void)
 {
 	if (!boot_cpu_has(X86_FEATURE_XMM2) ||
 	    !boot_cpu_has(X86_FEATURE_AES) ||
-	    !boot_cpu_has(X86_FEATURE_OSXSAVE) ||
 	    !cpu_has_xfeatures(XFEATURE_MASK_SSE, NULL))
 		return -ENODEV;
 
arch/x86/crypto/aegis256-aesni-glue.c +0 -1
index b5f2a8fd5a71..8bebda2de92f 100644
@@ -379,7 +379,6 @@ static int __init crypto_aegis256_aesni_module_init(void)
 {
 	if (!boot_cpu_has(X86_FEATURE_XMM2) ||
 	    !boot_cpu_has(X86_FEATURE_AES) ||
-	    !boot_cpu_has(X86_FEATURE_OSXSAVE) ||
 	    !cpu_has_xfeatures(XFEATURE_MASK_SSE, NULL))
 		return -ENODEV;
 
arch/x86/crypto/morus1280-sse2-glue.c +0 -1
index 95cf857d2cbb..f40244eaf14d 100644
@@ -40,7 +40,6 @@ MORUS1280_DECLARE_ALGS(sse2, "morus1280-sse2", 350);
 static int __init crypto_morus1280_sse2_module_init(void)
 {
 	if (!boot_cpu_has(X86_FEATURE_XMM2) ||
-	    !boot_cpu_has(X86_FEATURE_OSXSAVE) ||
 	    !cpu_has_xfeatures(XFEATURE_MASK_SSE, NULL))
 		return -ENODEV;
 
arch/x86/crypto/morus640-sse2-glue.c +0 -1
index 615fb7bc9a32..9afaf8f8565a 100644
@@ -40,7 +40,6 @@ MORUS640_DECLARE_ALGS(sse2, "morus640-sse2", 400);
 static int __init crypto_morus640_sse2_module_init(void)
 {
 	if (!boot_cpu_has(X86_FEATURE_XMM2) ||
-	    !boot_cpu_has(X86_FEATURE_OSXSAVE) ||
 	    !cpu_has_xfeatures(XFEATURE_MASK_SSE, NULL))
 		return -ENODEV;
 
author maintainer
#55 lore raw

PATCH 53/64 ext4: avoid arithemetic overflow that can trigger a BUG

In reply to Greg Kroah-Hartman

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

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

From: Theodore Ts'o <[email protected]>

commit bcd8e91f98c156f4b1ebcfacae675f9cfd962441 upstream.

A maliciously crafted file system can cause an overflow when the results of a 64-bit calculation is stored into a 32-bit length parameter.

https://bugzilla.kernel.org/show_bug.cgi?id=200623

---
 fs/ext4/ext4.h  |    3 +++
 fs/ext4/inode.c |    9 +++++++--
 2 files changed, 10 insertions(+), 2 deletions(-)
fs/ext4/ext4.h +3 -0
@@ -714,6 +714,9 @@ struct fsxattr {
 /* Max physical block we can address w/o extents */
 #define EXT4_MAX_BLOCK_FILE_PHYS	0xFFFFFFFF
 
+/* Max logical block we can support */
+#define EXT4_MAX_LOGICAL_BLOCK		0xFFFFFFFF
+
 /*
  * Structure of an inode on the disk
  */
fs/ext4/inode.c +7 -2
@@ -3407,11 +3407,16 @@ static int ext4_iomap_begin(struct inode
 {
 	struct ext4_sb_info *sbi = EXT4_SB(inode->i_sb);
 	unsigned int blkbits = inode->i_blkbits;
-	unsigned long first_block = offset >> blkbits;
-	unsigned long last_block = (offset + length - 1) >> blkbits;
+	unsigned long first_block, last_block;
 	struct ext4_map_blocks map;
 	int ret;
 
+	if ((offset >> blkbits) > EXT4_MAX_LOGICAL_BLOCK)
+		return -EINVAL;
+	first_block = offset >> blkbits;
+	last_block = min_t(loff_t, (offset + length - 1) >> blkbits,
+			   EXT4_MAX_LOGICAL_BLOCK);
+
 	if (WARN_ON_ONCE(ext4_has_inline_data(inode)))
 		return -ERANGE;
 
author maintainer
#56 lore raw

PATCH 54/64 ext4: recalucate superblock checksum after updating free blocks/inodes

In reply to Greg Kroah-Hartman

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

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

From: Theodore Ts'o <[email protected]>

commit 4274f516d4bc50648a4d97e4f67ecbd7b65cde4a upstream.

When mounting the superblock, ext4_fill_super() calculates the free blocks and free inodes and stores them in the superblock. It's not strictly necessary, since we don't use them any more, but it's nice to keep them roughly aligned to reality.

Since it's not critical for file system correctness, the code doesn't call ext4_commit_super(). The problem is that it's in ext4_commit_super() that we recalculate the superblock checksum. So if we're not going to call ext4_commit_super(), we need to call ext4_superblock_csum_set() to make sure the superblock checksum is consistent.

Most of the time, this doesn't matter, since we end up calling ext4_commit_super() very soon thereafter, and definitely by the time the file system is unmounted. However, it doesn't work in this sequence:

mke2fs -Fq -t ext4 /dev/vdc 128M
mount /dev/vdc /vdc
cp xfstests/git-versions /vdc
godown /vdc
umount /vdc
mount /dev/vdc
tune2fs -l /dev/vdc

With this commit, the "tune2fs -l" no longer fails.

---
 fs/ext4/super.c |    2 ++
 1 file changed, 2 insertions(+)
fs/ext4/super.c +2 -0
@@ -4311,11 +4311,13 @@ no_journal:
 	block = ext4_count_free_clusters(sb);
 	ext4_free_blocks_count_set(sbi->s_es, 
 				   EXT4_C2B(sbi, block));
+	ext4_superblock_csum_set(sb);
 	err = percpu_counter_init(&sbi->s_freeclusters_counter, block,
 				  GFP_KERNEL);
 	if (!err) {
 		unsigned long freei = ext4_count_free_inodes(sb);
 		sbi->s_es->s_free_inodes_count = cpu_to_le32(freei);
+		ext4_superblock_csum_set(sb);
 		err = percpu_counter_init(&sbi->s_freeinodes_counter, freei,
 					  GFP_KERNEL);
 	}
author maintainer
#57 lore raw

PATCH 55/64 ext4: fix online resizes handling of a too-small final block group

In reply to Greg Kroah-Hartman

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

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

From: Theodore Ts'o <[email protected]>

commit f0a459dec5495a3580f8d784555e6f8f3bf7f263 upstream.

Avoid growing the file system to an extent so that the last block group is too small to hold all of the metadata that must be stored in the block group.

This problem can be triggered with the following reproducer:

umount /mnt

mke2fs -F -m0 -b 4096 -t ext4 -O resize_inode,^has_journal \
	-E resize=1073741824 /tmp/foo.img 128M

mount /tmp/foo.img /mnt
truncate --size 1708M /tmp/foo.img
resize2fs /dev/loop0 295400
umount /mnt
e2fsck -fy /tmp/foo.img

---
 fs/ext4/resize.c |   20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)
fs/ext4/resize.c +20 -0
@@ -1956,6 +1956,26 @@ retry:
 		}
 	}
 
+	/*
+	 * Make sure the last group has enough space so that it's
+	 * guaranteed to have enough space for all metadata blocks
+	 * that it might need to hold.  (We might not need to store
+	 * the inode table blocks in the last block group, but there
+	 * will be cases where this might be needed.)
+	 */
+	if ((ext4_group_first_block_no(sb, n_group) +
+	     ext4_group_overhead_blocks(sb, n_group) + 2 +
+	     sbi->s_itb_per_group + sbi->s_cluster_ratio) >= n_blocks_count) {
+		n_blocks_count = ext4_group_first_block_no(sb, n_group);
+		n_group--;
+		n_blocks_count_retry = 0;
+		if (resize_inode) {
+			iput(resize_inode);
+			resize_inode = NULL;
+		}
+		goto retry;
+	}
+
 	/* extend the last group */
 	if (n_group == o_group)
 		add = n_blocks_count - o_blocks_count;
author maintainer
#58 lore raw

PATCH 56/64 ext4: fix online resizing for bigalloc file systems with a 1k block size

In reply to Greg Kroah-Hartman

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

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

From: Theodore Ts'o <[email protected]>

commit 5f8c10936fab2b69a487400f2872902e597dd320 upstream.

An online resize of a file system with the bigalloc feature enabled and a 1k block size would be refused since ext4_resize_begin() did not understand s_first_data_block is 0 for all bigalloc file systems, even when the block size is 1k.

---
 fs/ext4/resize.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
fs/ext4/resize.c +2 -1
@@ -19,6 +19,7 @@
 
 int ext4_resize_begin(struct super_block *sb)
 {
+	struct ext4_sb_info *sbi = EXT4_SB(sb);
 	int ret = 0;
 
 	if (!capable(CAP_SYS_RESOURCE))
@@ -29,7 +30,7 @@ int ext4_resize_begin(struct super_block
          * because the user tools have no way of handling this.  Probably a
          * bad time to do it anyways.
          */
-	if (EXT4_SB(sb)->s_sbh->b_blocknr !=
+	if (EXT4_B2C(sbi, sbi->s_sbh->b_blocknr) !=
 	    le32_to_cpu(EXT4_SB(sb)->s_es->s_first_data_block)) {
 		ext4_warning(sb, "won't resize using backup superblock at %llu",
 			(unsigned long long)EXT4_SB(sb)->s_sbh->b_blocknr);
author maintainer
#59 lore raw

PATCH 57/64 ext4: dont mark mmp buffer head dirty

In reply to Greg Kroah-Hartman

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

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

From: Li Dongyang <[email protected]>

commit fe18d649891d813964d3aaeebad873f281627fbc upstream.

Marking mmp bh dirty before writing it will make writeback pick up mmp block later and submit a write, we don't want the duplicate write as kmmpd thread should have full control of reading and writing the mmp block.
Another reason is we will also have random I/O error on the writeback request when blk integrity is enabled, because kmmpd could modify the content of the mmp block(e.g. setting new seq and time) while the mmp block is under I/O requested by writeback.

---
 fs/ext4/mmp.c |    1 -
 1 file changed, 1 deletion(-)
fs/ext4/mmp.c +0 -1
@@ -49,7 +49,6 @@ static int write_mmp_block(struct super_
 	 */
 	sb_start_write(sb);
 	ext4_mmp_csum_set(sb, mmp);
-	mark_buffer_dirty(bh);
 	lock_buffer(bh);
 	bh->b_end_io = end_buffer_write_sync;
 	get_bh(bh);
author maintainer
#61 lore raw

PATCH 59/64 sched/fair: Fix vruntime_normalized() for remote non-migration wakeup

In reply to Greg Kroah-Hartman

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

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

From: Steve Muckle <[email protected]>

commit d0cdb3ce8834332d918fc9c8ff74f8a169ec9abe upstream.

When a task which previously ran on a given CPU is remotely queued to wake up on that same CPU, there is a period where the task's state is TASK_WAKING and its vruntime is not normalized. This is not accounted for in vruntime_normalized() which will cause an error in the task's vruntime if it is switched from the fair class during this time.

For example if it is boosted to RT priority via rt_mutex_setprio(), rq->min_vruntime will not be subtracted from the task's vruntime but it will be added again when the task returns to the fair class. The task's vruntime will have been erroneously doubled and the effective priority of the task will be reduced.

Note this will also lead to inflation of all vruntimes since the doubled vruntime value will become the rq's min_vruntime when other tasks leave the rq. This leads to repeated doubling of the vruntime and priority penalty.

Fix this by recognizing a WAKING task's vruntime as normalized only if sched_remote_wakeup is true. This indicates a migration, in which case the vruntime would have been normalized in migrate_task_rq_fair().

Based on a similar patch from John Dias <[email protected]>.

Cc Chris Redpath <[email protected]>
Cc John Dias <[email protected]>
Cc Linus Torvalds <[email protected]>
Cc Miguel de Dios <[email protected]>
Cc Morten Rasmussen <[email protected]>
Cc Patrick Bellasi <[email protected]>
Cc Paul Turner <[email protected]>
Cc Quentin Perret <[email protected]>
Cc Thomas Gleixner <[email protected]>
Cc Todd Kjos <[email protected]>
Fixes b5179ac70de8 ("sched/fair: Prepare to fix fairness problems on migration")
---
 kernel/sched/fair.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
kernel/sched/fair.c +2 -1
@@ -9137,7 +9137,8 @@ static inline bool vruntime_normalized(s
 	 * - A task which has been woken up by try_to_wake_up() and
 	 *   waiting for actually being woken up by sched_ttwu_pending().
 	 */
-	if (!se->sum_exec_runtime || p->state == TASK_WAKING)
+	if (!se->sum_exec_runtime ||
+	    (p->state == TASK_WAKING && p->sched_remote_wakeup))
 		return true;
 
 	return false;
author maintainer
#53 lore raw

PATCH 51/64 ext4: check to make sure the rename(2)s destination is not freed

In reply to Greg Kroah-Hartman

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

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

From: Theodore Ts'o <[email protected]>

commit b50282f3241acee880514212d88b6049fb5039c8 upstream.

If the destination of the rename(2) system call exists, the inode's link count (i_nlinks) must be non-zero. If it is, the inode can end up on the orphan list prematurely, leading to all sorts of hilarity, including a use-after-free.

https://bugzilla.kernel.org/show_bug.cgi?id=200931

---
 fs/ext4/namei.c |    6 ++++++
 1 file changed, 6 insertions(+)
fs/ext4/namei.c +6 -0
@@ -3514,6 +3514,12 @@ static int ext4_rename(struct inode *old
 	int credits;
 	u8 old_file_type;
 
+	if (new.inode && new.inode->i_nlink == 0) {
+		EXT4_ERROR_INODE(new.inode,
+				 "target of rename is already freed");
+		return -EFSCORRUPTED;
+	}
+
 	if ((ext4_test_inode_flag(new_dir, EXT4_INODE_PROJINHERIT)) &&
 	    (!projid_eq(EXT4_I(new_dir)->i_projid,
 			EXT4_I(old_dentry->d_inode)->i_projid)))
#67 lore raw

Re: [PATCH 4.14 64/64] crypto: x86/aegis,morus - Do not require OSXSAVE for SSE2

In reply to Greg Kroah-Hartman

Hi Greg,

Quoted 12 lines · Greg Kroah-Hartman

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

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

From: Ondrej Mosnacek <[email protected]>

commit 24568b47d48ec8c906fd0f589489a08b17e1edca upstream.

It turns out OSXSAVE needs to be checked only for AVX, not for SSE. Without this patch the affected modules refuse to load on CPUs with SSE2 but without AVX support.

Quoted 6 lines
Fixes 877ccce7cbe8 ("crypto: x86/aegis,morus - Fix and simplify CPUID checks")
Cc <[email protected]> # 4.18

I am confused with this one. I am not seeing this in the "git log" from your 4.14.73-rc1.
I also tried to apply this from your queue to v4.14.72 and it did not apply as it could not
find some files.

error: arch/x86/crypto/aegis128-aesni-glue.c: No such file or directory
error: arch/x86/crypto/aegis128l-aesni-glue.c: No such file or directory
error: arch/x86/crypto/aegis256-aesni-glue.c: No such file or directory
error: arch/x86/crypto/morus1280-sse2-glue.c: No such file or directory
error: arch/x86/crypto/morus640-sse2-glue.c: No such file or directory

Am I missing something?

--
Regards
Sudip

author maintainer
#68 lore raw

Re: [PATCH 4.14 64/64] crypto: x86/aegis,morus - Do not require OSXSAVE for SSE2

Quoted 29 lines · Sudip Mukherjee

Hi Greg,

Quoted 12 lines · Greg Kroah-Hartman

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

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

From: Ondrej Mosnacek <[email protected]>

commit 24568b47d48ec8c906fd0f589489a08b17e1edca upstream.

It turns out OSXSAVE needs to be checked only for AVX, not for SSE. Without this patch the affected modules refuse to load on CPUs with SSE2 but without AVX support.

Quoted 6 lines
Fixes 877ccce7cbe8 ("crypto: x86/aegis,morus - Fix and simplify CPUID checks")
Cc <[email protected]> # 4.18

I am confused with this one. I am not seeing this in the "git log" from your 4.14.73-rc1.
I also tried to apply this from your queue to v4.14.72 and it did not apply as it could not
find some files.

Quoted 7 lines

error: arch/x86/crypto/aegis128-aesni-glue.c: No such file or directory
error: arch/x86/crypto/aegis128l-aesni-glue.c: No such file or directory
error: arch/x86/crypto/aegis256-aesni-glue.c: No such file or directory
error: arch/x86/crypto/morus1280-sse2-glue.c: No such file or directory
error: arch/x86/crypto/morus640-sse2-glue.c: No such file or directory

Am I missing something?

Nope, my fault, it was at the end of my quilt queue and should have been deleted. My scripts didn't catch the error, which is odd.

Now dropped, thanks.

greg k-h

maintainer
#50 lore raw

Re: [PATCH 4.14 49/64] drm/atomic: Use drm_drv_uses_atomic_modeset() for debugfs creation

In reply to Greg Kroah-Hartman

Hi Greg, Lyude,

Quoted 43 lines · Greg Kroah-Hartman

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

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

From: Lyude Paul <[email protected]>

commit 3c499ea0c662e2f38aafbd4f516b08aab8cfa0e5 upstream.

As pointed out by Daniel Vetter, we should be usinng drm_drv_uses_atomic_modeset() for determining whether or not we want to make the debugfs nodes for atomic instead of checking DRIVER_ATOMIC, as the former isn't an accurate representation of whether or not the driver is actually using atomic modesetting internally (even though it might not be exposing atomic capabilities).

---
 drivers/gpu/drm/drm_atomic.c  |    2 +-
 drivers/gpu/drm/drm_debugfs.c |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)
drivers/gpu/drm/drm_atomic.c +1 -1
@@ -1748,7 +1748,7 @@ static void __drm_state_dump(struct drm_
 	struct drm_connector *connector;
 	struct drm_connector_list_iter conn_iter;
 
-	if (!drm_core_check_feature(dev, DRIVER_ATOMIC))
+	if (!drm_drv_uses_atomic_modeset(dev))
 		return;
 
 	list_for_each_entry(plane, &config->plane_list, head) {

drivers/gpu/drm/drm_debugfs.c int drm_debugfs_init(struct drm_minor *m · line 156

Quoted 8 lines
drivers/gpu/drm/drm_debugfs.c +1 -1
@@ -150,7 +150,7 @@ int drm_debugfs_init(struct drm_minor *m
 		return ret;
 	}
 
-	if (drm_core_check_feature(dev, DRIVER_ATOMIC)) {
+	if (drm_drv_uses_atomic_modeset(dev)) {
 		ret = drm_atomic_debugfs_init(minor);
 		if (ret) {
 			DRM_ERROR("Failed to create atomic debugfs files\n");

This is causing a boot regression on some Tegra devices. For completeness I have included the stack trace below.

Jon

[    4.115829] Unable to handle kernel NULL pointer dereference at virtual address 00000010
[    4.123912] pgd = c0204000
[    4.126661] [00000010] *pgd=00000000
[    4.130245] Internal error: Oops: 5 [#1] SMP ARM
[    4.134857] Modules linked in:
[    4.137917] CPU: 0 PID: 28 Comm: kworker/0:1 Not tainted 4.14.73-rc1-g1e2fd38 #1
[    4.145301] Hardware name: NVIDIA Tegra SoC (Flattened Device Tree)
[    4.151569] Workqueue: events deferred_probe_work_func
[    4.156704] task: ee0fae00 task.stack: ee1de000
[    4.161235] PC is at drm_debugfs_init+0x88/0x178
[    4.165850] LR is at drm_debugfs_create_files+0xf0/0x148
[    4.171152] pc : [<c0831ccc>]    lr : [<c0831984>]    psr: 60000113
[    4.177410] sp : ee1dfcd0  ip : 00000000  fp : ee1de000
[    4.182625] r10: 00000017  r9 : 00000000  r8 : c163a884
[    4.187841] r7 : 00000080  r6 : 00000000  r5 : ed12b000  r4 : ed15fe00
[    4.194357] r3 : 00000000  r2 : 00000000  r1 : c0831984  r0 : 00000000
[    4.200884] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
[    4.208013] Control: 10c5387d  Table: 8020406a  DAC: 00000051
[    4.213753] Process kworker/0:1 (pid: 28, stack limit = 0xee1de220)
[    4.220011] Stack: (0xee1dfcd0 to 0xee1e0000)
[    4.224365] fcc0:                                     00383231 ffffffff 014080c0 c0815a14
[    4.232534] fce0: ffffffff 00000000 ffffffff ee452858 00000004 c04591c4 ee452848 00000000
[    4.240702] fd00: 00000004 ed15ffc0 c117438c ee655810 c163a778 ed15fe00 c16d7ef4 00000000
[    4.248869] fd20: c163a778 c0813ca4 ee0fae00 ed12b000 00000000 00000000 c163a778 c0814268
[    4.257036] fd40: c1685a8c ee655810 c163a778 ed12b000 00000000 ed12b000 ee655800 c16d8088
[    4.265205] fd60: 00000000 c163a884 00000000 c08643b8 c0864388 ee655810 c16d8084 c07ef578
[    4.273372] fd80: c07ef558 c08a2cc4 00000000 ee1dfdc0 c08a2e7c 00000001 c16d8060 00000000
[    4.281539] fda0: 00000000 c08a11f8 ee64616c ee64b338 ee655810 ee655810 ee655844 c08a29c4
[    4.289707] fdc0: ee655810 00000001 00000000 ee655818 ee655810 c1638c80 ee228010 c08a1fa8
[    4.297875] fde0: ee655818 ee655810 00000000 c08a04c8 c0877720 ee407010 00000000 ee213600
[    4.306044] fe00: ee655800 ee407010 ee6484c0 ee655810 ee6559b0 ee663810 00000017 c07efb30
[    4.314211] fe20: c1638c64 c1638cfc ee655804 ee663c28 ee407010 c07f0058 c0f6044c ee407010
[    4.322378] fe40: ee228610 00000000 ee228600 00000000 00000000 c088177c 00000000 ee211ac0
[    4.330545] fe60: ee407010 ee228610 ee228610 fffffdfb c163a9e8 00000000 c163a9e8 c08a4914
[    4.338713] fe80: c08a48c8 ee228610 c16d8084 c16d8088 00000000 c08a2cc4 00000000 ee1dfed0
[    4.346881] fea0: c08a2e7c 00000001 c163b320 c1691be0 c16d8084 c08a11f8 ee0ab66c ee64b438
[    4.355049] fec0: ee228610 ee228610 ee228644 c08a29c4 ee228610 00000001 ee0fae00 c163b328
[    4.363217] fee0: ee228610 c163b518 c163b304 c08a1fa8 c163b328 ee1cef80 ee228610 c08a2404
[    4.371384] ff00: c08a23c0 c163b328 ee1cef80 eef8ac40 ee1de018 eef8dc00 00000000 00000000
[    4.379551] ff20: c1684e34 c035ba70 eef8ac40 eef8ac58 ee1de018 ee1cef80 eef8ac40 eef8ac58
[    4.387719] ff40: ee1de018 c1684975 ee1cef98 c1502d00 00000008 c035bf90 ee1d501c ee1de000
[    4.395887] ff60: 00000000 c1502d00 ee1d501c ee1d5000 00000000 ee1c6d00 ee1d501c ee1cef80
[    4.404056] ff80: c035bd68 ee0cbed0 00000000 c03611fc ee1c6d00 c03610d0 00000000 00000000
[    4.412235] ffa0: 00000000 00000000 00000000 c03080c8 00000000 00000000 00000000 00000000
[    4.420404] ffc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[    4.428572] ffe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
[    4.436759] [<c0831ccc>] (drm_debugfs_init) from [<c0813ca4>] (drm_minor_register+0x68/0x110)
[    4.445277] [<c0813ca4>] (drm_minor_register) from [<c0814268>] (drm_dev_register+0x8c/0x1cc)
[    4.453798] [<c0814268>] (drm_dev_register) from [<c08643b8>] (host1x_drm_probe+0x30/0x54)
[    4.462061] [<c08643b8>] (host1x_drm_probe) from [<c07ef578>] (host1x_device_probe+0x20/0x2c)
[    4.470583] [<c07ef578>] (host1x_device_probe) from [<c08a2cc4>] (driver_probe_device+0x224/0x2f8)
[    4.479536] [<c08a2cc4>] (driver_probe_device) from [<c08a11f8>] (bus_for_each_drv+0x58/0x8c)
[    4.488055] [<c08a11f8>] (bus_for_each_drv) from [<c08a29c4>] (__device_attach+0xb0/0x110)
[    4.496313] [<c08a29c4>] (__device_attach) from [<c08a1fa8>] (bus_probe_device+0x84/0x8c)
[    4.504484] [<c08a1fa8>] (bus_probe_device) from [<c08a04c8>] (device_add+0x3f0/0x570)
[    4.512397] [<c08a04c8>] (device_add) from [<c07efb30>] (host1x_subdev_register+0xac/0xd0)
[    4.520655] [<c07efb30>] (host1x_subdev_register) from [<c07f0058>] (host1x_client_register+0x10c/0x12c)
[    4.530129] [<c07f0058>] (host1x_client_register) from [<c088177c>] (tegra_hdmi_probe+0x1e4/0x2f0)
[    4.539080] [<c088177c>] (tegra_hdmi_probe) from [<c08a4914>] (platform_drv_probe+0x4c/0xac)
[    4.547511] [<c08a4914>] (platform_drv_probe) from [<c08a2cc4>] (driver_probe_device+0x224/0x2f8)
[    4.556375] [<c08a2cc4>] (driver_probe_device) from [<c08a11f8>] (bus_for_each_drv+0x58/0x8c)
[    4.564892] [<c08a11f8>] (bus_for_each_drv) from [<c08a29c4>] (__device_attach+0xb0/0x110)
[    4.573149] [<c08a29c4>] (__device_attach) from [<c08a1fa8>] (bus_probe_device+0x84/0x8c)
[    4.581319] [<c08a1fa8>] (bus_probe_device) from [<c08a2404>] (deferred_probe_work_func+0x44/0x13c)
[    4.590361] [<c08a2404>] (deferred_probe_work_func) from [<c035ba70>] (process_one_work+0x14c/0x444)
[    4.599486] [<c035ba70>] (process_one_work) from [<c035bf90>] (worker_thread+0x228/0x538)
[    4.607658] [<c035bf90>] (worker_thread) from [<c03611fc>] (kthread+0x12c/0x15c)
[    4.615049] [<c03611fc>] (kthread) from [<c03080c8>] (ret_from_fork+0x14/0x2c)
[    4.622266] Code: ebfffef4 e2506000 1a00001c e5953200 (e5933010) 
[    4.628417] ---[ end trace d346994bfc0c1628 ]---
Signature · 1 line
nvpublic
#69 lore raw
In reply to Greg Kroah-Hartman
Quoted 9 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.14.73 release. There are 64 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 Sat Sep 29 09:02:21 UTC 2018. Anything received after that time might be too late.

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

Quoted 9 lines
	https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.73-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.14.y
and the diffstat can be found below.

thanks,

greg k-h

Merged, compiled, and installed onto my Raspberry Pi.

No initial issues noticed in dmesg or general usage.

Thanks!
Nathan

author maintainer
#51 lore raw

Re: [PATCH 4.14 49/64] drm/atomic: Use drm_drv_uses_atomic_modeset() for debugfs creation

In reply to Jon Hunter
Quoted 122 lines · Jon Hunter

Hi Greg, Lyude,

Quoted 43 lines · Greg Kroah-Hartman

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

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

From: Lyude Paul <[email protected]>

commit 3c499ea0c662e2f38aafbd4f516b08aab8cfa0e5 upstream.

As pointed out by Daniel Vetter, we should be usinng drm_drv_uses_atomic_modeset() for determining whether or not we want to make the debugfs nodes for atomic instead of checking DRIVER_ATOMIC, as the former isn't an accurate representation of whether or not the driver is actually using atomic modesetting internally (even though it might not be exposing atomic capabilities).

---
 drivers/gpu/drm/drm_atomic.c  |    2 +-
 drivers/gpu/drm/drm_debugfs.c |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)
drivers/gpu/drm/drm_atomic.c +1 -1
@@ -1748,7 +1748,7 @@ static void __drm_state_dump(struct drm_
 	struct drm_connector *connector;
 	struct drm_connector_list_iter conn_iter;
 
-	if (!drm_core_check_feature(dev, DRIVER_ATOMIC))
+	if (!drm_drv_uses_atomic_modeset(dev))
 		return;
 
 	list_for_each_entry(plane, &config->plane_list, head) {

drivers/gpu/drm/drm_debugfs.c int drm_debugfs_init(struct drm_minor *m · line 156

Quoted 8 lines
drivers/gpu/drm/drm_debugfs.c +1 -1
@@ -150,7 +150,7 @@ int drm_debugfs_init(struct drm_minor *m
 		return ret;
 	}
 
-	if (drm_core_check_feature(dev, DRIVER_ATOMIC)) {
+	if (drm_drv_uses_atomic_modeset(dev)) {
 		ret = drm_atomic_debugfs_init(minor);
 		if (ret) {
 			DRM_ERROR("Failed to create atomic debugfs files\n");

This is causing a boot regression on some Tegra devices. For completeness I have included the stack trace below.

Jon

[    4.115829] Unable to handle kernel NULL pointer dereference at virtual address 00000010
[    4.123912] pgd = c0204000
[    4.126661] [00000010] *pgd=00000000
[    4.130245] Internal error: Oops: 5 [#1] SMP ARM
[    4.134857] Modules linked in:
[    4.137917] CPU: 0 PID: 28 Comm: kworker/0:1 Not tainted 4.14.73-rc1-g1e2fd38 #1
[    4.145301] Hardware name: NVIDIA Tegra SoC (Flattened Device Tree)
[    4.151569] Workqueue: events deferred_probe_work_func
[    4.156704] task: ee0fae00 task.stack: ee1de000
[    4.161235] PC is at drm_debugfs_init+0x88/0x178
[    4.165850] LR is at drm_debugfs_create_files+0xf0/0x148
[    4.171152] pc : [<c0831ccc>]    lr : [<c0831984>]    psr: 60000113
[    4.177410] sp : ee1dfcd0  ip : 00000000  fp : ee1de000
[    4.182625] r10: 00000017  r9 : 00000000  r8 : c163a884
[    4.187841] r7 : 00000080  r6 : 00000000  r5 : ed12b000  r4 : ed15fe00
[    4.194357] r3 : 00000000  r2 : 00000000  r1 : c0831984  r0 : 00000000
[    4.200884] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
[    4.208013] Control: 10c5387d  Table: 8020406a  DAC: 00000051
[    4.213753] Process kworker/0:1 (pid: 28, stack limit = 0xee1de220)
[    4.220011] Stack: (0xee1dfcd0 to 0xee1e0000)
[    4.224365] fcc0:                                     00383231 ffffffff 014080c0 c0815a14
[    4.232534] fce0: ffffffff 00000000 ffffffff ee452858 00000004 c04591c4 ee452848 00000000
[    4.240702] fd00: 00000004 ed15ffc0 c117438c ee655810 c163a778 ed15fe00 c16d7ef4 00000000
[    4.248869] fd20: c163a778 c0813ca4 ee0fae00 ed12b000 00000000 00000000 c163a778 c0814268
[    4.257036] fd40: c1685a8c ee655810 c163a778 ed12b000 00000000 ed12b000 ee655800 c16d8088
[    4.265205] fd60: 00000000 c163a884 00000000 c08643b8 c0864388 ee655810 c16d8084 c07ef578
[    4.273372] fd80: c07ef558 c08a2cc4 00000000 ee1dfdc0 c08a2e7c 00000001 c16d8060 00000000
[    4.281539] fda0: 00000000 c08a11f8 ee64616c ee64b338 ee655810 ee655810 ee655844 c08a29c4
[    4.289707] fdc0: ee655810 00000001 00000000 ee655818 ee655810 c1638c80 ee228010 c08a1fa8
[    4.297875] fde0: ee655818 ee655810 00000000 c08a04c8 c0877720 ee407010 00000000 ee213600
[    4.306044] fe00: ee655800 ee407010 ee6484c0 ee655810 ee6559b0 ee663810 00000017 c07efb30
[    4.314211] fe20: c1638c64 c1638cfc ee655804 ee663c28 ee407010 c07f0058 c0f6044c ee407010
[    4.322378] fe40: ee228610 00000000 ee228600 00000000 00000000 c088177c 00000000 ee211ac0
[    4.330545] fe60: ee407010 ee228610 ee228610 fffffdfb c163a9e8 00000000 c163a9e8 c08a4914
[    4.338713] fe80: c08a48c8 ee228610 c16d8084 c16d8088 00000000 c08a2cc4 00000000 ee1dfed0
[    4.346881] fea0: c08a2e7c 00000001 c163b320 c1691be0 c16d8084 c08a11f8 ee0ab66c ee64b438
[    4.355049] fec0: ee228610 ee228610 ee228644 c08a29c4 ee228610 00000001 ee0fae00 c163b328
[    4.363217] fee0: ee228610 c163b518 c163b304 c08a1fa8 c163b328 ee1cef80 ee228610 c08a2404
[    4.371384] ff00: c08a23c0 c163b328 ee1cef80 eef8ac40 ee1de018 eef8dc00 00000000 00000000
[    4.379551] ff20: c1684e34 c035ba70 eef8ac40 eef8ac58 ee1de018 ee1cef80 eef8ac40 eef8ac58
[    4.387719] ff40: ee1de018 c1684975 ee1cef98 c1502d00 00000008 c035bf90 ee1d501c ee1de000
[    4.395887] ff60: 00000000 c1502d00 ee1d501c ee1d5000 00000000 ee1c6d00 ee1d501c ee1cef80
[    4.404056] ff80: c035bd68 ee0cbed0 00000000 c03611fc ee1c6d00 c03610d0 00000000 00000000
[    4.412235] ffa0: 00000000 00000000 00000000 c03080c8 00000000 00000000 00000000 00000000
[    4.420404] ffc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[    4.428572] ffe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
[    4.436759] [<c0831ccc>] (drm_debugfs_init) from [<c0813ca4>] (drm_minor_register+0x68/0x110)
[    4.445277] [<c0813ca4>] (drm_minor_register) from [<c0814268>] (drm_dev_register+0x8c/0x1cc)
[    4.453798] [<c0814268>] (drm_dev_register) from [<c08643b8>] (host1x_drm_probe+0x30/0x54)
[    4.462061] [<c08643b8>] (host1x_drm_probe) from [<c07ef578>] (host1x_device_probe+0x20/0x2c)
[    4.470583] [<c07ef578>] (host1x_device_probe) from [<c08a2cc4>] (driver_probe_device+0x224/0x2f8)
[    4.479536] [<c08a2cc4>] (driver_probe_device) from [<c08a11f8>] (bus_for_each_drv+0x58/0x8c)
[    4.488055] [<c08a11f8>] (bus_for_each_drv) from [<c08a29c4>] (__device_attach+0xb0/0x110)
[    4.496313] [<c08a29c4>] (__device_attach) from [<c08a1fa8>] (bus_probe_device+0x84/0x8c)
[    4.504484] [<c08a1fa8>] (bus_probe_device) from [<c08a04c8>] (device_add+0x3f0/0x570)
[    4.512397] [<c08a04c8>] (device_add) from [<c07efb30>] (host1x_subdev_register+0xac/0xd0)
[    4.520655] [<c07efb30>] (host1x_subdev_register) from [<c07f0058>] (host1x_client_register+0x10c/0x12c)
[    4.530129] [<c07f0058>] (host1x_client_register) from [<c088177c>] (tegra_hdmi_probe+0x1e4/0x2f0)
[    4.539080] [<c088177c>] (tegra_hdmi_probe) from [<c08a4914>] (platform_drv_probe+0x4c/0xac)
[    4.547511] [<c08a4914>] (platform_drv_probe) from [<c08a2cc4>] (driver_probe_device+0x224/0x2f8)
[    4.556375] [<c08a2cc4>] (driver_probe_device) from [<c08a11f8>] (bus_for_each_drv+0x58/0x8c)
[    4.564892] [<c08a11f8>] (bus_for_each_drv) from [<c08a29c4>] (__device_attach+0xb0/0x110)
Quoted 9 lines
[    4.573149] [<c08a29c4>] (__device_attach) from [<c08a1fa8>] (bus_probe_device+0x84/0x8c)
[    4.581319] [<c08a1fa8>] (bus_probe_device) from [<c08a2404>] (deferred_probe_work_func+0x44/0x13c)
[    4.590361] [<c08a2404>] (deferred_probe_work_func) from [<c035ba70>] (process_one_work+0x14c/0x444)
[    4.599486] [<c035ba70>] (process_one_work) from [<c035bf90>] (worker_thread+0x228/0x538)
[    4.607658] [<c035bf90>] (worker_thread) from [<c03611fc>] (kthread+0x12c/0x15c)
[    4.615049] [<c03611fc>] (kthread) from [<c03080c8>] (ret_from_fork+0x14/0x2c)
[    4.622266] Code: ebfffef4 e2506000 1a00001c e5953200 (e5933010) 
[    4.628417] ---[ end trace d346994bfc0c1628 ]---

Now dropped, thanks.

greg k-h

author maintainer
#70 lore raw
In reply to Nathan Chancellor
Quoted 15 lines · Nathan Chancellor
Quoted 14 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.14.73 release. There are 64 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 Sat Sep 29 09:02:21 UTC 2018. Anything received after that time might be too late.

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

	https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.73-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.14.y
and the diffstat can be found below.

Quoted 8 lines
Quoted 4 lines

thanks,

greg k-h

Merged, compiled, and installed onto my Raspberry Pi.

No initial issues noticed in dmesg or general usage.

Great, thanks for testing these and letting me know.

greg k-h

#71 lore raw
In reply to Greg Kroah-Hartman
Quoted 9 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.14.73 release. There are 64 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 Sat Sep 29 09:02:21 UTC 2018. Anything received after that time might be too late.

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

Quoted 8 lines
	https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.73-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.14.y
and the diffstat can be found below.

thanks,

greg k-h

Note:

dragonboard-410c boot issues are now solved, after "rpmsg: core: add support to power domains for devices" commit was reverted. Thank you!

Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.

Summary
------------------------------------------------------------------------

kernel: 4.14.73-rc1
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.14.y
git commit: 1e2fd389792f6e2f7b7d9bc252c9010a2c1f97eb
git describe: v4.14.72-64-g1e2fd389792f
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.14-oe/build/v4.14.72-64-g1e2fd389792f

No regressions (compared to build v4.14.71-170-g2cc4d365363b)

Ran 20209 total tests in the following environments and test suites.

Environments
--------------
- dragonboard-410c - arm64
- hi6220-hikey - arm64
- i386
- juno-r2 - arm64
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15 - arm
- x86_64

Test Suites
-----------
* boot
* kselftest
* libhugetlbfs
* ltp-containers-tests
* ltp-cve-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-timers-tests
* ltp-cap_bounds-tests
* ltp-fcntl-locktests-tests
* ltp-open-posix-tests
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none

Signature · 2 lines
Linaro LKFT
https://lkft.linaro.org
#72 lore raw
In reply to Greg Kroah-Hartman
Quoted 9 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.14.73 release. There are 64 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 Sat Sep 29 09:02:21 UTC 2018. Anything received after that time might be too late.

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

Quoted 9 lines
	https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.73-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.14.y
and the diffstat can be found below.

thanks,

greg k-h

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

thanks,
-- Shuah

#73 lore raw
In reply to Greg Kroah-Hartman

Hi Greg,

Quoted 7 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.14.73 release. There are 64 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 Sat Sep 29 09:02:21 UTC 2018. Anything received after that time might be too late.

My kvm guest had this:

[    8.570020] kasan: CONFIG_KASAN_INLINE enabled
[    8.570272] kasan: GPF could be caused by NULL-ptr deref or user
memory access
[    8.570472] general protection fault: 0000 [#1] SMP KASAN PTI
[    8.570625] Modules linked in: bochs_drm(+) ppdev drm_kms_helper

ttm joydev evdev drm sg serio_raw pcspkr parport_pc parport button ip_tables x_tables autofs4 ext4 crc32c_generic crc16 mbcache jbd2 fscrypto sr_mod cdrom sd_mod ata_generic ata_piix xhci_pci e1000 psmouse xhci_hcd libata floppy usbcore i2c_piix4 scsi_mod

[    8.571218] CPU: 0 PID: 225 Comm: systemd-udevd Not tainted 4.14.73-rc1+ #5
[    8.571394] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS rel-1.10.2-0-g5f4c7b1-prebuilt.qemu-project.org 04/01/2014
[    8.571706] task: ffff8800366db100 task.stack: ffff88002b1b8000
[    8.571875] RIP: 0010:drm_debugfs_init+0x183/0x370 [drm]
[    8.572023] RSP: 0018:ffff88002b1bf5e8 EFLAGS: 00010202
[    8.572207] RAX: dffffc0000000000 RBX: ffff880031d37000 RCX: 0000000000000000
[    8.572384] RDX: 0000000000000004 RSI: ffff880031d37020 RDI: 0000000000000020
[    8.572560] RBP: 1ffff10005637ebe R08: ffff880036380638 R09: 0000000000000000
[    8.572736] R10: ffff880036380640 R11: ffff880028586290 R12: 0000000000000000
[    8.572914] R13: ffff880028ec1540 R14: 0000000000000000 R15: 0000000000000000
[    8.573091] FS:  00007ff59b7088c0(0000) GS:ffff880034400000(0000)
knlGS:0000000000000000
[    8.573289] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    8.573441] CR2: 00007ffdf9c90000 CR3: 000000002f478000 CR4: 00000000000006f0
[    8.573685] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[    8.573927] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[    8.574227] Call Trace:
[    8.574389]  ? drm_dev_set_unique+0x44/0x90 [drm]
[    8.574591]  ? connector_write+0x2e0/0x2e0 [drm]
[    8.574795]  ? add_hole+0x33e/0x600 [drm]
[    8.574980]  ? memcpy+0x34/0x50
[    8.575152]  drm_minor_register+0xa7/0x1d0 [drm]
[    8.575356]  drm_dev_register+0x117/0x5d0 [drm]
[    8.575562]  drm_get_pci_dev+0x17b/0x4b0 [drm]
[    8.575752]  ? bochs_load+0x110/0x110 [bochs_drm]
[    8.575946]  local_pci_probe+0xde/0x1a0
[    8.576123]  pci_device_probe+0x3f0/0x550
[    8.576306]  ? pci_device_remove+0x1d0/0x1d0
[    8.576492]  ? driver_sysfs_add+0x158/0x280
[    8.576675]  driver_probe_device+0x5e2/0xc80
[    8.576862]  ? driver_probe_device+0xc80/0xc80
[    8.577053]  __driver_attach+0x194/0x1e0
[    8.577231]  bus_for_each_dev+0x111/0x1a0
[    8.577411]  ? subsys_dev_iter_exit+0x10/0x10
[    8.577600]  ? __switch_to_asm+0x24/0x60
[    8.577780]  ? __switch_to_asm+0x24/0x60
[    8.577957]  ? klist_add_tail+0x5c/0x120
[    8.578135]  bus_add_driver+0x3b8/0x6f0
[    8.578314]  driver_register+0x187/0x3a0
[    8.578495]  ? 0xffffffffc0620000
[    8.578664]  do_one_initcall+0x7f/0x1e1
[    8.578845]  ? initcall_blacklisted+0x150/0x150
[    8.579037]  ? kmem_cache_alloc_trace+0xea/0x5d0
[    8.579228]  ? kasan_unpoison_shadow+0x30/0x40
[    8.579414]  ? __asan_register_globals+0x77/0x90
[    8.579611]  do_init_module+0x1ba/0x552
[    8.579790]  ? load_module+0x6798/0x9b30
[    8.579967]  load_module+0x67a5/0x9b30
[    8.580143]  ? module_frob_arch_sections+0x20/0x20
[    8.580340]  ? vfs_read+0x24e/0x2e0
[    8.580514]  ? kernel_read+0x90/0x130
[    8.580687]  ? set_binfmt+0x120/0x120
[    8.580862]  ? SYSC_finit_module+0x14d/0x180
[    8.581049]  SYSC_finit_module+0x14d/0x180
[    8.581230]  ? SYSC_init_module+0x1c0/0x1c0
[    8.581412]  ? vfs_statx_fd+0x49/0x80
[    8.581588]  ? syscall_trace_enter+0x30f/0xb00
[    8.581848]  ? exit_to_usermode_loop+0x7a/0x100
[    8.582105]  ? SyS_init_module+0x10/0x10
[    8.582283]  do_syscall_64+0x191/0x450
[    8.582460]  ? async_page_fault+0x2f/0x50
[    8.582643]  entry_SYSCALL_64_after_hwframe+0x3d/0xa2
[    8.582840] RIP: 0033:0x7ff59a586229
[    8.583011] RSP: 002b:00007ffcad244b18 EFLAGS: 00000246 ORIG_RAX:
0000000000000139
[    8.583318] RAX: ffffffffffffffda RBX: 0000561bda7e7e90 RCX: 00007ff59a586229
[    8.583558] RDX: 0000000000000000 RSI: 00007ff59ae9f265 RDI: 0000000000000011
[    8.583780] RBP: 00007ff59ae9f265 R08: 0000000000000000 R09: 00007ffcad245090
[    8.584001] R10: 0000000000000011 R11: 0000000000000246 R12: 0000000000000000
[    8.584272] R13: 0000561bda7e7cb0 R14: 0000000000020000 R15: 0000561bd9fc4cbc
[    8.584496] Code: fa 48 c1 ea 03 80 3c 02 00 0f 85 9f 01 00 00 4d
8b b5 70 03 00 00 48 b8 00 00 00 00 00 fc ff df 49 8d 7e 20 48 89 fa
48 c1 ea 03 <80> 3c 02 00 0f 85 6f 01 00 00 49 83 7e 20 00 74 10 48 89
df e8
[    8.585076] RIP: drm_debugfs_init+0x183/0x370 [drm] RSP: ffff88002b1bf5e8
[    8.585404] ---[ end trace 62728db3ac408aba ]---

And I had to revert 7e58fe2a97bc ("drm/atomic: Use drm_drv_uses_atomic_modeset() for debugfs creation") to make it work. I am looking more into why it failed.

Signature · 2 lines
Regards
Sudip
#74 lore raw

Hi Greg,

Quoted 14 lines · Sudip Mukherjee

Hi Greg,

Quoted 7 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.14.73 release. There are 64 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 Sat Sep 29 09:02:21 UTC 2018. Anything received after that time might be too late.

My kvm guest had this:

<snip>

Quoted 6 lines
[    8.585076] RIP: drm_debugfs_init+0x183/0x370 [drm] RSP: ffff88002b1bf5e8
[    8.585404] ---[ end trace 62728db3ac408aba ]---

And I had to revert 7e58fe2a97bc ("drm/atomic: Use drm_drv_uses_atomic_modeset() for debugfs creation") to make it work. I am looking more into why it failed.

update:

Backporting 57078338b2e4 ("drm: fix drm_drv_uses_atomic_modeset on non modesetting drivers.") fixed the issue. But 7e58fe2a97bc ("drm/atomic:
Use drm_drv_uses_atomic_modeset() for debugfs creation") changed the functionality of the check. If this has to be applied, it will also need an additional patch to keep the check same as linus tree.

But looking at the other mails now, and you have already dropped the patch.

Signature · 2 lines
Regards
Sudip
#76 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.14.73 release. There are 64 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 Sat Sep 29 09:02:21 UTC 2018. Anything received after that time might be too late.

Build results:

	total: 151 pass: 151 fail: 0
Qemu test results:
	total: 318 pass: 314 fail: 4
Failed tests: 
	arm:sabrelite:imx_v6_v7_defconfig:imx6dl-sabrelite 
	powerpc:g3beige:ppc_book3s_defconfig:nosmp:ide:rootfs 
	x86_64:q35:Broadwell-noTSX:defconfig:smp:mem256:ata:rootfs 
	x86_64:pc:Opteron_G2:defconfig:smp:efi32:mem2G:scsi[virtio-pci]:rootfs

arm_sabrelite crashes in drm code as already reported.

powerpc:g3beige is the known problem. Patch should be available upstream in the near future.

The x86_64 failures are spurious. I'll change the scripts to no longer report those until I figure out what is going on.

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

Guenter

author maintainer
#75 lore raw
In reply to Sudip Mukherjee
Quoted 30 lines · Sudip Mukherjee

Hi Greg,

Quoted 14 lines · Sudip Mukherjee

Hi Greg,

Quoted 7 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.14.73 release. There are 64 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 Sat Sep 29 09:02:21 UTC 2018. Anything received after that time might be too late.

My kvm guest had this:

<snip>

Quoted 6 lines
[    8.585076] RIP: drm_debugfs_init+0x183/0x370 [drm] RSP: ffff88002b1bf5e8
[    8.585404] ---[ end trace 62728db3ac408aba ]---

And I had to revert 7e58fe2a97bc ("drm/atomic: Use drm_drv_uses_atomic_modeset() for debugfs creation") to make it work. I am looking more into why it failed.

update:

Quoted 7 lines

Backporting 57078338b2e4 ("drm: fix drm_drv_uses_atomic_modeset on non modesetting drivers.") fixed the issue. But 7e58fe2a97bc ("drm/atomic:
Use drm_drv_uses_atomic_modeset() for debugfs creation") changed the functionality of the check. If this has to be applied, it will also need an additional patch to keep the check same as linus tree.

But looking at the other mails now, and you have already dropped the patch.

Yes, already dropped :)