commit 0a9d6a58b4acfa52384b3175bd3d0742467bcf65 Author: Greg Kroah-Hartman Date: Tue Oct 1 09:01:46 2019 +0200 Linux 5.2.18 commit c704eb3aaffae0d6463b1773b37e69695b112ca4 Author: Chao Yu Date: Thu Jun 20 11:36:14 2019 +0800 f2fs: use generic EFSBADCRC/EFSCORRUPTED [ Upstream commit 10f966bbf521bb9b2e497bbca496a5141f4071d0 ] f2fs uses EFAULT as error number to indicate filesystem is corrupted all the time, but generic filesystems use EUCLEAN for such condition, we need to change to follow others. This patch adds two new macros as below to wrap more generic error code macros, and spread them in code. EFSBADCRC EBADMSG /* Bad CRC detected */ EFSCORRUPTED EUCLEAN /* Filesystem is corrupted */ Reported-by: Pavel Machek Signed-off-by: Chao Yu Acked-by: Pavel Machek Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 673d1167b40eb02da6c33c9dabec6c849b981dc0 Author: Ka-Cheong Poon Date: Tue Sep 24 08:51:16 2019 -0700 net/rds: Check laddr_check before calling it [ Upstream commit 05733434ee9ae6548723a808647248583e347cca ] In rds_bind(), laddr_check is called without checking if it is NULL or not. And rs_transport should be reset if rds_add_bound() fails. Fixes: c5c1a030a7db ("net/rds: An rds_sock is added too early to the hash table") Reported-by: syzbot+fae39afd2101a17ec624@syzkaller.appspotmail.com Signed-off-by: Ka-Cheong Poon Acked-by: Santosh Shilimkar Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit fc5b59770306a0e6245e420951191c6322b673ac Author: Ka-Cheong Poon Date: Wed Sep 11 02:58:05 2019 -0700 net/rds: An rds_sock is added too early to the hash table [ Upstream commit c5c1a030a7dbf8dd4e1fa4405ae9a89dc1d2a8db ] In rds_bind(), an rds_sock is added to the RDS bind hash table before rs_transport is set. This means that the socket can be found by the receive code path when rs_transport is NULL. And the receive code path de-references rs_transport for congestion update check. This can cause a panic. An rds_sock should not be added to the bind hash table before all the needed fields are set. Reported-by: syzbot+4b4f8163c2e246df3c4c@syzkaller.appspotmail.com Signed-off-by: Ka-Cheong Poon Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 719532b9b83211febd34a1a5b1aa28c5469a0697 Author: Cong Wang Date: Sun Sep 8 12:11:23 2019 -0700 net_sched: check cops->tcf_block in tc_bind_tclass() [ Upstream commit 8b142a00edcf8422ca48b8de88d286efb500cb53 ] At least sch_red and sch_tbf don't implement ->tcf_block() while still have a non-zero tc "class". Instead of adding nop implementations to each of such qdisc's, we can just relax the check of cops->tcf_block() in tc_bind_tclass(). They don't support TC filter anyway. Reported-by: syzbot+21b29db13c065852f64b@syzkaller.appspotmail.com Cc: Jamal Hadi Salim Cc: Jiri Pirko Signed-off-by: Cong Wang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit bd740eacb1d2034331cc5ec48e73fe45c6a06d85 Author: Jian-Hong Pan Date: Tue Sep 3 17:10:42 2019 +0800 Bluetooth: btrtl: Additional Realtek 8822CE Bluetooth devices [ Upstream commit 6d0762b19c5963ff9e178e8af3626532ee04d93d ] The ASUS X412FA laptop contains a Realtek RTL8822CE device with an associated BT chip using a USB ID of 04ca:4005. This ID is added to the driver. The /sys/kernel/debug/usb/devices portion for this device is: T: Bus=01 Lev=01 Prnt=01 Port=09 Cnt=04 Dev#= 4 Spd=12 MxCh= 0 D: Ver= 1.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=04ca ProdID=4005 Rev= 0.00 S: Manufacturer=Realtek S: Product=Bluetooth Radio S: SerialNumber=00e04c000001 C:* #Ifs= 2 Cfg#= 1 Atr=a0 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=204707 Signed-off-by: Jian-Hong Pan Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit f63432cd1bb224f61216e4a4726ff29ddffbed98 Author: Fernando Fernandez Mancera Date: Sun Sep 1 11:48:08 2019 +0200 netfilter: nft_socket: fix erroneous socket assignment [ Upstream commit 039b1f4f24ecc8493b6bb9d70b4b78750d1b35c2 ] The socket assignment is wrong, see skb_orphan(): When skb->destructor callback is not set, but skb->sk is set, this hits BUG(). Link: https://bugzilla.redhat.com/show_bug.cgi?id=1651813 Fixes: 554ced0a6e29 ("netfilter: nf_tables: add support for native socket matching") Signed-off-by: Fernando Fernandez Mancera Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit a2a3638f3e6f5d3fde5affae04fc6a540cdc9319 Author: Florian Westphal Date: Mon Aug 12 10:32:13 2019 +0200 xfrm: policy: avoid warning splat when merging nodes [ Upstream commit 769a807d0b41df4201dbeb01c22eaeb3e5905532 ] syzbot reported a splat: xfrm_policy_inexact_list_reinsert+0x625/0x6e0 net/xfrm/xfrm_policy.c:877 CPU: 1 PID: 6756 Comm: syz-executor.1 Not tainted 5.3.0-rc2+ #57 Call Trace: xfrm_policy_inexact_node_reinsert net/xfrm/xfrm_policy.c:922 [inline] xfrm_policy_inexact_node_merge net/xfrm/xfrm_policy.c:958 [inline] xfrm_policy_inexact_insert_node+0x537/0xb50 net/xfrm/xfrm_policy.c:1023 xfrm_policy_inexact_alloc_chain+0x62b/0xbd0 net/xfrm/xfrm_policy.c:1139 xfrm_policy_inexact_insert+0xe8/0x1540 net/xfrm/xfrm_policy.c:1182 xfrm_policy_insert+0xdf/0xce0 net/xfrm/xfrm_policy.c:1574 xfrm_add_policy+0x4cf/0x9b0 net/xfrm/xfrm_user.c:1670 xfrm_user_rcv_msg+0x46b/0x720 net/xfrm/xfrm_user.c:2676 netlink_rcv_skb+0x1f0/0x460 net/netlink/af_netlink.c:2477 xfrm_netlink_rcv+0x74/0x90 net/xfrm/xfrm_user.c:2684 netlink_unicast_kernel net/netlink/af_netlink.c:1302 [inline] netlink_unicast+0x809/0x9a0 net/netlink/af_netlink.c:1328 netlink_sendmsg+0xa70/0xd30 net/netlink/af_netlink.c:1917 sock_sendmsg_nosec net/socket.c:637 [inline] sock_sendmsg net/socket.c:657 [inline] There is no reproducer, however, the warning can be reproduced by adding rules with ever smaller prefixes. The sanity check ("does the policy match the node") uses the prefix value of the node before its updated to the smaller value. To fix this, update the prefix earlier. The bug has no impact on tree correctness, this is only to prevent a false warning. Reported-by: syzbot+8cc27ace5f6972910b31@syzkaller.appspotmail.com Signed-off-by: Florian Westphal Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit b442b6d3742b1838ae09416ad36204d7dd5c6aff Author: Darrick J. Wong Date: Sun Aug 11 15:52:27 2019 -0700 xfs: don't crash on null attr fork xfs_bmapi_read [ Upstream commit 8612de3f7ba6e900465e340516b8313806d27b2d ] Zorro Lang reported a crash in generic/475 if we try to inactivate a corrupt inode with a NULL attr fork (stack trace shortened somewhat): RIP: 0010:xfs_bmapi_read+0x311/0xb00 [xfs] RSP: 0018:ffff888047f9ed68 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: ffff888047f9f038 RCX: 1ffffffff5f99f51 RDX: 0000000000000002 RSI: 0000000000000008 RDI: 0000000000000012 RBP: ffff888002a41f00 R08: ffffed10005483f0 R09: ffffed10005483ef R10: ffffed10005483ef R11: ffff888002a41f7f R12: 0000000000000004 R13: ffffe8fff53b5768 R14: 0000000000000005 R15: 0000000000000001 FS: 00007f11d44b5b80(0000) GS:ffff888114200000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000ef6000 CR3: 000000002e176003 CR4: 00000000001606e0 Call Trace: xfs_dabuf_map.constprop.18+0x696/0xe50 [xfs] xfs_da_read_buf+0xf5/0x2c0 [xfs] xfs_da3_node_read+0x1d/0x230 [xfs] xfs_attr_inactive+0x3cc/0x5e0 [xfs] xfs_inactive+0x4c8/0x5b0 [xfs] xfs_fs_destroy_inode+0x31b/0x8e0 [xfs] destroy_inode+0xbc/0x190 xfs_bulkstat_one_int+0xa8c/0x1200 [xfs] xfs_bulkstat_one+0x16/0x20 [xfs] xfs_bulkstat+0x6fa/0xf20 [xfs] xfs_ioc_bulkstat+0x182/0x2b0 [xfs] xfs_file_ioctl+0xee0/0x12a0 [xfs] do_vfs_ioctl+0x193/0x1000 ksys_ioctl+0x60/0x90 __x64_sys_ioctl+0x6f/0xb0 do_syscall_64+0x9f/0x4d0 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x7f11d39a3e5b The "obvious" cause is that the attr ifork is null despite the inode claiming an attr fork having at least one extent, but it's not so obvious why we ended up with an inode in that state. Reported-by: Zorro Lang Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204031 Signed-off-by: Darrick J. Wong Reviewed-by: Bill O'Donnell Signed-off-by: Sasha Levin commit baa3902119f553d8ee521d8afd40c18ab4f7af0e Author: Ilia Mirkin Date: Sat May 25 18:41:49 2019 -0400 drm/nouveau/disp/nv50-: fix center/aspect-corrected scaling [ Upstream commit 533f4752407543f488a9118d817b8c504352b6fb ] Previously center scaling would get scaling applied to it (when it was only supposed to center the image), and aspect-corrected scaling did not always correctly pick whether to reduce width or height for a particular combination of inputs/outputs. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110660 Signed-off-by: Ilia Mirkin Signed-off-by: Ben Skeggs Signed-off-by: Sasha Levin commit 452b129e4876cce72dc305a4a1c2390b7ed944f8 Author: Hans de Goede Date: Fri Jul 12 12:00:33 2019 +0200 ACPI: video: Add new hw_changes_brightness quirk, set it on PB Easynote MZ35 [ Upstream commit 4f7f96453b462b3de0fa18d18fe983960bb5ee7f ] Some machines change the brightness themselves when a brightness hotkey gets pressed, despite us telling them not to. This causes the brightness to go two steps up / down when the hotkey is pressed. This is esp. a problem on older machines with only a few brightness levels. This commit adds a new hw_changes_brightness quirk which makes acpi_video_device_notify() only call backlight_force_update(..., BACKLIGHT_UPDATE_HOTKEY) and not do anything else, notifying userspace that the brightness was changed and leaving it at that fixing the dual step problem. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=204077 Reported-by: Kacper Piwiński Tested-by: Kacper Piwiński Signed-off-by: Hans de Goede Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 62b72c1f7ba557b88270c3e6db00ce7d52f2ba5d Author: Jian-Hong Pan Date: Tue Jun 25 16:30:51 2019 +0800 Bluetooth: btrtl: HCI reset on close for Realtek BT chip [ Upstream commit 7af3f558aca74f2ee47b173f1c27f6bb9a5b5561 ] Realtek RTL8822BE BT chip on ASUS X420FA cannot be turned on correctly after on-off several times. Bluetooth daemon sets BT mode failed when this issue happens. Scanning must be active while turning off for this bug to be hit. bluetoothd[1576]: Failed to set mode: Failed (0x03) If BT is turned off, then turned on again, it works correctly again. According to the vendor driver, the HCI_QUIRK_RESET_ON_CLOSE flag is set during probing. So, this patch makes Realtek's BT reset on close to fix this issue. Link: https://bugzilla.kernel.org/show_bug.cgi?id=203429 Signed-off-by: Jian-Hong Pan Reviewed-by: Daniel Drake Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit f6983a936fbfa5ebb437be6e3157b81ce2aef40b Author: Stephen Hemminger Date: Tue Jul 2 15:20:21 2019 -0700 net: don't warn in inet diag when IPV6 is disabled [ Upstream commit 1e64d7cbfdce4887008314d5b367209582223f27 ] If IPV6 was disabled, then ss command would cause a kernel warning because the command was attempting to dump IPV6 socket information. The fix is to just remove the warning. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=202249 Fixes: 432490f9d455 ("net: ip, diag -- Add diag interface for raw sockets") Signed-off-by: Stephen Hemminger Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 955b7a09bf57a5d5dd371a66d05aa2e11fb2e214 Author: Ville Syrjälä Date: Tue May 28 17:06:49 2019 +0300 drm/dp: Add DP_DPCD_QUIRK_NO_SINK_COUNT [ Upstream commit 7974033e527a5dd12d96126d09d4cff4f9b65c69 ] CH7511 eDP->LVDS bridge doesn't seem to set SINK_COUNT properly causing i915 to detect it as disconnected. Add a quirk to ignore SINK_COUNT on these devices. Cc: David S. Cc: Peteris Rudzusiks Tested-by: Peteris Rudzusiks Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105406 Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20190528140650.19230-1-ville.syrjala@linux.intel.com Acked-by: Jani Nikula #irc Signed-off-by: Sasha Levin commit a7734a035acf267504b4a68b6a58d9a87b3c70ad Author: Chris Wilson Date: Mon Jun 3 14:58:57 2019 +0100 drm: Flush output polling on shutdown [ Upstream commit 3b295cb1a411d9c82bbfaa66bc17a8508716ed07 ] We need to mark the output polling as disabled to prevent concurrent irqs from queuing new work as shutdown the probe -- causing that work to execute after we have freed the structs: <4> [341.846490] DEBUG_LOCKS_WARN_ON(mutex_is_locked(lock)) <4> [341.846497] WARNING: CPU: 3 PID: 3300 at kernel/locking/mutex-debug.c:103 mutex_destroy+0x49/0x50 <4> [341.846508] Modules linked in: i915(-) vgem thunderbolt snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic mei_hdcp x86_pkg_temp_thermal coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_codec snd_hwdep snd_hda_core snd_pcm mcs7830 btusb usbnet btrtl mii btbcm btintel bluetooth ecdh_generic ecc mei_me mei prime_numbers i2c_hid pinctrl_sunrisepoint pinctrl_intel [last unloaded: i915] <4> [341.846546] CPU: 3 PID: 3300 Comm: i915_module_loa Tainted: G U 5.2.0-rc2-CI-CI_DRM_6175+ #1 <4> [341.846553] Hardware name: Dell Inc. XPS 13 9360/0823VW, BIOS 2.9.0 07/09/2018 <4> [341.846560] RIP: 0010:mutex_destroy+0x49/0x50 <4> [341.846565] Code: 00 00 5b c3 e8 a8 9f 3b 00 85 c0 74 ed 8b 05 3e 55 23 01 85 c0 75 e3 48 c7 c6 00 d0 08 82 48 c7 c7 a8 aa 07 82 e8 e7 08 fa ff <0f> 0b eb cc 0f 1f 00 48 b8 11 11 11 11 11 11 11 11 48 89 76 20 48 <4> [341.846578] RSP: 0018:ffffc900006cfdb0 EFLAGS: 00010286 <4> [341.846583] RAX: 0000000000000000 RBX: ffff88826759a168 RCX: 0000000000000000 <4> [341.846589] RDX: 0000000000000002 RSI: 0000000000000000 RDI: ffffffff8112844c <4> [341.846595] RBP: ffff8882708fa548 R08: 0000000000000000 R09: 0000000000039600 <4> [341.846601] R10: 0000000000000000 R11: 0000000000000ce4 R12: ffffffffa07de1e0 <4> [341.846607] R13: 0000000000000000 R14: 0000000000000000 R15: ffffffffa07de2d0 <4> [341.846613] FS: 00007f62b5ae0e40(0000) GS:ffff888276380000(0000) knlGS:0000000000000000 <4> [341.846620] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4> [341.846626] CR2: 000055a4e064f4a0 CR3: 0000000266b16006 CR4: 00000000003606e0 <4> [341.846632] Call Trace: <4> [341.846639] drm_fb_helper_fini.part.17+0xb3/0x100 <4> [341.846682] intel_fbdev_fini+0x20/0x80 [i915] <4> [341.846722] intel_modeset_cleanup+0x9a/0x140 [i915] <4> [341.846750] i915_driver_unload+0xa3/0x100 [i915] <4> [341.846778] i915_pci_remove+0x19/0x30 [i915] <4> [341.846784] pci_device_remove+0x36/0xb0 <4> [341.846790] device_release_driver_internal+0xd3/0x1b0 <4> [341.846795] driver_detach+0x3f/0x80 <4> [341.846800] bus_remove_driver+0x53/0xd0 <4> [341.846805] pci_unregister_driver+0x25/0xa0 <4> [341.846843] i915_exit+0x16/0x1c [i915] <4> [341.846849] __se_sys_delete_module+0x162/0x210 <4> [341.846855] ? trace_hardirqs_off_thunk+0x1a/0x1c <4> [341.846859] ? do_syscall_64+0xd/0x1c0 <4> [341.846864] do_syscall_64+0x55/0x1c0 <4> [341.846869] entry_SYSCALL_64_after_hwframe+0x49/0xbe <4> [341.846875] RIP: 0033:0x7f62b51871b7 <4> [341.846881] Code: 73 01 c3 48 8b 0d d1 8c 2c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 b8 b0 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d a1 8c 2c 00 f7 d8 64 89 01 48 <4> [341.846897] RSP: 002b:00007ffe7a227138 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0 <4> [341.846904] RAX: ffffffffffffffda RBX: 00007ffe7a2272b0 RCX: 00007f62b51871b7 <4> [341.846910] RDX: 0000000000000001 RSI: 0000000000000800 RDI: 0000557cd6b55948 <4> [341.846916] RBP: 0000557cd6b558e0 R08: 0000557cd6b5594c R09: 00007ffe7a227160 <4> [341.846922] R10: 00007ffe7a226134 R11: 0000000000000206 R12: 0000000000000000 <4> [341.846927] R13: 00007ffe7a227820 R14: 0000000000000000 R15: 0000000000000000 <4> [341.846936] irq event stamp: 3547847 <4> [341.846940] hardirqs last enabled at (3547847): [] _raw_spin_unlock_irqrestore+0x4c/0x60 <4> [341.846949] hardirqs last disabled at (3547846): [] _raw_spin_lock_irqsave+0xd/0x50 <4> [341.846957] softirqs last enabled at (3547376): [] __do_softirq+0x33a/0x4b9 <4> [341.846966] softirqs last disabled at (3547367): [] irq_exit+0xa9/0xc0 <4> [341.846973] WARNING: CPU: 3 PID: 3300 at kernel/locking/mutex-debug.c:103 mutex_destroy+0x49/0x50 <4> [341.846980] ---[ end trace ba94ca8952ba970e ]--- <7> [341.866547] [drm:intel_dp_detect [i915]] MST support? port A: no, sink: no, modparam: yes <7> [341.890480] [drm:drm_add_display_info] non_desktop set to 0 <7> [341.890530] [drm:drm_add_edid_modes] ELD: no CEA Extension found <7> [341.890537] [drm:drm_add_display_info] non_desktop set to 0 <7> [341.890578] [drm:drm_helper_probe_single_connector_modes] [CONNECTOR:86:eDP-1] probed modes : <7> [341.890589] [drm:drm_mode_debug_printmodeline] Modeline "3200x1800": 60 373250 3200 3248 3280 3360 1800 1803 1808 1852 0x48 0xa <7> [341.890602] [drm:drm_mode_debug_printmodeline] Modeline "3200x1800": 48 298600 3200 3248 3280 3360 1800 1803 1808 1852 0x40 0xa <4> [341.890628] general protection fault: 0000 [#1] PREEMPT SMP PTI <4> [341.890636] CPU: 0 PID: 508 Comm: kworker/0:4 Tainted: G U W 5.2.0-rc2-CI-CI_DRM_6175+ #1 <4> [341.890646] Hardware name: Dell Inc. XPS 13 9360/0823VW, BIOS 2.9.0 07/09/2018 <4> [341.890655] Workqueue: events output_poll_execute <4> [341.890663] RIP: 0010:drm_setup_crtcs+0x13e/0xbe0 <4> [341.890669] Code: 00 41 8b 44 24 58 85 c0 0f 8e f9 01 00 00 44 8b 6c 24 20 44 8b 74 24 28 31 db 31 ed 49 8b 44 24 60 48 63 d5 44 89 ee 83 c5 01 <48> 8b 04 d0 44 89 f2 48 8b 38 48 8b 87 88 01 00 00 48 8b 40 20 e8 <4> [341.890686] RSP: 0018:ffffc9000033fd40 EFLAGS: 00010202 <4> [341.890692] RAX: 6b6b6b6b6b6b6b6b RBX: 0000000000000002 RCX: 0000000000000000 <4> [341.890700] RDX: 0000000000000001 RSI: 0000000000000c80 RDI: 00000000ffffffff <4> [341.890707] RBP: 0000000000000002 R08: 0000000000000000 R09: 0000000000000000 <4> [341.890715] R10: 0000000000000c80 R11: 0000000000000000 R12: ffff888267599fe8 <4> [341.890722] R13: 0000000000000c80 R14: 0000000000000708 R15: 0000000000000007 <4> [341.890730] FS: 0000000000000000(0000) GS:ffff888276200000(0000) knlGS:0000000000000000 <4> [341.890739] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4> [341.890745] CR2: 000055a4e064f4a0 CR3: 000000026d234003 CR4: 00000000003606f0 <4> [341.890752] Call Trace: <4> [341.890760] drm_fb_helper_hotplug_event.part.24+0x89/0xb0 <4> [341.890768] drm_kms_helper_hotplug_event+0x21/0x30 <4> [341.890774] output_poll_execute+0x9d/0x1a0 <4> [341.890782] process_one_work+0x245/0x610 <4> [341.890790] worker_thread+0x37/0x380 <4> [341.890796] ? process_one_work+0x610/0x610 <4> [341.890802] kthread+0x119/0x130 <4> [341.890808] ? kthread_park+0x80/0x80 <4> [341.890815] ret_from_fork+0x3a/0x50 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109964 Signed-off-by: Chris Wilson Reviewed-by: Imre Deak Link: https://patchwork.freedesktop.org/patch/msgid/20190603135910.15979-2-chris@chris-wilson.co.uk Signed-off-by: Sasha Levin commit 453bcdd2432bf6923a535b38abf7a7c6ee77d94d Author: Chao Yu Date: Sat May 25 23:07:25 2019 +0800 f2fs: fix to do sanity check on segment bitmap of LFS curseg [ Upstream commit c854f4d681365498f53ba07843a16423625aa7e9 ] As Jungyeon Reported in bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203233 - Reproduces gcc poc_13.c ./run.sh f2fs - Kernel messages F2FS-fs (sdb): Bitmap was wrongly set, blk:4608 kernel BUG at fs/f2fs/segment.c:2133! RIP: 0010:update_sit_entry+0x35d/0x3e0 Call Trace: f2fs_allocate_data_block+0x16c/0x5a0 do_write_page+0x57/0x100 f2fs_do_write_node_page+0x33/0xa0 __write_node_page+0x270/0x4e0 f2fs_sync_node_pages+0x5df/0x670 f2fs_write_checkpoint+0x364/0x13a0 f2fs_sync_fs+0xa3/0x130 f2fs_do_sync_file+0x1a6/0x810 do_fsync+0x33/0x60 __x64_sys_fsync+0xb/0x10 do_syscall_64+0x43/0x110 entry_SYSCALL_64_after_hwframe+0x44/0xa9 The testcase fails because that, in fuzzed image, current segment was allocated with LFS type, its .next_blkoff should point to an unused block address, but actually, its bitmap shows it's not. So during allocation, f2fs crash when setting bitmap. Introducing sanity_check_curseg() to check such inconsistence of current in-used segment. Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit d331d4b99fb610da4a1f801e6e05985fa132d383 Author: Michal Suchanek Date: Mon Sep 9 22:44:51 2019 +0200 net/ibmvnic: Fix missing { in __ibmvnic_reset [ Upstream commit c8dc55956b09b53ccffceb6e3146981210e27821 ] Commit 1c2977c09499 ("net/ibmvnic: free reset work of removed device from queue") adds a } without corresponding { causing build break. Fixes: 1c2977c09499 ("net/ibmvnic: free reset work of removed device from queue") Signed-off-by: Michal Suchanek Reviewed-by: Tyrel Datwyler Reviewed-by: Juliet Kim Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 8defaa56897e201426af10265d3edb4969b66bba Author: Mikulas Patocka Date: Mon Aug 26 02:41:17 2019 -0400 dm zoned: fix invalid memory access [ Upstream commit 0c8e9c2d668278652af028c3cc068c65f66342f4 ] Commit 75d66ffb48efb30f2dd42f041ba8b39c5b2bd115 ("dm zoned: properly handle backing device failure") triggers a coverity warning: *** CID 1452808: Memory - illegal accesses (USE_AFTER_FREE) /drivers/md/dm-zoned-target.c: 137 in dmz_submit_bio() 131 clone->bi_private = bioctx; 132 133 bio_advance(bio, clone->bi_iter.bi_size); 134 135 refcount_inc(&bioctx->ref); 136 generic_make_request(clone); >>> CID 1452808: Memory - illegal accesses (USE_AFTER_FREE) >>> Dereferencing freed pointer "clone". 137 if (clone->bi_status == BLK_STS_IOERR) 138 return -EIO; 139 140 if (bio_op(bio) == REQ_OP_WRITE && dmz_is_seq(zone)) 141 zone->wp_block += nr_blocks; 142 The "clone" bio may be processed and freed before the check "clone->bi_status == BLK_STS_IOERR" - so this check can access invalid memory. Fixes: 75d66ffb48efb3 ("dm zoned: properly handle backing device failure") Cc: stable@vger.kernel.org Signed-off-by: Mikulas Patocka Reviewed-by: Damien Le Moal Signed-off-by: Mike Snitzer Signed-off-by: Sasha Levin commit bca9bfa41e3fffcf4ef5fb196e5ee2d4749c01e3 Author: Chao Yu Date: Fri Aug 2 18:15:48 2019 +0800 Revert "f2fs: avoid out-of-range memory access" [ Upstream commit a37d0862d17411edb67677a580a6f505ec2225f6 ] As Pavel Machek reported: "We normally use -EUCLEAN to signal filesystem corruption. Plus, it is good idea to report it to the syslog and mark filesystem as "needing fsck" if filesystem can do that." Still we need improve the original patch with: - use unlikely keyword - add message print - return EUCLEAN However, after rethink this patch, I don't think we should add such condition check here as below reasons: - We have already checked the field in f2fs_sanity_check_ckpt(), - If there is fs corrupt or security vulnerability, there is nothing to guarantee the field is integrated after the check, unless we do the check before each of its use, however no filesystem does that. - We only have similar check for bitmap, which was added due to there is bitmap corruption happened on f2fs' runtime in product. - There are so many key fields in SB/CP/NAT did have such check after f2fs_sanity_check_{sb,cp,..}. So I propose to revert this unneeded check. This reverts commit 56f3ce675103e3fb9e631cfb4131fc768bc23e9a. Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 47af17950b03b748eea68ad7613f8d8b4c688d45 Author: Josh Poimboeuf Date: Thu Aug 29 18:28:49 2019 -0500 objtool: Clobber user CFLAGS variable commit f73b3cc39c84220e6dccd463b5c8279b03514646 upstream. If the build user has the CFLAGS variable set in their environment, objtool blindly appends to it, which can cause unexpected behavior. Clobber CFLAGS to ensure consistent objtool compilation behavior. Reported-by: Valdis Kletnieks Tested-by: Valdis Kletnieks Signed-off-by: Josh Poimboeuf Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Link: https://lkml.kernel.org/r/83a276df209962e6058fcb6c615eef9d401c21bc.1567121311.git.jpoimboe@redhat.com Signed-off-by: Ingo Molnar CC: Nathan Chancellor Signed-off-by: Greg Kroah-Hartman commit 0f5df0b76e4fff26da409483297d6ac95a2032ca Author: Heikki Krogerus Date: Fri Sep 20 13:02:33 2019 +0300 platform/x86: i2c-multi-instantiate: Derive the device name from parent commit 24a8d78a9affb63e5ced313ccde6888fe96edc6e upstream. When naming the new devices, instead of using the ACPI ID in the name as base, using the parent device's name. That makes it possible to support multiple multi-instance i2c devices of the same type in the same system. This fixes an issue seen on some Intel Kaby Lake based boards: sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:15.0/i2c_designware.0/i2c-0/i2c-INT3515-tps6598x.0' Fixes: 2336dfadfb1e ("platform/x86: i2c-multi-instantiate: Allow to have same slaves") Cc: stable@vger.kernel.org Signed-off-by: Heikki Krogerus Reviewed-by: Hans de Goede Signed-off-by: Andy Shevchenko Signed-off-by: Greg Kroah-Hartman commit 811fc53c37be77bfa8272fea12cb519fa8f792f8 Author: Takashi Iwai Date: Fri Sep 20 09:30:40 2019 +0200 ALSA: hda - Apply AMD controller workaround for Raven platform commit d2c63b7dfd06788a466d5ec8a850491f084c5fc2 upstream. It's reported that the garbled sound on HP Envy x360 13z-ag000 (Ryzen Laptop) is fixed by the same workaround applied to other AMD chips. Update the driver_data entry for Raven (1022:15e3) to use the newly introduced preset, AZX_DCAPS_PRESET_AMD_SB. Since it already contains AZX_DCAPS_PM_RUNTIME, we can drop that bit, too. Reported-and-tested-by: Dennis Padiernos Cc: Link: https://lore.kernel.org/r/20190920073040.31764-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit b5215e9269c75ead4be821021db3853923f4b168 Author: Shih-Yuan Lee (FourDollars) Date: Fri Sep 20 21:40:53 2019 +0800 ALSA: hda - Add laptop imic fixup for ASUS M9V laptop commit 7b485d175631be676424aedb8cd2f66d0c93da78 upstream. The same fixup to enable laptop imic is needed for ASUS M9V with AD1986A codec like another HP machine. Signed-off-by: Shih-Yuan Lee (FourDollars) Cc: Link: https://lore.kernel.org/r/20190920134052.GA8035@localhost Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit d51c3b844afb920f82af2c1c62f09c1671bd35e0 Author: Takashi Sakamoto Date: Mon Sep 16 19:18:51 2019 +0900 ALSA: dice: fix wrong packet parameter for Alesis iO26 commit 3a9236e97207f2469254b4098995159b80174d95 upstream. At higher sampling rate (e.g. 192.0 kHz), Alesis iO26 transfers 4 data channels per data block in CIP. Both iO14 and iO26 have the same contents in their configuration ROM. For this reason, ALSA Dice driver attempts to distinguish them according to the value of TX0_AUDIO register at probe callback. Although the way is valid at lower and middle sampling rate, it's lastly invalid at higher sampling rate because because the two models returns the same value for read transaction to the register. In the most cases, users just plug-in the device and ALSA dice driver detects it. In the case, the device runs at lower sampling rate and the driver detects expectedly. For this reason, this commit leaves the way to detect as is. Fixes: 28b208f600a3 ("ALSA: dice: add parameters of stream formats for models produced by Alesis") Cc: # v4.18+ Signed-off-by: Takashi Sakamoto Link: https://lore.kernel.org/r/20190916101851.30409-1-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit bf4d30e9950e580e6f170a9f433fdc1c14cc2405 Author: Jussi Laako Date: Tue Sep 24 10:11:43 2019 +0300 ALSA: usb-audio: Add DSD support for EVGA NU Audio commit f41f900568d9ffd896cc941db7021eb14bd55910 upstream. EVGA NU Audio is actually a USB audio device on a PCIexpress card, with it's own USB controller. It supports both PCM and DSD. Signed-off-by: Jussi Laako Cc: Link: https://lore.kernel.org/r/20190924071143.30911-1-jussi@sonarnerd.net Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 284a3048889165122a1ff7fac4cf70d7b95c3953 Author: Ilya Pshonkin Date: Tue Sep 17 10:49:34 2019 +0300 ALSA: usb-audio: Add Hiby device family to quirks for native DSD support commit 029d2c0fd61eac74700fb4ffff36fc63bfff7e5e upstream. This patch adds quirk VID ID for Hiby portable players family with native DSD playback support. Signed-off-by: Ilya Pshonkin Cc: Link: https://lore.kernel.org/r/20190917074937.157802-1-ilya.pshonkin@netforce.ua Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit d17860e1e8944fd89a6645d2ebd4654e62ab9d9c Author: Vitaly Wool Date: Mon Sep 23 15:32:56 2019 -0700 Revert "mm/z3fold.c: fix race between migration and destruction" commit 6e73fd25e2c7510b7dfadbaf701f31d4bff9c75b upstream. With the original commit applied, z3fold_zpool_destroy() may get blocked on wait_event() for indefinite time. Revert this commit for the time being to get rid of this problem since the issue the original commit addresses is less severe. Link: http://lkml.kernel.org/r/20190910123142.7a9c8d2de4d0acbc0977c602@gmail.com Fixes: d776aaa9895eb6eb77 ("mm/z3fold.c: fix race between migration and destruction") Reported-by: Agustín Dall'Alba Signed-off-by: Vitaly Wool Cc: Vlastimil Babka Cc: Vitaly Wool Cc: Shakeel Butt Cc: Jonathan Adams Cc: Henry Burns Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 2de3de21bc8a52d5741e01c2461577195b0a57bd Author: Benjamin Tissoires Date: Tue Aug 13 15:38:06 2019 +0200 Revert "HID: logitech-hidpp: add USB PID for a few more supported mice" commit addf3382c47c033e579c9c88f18e36c4e75d806a upstream. This partially reverts commit 27fc32fd9417968a459d43d9a7c50fd423d53eb9. It turns out that the G502 has some issues with hid-logitech-hidpp: when plugging it in, the driver tries to contact it but it fails. So the driver bails out leaving only the mouse event node available. This timeout is problematic as it introduce a delay in the boot, and having only the mouse event node means that the hardware macros keys can not be relayed to the userspace. Filipe and I just gave a shot at the following devices: G403 Wireless (0xC082) G703 (0xC087) G703 Hero (0xC090) G903 (0xC086) G903 Hero (0xC091) G Pro (0xC088) Reverting the devices we are not sure that works flawlessly. Reviewed-by: Filipe Laíns Signed-off-by: Benjamin Tissoires Signed-off-by: Jeremy Cline Signed-off-by: Greg Kroah-Hartman commit 807370d0241383efb3ba2527c588201ff6f78aba Author: Peng Fan Date: Mon Jul 15 02:55:43 2019 +0000 clk: imx: imx8mm: fix audio pll setting commit 053a4ffe298836bb973d2cba59f82fff60c7db5b upstream. The AUDIO PLL max support 650M, so the original clk settings violate spec. This patch makes the output 786432000 -> 393216000, and 722534400 -> 361267200 to aligned with NXP vendor kernel without any impact on audio functionality and go within 650MHz PLL limit. Cc: Fixes: ba5625c3e272 ("clk: imx: Add clock driver support for imx8mm") Signed-off-by: Peng Fan Acked-by: Abel Vesa Signed-off-by: Shawn Guo Signed-off-by: Greg Kroah-Hartman commit bdbf837b89a9f7fd88537a15bccab7025bdde8f0 Author: Gustavo A. R. Silva Date: Mon Sep 9 00:29:52 2019 -0500 crypto: talitos - fix missing break in switch statement commit 5fc194ea6d34dfad9833d3043ce41d6c52aff39a upstream. Add missing break statement in order to prevent the code from falling through to case CRYPTO_ALG_TYPE_AHASH. Fixes: aeb4c132f33d ("crypto: talitos - Convert to new AEAD interface") Cc: stable@vger.kernel.org Reported-by: kbuild test robot Signed-off-by: Gustavo A. R. Silva Reviewed-by: Christophe Leroy Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit a1e67dae1599868978846d54464c5e31f102da97 Author: Tokunori Ikegami Date: Tue Aug 6 04:03:18 2019 +0900 mtd: cfi_cmdset_0002: Use chip_good() to retry in do_write_oneword() commit 37c673ade35c707d50583b5b25091ff8ebdeafd7 upstream. As reported by the OpenWRT team, write requests sometimes fail on some platforms. Currently to check the state chip_ready() is used correctly as described by the flash memory S29GL256P11TFI01 datasheet. Also chip_good() is used to check if the write is succeeded and it was implemented by the commit fb4a90bfcd6d8 ("[MTD] CFI-0002 - Improve error checking"). But actually the write failure is caused on some platforms and also it can be fixed by using chip_good() to check the state and retry instead. Also it seems that it is caused after repeated about 1,000 times to retry the write one word with the reset command. By using chip_good() to check the state to be done it can be reduced the retry with reset. It is depended on the actual flash chip behavior so the root cause is unknown. Cc: Chris Packham Cc: Joakim Tjernlund Cc: linux-mtd@lists.infradead.org Cc: stable@vger.kernel.org Reported-by: Fabio Bettoni Signed-off-by: Felix Fietkau Signed-off-by: Hauke Mehrtens Signed-off-by: Tokunori Ikegami [vigneshr@ti.com: Fix a checkpatch warning] Signed-off-by: Vignesh Raghavendra Signed-off-by: Greg Kroah-Hartman commit 6c6d88dc737a797b5c4ac9ba9686d3b6ca7d568e Author: Sebastian Parschauer Date: Mon Sep 2 12:39:30 2019 +0200 HID: Add quirk for HP X500 PIXART OEM mouse commit 2acf40f0454d41b8d51c95d317283c20c931164d upstream. The PixArt OEM mice are known for disconnecting every minute in runlevel 1 or 3 if they are not always polled. So add quirk ALWAYS_POLL for this one as well. Ville Viinikka (viinikv) reported and tested the quirk. Link: https://github.com/sriemer/fix-linux-mouse issue 15 Signed-off-by: Sebastian Parschauer CC: stable@vger.kernel.org # v4.16+ Signed-off-by: Benjamin Tissoires Signed-off-by: Greg Kroah-Hartman commit af5676bf7d891da6426e76f6fceb1f4838db9983 Author: Alan Stern Date: Wed Aug 21 13:27:12 2019 -0400 HID: hidraw: Fix invalid read in hidraw_ioctl commit 416dacb819f59180e4d86a5550052033ebb6d72c upstream. The syzbot fuzzer has reported a pair of problems in the hidraw_ioctl() function: slab-out-of-bounds read and use-after-free read. An example of the first: BUG: KASAN: slab-out-of-bounds in strlen+0x79/0x90 lib/string.c:525 Read of size 1 at addr ffff8881c8035f38 by task syz-executor.4/2833 CPU: 1 PID: 2833 Comm: syz-executor.4 Not tainted 5.3.0-rc2+ #1 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0xca/0x13e lib/dump_stack.c:113 print_address_description+0x6a/0x32c mm/kasan/report.c:351 __kasan_report.cold+0x1a/0x33 mm/kasan/report.c:482 kasan_report+0xe/0x12 mm/kasan/common.c:612 strlen+0x79/0x90 lib/string.c:525 strlen include/linux/string.h:281 [inline] hidraw_ioctl+0x245/0xae0 drivers/hid/hidraw.c:446 vfs_ioctl fs/ioctl.c:46 [inline] file_ioctl fs/ioctl.c:509 [inline] do_vfs_ioctl+0xd2d/0x1330 fs/ioctl.c:696 ksys_ioctl+0x9b/0xc0 fs/ioctl.c:713 __do_sys_ioctl fs/ioctl.c:720 [inline] __se_sys_ioctl fs/ioctl.c:718 [inline] __x64_sys_ioctl+0x6f/0xb0 fs/ioctl.c:718 do_syscall_64+0xb7/0x580 arch/x86/entry/common.c:296 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x459829 Code: fd b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 cb b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:00007f7a68f6dc78 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000459829 RDX: 0000000000000000 RSI: 0000000080404805 RDI: 0000000000000004 RBP: 000000000075bf20 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f7a68f6e6d4 R13: 00000000004c21de R14: 00000000004d5620 R15: 00000000ffffffff The two problems have the same cause: hidraw_ioctl() fails to test whether the device has been removed. This patch adds the missing test. Reported-and-tested-by: syzbot+5a6c4ec678a0c6ee84ba@syzkaller.appspotmail.com Signed-off-by: Alan Stern CC: Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 8d88e0d1b3e6902f4cf555ba4bbb05149ad95079 Author: Hans de Goede Date: Sun Aug 25 17:35:42 2019 +0200 HID: logitech-dj: Fix crash when initial logi_dj_recv_query_paired_devices fails commit 8ccff2843fb4e6d9d26e5ae9ffe9840b38b92638 upstream. Before this commit dj_probe would exit with an error if the initial logi_dj_recv_query_paired_devices fails. The initial call may fail when the receiver is connected through a kvm and the focus is away. When the call fails this causes 2 problems: 1) dj_probe calls logi_dj_recv_query_paired_devices after calling hid_device_io_start() so a HID report may have been received in between and our delayedwork_callback may be running. It seems that the initial logi_dj_recv_query_paired_devices failure happening with some KVMs triggers this exact scenario, causing the work-queue to run on free-ed memory, leading to: BUG: unable to handle page fault for address: 0000000000001e88 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] SMP PTI CPU: 3 PID: 257 Comm: kworker/3:3 Tainted: G OE 5.3.0-rc5+ #100 Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./B150M Pro4S/D3, BIOS P7.10 12/06/2016 Workqueue: events 0xffffffffc02ba200 RIP: 0010:0xffffffffc02ba1bd Code: e8 e8 13 00 d8 48 89 c5 48 85 c0 74 4c 48 8b 7b 10 48 89 ea b9 07 00 00 00 41 b9 09 00 00 00 41 b8 01 00 00 00 be 10 00 00 00 <48> 8b 87 88 1e 00 00 48 8b 40 40 e8 b3 6b b4 d8 48 89 ef 41 89 c4 RSP: 0018:ffffb760c046bdb8 EFLAGS: 00010286 RAX: ffff935038ea4550 RBX: ffff935046778000 RCX: 0000000000000007 RDX: ffff935038ea4550 RSI: 0000000000000010 RDI: 0000000000000000 RBP: ffff935038ea4550 R08: 0000000000000001 R09: 0000000000000009 R10: 000000000000e011 R11: 0000000000000001 R12: ffff9350467780e8 R13: ffff935046778000 R14: 0000000000000000 R15: ffff935046778070 FS: 0000000000000000(0000) GS:ffff935054e00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000001e88 CR3: 000000075a612002 CR4: 00000000003606e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: 0xffffffffc02ba2f7 ? process_one_work+0x1b1/0x560 process_one_work+0x234/0x560 worker_thread+0x50/0x3b0 kthread+0x10a/0x140 ? process_one_work+0x560/0x560 ? kthread_park+0x80/0x80 ret_from_fork+0x3a/0x50 Modules linked in: vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) bnep vfat fat btusb btrtl btbcm btintel bluetooth intel_rapl_msr ecdh_generic rfkill ecc snd_usb_audio snd_usbmidi_lib intel_rapl_common snd_rawmidi mc x86_pkg_temp_thermal intel_powerclamp coretemp iTCO_wdt iTCO_vendor_support mei_wdt mei_hdcp ppdev kvm_intel kvm irqbypass crct10dif_pclmul crc32_generic crc32_pclmul snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio ghash_clmulni_intel intel_cstate snd_hda_intel snd_hda_codec intel_uncore snd_hda_core snd_hwdep intel_rapl_perf snd_seq snd_seq_device snd_pcm snd_timer intel_wmi_thunderbolt snd e1000e soundcore mxm_wmi i2c_i801 bfq mei_me mei intel_pch_thermal parport_pc parport acpi_pad binfmt_misc hid_lg_g15(E) hid_logitech_dj(E) i915 crc32c_intel i2c_algo_bit drm_kms_helper nvme nvme_core drm wmi video uas usb_storage i2c_dev CR2: 0000000000001e88 ---[ end trace 1d3f8afdcfcbd842 ]--- 2) Even if we were to fix 1. by making sure the work is stopped before failing probe, failing probe is the wrong thing to do, we have logi_dj_recv_queue_unknown_work to deal with the initial logi_dj_recv_query_paired_devices failure. Rather then error-ing out of the probe, causing the receiver to not work at all we should rely on this, so that the attached devices will get properly enumerated once the KVM focus is switched back. Cc: stable@vger.kernel.org Fixes: 74808f9115ce ("HID: logitech-dj: add support for non unifying receivers") Signed-off-by: Hans de Goede Signed-off-by: Benjamin Tissoires Signed-off-by: Greg Kroah-Hartman commit 55c2b2ac27060ffa05c8f4bdd0ee64460bb479de Author: Alan Stern Date: Tue Aug 20 16:00:21 2019 -0400 HID: logitech: Fix general protection fault caused by Logitech driver commit 5f9242775bb61f390f0885f23fc16397262c7538 upstream. The syzbot fuzzer found a general protection fault in the HID subsystem: kasan: CONFIG_KASAN_INLINE enabled kasan: GPF could be caused by NULL-ptr deref or user memory access general protection fault: 0000 [#1] SMP KASAN CPU: 0 PID: 3715 Comm: syz-executor.3 Not tainted 5.2.0-rc6+ #15 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:__pm_runtime_resume+0x49/0x180 drivers/base/power/runtime.c:1069 Code: ed 74 d5 fe 45 85 ed 0f 85 9a 00 00 00 e8 6f 73 d5 fe 48 8d bd c1 02 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 48 89 fa 83 e2 07 38 d0 7f 08 84 c0 0f 85 fe 00 00 00 RSP: 0018:ffff8881d99d78e0 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: 0000000000000020 RCX: ffffc90003f3f000 RDX: 0000000416d8686d RSI: ffffffff82676841 RDI: 00000020b6c3436a RBP: 00000020b6c340a9 R08: ffff8881c6d64800 R09: fffffbfff0e84c25 R10: ffff8881d99d7940 R11: ffffffff87426127 R12: 0000000000000004 R13: 0000000000000000 R14: ffff8881d9b94000 R15: ffffffff897f9048 FS: 00007f047f542700(0000) GS:ffff8881db200000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b30f21000 CR3: 00000001ca032000 CR4: 00000000001406f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: pm_runtime_get_sync include/linux/pm_runtime.h:226 [inline] usb_autopm_get_interface+0x1b/0x50 drivers/usb/core/driver.c:1707 usbhid_power+0x7c/0xe0 drivers/hid/usbhid/hid-core.c:1234 hid_hw_power include/linux/hid.h:1038 [inline] hidraw_open+0x20d/0x740 drivers/hid/hidraw.c:282 chrdev_open+0x219/0x5c0 fs/char_dev.c:413 do_dentry_open+0x497/0x1040 fs/open.c:778 do_last fs/namei.c:3416 [inline] path_openat+0x1430/0x3ff0 fs/namei.c:3533 do_filp_open+0x1a1/0x280 fs/namei.c:3563 do_sys_open+0x3c0/0x580 fs/open.c:1070 do_syscall_64+0xb7/0x560 arch/x86/entry/common.c:301 entry_SYSCALL_64_after_hwframe+0x49/0xbe It turns out the fault was caused by a bug in the HID Logitech driver, which violates the requirement that every pathway calling hid_hw_start() must also call hid_hw_stop(). This patch fixes the bug by making sure the requirement is met. Reported-and-tested-by: syzbot+3cbe5cd105d2ad56a1df@syzkaller.appspotmail.com Signed-off-by: Alan Stern CC: Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit a069e96b5280177ee73732f42aabfddb1483dd45 Author: Roderick Colenbrander Date: Wed Sep 4 14:22:11 2019 -0700 HID: sony: Fix memory corruption issue on cleanup. commit 2bcdacb70327013ca2066bfcf2af1009eff01f1d upstream. The sony driver is not properly cleaning up from potential failures in sony_input_configured. Currently it calls hid_hw_stop, while hid_connect is still running. This is not a good idea, instead hid_hw_stop should be moved to sony_probe. Similar changes were recently made to Logitech drivers, which were also doing improper cleanup. Signed-off-by: Roderick Colenbrander CC: stable@vger.kernel.org Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 5f2ba05924ca5c4ff668e7404db281779f2633de Author: Alan Stern Date: Wed Sep 4 11:54:20 2019 -0400 HID: prodikeys: Fix general protection fault during probe commit 98375b86c79137416e9fd354177b85e768c16e56 upstream. The syzbot fuzzer provoked a general protection fault in the hid-prodikeys driver: kasan: CONFIG_KASAN_INLINE enabled kasan: GPF could be caused by NULL-ptr deref or user memory access general protection fault: 0000 [#1] SMP KASAN CPU: 0 PID: 12 Comm: kworker/0:1 Not tainted 5.3.0-rc5+ #28 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: usb_hub_wq hub_event RIP: 0010:pcmidi_submit_output_report drivers/hid/hid-prodikeys.c:300 [inline] RIP: 0010:pcmidi_set_operational drivers/hid/hid-prodikeys.c:558 [inline] RIP: 0010:pcmidi_snd_initialise drivers/hid/hid-prodikeys.c:686 [inline] RIP: 0010:pk_probe+0xb51/0xfd0 drivers/hid/hid-prodikeys.c:836 Code: 0f 85 50 04 00 00 48 8b 04 24 4c 89 7d 10 48 8b 58 08 e8 b2 53 e4 fc 48 8b 54 24 20 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f 85 13 04 00 00 48 ba 00 00 00 00 00 fc ff df 49 8b The problem is caused by the fact that pcmidi_get_output_report() will return an error if the HID device doesn't provide the right sort of output report, but pcmidi_set_operational() doesn't bother to check the return code and assumes the function call always succeeds. This patch adds the missing check and aborts the probe operation if necessary. Reported-and-tested-by: syzbot+1088533649dafa1c9004@syzkaller.appspotmail.com Signed-off-by: Alan Stern CC: Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit df3cc96b204964b39a9feda88f63ef4ceeecf8a8 Author: David S. Miller Date: Mon Jul 22 20:44:48 2019 -0700 Revert "net: hns: fix LED configuration for marvell phy" commit b3e487c0cf425369a48049251af75593a5652dc1 upstream. This reverts commit f4e5f775db5a4631300dccd0de5eafb50a77c131. Andrew Lunn says this should be handled another way. Signed-off-by: David S. Miller Cc: Yonglong Liu Signed-off-by: Greg Kroah-Hartman commit 3349449ae7305513694d5b5bda4434daae57708a Author: Nick Desaulniers Date: Mon Jul 22 15:31:05 2019 -0700 drm/amd/display: readd -msse2 to prevent Clang from emitting libcalls to undefined SW FP routines [ Upstream commit 0f0727d971f6fdf8f1077180d495ddb9928f0c8b ] arch/x86/Makefile disables SSE and SSE2 for the whole kernel. The AMDGPU drivers modified in this patch re-enable SSE but not SSE2. Turn on SSE2 to support emitting double precision floating point instructions rather than calls to non-existent (usually available from gcc_s or compiler_rt) floating point helper routines for Clang. This was originally landed in: commit 10117450735c ("drm/amd/display: add -msse2 to prevent Clang from emitting libcalls to undefined SW FP routines") but reverted in: commit 193392ed9f69 ("Revert "drm/amd/display: add -msse2 to prevent Clang from emitting libcalls to undefined SW FP routines"") due to bugreports from GCC builds. Add guards to only do so for Clang. Link: https://bugs.freedesktop.org/show_bug.cgi?id=109487 Link: https://github.com/ClangBuiltLinux/linux/issues/327 Suggested-by: Sedat Dilek Suggested-by: Sami Tolvanen Signed-off-by: Nick Desaulniers Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit be3b5f44206e05c06702de30e0d0565377e0eb40 Author: Greg Kurz Date: Wed Sep 11 17:52:18 2019 +0200 powerpc/xive: Fix bogus error code returned by OPAL commit 6ccb4ac2bf8a35c694ead92f8ac5530a16e8f2c8 upstream. There's a bug in skiboot that causes the OPAL_XIVE_ALLOCATE_IRQ call to return the 32-bit value 0xffffffff when OPAL has run out of IRQs. Unfortunatelty, OPAL return values are signed 64-bit entities and errors are supposed to be negative. If that happens, the linux code confusingly treats 0xffffffff as a valid IRQ number and panics at some point. A fix was recently merged in skiboot: e97391ae2bb5 ("xive: fix return value of opal_xive_allocate_irq()") but we need a workaround anyway to support older skiboots already in the field. Internally convert 0xffffffff to OPAL_RESOURCE which is the usual error returned upon resource exhaustion. Cc: stable@vger.kernel.org # v4.12+ Signed-off-by: Greg Kurz Reviewed-by: Cédric Le Goater Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/156821713818.1985334.14123187368108582810.stgit@bahia.lan Signed-off-by: Greg Kroah-Hartman commit 606f7f9fc442bfe71518e807c1d09062d3103453 Author: Nicholas Kazlauskas Date: Wed Jul 31 10:33:54 2019 -0400 drm/amd/display: Don't replace the dc_state for fast updates commit bd200d190f45b62c006d1ad0a63eeffd87db7a47 upstream. [Why] DRM private objects have no hw_done/flip_done fencing mechanism on their own and cannot be used to sequence commits accordingly. When issuing commits that don't touch the same set of hardware resources like page-flips on different CRTCs we can run into the issue below because of this: 1. Client requests non-blocking Commit #1, has a new dc_state #1, state is swapped, commit tail is deferred to work queue 2. Client requests non-blocking Commit #2, has a new dc_state #2, state is swapped, commit tail is deferred to work queue 3. Commit #2 work starts, commit tail finishes, atomic state is cleared, dc_state #1 is freed 4. Commit #1 work starts, commit tail encounters null pointer deref on dc_state #1 In order to change the DC state as in the private object we need to ensure that we wait for all outstanding commits to finish and that any other pending commits must wait for the current one to finish as well. We do this for MEDIUM and FULL updates. But not for FAST updates, nor would we want to since it would cause stuttering from the delays. FAST updates that go through dm_determine_update_type_for_commit always create a new dc_state and lock the DRM private object if there are any changed planes. We need the old state to validate, but we don't actually need the new state here. [How] If the commit isn't a full update then the use after free can be resolved by simply discarding the new state entirely and retaining the existing one instead. With this change the sequence above can be reexamined. Commit #2 will still free Commit #1's reference, but before this happens we actually added an additional reference as part of Commit #2. If an update comes in during this that needs to change the dc_state it will need to wait on Commit #1 and Commit #2 to finish. Then it'll swap the state, finish the work in commit tail and drop the last reference on Commit #2's dc_state. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204181 Fixes: 004b3938e637 ("drm/amd/display: Check scaling info when determing update type") Signed-off-by: Nicholas Kazlauskas Acked-by: Alex Deucher Reviewed-by: David Francis Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 0365d15f565ae0c3c43f7a667a4fc4b31f2d27ea Author: Nicholas Kazlauskas Date: Wed Jul 31 09:45:16 2019 -0400 drm/amd/display: Skip determining update type for async updates commit 43d10d30df156f7834fa91aecb69614fefc8bb0a upstream. [Why] By passing through the dm_determine_update_type_for_commit for atomic commits that can be done asynchronously we are incurring a performance penalty by locking access to the global private object and holding that access until the end of the programming sequence. This is also allocating a new large dc_state on every access in addition to retaining all the references on each stream and plane until the end of the programming sequence. [How] Shift the determination for async update before validation. Return early if it's going to be an async update. Signed-off-by: Nicholas Kazlauskas Acked-by: Alex Deucher Reviewed-by: David Francis Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 891eae79f7a53d95165d51de60ad3aab46fdc779 Author: Nicholas Kazlauskas Date: Mon Jun 10 08:47:57 2019 -0400 drm/amd/display: Allow cursor async updates for framebuffer swaps commit e16e37efb4c9eb7bcb9dab756c975040c5257e98 upstream. [Why] We previously allowed framebuffer swaps as async updates for cursor planes but had to disable them due to a bug in DRM with async update handling and incorrect ref counting. The check to block framebuffer swaps has been added to DRM for a while now, so this check is redundant. The real fix that allows this to properly in DRM has also finally been merged and is getting backported into stable branches, so dropping this now seems to be the right time to do so. [How] Drop the redundant check for old_fb != new_fb. With the proper fix in DRM, this should also fix some cursor stuttering issues with xf86-video-amdgpu since it double buffers the cursor. IGT tests that swap framebuffers (-varying-size for example) should also pass again. Signed-off-by: Nicholas Kazlauskas Acked-by: Alex Deucher Reviewed-by: David Francis Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit f6faeecb3659e2a02e924389ed84f44030addef6 Author: Juliet Kim Date: Thu Sep 5 17:30:01 2019 -0400 net/ibmvnic: free reset work of removed device from queue [ Upstream commit 1c2977c094998de032fee6e898c88b4a05483d08 ] Commit 36f1031c51a2 ("ibmvnic: Do not process reset during or after device removal") made the change to exit reset if the driver has been removed, but does not free reset work items of the adapter from queue. Ensure all reset work items are freed when breaking out of the loop early. Fixes: 36f1031c51a2 ("ibmnvic: Do not process reset during or after device removal”) Signed-off-by: Juliet Kim Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit cdc112b9cb64548ac0f5dbbda6a2546254c8067f Author: Bjorn Andersson Date: Mon Aug 5 17:42:56 2019 -0700 phy: qcom-qmp: Correct ready status, again [ Upstream commit 14ced7e3a1ae9bed7051df3718c8c7b583854a5c ] Despite extensive testing of commit 885bd765963b ("phy: qcom-qmp: Correct READY_STATUS poll break condition") I failed to conclude that the PHYSTATUS bit of the PCS_STATUS register used in PCIe and USB3 falls as the PHY gets ready. Similar to the prior bug with UFS the code will generally get past the check before the transition and thereby "succeed". Correct the name of the register used PCIe and USB3 PHYs, replace mask_pcs_ready with a constant expression depending on the type of the PHY and check for the appropriate ready state. Cc: stable@vger.kernel.org Cc: Vivek Gautam Cc: Evan Green Cc: Niklas Cassel Reported-by: Marc Gonzalez Fixes: 885bd765963b ("phy: qcom-qmp: Correct READY_STATUS poll break condition") Signed-off-by: Bjorn Andersson Tested-by: Marc Gonzalez Signed-off-by: Kishon Vijay Abraham I Signed-off-by: Sasha Levin commit b08d7b36f11d08db7cd74f74a92c44ca4beee7a7 Author: Marc Gonzalez Date: Thu Jun 13 13:32:08 2019 +0200 phy: qcom-qmp: Raise qcom_qmp_phy_enable() polling delay [ Upstream commit 5206026404190125436f81088eb3667076e56083 ] readl_poll_timeout() calls usleep_range() to sleep between reads. usleep_range() doesn't work efficiently for tiny values. Raise the polling delay in qcom_qmp_phy_enable() to bring it in line with the delay in qcom_qmp_phy_com_init(). Signed-off-by: Marc Gonzalez Signed-off-by: Kishon Vijay Abraham I Signed-off-by: Sasha Levin commit 3da810f95b860d262d038b84ac9a10b48ed13da0 Author: Steve French Date: Thu Sep 12 17:52:54 2019 -0500 smb3: fix unmount hang in open_shroot [ Upstream commit 96d9f7ed00b86104bf03adeffc8980897e9694ab ] An earlier patch "CIFS: fix deadlock in cached root handling" did not completely address the deadlock in open_shroot. This patch addresses the deadlock. In testing the recent patch: smb3: improve handling of share deleted (and share recreated) we were able to reproduce the open_shroot deadlock to one of the target servers in unmount in a delete share scenario. Fixes: 7e5a70ad88b1e ("CIFS: fix deadlock in cached root handling") This is version 2 of this patch. An earlier version of this patch "smb3: fix unmount hang in open_shroot" had a problem found by Dan. Reported-by: kbuild test robot Reported-by: Dan Carpenter Suggested-by: Pavel Shilovsky Reviewed-by: Pavel Shilovsky Signed-off-by: Steve French CC: Aurelien Aptel CC: Stable Signed-off-by: Sasha Levin commit e6d6a001ed5a4c8799c074745b938b3e22bd97b8 Author: Marcel Holtmann Date: Wed Sep 4 20:13:08 2019 +0200 Revert "Bluetooth: validate BLE connection interval updates" [ Upstream commit 68d19d7d995759b96169da5aac313363f92a9075 ] This reverts commit c49a8682fc5d298d44e8d911f4fa14690ea9485e. There are devices which require low connection intervals for usable operation including keyboards and mice. Forcing a static connection interval for these types of devices has an impact in latency and causes a regression. Signed-off-by: Marcel Holtmann Signed-off-by: Johan Hedberg Signed-off-by: Sasha Levin