commit be53d23e68c29900da6b6ce486b5ab8507de94b1 Author: Greg Kroah-Hartman Date: Thu Dec 13 09:16:23 2018 +0100 Linux 4.19.9 commit 0fc19a8881e68ccbd252e2916756c7b6a7bec65c Author: Nic Soudée Date: Thu Dec 6 11:59:25 2018 -0500 HID: quirks: fix RetroUSB.com devices commit 868613f1c0ccf7b832f38b48b18cca31cdeb3d26 upstream. SNES RetroPort and RetroPad register only 4 gamepad buttons when they should register all 8 buttons. This is described here: https://ask.fedoraproject.org/en/question/128102 This is happening because of: Commit 190d7f02ce8e ("HID: input: do not increment usages when duplicate is found") Here, I add the quirk HID_QUIRK_INCREMENT_USAGE_ON_DUPLICATE (created for backward compatibility with the change in 190d7f02ce8e) for the two products. Tested with both RetroPort and RetroPad. Cc: stable@vger.kernel.org # v4.18+ Signed-off-by: Nic Soudée Signed-off-by: Benjamin Tissoires Signed-off-by: Greg Kroah-Hartman commit b74a078e48a9b142312b3fa1a41b2f4e6cfbebac Author: Emmanuel Grumbach Date: Mon Dec 3 21:16:07 2018 +0200 mac80211: ignore NullFunc frames in the duplicate detection commit 990d71846a0b7281bd933c34d734e6afc7408e7e upstream. NullFunc packets should never be duplicate just like QoS-NullFunc packets. We saw a client that enters / exits power save with NullFunc frames (and not with QoS-NullFunc) despite the fact that the association supports HT. This specific client also re-uses a non-zero sequence number for different NullFunc frames. At some point, the client had to send a retransmission of the NullFunc frame and we dropped it, leading to a misalignment in the power save state. Fix this by never consider a NullFunc frame as duplicate, just like we do for QoS NullFunc frames. This fixes https://bugzilla.kernel.org/show_bug.cgi?id=201449 CC: Signed-off-by: Emmanuel Grumbach Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit e9f8baa38c2ac4e2be680ce3a8897a162d660664 Author: Felix Fietkau Date: Wed Nov 28 22:39:16 2018 +0100 mac80211: fix reordering of buffered broadcast packets commit 9ec1190d065998650fd9260dea8cf3e1f56c0e8c upstream. If the buffered broadcast queue contains packets, letting new packets bypass that queue can lead to heavy reordering, since the driver is probably throttling transmission of buffered multicast packets after beacons. Keep buffering packets until the buffer has been cleared (and no client is in powersave mode). Cc: stable@vger.kernel.org Signed-off-by: Felix Fietkau Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 50749911b1cc6ab2534139ea72d81396e18e5f44 Author: Felix Fietkau Date: Tue Nov 13 20:32:13 2018 +0100 mac80211: ignore tx status for PS stations in ieee80211_tx_status_ext commit a317e65face482371de30246b6494feb093ff7f9 upstream. Make it behave like regular ieee80211_tx_status calls, except for the lack of filtered frame processing. This fixes spurious low-ack triggered disconnections with powersave clients connected to an AP. Fixes: f027c2aca0cf4 ("mac80211: add ieee80211_tx_status_noskb") Cc: stable@vger.kernel.org Signed-off-by: Felix Fietkau Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit a75ac4e15e9c2f45efdaebc5ecbf250722a6589b Author: Ben Greear Date: Tue Oct 23 13:36:52 2018 -0700 mac80211: Clear beacon_int in ieee80211_do_stop commit 5c21e8100dfd57c806e833ae905e26efbb87840f upstream. This fixes stale beacon-int values that would keep a netdev from going up. To reproduce: Create two VAP on one radio. vap1 has beacon-int 100, start it. vap2 has beacon-int 240, start it (and it will fail because beacon-int mismatch). reconfigure vap2 to have beacon-int 100 and start it. It will fail because the stale beacon-int 240 will be used in the ifup path and hostapd never gets a chance to set the new beacon interval. Cc: stable@vger.kernel.org Signed-off-by: Ben Greear Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit e08ab93325bb23aba2111fc4ad1e06f5adba7cb2 Author: Yan-Hsuan Chuang Date: Tue Oct 23 11:24:44 2018 +0800 mac80211: fix GFP_KERNEL under tasklet context commit c752cac9db1b0c469db7ba9d17af4ba708984db5 upstream. cfg80211_sta_opmode_change_notify needs a gfp_t flag to hint the nl80211 stack when allocating new skb, but it is called under tasklet context here with GFP_KERNEL and kernel will yield a warning about it. Cc: stable@vger.kernel.org Fixes: ff84e7bfe176 ("mac80211: Add support to notify ht/vht opmode modification.") Signed-off-by: Yan-Hsuan Chuang ACKed-by: Larry Finger Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit daac338a9e7bbdd89fae6f29314803192ffce921 Author: Vasyl Vavrychuk Date: Thu Oct 18 01:02:12 2018 +0300 mac80211_hwsim: Timer should be initialized before device registered commit a1881c9b8a1edef0a5ae1d5c1b61406fe3402114 upstream. Otherwise if network manager starts configuring Wi-Fi interface immidiatelly after getting notification of its creation, we will get NULL pointer dereference: BUG: unable to handle kernel NULL pointer dereference at (null) IP: [] hrtimer_active+0x28/0x50 ... Call Trace: [] ? hrtimer_try_to_cancel+0x27/0x110 [] ? hrtimer_cancel+0x15/0x20 [] ? mac80211_hwsim_config+0x140/0x1c0 [mac80211_hwsim] Cc: stable@vger.kernel.org Signed-off-by: Vasyl Vavrychuk Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit d66c1b9280d146f8b2215224ca42535d8ab1fb39 Author: Jouni Malinen Date: Wed Dec 5 12:55:54 2018 +0200 cfg80211: Fix busy loop regression in ieee80211_ie_split_ric() commit 312ca38ddda64bac6513ec68e0ac3789b4eb44dc upstream. This function was modified to support the information element extension case (WLAN_EID_EXTENSION) in a manner that would result in an infinite loop when going through set of IEs that include WLAN_EID_RIC_DATA and contain an IE that is in the after_ric array. The only place where this can currently happen is in mac80211 ieee80211_send_assoc() where ieee80211_ie_split_ric() is called with after_ric[]. This can be triggered by valid data from user space nl80211 association/connect request (i.e., requiring GENL_UNS_ADMIN_PERM). The only known application having an option to include WLAN_EID_RIC_DATA in these requests is wpa_supplicant and it had a bug that prevented this specific contents from being used (and because of that, not triggering this kernel bug in an automated test case ap_ft_ric) and now that this bug is fixed, it has a workaround to avoid this kernel issue. WLAN_EID_RIC_DATA is currently used only for testing purposes, so this does not cause significant harm for production use cases. Fixes: 2512b1b18d07 ("mac80211: extend ieee80211_ie_split to support EXTENSION") Cc: stable@vger.kernel.org Signed-off-by: Jouni Malinen Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 98206f3400334cbe9f4c3a5c453e68640f1ffce6 Author: Dan Williams Date: Sat Nov 24 10:47:04 2018 -0800 libnvdimm, pfn: Pad pfn namespaces relative to other regions commit ae86cbfef3818300f1972e52f67a93211acb0e24 upstream. Commit cfe30b872058 "libnvdimm, pmem: adjust for section collisions with 'System RAM'" enabled Linux to workaround occasions where platform firmware arranges for "System RAM" and "Persistent Memory" to collide within a single section boundary. Unfortunately, as reported in this issue [1], platform firmware can inflict the same collision between persistent memory regions. The approach of interrogating iomem_resource does not work in this case because platform firmware may merge multiple regions into a single iomem_resource range. Instead provide a method to interrogate regions that share the same parent bus. This is a stop-gap until the core-MM can grow support for hotplug on sub-section boundaries. [1]: https://github.com/pmem/ndctl/issues/76 Fixes: cfe30b872058 ("libnvdimm, pmem: adjust for section collisions with...") Cc: Reported-by: Patrick Geary Tested-by: Patrick Geary Reviewed-by: Vishal Verma Signed-off-by: Dan Williams Signed-off-by: Greg Kroah-Hartman commit beb68a727fb9d5eb42ae919a795dc997ece27de8 Author: Macpaul Lin Date: Wed Oct 17 23:08:38 2018 +0800 kgdboc: fix KASAN global-out-of-bounds bug in param_set_kgdboc_var() commit dada6a43b0402eba438a17ac86fdc64ac56a4607 upstream. This patch is trying to fix KE issue due to "BUG: KASAN: global-out-of-bounds in param_set_kgdboc_var+0x194/0x198" reported by Syzkaller scan." [26364:syz-executor0][name:report8t]BUG: KASAN: global-out-of-bounds in param_set_kgdboc_var+0x194/0x198 [26364:syz-executor0][name:report&]Read of size 1 at addr ffffff900e44f95f by task syz-executor0/26364 [26364:syz-executor0][name:report&] [26364:syz-executor0]CPU: 7 PID: 26364 Comm: syz-executor0 Tainted: G W 0 [26364:syz-executor0]Call trace: [26364:syz-executor0][] dump_bacIctrace+Ox0/0x470 [26364:syz-executor0][] show_stack+0x20/0x30 [26364:syz-executor0][] dump_stack+Oxd8/0x128 [26364:syz-executor0][] print_address_description +0x80/0x4a8 [26364:syz-executor0][] kasan_report+Ox178/0x390 [26364:syz-executor0][] _asan_report_loadi_noabort+Ox18/0x20 [26364:syz-executor0][] param_set_kgdboc_var+Ox194/0x198 [26364:syz-executor0][] param_attr_store+Ox14c/0x270 [26364:syz-executor0][] module_attr_store+0x60/0x90 [26364:syz-executor0][] sysfs_kl_write+Ox100/0x158 [26364:syz-executor0][] kernfs_fop_write+0x27c/0x3a8 [26364:syz-executor0][] do_loop_readv_writev+0x114/0x1b0 [26364:syz-executor0][] do_readv_writev+0x4f8/0x5e0 [26364:syz-executor0][] vfs_writev+0x7c/Oxb8 [26364:syz-executor0][] SyS_writev+Oxcc/0x208 [26364:syz-executor0][] elO_svc_naked +0x24/0x28 [26364:syz-executor0][name:report&] [26364:syz-executor0][name:report&]The buggy address belongs to the variable: [26364:syz-executor0][name:report&] kgdb_tty_line+Ox3f/0x40 [26364:syz-executor0][name:report&] [26364:syz-executor0][name:report&]Memory state around the buggy address: [26364:syz-executor0] ffffff900e44f800: 00 00 00 00 00 04 fa fa fa fa fa fa 00 fa fa fa [26364:syz-executor0] ffffff900e44f880: fa fa fa fa 00 fa fa fa fa fa fa fa 00 fa fa fa [26364:syz-executor0]> ffffff900e44f900: fa fa fa fa 04 fa fa fa fa fa fa fa 00 00 00 00 [26364:syz-executor0][name:report&] ^ [26364:syz-executor0] ffffff900e44f980: 00 fa fa fa fa fa fa fa 04 fa fa fa fa fa fa fa [26364:syz-executor0] ffffff900e44fa00: 04 fa fa fa fa fa fa fa 00 fa fa fa fa fa fa fa [26364:syz-executor0][name:report&] [26364:syz-executor0][name:panic&]Disabling lock debugging due to kernel taint [26364:syz-executor0]------------[cut here]------------ After checking the source code, we've found there might be an out-of-bounds access to "config[len - 1]" array when the variable "len" is zero. Signed-off-by: Macpaul Lin Acked-by: Daniel Thompson Cc: stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 3c1773b0275e2b4e37f7df01b17234ba65b2efc7 Author: Johan Hovold Date: Wed Dec 5 11:21:49 2018 +0100 gnss: sirf: fix activation retry handling commit 06fd9ab12b804451b14d538adbf98a57c2d6846b upstream. Fix activation helper which would return -ETIMEDOUT even if the last retry attempt was successful. Also change the semantics of the retries variable so that it actually holds the number of retries (rather than tries). Fixes: d2efbbd18b1e ("gnss: add driver for sirfstar-based receivers") Cc: stable # 4.19 Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 41867ab9b0d396ce51fb63e29fda2b5791124e0e Author: Chanho Park Date: Thu Nov 22 18:23:47 2018 +0900 tty: do not set TTY_IO_ERROR flag if console port commit 2a48602615e0a2f563549c7d5c8d507f904cf96e upstream. Since Commit 761ed4a94582 ('tty: serial_core: convert uart_close to use tty_port_close') and Commit 4dda864d7307 ('tty: serial_core: Fix serial console crash on port shutdown), a serial port which is used as console can be stuck when logging out if there is a remained process. After logged out, agetty will try to grab the serial port but it will be failed because the previous process did not release the port correctly. To fix this, TTY_IO_ERROR bit should not be enabled of tty_port_close if the port is console port. Reproduce step: - Run background processes from serial console $ while true; do sleep 10; done & - Log out $ logout -> Stuck - Read journal log by journalctl | tail Jan 28 16:07:01 ubuntu systemd[1]: Stopped Serial Getty on ttyAMA0. Jan 28 16:07:01 ubuntu systemd[1]: Started Serial Getty on ttyAMA0. Jan 28 16:07:02 ubuntu agetty[1643]: /dev/ttyAMA0: not a tty Fixes: 761ed4a94582 ("tty: serial_core: convert uart_close to use tty_port_close") Cc: Geert Uytterhoeven Cc: Rob Herring Cc: Jiri Slaby Signed-off-by: Chanho Park Cc: stable Signed-off-by: Greg Kroah-Hartman commit ecbfb178c75cf6b26d2071808111d9f9216f2d23 Author: Peter Shih Date: Tue Nov 27 12:49:50 2018 +0800 tty: serial: 8250_mtk: always resume the device in probe. commit 100bc3e2bebf95506da57cbdf5f26b25f6da4c81 upstream. serial8250_register_8250_port calls uart_config_port, which calls config_port on the port before it tries to power on the port. So we need the port to be on before calling serial8250_register_8250_port. Change the code to always do a runtime resume in probe before registering port, and always do a runtime suspend in remove. This basically reverts the change in commit 68e5fc4a255a ("tty: serial: 8250_mtk: use pm_runtime callbacks for enabling"), but still use pm_runtime callbacks. Fixes: 68e5fc4a255a ("tty: serial: 8250_mtk: use pm_runtime callbacks for enabling") Signed-off-by: Peter Shih Cc: stable Signed-off-by: Greg Kroah-Hartman commit b02b86bc74c37feccce8fc3fa67523285c9be1e1 Author: Dexuan Cui Date: Mon Dec 3 00:54:35 2018 +0000 Drivers: hv: vmbus: Offload the handling of channels to two workqueues commit 37c2578c0c40e286bc0d30bdc05290b2058cf66e upstream. vmbus_process_offer() mustn't call channel->sc_creation_callback() directly for sub-channels, because sc_creation_callback() -> vmbus_open() may never get the host's response to the OPEN_CHANNEL message (the host may rescind a channel at any time, e.g. in the case of hot removing a NIC), and vmbus_onoffer_rescind() may not wake up the vmbus_open() as it's blocked due to a non-zero vmbus_connection.offer_in_progress, and finally we have a deadlock. The above is also true for primary channels, if the related device drivers use sync probing mode by default. And, usually the handling of primary channels and sub-channels can depend on each other, so we should offload them to different workqueues to avoid possible deadlock, e.g. in sync-probing mode, NIC1's netvsc_subchan_work() can race with NIC2's netvsc_probe() -> rtnl_lock(), and causes deadlock: the former gets the rtnl_lock and waits for all the sub-channels to appear, but the latter can't get the rtnl_lock and this blocks the handling of sub-channels. The patch can fix the multiple-NIC deadlock described above for v3.x kernels (e.g. RHEL 7.x) which don't support async-probing of devices, and v4.4, v4.9, v4.14 and v4.18 which support async-probing but don't enable async-probing for Hyper-V drivers (yet). The patch can also fix the hang issue in sub-channel's handling described above for all versions of kernels, including v4.19 and v4.20-rc4. So actually the patch should be applied to all the existing kernels, not only the kernels that have 8195b1396ec8. Fixes: 8195b1396ec8 ("hv_netvsc: fix deadlock on hotplug") Cc: stable@vger.kernel.org Cc: Stephen Hemminger Cc: K. Y. Srinivasan Cc: Haiyang Zhang Signed-off-by: Dexuan Cui Signed-off-by: K. Y. Srinivasan Signed-off-by: Greg Kroah-Hartman commit e88ebc06bd53801891374d5d8f457dfaab02e0ae Author: Eric Snowberg Date: Thu Nov 29 18:12:20 2018 +0100 x86/efi: Allocate e820 buffer before calling efi_exit_boot_service commit b84a64fad40637b1c9fa4f4dbf847a23e29e672b upstream. The following commit: d64934019f6c ("x86/efi: Use efi_exit_boot_services()") introduced a regression on systems with large memory maps causing them to hang on boot. The first "goto get_map" that was removed from exit_boot() ensured there was enough room for the memory map when efi_call_early(exit_boot_services) was called. This happens when (nr_desc > ARRAY_SIZE(params->e820_table). Chain of events: exit_boot() efi_exit_boot_services() efi_get_memory_map <- at this point the mm can't grow over 8 desc priv_func() exit_boot_func() allocate_e820ext() <- new mm grows over 8 desc from e820 alloc efi_call_early(exit_boot_services) <- mm key doesn't match so retry efi_call_early(get_memory_map) <- not enough room for new mm system hangs This patch allocates the e820 buffer before calling efi_exit_boot_services() and fixes the regression. [ mingo: minor cleanliness edits. ] Signed-off-by: Eric Snowberg Signed-off-by: Ard Biesheuvel Cc: Cc: Andy Lutomirski Cc: Arend van Spriel Cc: Bhupesh Sharma Cc: Borislav Petkov Cc: Dave Hansen Cc: Hans de Goede Cc: Joe Perches Cc: Jon Hunter Cc: Julien Thierry Cc: Linus Torvalds Cc: Marc Zyngier Cc: Matt Fleming Cc: Nathan Chancellor Cc: Peter Zijlstra Cc: Sai Praneeth Prakhya Cc: Sedat Dilek Cc: Thomas Gleixner Cc: YiFei Zhu Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20181129171230.18699-2-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit ce74d11a3794d5000c64f1783d7e5a28570d5425 Author: Masami Hiramatsu Date: Fri Aug 24 02:16:12 2018 +0900 kprobes/x86: Fix instruction patching corruption when copying more than one RIP-relative instruction commit 43a1b0cb4cd6dbfd3cd9c10da663368394d299d8 upstream. After copy_optimized_instructions() copies several instructions to the working buffer it tries to fix up the real RIP address, but it adjusts the RIP-relative instruction with an incorrect RIP address for the 2nd and subsequent instructions due to a bug in the logic. This will break the kernel pretty badly (with likely outcomes such as a kernel freeze, a crash, or worse) because probed instructions can refer to the wrong data. For example putting kprobes on cpumask_next() typically hits this bug. cpumask_next() is normally like below if CONFIG_CPUMASK_OFFSTACK=y (in this case nr_cpumask_bits is an alias of nr_cpu_ids): : 48 89 f0 mov %rsi,%rax 8b 35 7b fb e2 00 mov 0xe2fb7b(%rip),%esi # ffffffff82db9e64 55 push %rbp ... If we put a kprobe on it and it gets jump-optimized, it gets patched by the kprobes code like this: : e9 95 7d 07 1e jmpq 0xffffffffa000207a 7b fb jnp 0xffffffff81f8a2e2 e2 00 loop 0xffffffff81f8a2e9 55 push %rbp This shows that the first two MOV instructions were copied to a trampoline buffer at 0xffffffffa000207a. Here is the disassembled result of the trampoline, skipping the optprobe template instructions: # Dump of assembly code from 0xffffffffa000207a to 0xffffffffa00020ea: 54 push %rsp ... 48 83 c4 08 add $0x8,%rsp 9d popfq 48 89 f0 mov %rsi,%rax 8b 35 82 7d db e2 mov -0x1d24827e(%rip),%esi # 0xffffffff82db9e67 This dump shows that the second MOV accesses *(nr_cpu_ids+3) instead of the original *nr_cpu_ids. This leads to a kernel freeze because cpumask_next() always returns 0 and for_each_cpu() never ends. Fix this by adding 'len' correctly to the real RIP address while copying. [ mingo: Improved the changelog. ] Reported-by: Michael Rodin Signed-off-by: Masami Hiramatsu Reviewed-by: Steven Rostedt (VMware) Cc: Arnaldo Carvalho de Melo Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Ravi Bangoria Cc: Steven Rostedt Cc: Thomas Gleixner Cc: stable@vger.kernel.org # v4.15+ Fixes: 63fef14fc98a ("kprobes/x86: Make insn buffer always ROX and use text_poke()") Link: http://lkml.kernel.org/r/153504457253.22602.1314289671019919596.stgit@devbox Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 1a90564078087a00aa4d07a559629b99dce46c4e Author: Chris Wilson Date: Thu Jul 26 17:15:27 2018 +0100 drm/i915: Downgrade Gen9 Plane WM latency error commit 86c1c87d0e6241cbe35bd52badfc84b154e1b959 upstream. According to intel_read_wm_latency() it is perfectly legal for one WM and all subsequent levels to be 0 (and the deeper powersaving states disabled), so don't shout *ERROR*, over and over again. Signed-off-by: Chris Wilson Cc: Maarten Lankhorst Cc: Ville Syrjala Acked-by: Maarten Lankhorst Link: https://patchwork.freedesktop.org/patch/msgid/20180726161527.10516-1-chris@chris-wilson.co.uk Signed-off-by: Greg Kroah-Hartman commit e8a7f59e36437c63cab485577c255126c0819c5a Author: Alex Deucher Date: Wed Nov 28 23:28:17 2018 -0500 drm/amdgpu/gmc8: always load MC firmware in the driver commit b52b6738cc2d50d2a8f4d0095bcb5a86716008a5 upstream. Some power features rely on the driver loaded version so always load the MC firmware from the driver even if the vbios loaded a version already. Acked-by: Christian König Reviewed-by: Junwei Zhang Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 39bdb32876df3710825d33b5c455ec2ffa9db64e Author: Alex Deucher Date: Wed Nov 28 23:25:41 2018 -0500 drm/amdgpu/gmc8: update MC firmware for polaris commit a81a7c9c9ea3042ab02d66ac35def74abf091c15 upstream. Some variants require different MC firmware images. Acked-by: Christian König Reviewed-by: Junwei Zhang Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 2abdfe248369555f4656662feee2b71256b08268 Author: Robert Foss Date: Mon Nov 5 11:13:12 2018 +0100 drm/msm: Move fence put to where failure occurs commit 2189463dba3eac10d7264a40ede12fc1a3c06fb1 upstream. If dma_fence_wait fails to wait for a supplied in-fence in msm_ioctl_gem_submit, make sure we release that in-fence. Also remove this dma_fence_put() from the 'out' label. Signed-off-by: Robert Foss Reviewed-by: Chris Wilson Cc: stable@vger.kernel.org Signed-off-by: Rob Clark Signed-off-by: Sean Paul Signed-off-by: Greg Kroah-Hartman commit 318f6e599dcd31a8de5756e4a6e01012aa7669cb Author: Daniel Vetter Date: Thu Nov 29 10:42:26 2018 +0100 drm/lease: Send a distinct uevent commit ce85882860f0e756f7066cbda1c43e8b50b73ab6 upstream. Sending the exact same hotplug event is not great uapi. Luckily the only already merged implementation of leases (in the -modesetting driver) doesn't care about what kind of uevent it gets, and unconditionally processes both hotplug and lease changes. So we can still adjust the uapi here. But e.g. weston tries to filter stuff, and I guess others might want to do that too. Try to make that possible. Cc: stable since it's uapi adjustement that we want to roll out everywhere. Michel Dänzer mentioned on irc that -amdgpu also has lease support. It has the same code flow as -modesetting though, so we can still go ahead. v2: Mention -amdgpu (Michel) Cc: Keith Packard Cc: Dave Airlie Cc: stable@vger.kernel.org Reviewed-by: Keith Packard Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20181129094226.30591-1-daniel.vetter@ffwll.ch Signed-off-by: Greg Kroah-Hartman commit fcf5d0dbfb7fbcf867ea9cf0c2added9205fbb2f Author: Junwei Zhang Date: Thu Nov 22 17:53:00 2018 +0800 drm/amdgpu: update mc firmware image for polaris12 variants commit d7fd67653f847327e545bdb198b901ee124afd7c upstream. Some new variants require updated firmware. Signed-off-by: Junwei Zhang Reviewed-by: Evan Quan Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 2f94605195abe45078c9983617ea0ea6946b8264 Author: Pan Bian Date: Thu Nov 22 18:00:16 2018 +0800 crypto: do not free algorithm before using commit e5bde04ccce64d808f8b00a489a1fe5825d285cb upstream. In multiple functions, the algorithm fields are read after its reference is dropped through crypto_mod_put. In this case, the algorithm memory may be freed, resulting in use-after-free bugs. This patch delays the put operation until the algorithm is never used. Fixes: 79c65d179a40 ("crypto: cbc - Convert to skcipher") Fixes: a7d85e06ed80 ("crypto: cfb - add support for Cipher FeedBack mode") Fixes: 043a44001b9e ("crypto: pcbc - Convert to skcipher") Cc: Signed-off-by: Pan Bian Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 35929281460b2d7cd1876dbb4b0f1d57056a56c5 Author: Young Xiao Date: Tue Nov 27 09:12:20 2018 +0000 Revert commit ef9209b642f "staging: rtl8723bs: Fix indenting errors and an off-by-one mistake in core/rtw_mlme_ext.c" commit 87e4a5405f087427fbf8b437d2796283dce2b38f upstream. pstapriv->max_num_sta is always <= NUM_STA, since max_num_sta is either set in _rtw_init_sta_priv() or rtw_set_beacon(). Fixes: ef9209b642f1 ("staging: rtl8723bs: Fix indenting errors and an off-by-one mistake in core/rtw_mlme_ext.c") Signed-off-by: Young Xiao Reviewed-by: Dan Carpenter Cc: stable Signed-off-by: Greg Kroah-Hartman commit 9138ce0a8011d9c22d87c449a5874858c0bea120 Author: Young Xiao Date: Wed Nov 28 08:06:53 2018 +0000 staging: rtl8712: Fix possible buffer overrun commit 300cd664865bed5d50ae0a42fb4e3a6f415e8a10 upstream. In commit 8b7a13c3f404 ("staging: r8712u: Fix possible buffer overrun") we fix a potential off by one by making the limit smaller. The better fix is to make the buffer larger. This makes it match up with the similar code in other drivers. Fixes: 8b7a13c3f404 ("staging: r8712u: Fix possible buffer overrun") Signed-off-by: Young Xiao Cc: stable Reviewed-by: Dan Carpenter Signed-off-by: Greg Kroah-Hartman commit 99c694081ba212599388955792a37d2a4560ed4e Author: Paulo Alcantara Date: Thu Nov 15 15:20:52 2018 +0100 cifs: Fix separator when building path from dentry commit c988de29ca161823db6a7125e803d597ef75b49c upstream. Make sure to use the CIFS_DIR_SEP(cifs_sb) as path separator for prefixpath too. Fixes a bug with smb1 UNIX extensions. Fixes: a6b5058fafdf ("fs/cifs: make share unaccessible at root level mountable") Signed-off-by: Paulo Alcantara Reviewed-by: Aurelien Aptel Signed-off-by: Steve French CC: Stable Signed-off-by: Greg Kroah-Hartman commit bd5d1c273cce02612f0d3a820fbbab2e33b46a34 Author: Masayoshi Mizuma Date: Fri Oct 26 15:10:24 2018 -0700 Revert "x86/e820: put !E820_TYPE_RAM regions into memblock.reserved" [ Upstream commit 9fd61bc95130d4971568b89c9548b5e0a4e18e0e ] commit 124049decbb1 ("x86/e820: put !E820_TYPE_RAM regions into memblock.reserved") breaks movable_node kernel option because it changed the memory gap range to reserved memblock. So, the node is marked as Normal zone even if the SRAT has Hot pluggable affinity. ===================================================================== kernel: BIOS-e820: [mem 0x0000180000000000-0x0000180fffffffff] usable kernel: BIOS-e820: [mem 0x00001c0000000000-0x00001c0fffffffff] usable ... kernel: reserved[0x12]#011[0x0000181000000000-0x00001bffffffffff], 0x000003f000000000 bytes flags: 0x0 ... kernel: ACPI: SRAT: Node 2 PXM 6 [mem 0x180000000000-0x1bffffffffff] hotplug kernel: ACPI: SRAT: Node 3 PXM 7 [mem 0x1c0000000000-0x1fffffffffff] hotplug ... kernel: Movable zone start for each node kernel: Node 3: 0x00001c0000000000 kernel: Early memory node ranges ... ===================================================================== The original issue is fixed by the former patches, so let's revert commit 124049decbb1 ("x86/e820: put !E820_TYPE_RAM regions into memblock.reserved"). Link: http://lkml.kernel.org/r/20181002143821.5112-4-msys.mizuma@gmail.com Signed-off-by: Masayoshi Mizuma Reviewed-by: Pavel Tatashin Acked-by: Ingo Molnar Cc: Naoya Horiguchi Cc: Michal Hocko Cc: Thomas Gleixner Cc: Oscar Salvador Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit e92cc52ee5e74e118a4becddca9e2ed44101ee2f Author: Sasha Levin Date: Mon Dec 10 18:52:35 2018 -0500 arm64: dts: rockchip: remove vdd_log from rock960 to fix a stability issues [ Upstream commit 13682e524167cbd7e2a26c5e91bec765f0f96273 ] When the performance governor is set as default, the rock960 hangs around one minute after booting, whatever the activity is (idle, key pressed, loaded, ...). Based on the commit log found at https://patchwork.kernel.org/patch/10092377/ "vdd_log has no consumer and therefore will not be set to a specific voltage. Still the PWM output pin gets configured and thence the vdd_log output voltage will changed from it's default. Depending on the idle state of the PWM this will slightly over or undervoltage the logic supply of the RK3399 and cause instability with GbE (undervoltage) and PCIe (overvoltage). Since the default value set by a voltage divider is the correct supply voltage and we don't need to change it during runtime we remove the rail from the devicetree completely so the PWM pin will not be configured." After removing the vdd-log from the rock960's specific DT, the board does no longer hang and shows a stable behavior. Apply the same change for the rock960 by removing the vdd-log from the DT. Fixes: 874846f1fccd ("arm64: dts: rockchip: add 96boards RK3399 Ficus board") Cc: stable@vger.kernel.org Tested-by: Manivannan Sadhasivam Signed-off-by: Daniel Lezcano Signed-off-by: Heiko Stuebner [sl: adjust filename for 4.19] Signed-off-by: Sasha Levin commit 33f310e093889405f7d90c9d302073c788b64daa Author: Mathias Nyman Date: Wed Dec 5 14:22:39 2018 +0200 xhci: Prevent U1/U2 link pm states if exit latency is too long commit 0472bf06c6fd33c1a18aaead4c8f91e5a03d8d7b upstream. Don't allow USB3 U1 or U2 if the latency to wake up from the U-state reaches the service interval for a periodic endpoint. This is according to xhci 1.1 specification section 4.23.5.2 extra note: "Software shall ensure that a device is prevented from entering a U-state where its worst case exit latency approaches the ESIT." Allowing too long exit latencies for periodic endpoint confuses xHC internal scheduling, and new devices may fail to enumerate with a "Not enough bandwidth for new device state" error from the host. Cc: Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman commit 5d3b10677bf82c37b23af00b30420919e336fa00 Author: Sandeep Singh Date: Wed Dec 5 14:22:38 2018 +0200 xhci: workaround CSS timeout on AMD SNPS 3.0 xHC commit a7d57abcc8a5bdeb53bbf8e87558e8e0a2c2a29d upstream. Occasionally AMD SNPS 3.0 xHC does not respond to CSS when set, also it does not flag anything on SRE and HCE to point the internal xHC errors on USBSTS register. This stalls the entire system wide suspend and there is no point in stalling just because of xHC CSS is not responding. To work around this problem, if the xHC does not flag anything on SRE and HCE, we can skip the CSS timeout and allow the system to continue the suspend. Once the system resume happens we can internally reset the controller using XHCI_RESET_ON_RESUME quirk Signed-off-by: Shyam Sundar S K Signed-off-by: Sandeep Singh cc: Nehal Shah Cc: Tested-by: Kai-Heng Feng Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman commit 3fe0c68aea216d9fb6160bf7ebffb71c88026b5b Author: Kees Cook Date: Tue Oct 30 22:12:56 2018 +0100 ARM: 8806/1: kprobes: Fix false positive with FORTIFY_SOURCE commit e46daee53bb50bde38805f1823a182979724c229 upstream. The arm compiler internally interprets an inline assembly label as an unsigned long value, not a pointer. As a result, under CONFIG_FORTIFY_SOURCE, the address of a label has a size of 4 bytes, which was tripping the runtime checks. Instead, we can just cast the label (as done with the size calculations earlier). Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1639397 Reported-by: William Cohen Fixes: 6974f0c4555e ("include/linux/string.h: add the option of fortified string.h functions") Cc: stable@vger.kernel.org Acked-by: Laura Abbott Acked-by: Masami Hiramatsu Tested-by: William Cohen Signed-off-by: Kees Cook Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit 37e74076f3cb92a9204e1a9a14687fe2a0d6b1c5 Author: Bin Liu Date: Mon Nov 12 09:43:22 2018 -0600 dmaengine: cppi41: delete channel from pending list when stop channel commit 59861547ec9a9736e7882f6fb0c096a720ff811a upstream. The driver defines three states for a cppi channel. - idle: .chan_busy == 0 && not in .pending list - pending: .chan_busy == 0 && in .pending list - busy: .chan_busy == 1 && not in .pending list There are cases in which the cppi channel could be in the pending state when cppi41_dma_issue_pending() is called after cppi41_runtime_suspend() is called. cppi41_stop_chan() has a bug for these cases to set channels to idle state. It only checks the .chan_busy flag, but not the .pending list, then later when cppi41_runtime_resume() is called the channels in .pending list will be transitioned to busy state. Removing channels from the .pending list solves the problem. Fixes: 975faaeb9985 ("dma: cppi41: start tear down only if channel is busy") Cc: stable@vger.kernel.org # v3.15+ Signed-off-by: Bin Liu Reviewed-by: Peter Ujfalusi Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 374f384bc66f7a928f11eb20c0518f0f3fc1ffd6 Author: Lucas Stach Date: Tue Nov 6 03:40:37 2018 +0000 dmaengine: imx-sdma: use GFP_NOWAIT for dma descriptor allocations commit 64068853bc77786d1a28abb4087d6a3e93aedbe2 upstream. DMA buffer descriptors aren't allocated from atomic context, so they can use the less heavyweigth GFP_NOWAIT. Signed-off-by: Lucas Stach Signed-off-by: Robin Gong Cc: stable Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 9063f5a99ea76f85935e3e453422d15e7be89b9e Author: Lucas Stach Date: Tue Nov 6 03:40:33 2018 +0000 dmaengine: imx-sdma: implement channel termination via worker commit b8603d2a5795c42f78998e70dc792336e0dc20c9 upstream. The dmaengine documentation states that device_terminate_all may be asynchronous and need not wait for the active transfers to stop. This allows us to move most of the functionality currently implemented in the sdma channel termination function to run in a worker, outside of any atomic context. Moving this out of atomic context has two benefits: we can now sleep while waiting for the channel to terminate, instead of busy waiting and the freeing of the dma descriptors happens with IRQs enabled, getting rid of a warning in the dma mapping code. As the termination is now async, we need to implement the device_synchronize dma engine function which simply waits for the worker to finish its execution. Signed-off-by: Lucas Stach Signed-off-by: Robin Gong Cc: stable Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 228bee887467770cda334c94980845f21d7e0b8b Author: Lucas Stach Date: Tue Nov 6 03:40:28 2018 +0000 Revert "dmaengine: imx-sdma: alloclate bd memory from dma pool" commit ebb853b1bd5f659b92c71dc6a9de44cfc37c78c0 upstream. This reverts commit fe5b85c656bc. The SDMA engine needs the descriptors to be contiguous in memory. As the dma pool API is only able to provide a single descriptor per alloc invocation there is no guarantee that multiple descriptors satisfy this requirement. Also the code in question is broken as it only allocates memory for a single descriptor, without looking at the number of descriptors required for the transfer, leading to out-of-bounds accesses when the descriptors are written. Signed-off-by: Lucas Stach Signed-off-by: Robin Gong Cc: stable Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 2f79476548d8f2e93aff4e956b7a29ebc5071eff Author: Lucas Stach Date: Tue Nov 6 03:40:25 2018 +0000 Revert "dmaengine: imx-sdma: Use GFP_NOWAIT for dma allocations" commit c06abca69218ac42fa58d1ba7a7b0d9bab5f1b18 upstream. This reverts commit c1199875d327, as this depends on another commit that is going to be reverted. Signed-off-by: Lucas Stach Signed-off-by: Robin Gong Cc: stable Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 37aefa0237342c9796bfe0752593a1382a9d640a Author: Andy Shevchenko Date: Wed Dec 5 18:33:59 2018 +0200 dmaengine: dw: Fix FIFO size for Intel Merrifield commit ffe843b18211301ad25893eba09f402c19d12304 upstream. Intel Merrifield has a reduced size of FIFO used in iDMA 32-bit controller, i.e. 512 bytes instead of 1024. Fix this by partitioning it as 64 bytes per channel. Note, in the future we might switch to 'fifo-size' property instead of hard coded value. Fixes: 199244d69458 ("dmaengine: dw: add support of iDMA 32-bit hardware") Signed-off-by: Andy Shevchenko Cc: stable@vger.kernel.org Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 33154a2998902b16a5a29910422078f2a700753b Author: Chuck Lever Date: Fri Nov 30 15:39:57 2018 -0500 SUNRPC: Fix leak of krb5p encode pages commit 8dae5398ab1ac107b1517e8195ed043d5f422bd0 upstream. call_encode can be invoked more than once per RPC call. Ensure that each call to gss_wrap_req_priv does not overwrite pointers to previously allocated memory. Signed-off-by: Chuck Lever Cc: stable@kernel.org Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 1d9ca56698ad6554d41057fec297b2ca7c842871 Author: Will Deacon Date: Fri Dec 7 12:47:10 2018 +0000 arm64: hibernate: Avoid sending cross-calling with interrupts disabled commit b4aecf78083d8c6424657c1746c7c3de6e61669f upstream. Since commit 3b8c9f1cdfc50 ("arm64: IPI each CPU after invalidating the I-cache for kernel mappings"), a call to flush_icache_range() will use an IPI to cross-call other online CPUs so that any stale instructions are flushed from their pipelines. This triggers a WARN during the hibernation resume path, where flush_icache_range() is called with interrupts disabled and is therefore prone to deadlock: | Disabling non-boot CPUs ... | CPU1: shutdown | psci: CPU1 killed. | CPU2: shutdown | psci: CPU2 killed. | CPU3: shutdown | psci: CPU3 killed. | WARNING: CPU: 0 PID: 1 at ../kernel/smp.c:416 smp_call_function_many+0xd4/0x350 | Modules linked in: | CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.20.0-rc4 #1 Since all secondary CPUs have been taken offline prior to invalidating the I-cache, there's actually no need for an IPI and we can simply call __flush_icache_range() instead. Cc: Fixes: 3b8c9f1cdfc50 ("arm64: IPI each CPU after invalidating the I-cache for kernel mappings") Reported-by: Kunihiko Hayashi Tested-by: Kunihiko Hayashi Tested-by: James Morse Signed-off-by: Will Deacon Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit f9cd25b1e5e575a5f18547bdc04ea40a23ad511a Author: Stefan Hajnoczi Date: Mon Nov 5 10:35:47 2018 +0000 vhost/vsock: fix use-after-free in network stack callers commit 834e772c8db0c6a275d75315d90aba4ebbb1e249 upstream. If the network stack calls .send_pkt()/.cancel_pkt() during .release(), a struct vhost_vsock use-after-free is possible. This occurs because .release() does not wait for other CPUs to stop using struct vhost_vsock. Switch to an RCU-enabled hashtable (indexed by guest CID) so that .release() can wait for other CPUs by calling synchronize_rcu(). This also eliminates vhost_vsock_lock acquisition in the data path so it could have a positive effect on performance. This is CVE-2018-14625 "kernel: use-after-free Read in vhost_transport_send_pkt". Cc: stable@vger.kernel.org Reported-and-tested-by: syzbot+bd391451452fb0b93039@syzkaller.appspotmail.com Reported-by: syzbot+e3e074963495f92a89ed@syzkaller.appspotmail.com Reported-by: syzbot+d5a0a170c5069658b141@syzkaller.appspotmail.com Signed-off-by: Stefan Hajnoczi Signed-off-by: Michael S. Tsirkin Acked-by: Jason Wang Signed-off-by: Greg Kroah-Hartman commit 2a622040a8bce2bb7e646ca73a328b4e86ba336f Author: Halil Pasic Date: Wed Sep 26 18:48:30 2018 +0200 virtio/s390: fix race in ccw_io_helper() commit 78b1a52e05c9db11d293342e8d6d8a230a04b4e7 upstream. While ccw_io_helper() seems like intended to be exclusive in a sense that it is supposed to facilitate I/O for at most one thread at any given time, there is actually nothing ensuring that threads won't pile up at vcdev->wait_q. If they do, all threads get woken up and see the status that belongs to some other request than their own. This can lead to bugs. For an example see: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1788432 This race normally does not cause any problems. The operations provided by struct virtio_config_ops are usually invoked in a well defined sequence, normally don't fail, and are normally used quite infrequent too. Yet, if some of the these operations are directly triggered via sysfs attributes, like in the case described by the referenced bug, userspace is given an opportunity to force races by increasing the frequency of the given operations. Let us fix the problem by ensuring, that for each device, we finish processing the previous request before starting with a new one. Signed-off-by: Halil Pasic Reported-by: Colin Ian King Cc: stable@vger.kernel.org Message-Id: <20180925121309.58524-3-pasic@linux.ibm.com> Signed-off-by: Cornelia Huck Signed-off-by: Michael S. Tsirkin Signed-off-by: Greg Kroah-Hartman commit 79f6e9facb8b53ef2097a9aa35c7069b5627301a Author: Halil Pasic Date: Wed Sep 26 18:48:29 2018 +0200 virtio/s390: avoid race on vcdev->config commit 2448a299ec416a80f699940a86f4a6d9a4f643b1 upstream. Currently we have a race on vcdev->config in virtio_ccw_get_config() and in virtio_ccw_set_config(). This normally does not cause problems, as these are usually infrequent operations. However, for some devices writing to/reading from the config space can be triggered through sysfs attributes. For these, userspace can force the race by increasing the frequency. Signed-off-by: Halil Pasic Cc: stable@vger.kernel.org Message-Id: <20180925121309.58524-2-pasic@linux.ibm.com> Signed-off-by: Cornelia Huck Signed-off-by: Michael S. Tsirkin Signed-off-by: Greg Kroah-Hartman commit 6c9ac388c6c86c32bc559c06a4ec52aa0f400374 Author: Helge Deller Date: Thu Nov 29 17:05:47 2018 +0100 parisc: Enable -ffunction-sections for modules on 32-bit kernel commit 1e8249b8a4e960018e4baca6b523b8a4500af600 upstream. Frank Schreiner reported, that since kernel 4.18 he faces sysfs-warnings when loading modules on a 32-bit kernel. Here is one such example: sysfs: cannot create duplicate filename '/module/nfs/sections/.text' CPU: 0 PID: 98 Comm: modprobe Not tainted 4.18.0-2-parisc #1 Debian 4.18.10-2 Backtrace: [<1017ce2c>] show_stack+0x3c/0x50 [<107a7210>] dump_stack+0x28/0x38 [<103f900c>] sysfs_warn_dup+0x88/0xac [<103f8b1c>] sysfs_add_file_mode_ns+0x164/0x1d0 [<103f9e70>] internal_create_group+0x11c/0x304 [<103fa0a0>] sysfs_create_group+0x48/0x60 [<1022abe8>] load_module.constprop.35+0x1f9c/0x23b8 [<1022b278>] sys_finit_module+0xd0/0x11c [<101831dc>] syscall_exit+0x0/0x14 This warning gets triggered by the fact, that due to commit 24b6c22504a2 ("parisc: Build kernel without -ffunction-sections") we now get multiple .text sections in the kernel modules for which sysfs_create_group() can't create multiple virtual files. This patch works around the problem by re-enabling the -ffunction-sections compiler option for modules, while keeping it disabled for the non-module kernel code. Reported-by: Frank Scheiner Fixes: 24b6c22504a2 ("parisc: Build kernel without -ffunction-sections") Cc: # v4.18+ Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit c91ec2c4eb65cbba321e6edebc3d5e023a24908d Author: Enric Balletbo i Serra Date: Tue Dec 4 16:58:43 2018 +0100 Revert "mfd: cros_ec: Use devm_kzalloc for private data" commit 48a2ca0ee3994df53da230c7079a18a70ec914f9 upstream. This reverts commit 3aa2177e47878f7e7616da8a2050c44f22301b6e. That commit triggered a new WARN when unloading the module (see at the end of the commit message). When a class_dev is embedded in a structure then that class_dev is the thing that controls the lifetime of that structure, for that reason device managed allocations can't be used here. See Documentation/kobject.txt. Revert the above patch, so the struct is allocated using kzalloc and we have a release function for it that frees the allocated memory, otherwise it is broken. ------------[ cut here ]------------ Device 'cros_ec' does not have a release() function, it is broken and must be fixed. WARNING: CPU: 3 PID: 3675 at drivers/base/core.c:895 device_release+0x80/0x90 Modules linked in: btusb btrtl btintel btbcm bluetooth ... CPU: 3 PID: 3675 Comm: rmmod Not tainted 4.20.0-rc4 #76 Hardware name: Google Kevin (DT) pstate: 40000005 (nZcv daif -PAN -UAO) pc : device_release+0x80/0x90 lr : device_release+0x80/0x90 sp : ffff00000c47bc70 x29: ffff00000c47bc70 x28: ffff8000e86b0d40 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000056000000 x24: 0000000000000015 x23: ffff8000f0bbf860 x22: ffff000000d320a0 x21: ffff8000ee93e100 x20: ffff8000ed931428 x19: ffff8000ed931418 x18: 0000000000000020 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000400 x14: 0000000000000143 x13: 0000000000000000 x12: 0000000000000400 x11: 0000000000000157 x10: 0000000000000960 x9 : ffff00000c47b9b0 x8 : ffff8000e86b1700 x7 : 0000000000000000 x6 : ffff8000f7d520b8 x5 : ffff8000f7d520b8 x4 : 0000000000000000 x3 : ffff8000f7d58e68 x2 : ffff8000e86b0d40 x1 : 37d859939c964800 x0 : 0000000000000000 Call trace: device_release+0x80/0x90 kobject_put+0x74/0xe8 device_unregister+0x20/0x30 ec_device_remove+0x34/0x48 [cros_ec_dev] platform_drv_remove+0x28/0x48 device_release_driver_internal+0x1a8/0x240 driver_detach+0x40/0x80 bus_remove_driver+0x54/0xa8 driver_unregister+0x2c/0x58 platform_driver_unregister+0x10/0x18 cros_ec_dev_exit+0x1c/0x2d8 [cros_ec_dev] __arm64_sys_delete_module+0x16c/0x1f8 el0_svc_common+0x84/0xd8 el0_svc_handler+0x2c/0x80 el0_svc+0x8/0xc ---[ end trace a57c4625f3c60ae8 ]--- Cc: stable@vger.kernel.org Fixes: 3aa2177e4787 ("mfd: cros_ec: Use devm_kzalloc for private data") Signed-off-by: Enric Balletbo i Serra Reviewed-by: Guenter Roeck Reviewed-by: Dmitry Torokhov Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman commit 24a776e398e9c203a712cec9970dd55e2f630607 Author: Mauro Carvalho Chehab Date: Fri Nov 23 12:10:57 2018 -0500 media: dvb-pll: don't re-validate tuner frequencies commit 3420f65cbbd0555049bd02394bed33a0ef74d860 upstream. The dvb_frontend core already checks for the frequencies. No need for any additional check inside the driver. It is part of the fixes for the following bug: https://bugzilla.opensuse.org/show_bug.cgi?id=1116374 Fixes: a3f90c75b833 ("media: dvb: convert tuner_info frequencies to Hz") Reported-by: Stakanov Schufter Reported-by: Takashi Iwai Cc: stable@vger.kernel.org # For 4.19 Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit d7db760650414f857fd7618c0f39596d305da875 Author: Mauro Carvalho Chehab Date: Tue Nov 20 05:19:36 2018 -0500 media: dvb-pll: fix tuner frequency ranges commit 3d8e450f517cdb33da77827ec75929354753e9c0 upstream. Tuners should report frequencies in Hz. That works fine on most drivers, but, in the case of dvb-pll, some settings are for satellite tuners, while others are for terrestrial/cable ones. The code was trying to solve it at probing time, but that doesn't work, as, when _attach is called, the delivery system may be wrong. Fix it by ensuring that all frequencies are in Hz at the per-tuner max/min values. While here, add a debug message, as this would help to debug any issues there. It partially fixes the following bug: https://bugzilla.opensuse.org/show_bug.cgi?id=1116374 Fixes: a3f90c75b833 ("media: dvb: convert tuner_info frequencies to Hz") Reported-by: Stakanov Schufter Reported-by: Takashi Iwai Cc: stable@vger.kernel.org # For 4.19 Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 663bfc44d1a0ac440dd0d94ec7aa94a4c690f233 Author: Hans Verkuil Date: Sat Nov 17 06:25:08 2018 -0500 media: vicodec: fix memchr() kernel oops commit cb3b2ffb757e75fef40fb94bc093cbbf49a6bf6e upstream. The size passed to memchr is too large as it assumes the search starts at the start of the buffer, but it can start at an offset. Cc: # for v4.19 and up Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit c4dabf370838d1cf3bae6e96fc1a02cd39f9404f Author: Hans Verkuil Date: Tue Nov 20 05:13:04 2018 -0500 media: gspca: fix frame overflow error commit f96d84488f7d5f9123428c700cea82a292bca53e upstream. When converting gspca to vb2 I missed that fact that the buffer sizes were rounded up to the next page size. As a result some gspca drivers (spca561 being one of them) reported frame overflows. Modify the code to align the buffer sizes to the next page size, just as the original code did. Fixes: 1f5965c4dfd7 ("media: gspca: convert to vb2") Tested-off-by: Hans Verkuil Signed-off-by: Hans Verkuil Reported-by: softwarebugs Cc: # for v4.18 and up Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit fbb982c6ad97fcaca3d0e01a98c56bf665d34163 Author: Chris Chiu Date: Wed Dec 5 14:48:56 2018 +0800 ALSA: hda/realtek: Fix mic issue on Acer AIO Veriton Z4860G/Z6860G commit b72f936f6b325f4fde06b02e4b6ab682f6f2e73f upstream. Acer AIO Veriton Z4860G/Z6860G with the same ALC286 codec has issues with the input from external microphone. The issue can be fixed by the fixup ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE for Veriton Z4660G. Signed-off-by: Jian-Hong Pan Signed-off-by: Daniel Drake Signed-off-by: Chris Chiu Cc: Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit ba3ce1bf275c74808a4399a3c5f8380af5bdcb54 Author: Chris Chiu Date: Wed Dec 5 14:48:55 2018 +0800 ALSA: hda/realtek: Fix mic issue on Acer AIO Veriton Z4660G commit 9f8aefed9623a91dec54eab8908f3810b7f8d73a upstream. Acer AIO Veriton Z4660G with ALC286 codec has issue with the input from external microphones connecting via 'Front Mic' jack. The fixup ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE enables the jack sensing of the headset and fix the audio input issue of external microphone. Signed-off-by: Jian-Hong Pan Signed-off-by: Daniel Drake Signed-off-by: Chris Chiu Cc: Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit bf03eb5e297f0b705ca0c7fbe9c21e449f73a51d Author: Chris Chiu Date: Wed Dec 5 14:48:54 2018 +0800 ALSA: hda/realtek - Add support for Acer Aspire C24-860 headset mic commit 705b65f107470499442240ff7afee5021a7002a6 upstream. The Acer AIO Aspire C24-860 with ALC286 can't detect the headset microphone. Just like another Acer AIO U27-880, it needs a different pin value for 0x18 and the headset fixup to make headset mic work. Signed-off-by: Jian-Hong Pan Signed-off-by: Daniel Drake Signed-off-by: Chris Chiu Cc: Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 642314e11aded202a7e3ee66e876894c59428bbd Author: Chris Chiu Date: Wed Dec 5 14:48:53 2018 +0800 ALSA: hda/realtek: ALC286 mic and headset-mode fixups for Acer Aspire U27-880 commit 33aaebd48ae2d2c78fef5063a0381e17db19b060 upstream. Acer Aspire U27-880(AIO) with ALC286 codec can not detect headset mic and internal mic not working either. It needs the similar quirk like Sony laptops to fix headphone jack sensing and enables use of the internal microphone. Unfortunately jack sensing for the headset mic is still not working. Signed-off-by: Jian-Hong Pan Signed-off-by: Daniel Drake Signed-off-by: Chris Chiu Cc: Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 071b34a1a5ed9cffbfa7e22643689fe336d8203b Author: Takashi Iwai Date: Mon Dec 3 10:44:15 2018 +0100 ALSA: hda/realtek - Fix speaker output regression on Thinkpad T570 commit 54947cd64c1b8290f64bb2958e343c07270e3a58 upstream. We've got a regression report for some Thinkpad models (at least T570s) which shows the too low speaker output volume. The bisection leaded to the commit 61fcf8ece9b6 ("ALSA: hda/realtek - Enable Thinkpad Dock device for ALC298 platform"), and it's basically adding the two pin configurations for the dock, and looks harmless. The real culprit seems, though, that the DAC assignment for the speaker pin is implicitly assumed on these devices, i.e. pin NID 0x14 to be coupled with DAC NID 0x03. When more pins are configured by the commit above, the auto-parser changes the DAC assignment, and this resulted in the regression. As a workaround, just provide the fixed pin / DAC mapping table for this Thinkpad fixup function. It's no generic solution, but the problem itself is pretty much device-specific, so must be good enough. Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1554304 Fixes: 61fcf8ece9b6 ("ALSA: hda/realtek - Enable Thinkpad Dock device for ALC298 platform") Cc: Reported-and-tested-by: Jeremy Cline Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit a2928e74981266381b5df13f150384a5c5120ff3 Author: Takashi Iwai Date: Thu Nov 29 12:05:19 2018 +0100 ALSA: pcm: Fix interval evaluation with openmin/max commit 5363857b916c1f48027e9b96ee8be8376bf20811 upstream. As addressed in alsa-lib (commit b420056604f0), we need to fix the case where the evaluation of PCM interval "(x x+1]" leading to -EINVAL. After applying rules, such an interval may be translated as "(x x+1)". Fixes: ff2d6acdf6f1 ("ALSA: pcm: Fix snd_interval_refine first/last with open min/max") Cc: Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 19054c18846ec5fb0820febae3bfea4cac05d6e8 Author: Takashi Iwai Date: Thu Nov 29 08:02:49 2018 +0100 ALSA: pcm: Call snd_pcm_unlink() conditionally at closing commit b51abed8355e5556886623b2772fa6b7598d2282 upstream. Currently the PCM core calls snd_pcm_unlink() always unconditionally at closing a stream. However, since snd_pcm_unlink() invokes the global rwsem down, the lock can be easily contended. More badly, when a thread runs in a high priority RT-FIFO, it may stall at spinning. Basically the call of snd_pcm_unlink() is required only for the linked streams that are already rare occasion. For normal use cases, this code path is fairly superfluous. As an optimization (and also as a workaround for the RT problem above in normal situations without linked streams), this patch adds a check before calling snd_pcm_unlink() and calls it only when needed. Reported-by: Chanho Min Cc: Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 026fdecbc3d79bce37d46290305cb69df4ca2711 Author: Chanho Min Date: Mon Nov 26 14:36:37 2018 +0900 ALSA: pcm: Fix starvation on down_write_nonblock() commit b888a5f713e4d17faaaff24316585a4eb07f35b7 upstream. Commit 67ec1072b053 ("ALSA: pcm: Fix rwsem deadlock for non-atomic PCM stream") fixes deadlock for non-atomic PCM stream. But, This patch causes antother stuck. If writer is RT thread and reader is a normal thread, the reader thread will be difficult to get scheduled. It may not give chance to release readlocks and writer gets stuck for a long time if they are pinned to single cpu. The deadlock described in the previous commit is because the linux rwsem queues like a FIFO. So, we might need non-FIFO writelock, not non-block one. My suggestion is that the writer gives reader a chance to be scheduled by using the minimum msleep() instaed of spinning without blocking by writer. Also, The *_nonblock may be changed to *_nonfifo appropriately to this concept. In terms of performance, when trylock is failed, this minimum periodic msleep will have the same performance as the tick-based schedule()/wake_up_q(). [ Although this has a fairly high performance penalty, the relevant code path became already rare due to the previous commit ("ALSA: pcm: Call snd_pcm_unlink() conditionally at closing"). That is, now this unconditional msleep appears only when using linked streams, and this must be a rare case. So we accept this as a quick workaround until finding a more suitable one -- tiwai ] Fixes: 67ec1072b053 ("ALSA: pcm: Fix rwsem deadlock for non-atomic PCM stream") Suggested-by: Wonmin Jung Signed-off-by: Chanho Min Cc: Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 2ea30d9d5fa1fb9777af4758c96073a5db4b8011 Author: Kai-Heng Feng Date: Thu Nov 29 08:57:37 2018 +0000 ALSA: hda: Add support for AMD Stoney Ridge commit 3deef52ce10514ccdebba8e8ab85f9cebd0eb3f7 upstream. It's similar to other AMD audio devices, it also supports D3, which can save some power drain. Signed-off-by: Kai-Heng Feng Cc: Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit a7e719ace75e4451b7958cb73cbc12c627760007 Author: Hui Peng Date: Mon Dec 3 16:09:34 2018 +0100 ALSA: usb-audio: Fix UAF decrement if card has no live interfaces in card.c commit 5f8cf712582617d523120df67d392059eaf2fc4b upstream. If a USB sound card reports 0 interfaces, an error condition is triggered and the function usb_audio_probe errors out. In the error path, there was a use-after-free vulnerability where the memory object of the card was first freed, followed by a decrement of the number of active chips. Moving the decrement above the atomic_dec fixes the UAF. [ The original problem was introduced in 3.1 kernel, while it was developed in a different form. The Fixes tag below indicates the original commit but it doesn't mean that the patch is applicable cleanly. -- tiwai ] Fixes: 362e4e49abe5 ("ALSA: usb-audio - clear chip->probing on error exit") Reported-by: Hui Peng Reported-by: Mathias Payer Signed-off-by: Hui Peng Signed-off-by: Mathias Payer Cc: Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 86c257e05223a19a80882904ea5a14babb72eb26 Author: Tony Das Date: Wed Nov 28 20:16:37 2018 +0000 ALSA: usb-audio: Add SMSL D1 to quirks for native DSD support commit 44ff57e685f96d0cb9540004cc9d1d880e7a4315 upstream. This patch adds quirk VID/PID IDs for the SMSL D1 in order to enable Native DSD support. [ Moved the added entry in numerical order -- tiwai ] Signed-off-by: Tony Das Cc: Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 9d9026afc36ba7a4977453cd0bfb9cc4b9cae444 Author: Johan Hovold Date: Tue Dec 4 17:00:36 2018 +0100 USB: serial: console: fix reported terminal settings commit f51ccf46217c28758b1f3b5bc0ccfc00eca658b2 upstream. The USB-serial console implementation has never reported the actual terminal settings used. Despite storing the corresponding cflags in its struct console, these were never honoured on later tty open() where the tty termios would be left initialised to the driver defaults. Unlike the serial console implementation, the USB-serial code calls subdriver open() already at console setup. While calling set_termios() and write() before open() looks like it could work for some USB-serial drivers, others definitely do not expect this, so modelling this after serial core is going to be intrusive, if at all possible. Instead, use a (renamed) tty helper to save the termios data used at console setup so that the tty termios reflects the actual terminal settings after a subsequent tty open(). Note that the calls to tty_init_termios() (tty_driver_install()) and tty_save_termios() are serialised using the disconnect mutex. This specifically fixes a regression that was triggered by a recent change adding software flow control to the pl2303 driver: a getty trying to disable flow control while leaving the baud rate unchanged would now also set the baud rate to the driver default (prior to the flow-control change this had been a noop). Fixes: 7041d9c3f01b ("USB: serial: pl2303: add support for tx xon/xoff flow control") Cc: stable # 4.18 Cc: Florian Zumbiehl Reported-by: Jarkko Nikula Tested-by: Jarkko Nikula Acked-by: Greg Kroah-Hartman Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 1b2e742bf7230ce04cda5b7348f922174bef2d7a Author: Mathias Payer Date: Wed Dec 5 21:19:59 2018 +0100 USB: check usb_get_extra_descriptor for proper size commit 704620afc70cf47abb9d6a1a57f3825d2bca49cf upstream. When reading an extra descriptor, we need to properly check the minimum and maximum size allowed, to prevent from invalid data being sent by a device. Reported-by: Hui Peng Reported-by: Mathias Payer Co-developed-by: Linus Torvalds Signed-off-by: Hui Peng Signed-off-by: Mathias Payer Signed-off-by: Linus Torvalds Cc: stable Signed-off-by: Greg Kroah-Hartman commit 24e09d7a52ae07557fd8ac77492a8bb33bdeb132 Author: Alexander Theissen Date: Tue Dec 4 23:43:35 2018 +0100 usb: appledisplay: Add 27" Apple Cinema Display commit d7859905301880ad3e16272399d26900af3ac496 upstream. Add another Apple Cinema Display to the list of supported displays. Signed-off-by: Alexander Theissen Cc: stable Signed-off-by: Greg Kroah-Hartman commit f025aa79bda0a963728cdd401125bffab628c5c8 Author: Harry Pan Date: Thu Nov 29 00:40:41 2018 +0800 usb: quirk: add no-LPM quirk on SanDisk Ultra Flair device commit 2f2dde6ba89b1ef1fe23c1138131b315d9aa4019 upstream. Some lower volume SanDisk Ultra Flair in 16GB, which the VID:PID is in 0781:5591, will aggressively request LPM of U1/U2 during runtime, when using this thumb drive as the OS installation key we found the device will generate failure during U1 exit path making it dropped from the USB bus, this causes a corrupted installation in system at the end. i.e., [ 166.918296] hub 2-0:1.0: state 7 ports 7 chg 0000 evt 0004 [ 166.918327] usb usb2-port2: link state change [ 166.918337] usb usb2-port2: do warm reset [ 166.970039] usb usb2-port2: not warm reset yet, waiting 50ms [ 167.022040] usb usb2-port2: not warm reset yet, waiting 200ms [ 167.276043] usb usb2-port2: status 02c0, change 0041, 5.0 Gb/s [ 167.276050] usb 2-2: USB disconnect, device number 2 [ 167.276058] usb 2-2: unregistering device [ 167.276060] usb 2-2: unregistering interface 2-2:1.0 [ 167.276170] xhci_hcd 0000:00:15.0: shutdown urb ffffa3c7cc695cc0 ep1in-bulk [ 167.284055] sd 0:0:0:0: [sda] tag#0 FAILED Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK [ 167.284064] sd 0:0:0:0: [sda] tag#0 CDB: Read(10) 28 00 00 33 04 90 00 01 00 00 ... Analyzed the USB trace in the link layer we realized it is because of the 6-ms timer of tRecoveryConfigurationTimeout which documented on the USB 3.2 Revision 1.0, the section 7.5.10.4.2 of "Exit from Recovery.Configuration"; device initiates U1 exit -> Recovery.Active -> Recovery.Configuration, then the host timer timeout makes the link transits to eSS.Inactive -> Rx.Detect follows by a Warm Reset. Interestingly, the other higher volume of SanDisk Ultra Flair sharing the same VID:PID, such as 64GB, would not request LPM during runtime, it sticks at U0 always, thus disabling LPM does not affect those thumb drives at all. The same odd occures in SanDisk Ultra Fit 16GB, VID:PID in 0781:5583. Signed-off-by: Harry Pan Cc: stable Signed-off-by: Greg Kroah-Hartman commit c34678d4c15577b2c76d4dd105eb0b7f3fae0152 Author: Yangtao Li Date: Thu Nov 22 07:34:41 2018 -0500 net: amd: add missing of_node_put() [ Upstream commit c44c749d3b6fdfca39002e7e48e03fe9f9fe37a3 ] of_find_node_by_path() acquires a reference to the node returned by it and that reference needs to be dropped by its caller. This place doesn't do that, so fix it. Signed-off-by: Yangtao Li Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit ebc4b790103d66d3c6bc5b74ee0c9d4730adcca9 Author: Hangbin Liu Date: Thu Nov 22 16:15:28 2018 +0800 team: no need to do team_notify_peers or team_mcast_rejoin when disabling port [ Upstream commit 5ed9dc99107144f83b6c1bb52a69b58875baf540 ] team_notify_peers() will send ARP and NA to notify peers. team_mcast_rejoin() will send multicast join group message to notify peers. We should do this when enabling/changed to a new port. But it doesn't make sense to do it when a port is disabled. On the other hand, when we set mcast_rejoin_count to 2, and do a failover, team_port_disable() will increase mcast_rejoin.count_pending to 2 and then team_port_enable() will increase mcast_rejoin.count_pending to 4. We will send 4 mcast rejoin messages at latest, which will make user confused. The same with notify_peers.count. Fix it by deleting team_notify_peers() and team_mcast_rejoin() in team_port_disable(). Reported-by: Liang Li Fixes: fc423ff00df3a ("team: add peer notification") Fixes: 492b200efdd20 ("team: add support for sending multicast rejoins") Signed-off-by: Hangbin Liu Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f1c4022ab26850408952c74bada285414ba74d77 Author: Thomas Falcon Date: Wed Nov 21 11:17:59 2018 -0600 ibmvnic: Update driver queues after change in ring size support [ Upstream commit 5bf032ef08e6a110edc1e3bfb3c66a208fb55125 ] During device reset, queue memory is not being updated to accommodate changes in ring buffer sizes supported by backing hardware. Track any differences in ring buffer sizes following the reset and update queue memory when possible. Signed-off-by: Thomas Falcon Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit a13220e6817c275bdcd8f4454d6e2b138e9e1d65 Author: Thomas Falcon Date: Wed Nov 21 11:17:58 2018 -0600 ibmvnic: Fix RX queue buffer cleanup [ Upstream commit b7cdec3d699db2e5985ad39de0f25d3b6111928e ] The wrong index is used when cleaning up RX buffer objects during release of RX queues. Update to use the correct index counter. Signed-off-by: Thomas Falcon Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 0a98c7c5dc62ab24c6a03063a507cfec8e23f9d8 Author: Tigran Mkrtchyan Date: Wed Nov 21 12:25:41 2018 +0100 flexfiles: use per-mirror specified stateid for IO [ Upstream commit bb21ce0ad227b69ec0f83279297ee44232105d96 ] rfc8435 says: For tight coupling, ffds_stateid provides the stateid to be used by the client to access the file. However current implementation replaces per-mirror provided stateid with by open or lock stateid. Ensure that per-mirror stateid is used by ff_layout_write_prepare_v4 and nfs4_ff_layout_prepare_ds. Signed-off-by: Tigran Mkrtchyan Signed-off-by: Rick Macklem Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 07b92c224d5ca13aa07dd1c31908dfa19400df3e Author: Olga Kornievskaia Date: Wed Nov 21 11:24:22 2018 -0500 NFSv4.2 copy do not allocate memory under the lock [ Upstream commit 99f2c55591fb5c1b536263970d98c2ebc2089906 ] Bruce pointed out that we shouldn't allocate memory while holding a lock in the nfs4_callback_offload() and handle_async_copy() that deal with a racing CB_OFFLOAD and reply to COPY case. Signed-off-by: Olga Kornievskaia Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit d1862827f41a79560bb98ba91e6b4be8f8c726f9 Author: Pan Bian Date: Wed Nov 21 17:53:47 2018 +0800 iommu/vt-d: Use memunmap to free memremap [ Upstream commit 829383e183728dec7ed9150b949cd6de64127809 ] memunmap() should be used to free the return of memremap(), not iounmap(). Fixes: dfddb969edf0 ('iommu/vt-d: Switch from ioremap_cache to memremap') Signed-off-by: Pan Bian Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 549e3c24ac348249bd5169382efc0ef8b63da466 Author: Vincent Chen Date: Wed Nov 21 09:38:11 2018 +0800 net: faraday: ftmac100: remove netif_running(netdev) check before disabling interrupts [ Upstream commit 426a593e641ebf0d9288f0a2fcab644a86820220 ] In the original ftmac100_interrupt(), the interrupts are only disabled when the condition "netif_running(netdev)" is true. However, this condition causes kerenl hang in the following case. When the user requests to disable the network device, kernel will clear the bit __LINK_STATE_START from the dev->state and then call the driver's ndo_stop function. Network device interrupts are not blocked during this process. If an interrupt occurs between clearing __LINK_STATE_START and stopping network device, kernel cannot disable the interrupts due to the condition "netif_running(netdev)" in the ISR. Hence, kernel will hang due to the continuous interruption of the network device. In order to solve the above problem, the interrupts of the network device should always be disabled in the ISR without being restricted by the condition "netif_running(netdev)". [V2] Remove unnecessary curly braces. Signed-off-by: Vincent Chen Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit d69eb98a86c0ed560b303a1a078e668d230d9d39 Author: David Abdurachmanov Date: Thu Nov 8 20:07:00 2018 +0100 riscv: fix warning in arch/riscv/include/asm/module.h [ Upstream commit 0138ebb90c633f76bc71617f8f23635ce41c84fd ] Fixes warning: 'struct module' declared inside parameter list will not be visible outside of this definition or declaration Signed-off-by: David Abdurachmanov Acked-by: Olof Johansson Signed-off-by: Palmer Dabbelt Signed-off-by: Sasha Levin commit bfa634ba505ab5ad24e1d40b49b23768d8e8d046 Author: Juliet Kim Date: Mon Nov 19 15:59:22 2018 -0600 net/ibmnvic: Fix deadlock problem in reset [ Upstream commit a5681e20b541a507c7d4fd48ae4a4040d32ee1ef ] This patch changes to use rtnl_lock only during a reset to avoid deadlock that could occur when a thread operating close is holding rtnl_lock and waiting for reset_lock acquired by another thread, which is waiting for rtnl_lock in order to set the number of tx/rx queues during a reset. Also, we now setting the number of tx/rx queues during a soft reset for failover or LPM events. Signed-off-by: Juliet Kim Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 07f745f9a6d624dc1829f0d2a3a1d31b40a3eb69 Author: Denis Bolotin Date: Mon Nov 19 16:28:31 2018 +0200 qed: Fix QM getters to always return a valid pq [ Upstream commit eb62cca9bee842e5b23bd0ddfb1f271ca95e8759 ] The getter callers doesn't know the valid Physical Queues (PQ) values. This patch makes sure that a valid PQ will always be returned. The patch consists of 3 fixes: - When qed_init_qm_get_idx_from_flags() receives a disabled flag, it returned PQ 0, which can potentially be another function's pq. Verify that flag is enabled, otherwise return default start_pq. - When qed_init_qm_get_idx_from_flags() receives an unknown flag, it returned NULL and could lead to a segmentation fault. Return default start_pq instead. - A modulo operation was added to MCOS/VFS PQ getters to make sure the PQ returned is in range of the required flag. Fixes: b5a9ee7cf3be ("qed: Revise QM cofiguration") Signed-off-by: Denis Bolotin Signed-off-by: Michal Kalderon Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit b63de441365669195db4db67e9b1a60e6c363b59 Author: Denis Bolotin Date: Mon Nov 19 16:28:30 2018 +0200 qed: Fix bitmap_weight() check [ Upstream commit 276d43f0ae963312c0cd0e2b9a85fd11ac65dfcc ] Fix the condition which verifies that only one flag is set. The API bitmap_weight() should receive size in bits instead of bytes. Fixes: b5a9ee7cf3be ("qed: Revise QM cofiguration") Signed-off-by: Denis Bolotin Signed-off-by: Michal Kalderon Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit e359a17143ef285921c2d5f55bfe3042412b5625 Author: Trond Myklebust Date: Mon Nov 19 20:11:45 2018 -0500 NFSv4: Fix a NFSv4 state manager deadlock [ Upstream commit aeabb3c96186a0f944fc2b1f25c84d5eb3a93fa9 ] Fix a deadlock whereby the NFSv4 state manager can get stuck in the delegation return code, waiting for a layout return to complete in another thread. If the server reboots before that other thread completes, then we need to be able to start a second state manager thread in order to perform recovery. Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 4a9ad460a07b2fcbe071fb33df5b79b12dc4ca61 Author: Arthur Kiyanovski Date: Mon Nov 19 12:05:20 2018 +0200 net: ena: fix crash during failed resume from hibernation [ Upstream commit e76ad21d070f79e566ac46ce0b0584c3c93e1b43 ] During resume from hibernation if ena_restore_device fails, ena_com_dev_reset() is called, and uses the readless read mechanism, which was already destroyed by the call to ena_com_mmio_reg_read_request_destroy(). This causes a NULL pointer reference. In this commit we switch the call order of the above two functions to avoid this crash. Fixes: d7703ddbd7c9 ("net: ena: fix rare bug when failed restart/resume is followed by driver removal") Signed-off-by: Arthur Kiyanovski Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit d7dace92d0402d2c64d2486b93f8b655a87f33b2 Author: Thor Thayer Date: Fri Nov 16 08:25:49 2018 -0600 mtd: spi-nor: Fix Cadence QSPI page fault kernel panic [ Upstream commit a6a66f80c85e8e20573ca03fabf32445954a88d5 ] The current Cadence QSPI driver caused a kernel panic sporadically when writing to QSPI. The problem was caused by writing more bytes than needed because the QSPI operated on 4 bytes at a time. [ 11.202044] Unable to handle kernel paging request at virtual address bffd3000 [ 11.209254] pgd = e463054d [ 11.211948] [bffd3000] *pgd=2fffb811, *pte=00000000, *ppte=00000000 [ 11.218202] Internal error: Oops: 7 [#1] SMP ARM [ 11.222797] Modules linked in: [ 11.225844] CPU: 1 PID: 1317 Comm: systemd-hwdb Not tainted 4.17.7-d0c45cd44a8f [ 11.235796] Hardware name: Altera SOCFPGA Arria10 [ 11.240487] PC is at __raw_writesl+0x70/0xd4 [ 11.244741] LR is at cqspi_write+0x1a0/0x2cc On a page boundary limit the number of bytes copied from the tx buffer to remain within the page. This patch uses a temporary buffer to hold the 4 bytes to write and then copies only the bytes required from the tx buffer. Reported-by: Adrian Amborzewicz Signed-off-by: Thor Thayer Signed-off-by: Boris Brezillon Signed-off-by: Sasha Levin commit d861fe2fd5b1babb879dfedb438cf0751ed45c3c Author: Kai-Heng Feng Date: Wed Nov 14 05:35:20 2018 +0000 HID: multitouch: Add pointstick support for Cirque Touchpad [ Upstream commit 12d43aacf9a74d0eb66fd0ea54ebeb79ca28940f ] Cirque Touchpad/Pointstick combo is similar to Alps devices, it requires MT_CLS_WIN_8_DUAL to expose its pointstick as a mouse. Signed-off-by: Kai-Heng Feng Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 699faa9cf00c0f0b8a07ad71ee2d86eadad3cabe Author: David Herrmann Date: Wed Nov 14 14:16:42 2018 +0100 Revert "HID: uhid: use strlcpy() instead of strncpy()" [ Upstream commit 4d26d1d1e8065bb3326a7c06d5d4698e581443a9 ] This reverts commit 336fd4f5f25157e9e8bd50e898a1bbcd99eaea46. Please note that `strlcpy()` does *NOT* do what you think it does. strlcpy() *ALWAYS* reads the full input string, regardless of the 'length' parameter. That is, if the input is not zero-terminated, strlcpy() will *READ* beyond input boundaries. It does this, because it always returns the size it *would* copy if the target was big enough, not the truncated size it actually copied. The original code was perfectly fine. The hid device is zero-initialized and the strncpy() functions copied up to n-1 characters. The result is always zero-terminated this way. This is the third time someone tried to replace strncpy with strlcpy in this function, and gets it wrong. I now added a comment that should at least make people reconsider. Signed-off-by: David Herrmann Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 0799feafeb1b633442432810d8107fb0367dc37a Author: Dave Gerlach Date: Tue Nov 13 13:30:40 2018 -0600 cpufreq: ti-cpufreq: Only register platform_device when supported [ Upstream commit d98ccfc3948ab63152494bb6b9c17e15295c0310 ] Currently the ti-cpufreq driver blindly registers a 'ti-cpufreq' to force the driver to probe on any platforms where the driver is built in. However, this should only happen on platforms that actually can make use of the driver. There is already functionality in place to match the SoC compatible so let's factor this out into a separate call and make sure we find a match before creating the ti-cpufreq platform device. Reviewed-by: Johan Hovold Signed-off-by: Dave Gerlach Acked-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 1a488242d942c12014f333a6c2a98082882f6707 Author: Olof Johansson Date: Fri Nov 16 19:43:27 2018 -0800 mtd: rawnand: qcom: Namespace prefix some commands [ Upstream commit 33bf5519ae5dd356b182a94e3622f42860274a38 ] PAGE_READ is used by RISC-V arch code included through mm headers, and it makes sense to bring in a prefix on these in the driver. drivers/mtd/nand/raw/qcom_nandc.c:153: warning: "PAGE_READ" redefined #define PAGE_READ 0x2 In file included from include/linux/memremap.h:7, from include/linux/mm.h:27, from include/linux/scatterlist.h:8, from include/linux/dma-mapping.h:11, from drivers/mtd/nand/raw/qcom_nandc.c:17: arch/riscv/include/asm/pgtable.h:48: note: this is the location of the previous definition Caught by riscv allmodconfig. Signed-off-by: Olof Johansson Reviewed-by: Miquel Raynal Signed-off-by: Boris Brezillon Signed-off-by: Sasha Levin commit 4ef9e48c9c8f9e4b684d188d7d6c5f18069c86bb Author: Brenda J. Butler Date: Fri Nov 16 17:37:56 2018 -0500 tc-testing: tdc.py: Guard against lack of returncode in executed command [ Upstream commit c6cecf4ae44e4ce9158ef8806358142c3512cd33 ] Add some defensive coding in case one of the subprocesses created by tdc returns nothing. If no object is returned from exec_cmd, then tdc will halt with an unhandled exception. Signed-off-by: Brenda J. Butler Signed-off-by: Lucas Bates Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 9806e7473d10988677c3404301dbbc00cb6d8858 Author: Lucas Bates Date: Fri Nov 16 17:37:55 2018 -0500 tc-testing: tdc.py: ignore errors when decoding stdout/stderr [ Upstream commit 5aaf6428526bcad98d6f51f2f679c919bb75d7e9 ] Prevent exceptions from being raised while decoding output from an executed command. There is no impact on tdc's execution and the verify command phase would fail the pattern match. Signed-off-by: Lucas Bates Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit b8c51924b4e1bc019a81aae3d6456ac26310cd38 Author: Bartosz Golaszewski Date: Thu Nov 8 17:52:53 2018 +0100 gpio: mockup: fix indicated direction [ Upstream commit bff466bac59994cfcceabe4d0be5fdc1c20cd5b8 ] Commit 3edfb7bd76bd ("gpiolib: Show correct direction from the beginning") fixed an existing issue but broke libgpiod tests by changing the default direction of dummy lines to output. We don't break user-space so make gpio-mockup behave as before. Signed-off-by: Bartosz Golaszewski Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit b9284d6c30cb0a273230d83955cdbd71df7198b9 Author: Robert Jarzmik Date: Thu Nov 15 18:16:38 2018 +0100 gpio: pxa: fix legacy non pinctrl aware builds again [ Upstream commit 70cdb6ad6dc342d9643a00c9092e88f0075f2b9a ] As pointed out by Gregor, spitz keyboard matrix is broken, with or without CONFIG_PINCTRL set, quoting : "The gpio matrix keypard on the Zaurus C3x00 (see spitz.c) does not work properly. Noticeable are that rshift+c does nothing where as lshift+c creates C. Opposite it is for rshift+a vs lshift+a, here only rshift works. This affects a few other combinations using the rshift or lshift buttons." As a matter of fact, as for platform_data based builds CONFIG_PINCTRL=n is required for now (as opposed for devicetree builds where it should be set), this means gpio driver should change the direction, which is what was attempted by commit c4e5ffb6f224 ("gpio: pxa: fix legacy non pinctrl aware builds"). Unfortunately, the input case was inverted, and the direction change was never done. This wasn't seen up until now because the initial platform setup (MFP) was setting this direction. Yet in Gregory's case, the matrix-keypad driver changes back and forth the direction dynamically, and this is why he's the first to report it. Fixes: c4e5ffb6f224 ("gpio: pxa: fix legacy non pinctrl aware builds") Tested-by: Greg Signed-off-by: Robert Jarzmik Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 9ebacc1a87541164c9faa528189feb0151e57544 Author: Andrew Morton Date: Thu Nov 15 16:15:20 2018 -0800 drivers/net/ethernet/qlogic/qed/qed_rdma.h: fix typo [ Upstream commit a97b9565338350d70d8d971c4ee6f0d4fa967418 ] Add missing semicolon. Fixes: 291d57f67d244973 ("qed: Fix rdma_info structure allocation") Cc: Michal Kalderon Cc: Denis Bolotin Cc: David S. Miller Signed-off-by: Andrew Morton Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit b53fa368dd8e18822cd496083517b9736d1b5e0d Author: Aya Levin Date: Thu Nov 15 18:05:15 2018 +0200 net/mlx4: Fix UBSAN warning of signed integer overflow [ Upstream commit a463146e67c848cbab5ce706d6528281b7cded08 ] UBSAN: Undefined behavior in drivers/net/ethernet/mellanox/mlx4/resource_tracker.c:626:29 signed integer overflow: 1802201963 + 1802201963 cannot be represented in type 'int' The union of res_reserved and res_port_rsvd[MLX4_MAX_PORTS] monitors granting of reserved resources. The grant operation is calculated and protected, thus both members of the union cannot be negative. Changed type of res_reserved and of res_port_rsvd[MLX4_MAX_PORTS] from signed int to unsigned int, allowing large value. Fixes: 5a0d0a6161ae ("mlx4: Structures and init/teardown for VF resource quotas") Signed-off-by: Aya Levin Signed-off-by: Tariq Toukan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 034f7ad3f7066b2c0ef03710a266e9d471f47560 Author: Tariq Toukan Date: Thu Nov 15 18:05:14 2018 +0200 net/mlx4_core: Fix uninitialized variable compilation warning [ Upstream commit 3ea7e7ea53c9f6ee41cb69a29c375fe9dd9a56a7 ] Initialize the uid variable to zero to avoid the compilation warning. Fixes: 7a89399ffad7 ("net/mlx4: Add mlx4_bitmap zone allocator") Signed-off-by: Tariq Toukan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 5110c0406c8c83db24995ffeb01bcabe3be52b2f Author: Jack Morgenstein Date: Thu Nov 15 18:05:13 2018 +0200 net/mlx4_core: Zero out lkey field in SW2HW_MPT fw command [ Upstream commit bd85fbc2038a1bbe84990b23ff69b6fc81a32b2c ] When re-registering a user mr, the mpt information for the existing mr when running SRIOV is obtained via the QUERY_MPT fw command. The returned information includes the mpt's lkey. This retrieved mpt information is used to move the mpt back to hardware ownership in the rereg flow (via the SW2HW_MPT fw command when running SRIOV). The fw API spec states that for SW2HW_MPT, the lkey field must be zero. Any ConnectX-3 PF driver which checks for strict spec adherence will return failure for SW2HW_MPT if the lkey field is not zero (although the fw in practice ignores this field for SW2HW_MPT). Thus, in order to conform to the fw API spec, set the lkey field to zero before invoking SW2HW_MPT when running SRIOV. Fixes: e630664c8383 ("mlx4_core: Add helper functions to support MR re-registration") Signed-off-by: Jack Morgenstein Signed-off-by: Tariq Toukan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 3374518d4d1ae021dc60885f4ea8dca0a3ca290f Author: Nicholas Kazlauskas Date: Thu Nov 15 17:21:34 2018 -0500 drm/amd/display: Support amdgpu "max bpc" connector property (v2) [ Upstream commit 07e3a1cfb0568b6d8d7862077029af96af6690ea ] [Why] Many panels support more than 8bpc but some modes are unavailable while running at greater than 8bpc due to DP/HDMI bandwidth constraints. Support for more than 8bpc was added recently in the driver but it defaults to the maximum supported bpc - locking out these modes. This should be a user configurable option such that the user can select what bpc configuration they would like. [How] This patch adds support for getting and setting the amdgpu driver specific "max bpc" property on the connector. It also adds support for limiting the output bpc based on the property value. The default limitation is the lowest value in the range, 8bpc. This was the old value before the range was uncapped. This patch should be updated/replaced later once common drm support for max bpc lands. Bugzilla: https://bugs.freedesktop.org/108542 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=201585 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=200645 Fixes: e03fd3f300f6 ("drm/amd/display: Do not limit color depth to 8bpc") v2: rebase on upstream (Alex) Signed-off-by: Nicholas Kazlauskas Acked-by: Alex Deucher Reviewed-by: Harry Wentland Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit a0c25b4098b8de23f34f81860ddc3cbaaa159189 Author: Nicholas Kazlauskas Date: Thu Nov 15 17:19:12 2018 -0500 drm/amdgpu: Add amdgpu "max bpc" connector property (v2) [ Upstream commit 69756c6ff0de478c10100481f16c966dde3b5339 ] [Why] Many panels support more than 8bpc but some modes are unavailable while running at greater than 8bpc due to DP/HDMI bandwidth constraints. Support for more than 8bpc was added recently in the driver but it defaults to the maximum supported bpc - locking out these modes. This should be a user configurable option such that the user can select what bpc configuration they would like. [How] This patch introduces the "max bpc" amdgpu driver specific connector property so the user can limit the maximum bpc. It ranges from 8 to 16. This doesn't directly set the preferred bpc for the panel since it follows Intel's existing driver conventions. This proprety should be removed once common drm support for max bpc lands. v2: rebase on upstream (Alex) Signed-off-by: Nicholas Kazlauskas Acked-by: Alex Deucher Reviewed-by: Harry Wentland Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 12163e3e69020fa409110a00fffbfd4c8969df2c Author: Vasundhara Volam Date: Thu Nov 15 03:25:42 2018 -0500 bnxt_en: Fix filling time in bnxt_fill_coredump_record() [ Upstream commit 8dc5ae2d48976764cf3498e97963fa06befefb0e ] Fix the year and month offset while storing it in bnxt_fill_coredump_record(). Fixes: 6c5657d085ae ("bnxt_en: Add support for ethtool get dump.") Signed-off-by: Vasundhara Volam Signed-off-by: Michael Chan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 0e79e30e612143771b343ff330fc0dbe54096ad8 Author: James Smart Date: Wed Nov 14 16:35:10 2018 -0800 nvme-fc: resolve io failures during connect [ Upstream commit 4cff280a5fccf6513ed9e895bb3a4e7ad8b0cedc ] If an io error occurs on an io issued while connecting, recovery of the io falls flat as the state checking ends up nooping the error handler. Create an err_work work item that is scheduled upon an io error while connecting. The work thread terminates all io on all queues and marks the queues as not connected. The termination of the io will return back to the callee, which will then back out of the connection attempt and will reschedule, if possible, the connection attempt. The changes: - in case there are several commands hitting the error handler, a state flag is kept so that the error work is only scheduled once, on the first error. The subsequent errors can be ignored. - The calling sequence to stop keep alive and terminate the queues and their io is lifted from the reset routine. Made a small service routine used by both reset and err_work. - During debugging, found that the teardown path can reference an uninitialized pointer, resulting in a NULL pointer oops. The aen_ops weren't initialized yet. Add validation on their initialization before calling the teardown routine. Signed-off-by: James Smart Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit b65fa443e56ee2742ed91c6dfcaa4ee428076e30 Author: Ursula Braun Date: Mon Nov 12 17:06:12 2018 +0100 s390/ism: clear dmbe_mask bit before SMC IRQ handling [ Upstream commit 007b656851ed7f94ba0fa358ac3e5d7705da6846 ] SMC-D stress workload showed connection stalls. Since the firmware decides to skip raising an interrupt if the SBA DMBE mask bit is still set, this SBA DMBE mask bit should be cleared before the IRQ handling in the SMC code runs. Otherwise there are small windows possible with missing interrupts for incoming data. SMC-D currently does not care about the old value of the SBA DMBE mask. Acked-by: Sebastian Ott Signed-off-by: Ursula Braun Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 8b87305f816cf58b7a4c840b2bedfd37a8c06254 Author: Shen Jing Date: Thu Nov 1 15:35:17 2018 +0530 Revert "usb: gadget: ffs: Fix BUG when userland exits with submitted AIO transfers" [ Upstream commit a9c859033f6ec772f8e3228c343bb1321584ae0e ] This reverts commit b4194da3f9087dd38d91b40f9bec42d59ce589a8 since it causes list corruption followed by kernel panic: Workqueue: adb ffs_aio_cancel_worker RIP: 0010:__list_add_valid+0x4d/0x70 Call Trace: insert_work+0x47/0xb0 __queue_work+0xf6/0x400 queue_work_on+0x65/0x70 dwc3_gadget_giveback+0x44/0x50 [dwc3] dwc3_gadget_ep_dequeue+0x83/0x2d0 [dwc3] ? finish_wait+0x80/0x80 usb_ep_dequeue+0x1e/0x90 process_one_work+0x18c/0x3b0 worker_thread+0x3c/0x390 ? process_one_work+0x3b0/0x3b0 kthread+0x11e/0x140 ? kthread_create_worker_on_cpu+0x70/0x70 ret_from_fork+0x3a/0x50 This issue is seen with warm reboot stability testing. Signed-off-by: Shen Jing Signed-off-by: Saranya Gopal Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit 3355199746b89d6e92d83e788b36ce1fe4a98813 Author: Dan Carpenter Date: Thu Oct 18 10:36:47 2018 +0300 usb: dwc2: pci: Fix an error code in probe [ Upstream commit 3c135e8900199e3b9375c1eff808cceba2ee37de ] We added some error handling to this function but forgot to set the error code on this path. Fixes: ecd29dabb2ba ("usb: dwc2: pci: Handle error cleanup in probe") Acked-by: Minas Harutyunyan Signed-off-by: Dan Carpenter Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit 4f22a32f555d1088165ae089e8d92ca3baadc61f Author: Denis Bolotin Date: Mon Nov 12 12:50:23 2018 +0200 qed: Fix reading wrong value in loop condition [ Upstream commit ed4eac20dcffdad47709422e0cb925981b056668 ] The value of "sb_index" is written by the hardware. Reading its value and writing it to "index" must finish before checking the loop condition. Signed-off-by: Denis Bolotin Signed-off-by: Michal Kalderon Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit d4105c836c131bc07c778a7f9e95738e91ff2f94 Author: Michal Kalderon Date: Mon Nov 12 12:50:22 2018 +0200 qed: Fix rdma_info structure allocation [ Upstream commit 291d57f67d2449737d1e370ab5b9a583818eaa0c ] Certain flows need to access the rdma-info structure, for example dcbx update flows. In some cases there can be a race between the allocation or deallocation of the structure which was done in roce start / roce stop and an asynchrounous dcbx event that tries to access the structure. For this reason, we move the allocation of the rdma_info structure to be similar to the iscsi/fcoe info structures which are allocated during device setup. We add a new field of "active" to the struct to define whether roce has already been started or not, and this is checked instead of whether the pointer to the info structure. Fixes: 51ff17251c9c ("qed: Add support for RoCE hw init") Signed-off-by: Michal Kalderon Signed-off-by: Denis Bolotin Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 52da24907e6e775a5f153e934417db66c1d17af0 Author: Denis Bolotin Date: Mon Nov 12 12:50:21 2018 +0200 qed: Fix overriding offload_tc by protocols without APP TLV [ Upstream commit e90202ed1cf9672c48a363c84a929932ebfe6fc0 ] The TC received from APP TLV is stored in offload_tc, and should not be set by protocols which did not receive an APP TLV. Fixed the condition when overriding the offload_tc. Signed-off-by: Denis Bolotin Signed-off-by: Michal Kalderon Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 631ebe93bdcb7893e64f5e383d84d5367e92a79c Author: Denis Bolotin Date: Mon Nov 12 12:50:20 2018 +0200 qed: Fix PTT leak in qed_drain() [ Upstream commit 9aaa4e8ba12972d674caeefbc5f88d83235dd697 ] Release PTT before entering error flow. Signed-off-by: Denis Bolotin Signed-off-by: Michal Kalderon Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 147bcca117b84bdb4733f11e5892c59376e67a97 Author: Sudarsana Reddy Kalluru Date: Sun Nov 11 18:27:34 2018 -0800 bnx2x: Assign unique DMAE channel number for FW DMAE transactions. [ Upstream commit 77e461d14ed141253573eeeb4d34eccc51e38328 ] Driver assigns DMAE channel 0 for FW as part of START_RAMROD command. FW uses this channel for DMAE operations (e.g., TIME_SYNC implementation). Driver also uses the same channel 0 for DMAE operations for some of the PFs (e.g., PF0 on Port0). This could lead to concurrent access to the DMAE channel by FW and driver which is not legal. Hence need to assign unique DMAE id for FW. Currently following DMAE channels are used by the clients, MFW - OCBB/OCSD functionality uses DMAE channel 14/15 Driver 0-3 and 8-11 (for PF dmae operations) 4 and 12 (for stats requests) Assigning unique dmae_id '13' to the FW. Changes from previous version: ------------------------------ v2: Incorporated the review comments. Signed-off-by: Sudarsana Reddy Kalluru Signed-off-by: Michal Kalderon Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 821d0b9afa8d136c5d2c3263a5c060a11b332c7e Author: Filippo Sironi Date: Mon Nov 12 12:26:30 2018 +0000 amd/iommu: Fix Guest Virtual APIC Log Tail Address Register [ Upstream commit ab99be4683d9db33b100497d463274ebd23bd67e ] This register should have been programmed with the physical address of the memory location containing the shadow tail pointer for the guest virtual APIC log instead of the base address. Fixes: 8bda0cfbdc1a ('iommu/amd: Detect and initialize guest vAPIC log') Signed-off-by: Filippo Sironi Signed-off-by: Wei Wang Signed-off-by: Suravee Suthikulpanit Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 2e959f2509499d6586e244c7f3a92b52fa692032 Author: Sven Eckelmann Date: Wed Nov 7 23:09:12 2018 +0100 batman-adv: Expand merged fragment buffer for full packet [ Upstream commit d7d8bbb40a5b1f682ee6589e212934f4c6b8ad60 ] The complete size ("total_size") of the fragmented packet is stored in the fragment header and in the size of the fragment chain. When the fragments are ready for merge, the skbuff's tail of the first fragment is expanded to have enough room after the data pointer for at least total_size. This means that it gets expanded by total_size - first_skb->len. But this is ignoring the fact that after expanding the buffer, the fragment header is pulled by from this buffer. Assuming that the tailroom of the buffer was already 0, the buffer after the data pointer of the skbuff is now only total_size - len(fragment_header) large. When the merge function is then processing the remaining fragments, the code to copy the data over to the merged skbuff will cause an skb_over_panic when it tries to actually put enough data to fill the total_size bytes of the packet. The size of the skb_pull must therefore also be taken into account when the buffer's tailroom is expanded. Fixes: 610bfc6bc99b ("batman-adv: Receive fragmented packets and merge") Reported-by: Martin Weinelt Co-authored-by: Linus Lüssing Signed-off-by: Sven Eckelmann Signed-off-by: Simon Wunderlich Signed-off-by: Sasha Levin commit 25683accf7c74580285ab42957b25e6518cf3387 Author: Sven Eckelmann Date: Tue Oct 30 12:17:10 2018 +0100 batman-adv: Use explicit tvlv padding for ELP packets [ Upstream commit f4156f9656feac21f4de712fac94fae964c5d402 ] The announcement messages of batman-adv COMPAT_VERSION 15 have the possibility to announce additional information via a dynamic TVLV part. This part is optional for the ELP packets and currently not parsed by the Linux implementation. Still out-of-tree versions are using it to transport things like neighbor hashes to optimize the rebroadcast behavior. Since the ELP broadcast packets are smaller than the minimal ethernet packet, it often has to be padded. This is often done (as specified in RFC894) with octets of zero and thus work perfectly fine with the TVLV part (making it a zero length and thus empty). But not all ethernet compatible hardware seems to follow this advice. To avoid ambiguous situations when parsing the TVLV header, just force the 4 bytes (TVLV length + padding) after the required ELP header to zero. Fixes: d6f94d91f766 ("batman-adv: ELP - adding basic infrastructure") Reported-by: Linus Lüssing Signed-off-by: Sven Eckelmann Signed-off-by: Simon Wunderlich Signed-off-by: Sasha Levin commit 92724c1deaf9ca829448b91c271f5296e8e8c9d2 Author: Benson Leung Date: Thu Nov 8 15:59:21 2018 -0800 HID: input: Ignore battery reported by Symbol DS4308 [ Upstream commit 0fd791841a6d67af1155a9c3de54dea51220721e ] The Motorola/Zebra Symbol DS4308-HD is a handheld USB barcode scanner which does not have a battery, but reports one anyway that always has capacity 2. Let's apply the IGNORE quirk to prevent it from being treated like a power supply so that userspaces don't get confused that this accessory is almost out of power and warn the user that they need to charge their wired barcode scanner. Reported here: https://bugs.chromium.org/p/chromium/issues/detail?id=804720 Signed-off-by: Benson Leung Reviewed-by: Benjamin Tissoires Signed-off-by: Benjamin Tissoires Signed-off-by: Sasha Levin commit 27b504af882ba40e4bbada1fec430ffef98f12ca Author: Colin Ian King Date: Fri Oct 19 13:58:01 2018 +0100 test_firmware: fix error return getting clobbered [ Upstream commit 8bb0a88600f0267cfcc245d34f8c4abe8c282713 ] In the case where eq->fw->size > PAGE_SIZE the error return rc is being set to EINVAL however this is being overwritten to rc = req->fw->size because the error exit path via label 'out' is not being taken. Fix this by adding the jump to the error exit path 'out'. Detected by CoverityScan, CID#1453465 ("Unused value") Fixes: c92316bf8e94 ("test_firmware: add batched firmware tests") Signed-off-by: Colin Ian King Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 0e3e8e31877a043c0180f2a011bae22db509d67f Author: Fabrizio Castro Date: Mon Sep 10 11:43:13 2018 +0100 can: rcar_can: Fix erroneous registration [ Upstream commit 68c8d209cd4337da4fa04c672f0b62bb735969bc ] Assigning 2 to "renesas,can-clock-select" tricks the driver into registering the CAN interface, even though we don't want that. This patch improves one of the checks to prevent that from happening. Fixes: 862e2b6af9413b43 ("can: rcar_can: support all input clocks") Signed-off-by: Fabrizio Castro Signed-off-by: Chris Paterson Reviewed-by: Simon Horman Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit 1f329e64e1f1d8b24d47d804afb2ae8e4ddc83fe Author: YueHaibing Date: Wed Aug 29 01:46:54 2018 +0000 can: ucan: remove set but not used variable 'udev' [ Upstream commit 207681fc5f3d5d398f106d1ae0080fc2373f707a ] Fixes gcc '-Wunused-but-set-variable' warning: drivers/net/can/usb/ucan.c: In function 'ucan_disconnect': drivers/net/can/usb/ucan.c:1578:21: warning: variable 'udev' set but not used [-Wunused-but-set-variable] struct usb_device *udev; Signed-off-by: YueHaibing Reviewed-by: Martin Elshuber Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit f2e78c08e8442f0b9098edc0fa6ceae1b83520e1 Author: Wei Li Date: Thu Nov 8 09:08:29 2018 -0800 scsi: ufs: Fix hynix ufs bug with quirk on hi36xx SoC [ Upstream commit 8e4829c6f7470722c1f5a1dc5769ebe09ef036d6 ] Hynix ufs has deviations on hi36xx platform which will result in ufs bursts transfer failures. To fix the problem, the Hynix device must set the register VS_DebugSaveConfigTime to 0x10, which will set time reference for SaveConfigTime is 250 ns. The time reference for SaveConfigTime is 40 ns by default. This patch is necessary to boot on HiKey960 boards that use Hynix UFS chips (H28U62301AMR model: hB8aL1). Cc: Vinayak Holikatti Cc: "James E.J. Bottomley" Cc: "Martin K. Petersen" Cc: linux-scsi@vger.kernel.org Signed-off-by: Wei Li Signed-off-by: Dmitry Shmidt [jstultz: Forward ported from older code, slight tweak to commit message] Signed-off-by: John Stultz Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit c97a2a726cef389dd0f85f12cb8a3bddb5711d9c Author: Geert Uytterhoeven Date: Wed Nov 7 14:18:50 2018 +0100 iommu/ipmmu-vmsa: Fix crash on early domain free [ Upstream commit e5b78f2e349eef5d4fca5dc1cf5a3b4b2cc27abd ] If iommu_ops.add_device() fails, iommu_ops.domain_free() is still called, leading to a crash, as the domain was only partially initialized: ipmmu-vmsa e67b0000.mmu: Cannot accommodate DMA translation for IOMMU page tables sata_rcar ee300000.sata: Unable to initialize IPMMU context iommu: Failed to add device ee300000.sata to group 0: -22 Unable to handle kernel NULL pointer dereference at virtual address 0000000000000038 ... Call trace: ipmmu_domain_free+0x1c/0xa0 iommu_group_release+0x48/0x68 kobject_put+0x74/0xe8 kobject_del.part.0+0x3c/0x50 kobject_put+0x60/0xe8 iommu_group_get_for_dev+0xa8/0x1f0 ipmmu_add_device+0x1c/0x40 of_iommu_configure+0x118/0x190 Fix this by checking if the domain's context already exists, before trying to destroy it. Signed-off-by: Geert Uytterhoeven Reviewed-by: Robin Murphy Fixes: d25a2a16f0889 ('iommu: Add driver for Renesas VMSA-compatible IPMMU') Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit e2807327b56264827373e8838c3562a026c0f35b Author: Arnd Bergmann Date: Mon Nov 5 16:51:47 2018 +0100 mt76: fix building without CONFIG_LEDS_CLASS [ Upstream commit b374e8686fc35ae124e62dc78725ea656ba1ef8a ] When CONFIG_LEDS_CLASS is disabled, or it is a loadable module while mt76 is built-in, we run into a link error: drivers/net/wireless/mediatek/mt76/mac80211.o: In function `mt76_register_device': mac80211.c:(.text+0xb78): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `devm_of_led_classdev_register' We don't really need a hard dependency here as the driver can presumably work just fine without LEDs, so this follows the iwlwifi example and adds a separate Kconfig option for the LED support, this will be available whenever it will link, and otherwise the respective code gets left out from the driver object. Fixes: 17f1de56df05 ("mt76: add common code shared between multiple chipsets") Signed-off-by: Arnd Bergmann Signed-off-by: Lorenzo Bianconi Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit 4a4c9b29a0c1b0cf2567ccca9c939f96ce27ddca Author: Rafał Miłecki Date: Fri Oct 26 12:50:39 2018 +0200 brcmutil: really fix decoding channel info for 160 MHz bandwidth [ Upstream commit 3401d42c7ea2d064d15c66698ff8eb96553179ce ] Previous commit /adding/ support for 160 MHz chanspecs was incomplete. It didn't set bandwidth info and didn't extract control channel info. As the result it was also using uninitialized "sb" var. This change has been tested for two chanspecs found to be reported by some devices/firmwares: 1) 60/160 (0xee32) Before: chnum:50 control_ch_num:36 After: chnum:50 control_ch_num:60 2) 120/160 (0xed72) Before: chnum:114 control_ch_num:100 After: chnum:114 control_ch_num:120 Fixes: 330994e8e8ec ("brcmfmac: fix for proper support of 160MHz bandwidth") Signed-off-by: Rafał Miłecki Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit 093255da5688347ddaa5f118c07b2873f542acdd Author: Lu Baolu Date: Mon Nov 5 10:18:58 2018 +0800 iommu/vt-d: Fix NULL pointer dereference in prq_event_thread() [ Upstream commit 19ed3e2dd8549c1a34914e8dad01b64e7837645a ] When handling page request without pasid event, go to "no_pasid" branch instead of "bad_req". Otherwise, a NULL pointer deference will happen there. Cc: Ashok Raj Cc: Jacob Pan Cc: Sohil Mehta Signed-off-by: Lu Baolu Fixes: a222a7f0bb6c9 'iommu/vt-d: Implement page request handling' Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit f84263bfd8015da1a48a9f7ab4aaacb1b105086c Author: Sakari Ailus Date: Wed Oct 10 04:01:05 2018 -0400 media: ipu3-cio2: Unregister device nodes first, then release resources [ Upstream commit 32388d6ef7cffc7d8291b67f8dfa26acd45217fd ] While there are issues related to object lifetime management, unregister the media device first, followed immediately by other device nodes when the driver is being unbound. Only then the resources needed by the driver may be released. This is slightly safer. Signed-off-by: Sakari Ailus Tested-by: Bingbu Cao Reviewed-by: Bingbu Cao Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 61880fb56851ca60b0520bc15378eef24e147f96 Author: Sakari Ailus Date: Tue Oct 9 07:49:49 2018 -0400 media: omap3isp: Unregister media device as first [ Upstream commit 30efae3d789cd0714ef795545a46749236e29558 ] While there are issues related to object lifetime management, unregister the media device first when the driver is being unbound. This is slightly safer. Signed-off-by: Sakari Ailus Reviewed-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit cd7b7f509cd05dfda2a47df49a35fe40615e2be1 Author: Hans Verkuil Date: Wed Oct 10 07:12:15 2018 -0400 media: cec: check for non-OK/NACK conditions while claiming a LA [ Upstream commit 55623b4169056d7bb493d1c6f715991f8db67302 ] During the configuration phase of a CEC adapter it is trying to claim a free logical address by polling. However, the code doesn't check if there were errors other than OK or NACK, those are just treated as if the poll was NACKed. Instead check for such errors and retry the poll. And if the problem persists then don't claim this LA since there is something weird going on. Signed-off-by: Hans Verkuil Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 35eaa0ee4e69cc17166e10c0c17506d050a3e60d Author: Hans Verkuil Date: Wed Oct 10 03:03:43 2018 -0400 media: vicodec: lower minimum height to 360 [ Upstream commit 7cf7b2e977abf3f992036939e35a8eab60013aff ] Lower the minimum height to 360 to be consistent with the webcam input of vivid. The 480 was rather arbitrary but it made it harder to use vivid as a source for encoding since the default resolution when you load vivid is 640x360. Signed-off-by: Hans Verkuil Reviewed-by: Kieran Bingham Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin