commit 128f430ae9acb403059d02d9bbcbd9dcf52968a0 Author: Greg Kroah-Hartman Date: Fri Dec 13 08:49:56 2019 +0100 Linux 5.3.16 commit 8332a60f3c5696f0dc97d267e48a8ddffe792597 Author: Kai Vehmanen Date: Mon Nov 11 15:38:38 2019 +0200 ALSA: hda: hdmi - fix pin setup on Tigerlake [ Upstream commit a7d0358ea3b7f8d7216e663c1ae71cabf7ac24e3 ] Apply same logic to pin setup as on previous platforms. Fixes errors in HDMI/DP playback. Tested with both snd-hda-intel and SOF drivers. Fixes: 9a11ba7388f1 ("ALSA: hda: hdmi - add Tigerlake support") Signed-off-by: Kai Vehmanen Link: https://lore.kernel.org/r/20191111133838.21213-1-kai.vehmanen@linux.intel.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 410448e640470b3cf1eaac06a568dba92147722d Author: Prabhakar Kushwaha Date: Tue Oct 22 13:27:17 2019 +0000 kselftest: Fix NULL INSTALL_PATH for TARGETS runlist [ Upstream commit 02bf1f8b3c43eec5053c35c14fb9f138186b4123 ] As per commit 131b30c94fbc ("kselftest: exclude failed TARGETS from runlist") failed targets were excluded from the runlist. But value $$INSTALL_PATH is always NULL. It should be $INSTALL_PATH instead $$INSTALL_PATH. So, fix Makefile to use $INSTALL_PATH. Fixes: 131b30c94fbc ("kselftest: exclude failed TARGETS from runlist") Signed-off-by: Prabhakar Kushwaha Reviewed-by: Cristian Marussi Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit 24352f42bf946cab7f0724dbc532418cf810d29a Author: Adrian Hunter Date: Wed Nov 27 11:56:31 2019 +0200 perf script: Fix invalid LBR/binary mismatch error [ Upstream commit 5172672da02e483d9b3c4d814c3482d0c8ffb1a6 ] The 'len' returned by grab_bb() includes an extra MAXINSN bytes to allow for the last instruction, so the the final 'offs' will not be 'len'. Fix the error condition logic accordingly. Before: $ perf record -e '{intel_pt//,cpu/mem_inst_retired.all_loads,aux-sample-size=8192/pp}:u' grep -rqs jhgjhg /boot [ perf record: Woken up 19 times to write data ] [ perf record: Captured and wrote 2.274 MB perf.data ] $ perf script -F +brstackinsn --xed --itrace=i1usl100 | head grep 13759 [002] 8091.310257: 1862 instructions:uH: 5641d58069eb bmexec+0x86b (/bin/grep) bmexec+2485: 00005641d5806b35 jnz 0x5641d5806bd0 # MISPRED 00005641d5806bd0 movzxb (%r13,%rdx,1), %eax 00005641d5806bd6 add %rdi, %rax 00005641d5806bd9 movzxb -0x1(%rax), %edx 00005641d5806bdd cmp %rax, %r14 00005641d5806be0 jnb 0x5641d58069c0 # MISPRED mismatch of LBR data and executable 00005641d58069c0 movzxb (%r13,%rdx,1), %edi After: $ perf script -F +brstackinsn --xed --itrace=i1usl100 | head grep 13759 [002] 8091.310257: 1862 instructions:uH: 5641d58069eb bmexec+0x86b (/bin/grep) bmexec+2485: 00005641d5806b35 jnz 0x5641d5806bd0 # MISPRED 00005641d5806bd0 movzxb (%r13,%rdx,1), %eax 00005641d5806bd6 add %rdi, %rax 00005641d5806bd9 movzxb -0x1(%rax), %edx 00005641d5806bdd cmp %rax, %r14 00005641d5806be0 jnb 0x5641d58069c0 # MISPRED 00005641d58069c0 movzxb (%r13,%rdx,1), %edi 00005641d58069c6 add %rax, %rdi Fixes: e98df280bc2a ("perf script brstackinsn: Fix recovery from LBR/binary mismatch") Reported-by: Andi Kleen Signed-off-by: Adrian Hunter Cc: Jiri Olsa Link: http://lore.kernel.org/lkml/20191127095631.15663-1-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit f737517d1d315854a6576ea489369dfdf94abb77 Author: Robert Richter Date: Tue Nov 5 20:07:51 2019 +0000 EDAC/ghes: Fix locking and memory barrier issues [ Upstream commit 23f61b9fc5cc10d87f66e50518707eec2a0fbda1 ] The ghes registration and refcount is broken in several ways: * ghes_edac_register() returns with success for a 2nd instance even if a first instance's registration is still running. This is not correct as the first instance may fail later. A subsequent registration may not finish before the first. Parallel registrations must be avoided. * The refcount was increased even if a registration failed. This leads to stale counters preventing the device from being released. * The ghes refcount may not be decremented properly on unregistration. Always decrement the refcount once ghes_edac_unregister() is called to keep the refcount sane. * The ghes_pvt pointer is handed to the irq handler before registration finished. * The mci structure could be freed while the irq handler is running. Fix this by adding a mutex to ghes_edac_register(). This mutex serializes instances to register and unregister. The refcount is only increased if the registration succeeded. This makes sure the refcount is in a consistent state after registering or unregistering a device. Note: A spinlock cannot be used here as the code section may sleep. The ghes_pvt is protected by ghes_lock now. This ensures the pointer is not updated before registration was finished or while the irq handler is running. It is unset before unregistering the device including necessary (implicit) memory barriers making the changes visible to other CPUs. Thus, the device can not be used anymore by an interrupt. Also, rename ghes_init to ghes_refcount for better readability and switch to refcount API. A refcount is needed because there can be multiple GHES structures being defined (see ACPI 6.3 specification, 18.3.2.7 Generic Hardware Error Source, "Some platforms may describe multiple Generic Hardware Error Source structures with different notification types, ..."). Another approach to use the mci's device refcount (get_device()) and have a release function does not work here. A release function will be called only for device_release() with the last put_device() call. The device must be deleted *before* that with device_del(). This is only possible by maintaining an own refcount. [ bp: touchups. ] Fixes: 0fe5f281f749 ("EDAC, ghes: Model a single, logical memory controller") Fixes: 1e72e673b9d1 ("EDAC/ghes: Fix Use after free in ghes_edac remove path") Co-developed-by: James Morse Signed-off-by: James Morse Co-developed-by: Borislav Petkov Signed-off-by: Borislav Petkov Signed-off-by: Robert Richter Signed-off-by: Borislav Petkov Cc: "linux-edac@vger.kernel.org" Cc: Mauro Carvalho Chehab Cc: Tony Luck Link: https://lkml.kernel.org/r/20191105200732.3053-1-rrichter@marvell.com Signed-off-by: Sasha Levin commit 898531d408784b8b051337d08d07ada93ff6bdd4 Author: Joel Stanley Date: Fri Nov 8 13:59:05 2019 +1030 watchdog: aspeed: Fix clock behaviour for ast2600 [ Upstream commit c04571251b3d842096f1597f5d4badb508be016d ] The ast2600 no longer uses bit 4 in the control register to indicate a 1MHz clock (It now controls whether this watchdog is reset by a SOC reset). This means we do not want to set it. It also does not need to be set for the ast2500, as it is read-only on that SoC. The comment next to the clock rate selection wandered away from where it was set, so put it back next to the register setting it's describing. Fixes: b3528b487448 ("watchdog: aspeed: Add support for AST2600") Signed-off-by: Joel Stanley Reviewed-by: Cédric Le Goater Reviewed-by: Guenter Roeck Link: https://lore.kernel.org/r/20191108032905.22463-1-joel@jms.id.au Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck Signed-off-by: Sasha Levin commit cc12de4c09652b18b949e842d62eda5a2cb1008b Author: Christophe JAILLET Date: Thu Aug 22 23:15:18 2019 +0200 drm/mcde: Fix an error handling path in 'mcde_probe()' [ Upstream commit 15c665bb4637310bc8ce5f357b6a6e5a8aafc7c1 ] If we don't find any matching components, we should go through the error handling path, in order to free some resources. Fixes: ca5be902a87d ("drm/mcde: Fix uninitialized variable") Signed-off-by: Christophe JAILLET Signed-off-by: Linus Walleij Link: https://patchwork.freedesktop.org/patch/msgid/20190822211518.5578-1-christophe.jaillet@wanadoo.fr Signed-off-by: Sasha Levin commit 701be55e4ba5c6d511e94269709ac1ad11e91a27 Author: Dan Carpenter Date: Sat Sep 21 09:00:31 2019 +0300 md/raid0: Fix an error message in raid0_make_request() [ Upstream commit e3fc3f3d0943b126f76b8533960e4168412d9e5a ] The first argument to WARN() is supposed to be a condition. The original code will just print the mdname() instead of the full warning message. Fixes: c84a1372df92 ("md/raid0: avoid RAID0 data corruption due to layout confusion.") Signed-off-by: Dan Carpenter Signed-off-by: Song Liu Signed-off-by: Sasha Levin commit a49ffffab6158ccc9bdf20e6ea654200e763e39b Author: Anson Huang Date: Tue Oct 22 16:33:19 2019 +0800 cpufreq: imx-cpufreq-dt: Correct i.MX8MN's default speed grade value [ Upstream commit af44d180e3de4cb411ce327b147ea3513f0bbbcb ] i.MX8MN has different speed grade definition compared to i.MX8MQ/i.MX8MM, when fuses are NOT written, the default speed_grade should be set to minimum available OPP defined in DT which is 1.2GHz, the corresponding speed_grade value should be 0xb. Fixes: 5b8010ba70d5 ("cpufreq: imx-cpufreq-dt: Add i.MX8MN support") Signed-off-by: Anson Huang Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit a24ab04028dbb531caa9bd57236f814aab1b86db Author: Takashi Iwai Date: Mon Oct 28 11:58:03 2019 +0100 ALSA: hda - Fix pending unsol events at shutdown [ Upstream commit ca58f55108fee41d87c9123f85ad4863e5de7f45 ] This is an alternative fix attemp for the issue reported in the commit caa8422d01e9 ("ALSA: hda: Flush interrupts on disabling") that was reverted later due to regressions. Instead of tweaking the hardware disablement order and the enforced irq flushing, do calling cancel_work_sync() of the unsol work early enough, and explicitly ignore the unsol events during the shutdown by checking the bus->shutdown flag. Fixes: caa8422d01e9 ("ALSA: hda: Flush interrupts on disabling") Cc: Chris Wilson Link: https://lore.kernel.org/r/s5h1ruxt9cz.wl-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 9e4bc1ba9f02d31b5f727f7c0a49f82dca0875b7 Author: Paolo Bonzini Date: Wed Dec 4 10:28:54 2019 +0100 KVM: x86: fix out-of-bounds write in KVM_GET_EMULATED_CPUID (CVE-2019-19332) commit 433f4ba1904100da65a311033f17a9bf586b287e upstream. The bounds check was present in KVM_GET_SUPPORTED_CPUID but not KVM_GET_EMULATED_CPUID. Reported-by: syzbot+e3f4897236c4eeb8af4f@syzkaller.appspotmail.com Fixes: 84cffe499b94 ("kvm: Emulate MOVBE", 2013-10-29) Signed-off-by: Paolo Bonzini Cc: Ben Hutchings Signed-off-by: Greg Kroah-Hartman commit b7a1f2e831c1ea95b83474856966b1cc1cd7b8e5 Author: Jann Horn Date: Fri Oct 18 22:56:31 2019 +0200 binder: Handle start==NULL in binder_update_page_range() commit 2a9edd056ed4fbf9d2e797c3fc06335af35bccc4 upstream. The old loop wouldn't stop when reaching `start` if `start==NULL`, instead continuing backwards to index -1 and crashing. Luckily you need to be highly privileged to map things at NULL, so it's not a big problem. Fix it by adjusting the loop so that the loop variable is always in bounds. This patch is deliberately minimal to simplify backporting, but IMO this function could use a refactor. The jump labels in the second loop body are horrible (the error gotos should be jumping to free_range instead), and both loops would look nicer if they just iterated upwards through indices. And the up_read()+mmput() shouldn't be duplicated like that. Cc: stable@vger.kernel.org Fixes: 457b9a6f09f0 ("Staging: android: add binder driver") Signed-off-by: Jann Horn Acked-by: Christian Brauner Link: https://lore.kernel.org/r/20191018205631.248274-3-jannh@google.com Signed-off-by: Greg Kroah-Hartman commit e82a217175179c9b936f381fb1474fcb12ab4b65 Author: Jann Horn Date: Fri Oct 18 22:56:30 2019 +0200 binder: Prevent repeated use of ->mmap() via NULL mapping commit a7a74d7ff55a0c657bc46238b050460b9eacea95 upstream. binder_alloc_mmap_handler() attempts to detect the use of ->mmap() on a binder_proc whose binder_alloc has already been initialized by checking whether alloc->buffer is non-zero. Before commit 880211667b20 ("binder: remove kernel vm_area for buffer space"), alloc->buffer was a kernel mapping address, which is always non-zero, but since that commit, it is a userspace mapping address. A sufficiently privileged user can map /dev/binder at NULL, tricking binder_alloc_mmap_handler() into assuming that the binder_proc has not been mapped yet. This leads to memory unsafety. Luckily, no context on Android has such privileges, and on a typical Linux desktop system, you need to be root to do that. Fix it by using the mapping size instead of the mapping address to distinguish the mapped case. A valid VMA can't have size zero. Fixes: 880211667b20 ("binder: remove kernel vm_area for buffer space") Cc: stable@vger.kernel.org Signed-off-by: Jann Horn Acked-by: Christian Brauner Link: https://lore.kernel.org/r/20191018205631.248274-2-jannh@google.com Signed-off-by: Greg Kroah-Hartman commit 4685fa9c260d9d7b42f70531542bf4ee283e2c1a Author: Jann Horn Date: Fri Oct 18 22:56:29 2019 +0200 binder: Fix race between mmap() and binder_alloc_print_pages() commit 8eb52a1ee37aafd9b796713aa0b3ab9cbc455be3 upstream. binder_alloc_print_pages() iterates over alloc->pages[0..alloc->buffer_size-1] under alloc->mutex. binder_alloc_mmap_handler() writes alloc->pages and alloc->buffer_size without holding that lock, and even writes them before the last bailout point. Unfortunately we can't take the alloc->mutex in the ->mmap() handler because mmap_sem can be taken while alloc->mutex is held. So instead, we have to locklessly check whether the binder_alloc has been fully initialized with binder_alloc_get_vma(), like in binder_alloc_new_buf_locked(). Fixes: 8ef4665aa129 ("android: binder: Add page usage in binder stats") Cc: stable@vger.kernel.org Signed-off-by: Jann Horn Acked-by: Christian Brauner Link: https://lore.kernel.org/r/20191018205631.248274-1-jannh@google.com Signed-off-by: Greg Kroah-Hartman commit a006855c86ede879fd57b6a944cd9a5b89a9cdce Author: Nicolas Pitre Date: Tue Nov 5 10:33:16 2019 +0100 vcs: prevent write access to vcsu devices commit 0c9acb1af77a3cb8707e43f45b72c95266903cee upstream. Commit d21b0be246bf ("vt: introduce unicode mode for /dev/vcs") guarded against using devices containing attributes as this is not yet implemented. It however failed to guard against writes to any devices as this is also unimplemented. Reported-by: Or Cohen Signed-off-by: Nicolas Pitre Cc: # v4.19+ Cc: Jiri Slaby Fixes: d21b0be246bf ("vt: introduce unicode mode for /dev/vcs") Link: https://lore.kernel.org/r/nycvar.YSQ.7.76.1911051030580.30289@knanqh.ubzr Signed-off-by: Greg Kroah-Hartman commit df06454a0d51ba1905af12bdac26a12c1c5e3ca0 Author: Wei Wang Date: Tue Nov 12 12:42:23 2019 -0800 thermal: Fix deadlock in thermal thermal_zone_device_check commit 163b00cde7cf2206e248789d2780121ad5e6a70b upstream. 1851799e1d29 ("thermal: Fix use-after-free when unregistering thermal zone device") changed cancel_delayed_work to cancel_delayed_work_sync to avoid a use-after-free issue. However, cancel_delayed_work_sync could be called insides the WQ causing deadlock. [54109.642398] c0 1162 kworker/u17:1 D 0 11030 2 0x00000000 [54109.642437] c0 1162 Workqueue: thermal_passive_wq thermal_zone_device_check [54109.642447] c0 1162 Call trace: [54109.642456] c0 1162 __switch_to+0x138/0x158 [54109.642467] c0 1162 __schedule+0xba4/0x1434 [54109.642480] c0 1162 schedule_timeout+0xa0/0xb28 [54109.642492] c0 1162 wait_for_common+0x138/0x2e8 [54109.642511] c0 1162 flush_work+0x348/0x40c [54109.642522] c0 1162 __cancel_work_timer+0x180/0x218 [54109.642544] c0 1162 handle_thermal_trip+0x2c4/0x5a4 [54109.642553] c0 1162 thermal_zone_device_update+0x1b4/0x25c [54109.642563] c0 1162 thermal_zone_device_check+0x18/0x24 [54109.642574] c0 1162 process_one_work+0x3cc/0x69c [54109.642583] c0 1162 worker_thread+0x49c/0x7c0 [54109.642593] c0 1162 kthread+0x17c/0x1b0 [54109.642602] c0 1162 ret_from_fork+0x10/0x18 [54109.643051] c0 1162 kworker/u17:2 D 0 16245 2 0x00000000 [54109.643067] c0 1162 Workqueue: thermal_passive_wq thermal_zone_device_check [54109.643077] c0 1162 Call trace: [54109.643085] c0 1162 __switch_to+0x138/0x158 [54109.643095] c0 1162 __schedule+0xba4/0x1434 [54109.643104] c0 1162 schedule_timeout+0xa0/0xb28 [54109.643114] c0 1162 wait_for_common+0x138/0x2e8 [54109.643122] c0 1162 flush_work+0x348/0x40c [54109.643131] c0 1162 __cancel_work_timer+0x180/0x218 [54109.643141] c0 1162 handle_thermal_trip+0x2c4/0x5a4 [54109.643150] c0 1162 thermal_zone_device_update+0x1b4/0x25c [54109.643159] c0 1162 thermal_zone_device_check+0x18/0x24 [54109.643167] c0 1162 process_one_work+0x3cc/0x69c [54109.643177] c0 1162 worker_thread+0x49c/0x7c0 [54109.643186] c0 1162 kthread+0x17c/0x1b0 [54109.643195] c0 1162 ret_from_fork+0x10/0x18 [54109.644500] c0 1162 cat D 0 7766 1 0x00000001 [54109.644515] c0 1162 Call trace: [54109.644524] c0 1162 __switch_to+0x138/0x158 [54109.644536] c0 1162 __schedule+0xba4/0x1434 [54109.644546] c0 1162 schedule_preempt_disabled+0x80/0xb0 [54109.644555] c0 1162 __mutex_lock+0x3a8/0x7f0 [54109.644563] c0 1162 __mutex_lock_slowpath+0x14/0x20 [54109.644575] c0 1162 thermal_zone_get_temp+0x84/0x360 [54109.644586] c0 1162 temp_show+0x30/0x78 [54109.644609] c0 1162 dev_attr_show+0x5c/0xf0 [54109.644628] c0 1162 sysfs_kf_seq_show+0xcc/0x1a4 [54109.644636] c0 1162 kernfs_seq_show+0x48/0x88 [54109.644656] c0 1162 seq_read+0x1f4/0x73c [54109.644664] c0 1162 kernfs_fop_read+0x84/0x318 [54109.644683] c0 1162 __vfs_read+0x50/0x1bc [54109.644692] c0 1162 vfs_read+0xa4/0x140 [54109.644701] c0 1162 SyS_read+0xbc/0x144 [54109.644708] c0 1162 el0_svc_naked+0x34/0x38 [54109.845800] c0 1162 D 720.000s 1->7766->7766 cat [panic] Fixes: 1851799e1d29 ("thermal: Fix use-after-free when unregistering thermal zone device") Cc: stable@vger.kernel.org Signed-off-by: Wei Wang Signed-off-by: Zhang Rui Signed-off-by: Greg Kroah-Hartman commit 9a3efa06682e8b6868d39238ba5523e436b9325a Author: Jan Kara Date: Thu Nov 21 16:14:38 2019 -0800 iomap: Fix pipe page leakage during splicing commit 419e9c38aa075ed0cd3c13d47e15954b686bcdb6 upstream. When splicing using iomap_dio_rw() to a pipe, we may leak pipe pages because bio_iov_iter_get_pages() records that the pipe will have full extent worth of data however if file size is not block size aligned iomap_dio_rw() returns less than what bio_iov_iter_get_pages() set up and splice code gets confused leaking a pipe page with the file tail. Handle the situation similarly to the old direct IO implementation and revert iter to actually returned read amount which makes iter consistent with value returned from iomap_dio_rw() and thus the splice code is happy. Fixes: ff6a9292e6f6 ("iomap: implement direct I/O") CC: stable@vger.kernel.org Reported-by: syzbot+991400e8eba7e00a26e1@syzkaller.appspotmail.com Signed-off-by: Jan Kara Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Reviewed-by: Christoph Hellwig Signed-off-by: Greg Kroah-Hartman commit bca481bd8eb0ea81c0ff138be96507b46b28b00f Author: Viresh Kumar Date: Thu Nov 7 08:50:25 2019 +0530 RDMA/qib: Validate ->show()/store() callbacks before calling them commit 7ee23491b39259ae83899dd93b2a29ef0f22f0a7 upstream. The permissions of the read-only or write-only sysfs files can be changed (as root) and the user can then try to read a write-only file or write to a read-only file which will lead to kernel crash here. Protect against that by always validating the show/store callbacks. Link: https://lore.kernel.org/r/d45cc26361a174ae12dbb86c994ef334d257924b.1573096807.git.viresh.kumar@linaro.org Signed-off-by: Viresh Kumar Reviewed-by: Greg Kroah-Hartman Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 333b7396439ac287013e51c3d493f37afa639c34 Author: Johan Hovold Date: Thu Nov 28 19:26:03 2019 +0100 can: ucan: fix non-atomic allocation in completion handler commit 870db5d1015c8bd63e93b579e857223c96249ff7 upstream. USB completion handlers are called in atomic context and must specifically not allocate memory using GFP_KERNEL. Fixes: 9f2d3eae88d2 ("can: ucan: add driver for Theobroma Systems UCAN devices") Cc: stable # 4.19 Cc: Jakob Unterwurzacher Cc: Martin Elshuber Cc: Philipp Tomsich Signed-off-by: Johan Hovold Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit e081b64f18b420a12c9eff18c7e1e35753db249d Author: Gregory CLEMENT Date: Thu Oct 24 16:13:09 2019 +0200 spi: Fix NULL pointer when setting SPI_CS_HIGH for GPIO CS commit 15f794bd977a0135328fbdd8a83cc64c1d267b39 upstream. Even if the flag use_gpio_descriptors is set, it is possible that cs_gpiods was not allocated, which leads to a kernel crash. Reported-by: "kernelci.org bot" Fixes: 3e5ec1db8bfe ("spi: Fix SPI_CS_HIGH setting when using native and GPIO CS") Signed-off-by: Gregory CLEMENT Link: https://lore.kernel.org/r/20191024141309.22434-1-gregory.clement@bootlin.com Signed-off-by: Mark Brown Cc: Signed-off-by: Greg Kroah-Hartman commit 6639dc50f844c9ef0a13c86b13f3b5d64cbc926e Author: Gregory CLEMENT Date: Fri Oct 18 17:29:29 2019 +0200 spi: Fix SPI_CS_HIGH setting when using native and GPIO CS commit 3e5ec1db8bfee845d9f8560d1c64aeaccd586398 upstream. When improving the CS GPIO support at core level, the SPI_CS_HIGH has been enabled for all the CS lines used for a given SPI controller. However, the SPI framework allows to have on the same controller native CS and GPIO CS. The native CS may not support the SPI_CS_HIGH, so they should not be setup automatically. With this patch the setting is done only for the CS that will use a GPIO as CS Fixes: f3186dd87669 ("spi: Optionally use GPIO descriptors for CS GPIOs") Cc: Signed-off-by: Gregory CLEMENT Link: https://lore.kernel.org/r/20191018152929.3287-1-gregory.clement@bootlin.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit f857d1baef9e625cc5dd4e311e836f0ca0c5c4e6 Author: Gregory CLEMENT Date: Thu Oct 17 16:18:41 2019 +0200 spi: atmel: Fix CS high support commit 7cbb16b2122c09f2ae393a1542fed628505b9da6 upstream. Until a few years ago, this driver was only used with CS GPIO. The only exception is CS0 on AT91RM9200 which has to use internal CS. A limitation of the internal CS is that they don't support CS High. So by using the CS GPIO the CS high configuration was available except for the particular case CS0 on RM9200. When the support for the internal chip-select was added, the check of the CS high support was not updated. Due to this the driver accepts this configuration for all the SPI controller v2 (used by all SoCs excepting the AT91RM9200) whereas the hardware doesn't support it for infernal CS. This patch fixes the test to match the hardware capabilities. Fixes: 4820303480a1 ("spi: atmel: add support for the internal chip-select of the spi controller") Cc: Signed-off-by: Gregory CLEMENT Link: https://lore.kernel.org/r/20191017141846.7523-3-gregory.clement@bootlin.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 77916ba882737caa619fc01d80be1340c70a3968 Author: Patrice Chotard Date: Fri Oct 4 14:36:06 2019 +0200 spi: stm32-qspi: Fix kernel oops when unbinding driver commit 3c0af1dd2fe78adc02fe21f6cfe7d6cb8602573e upstream. spi_master_put() must only be called in .probe() in case of error. As devm_spi_register_master() is used during probe, spi_master_put() mustn't be called in .remove() callback. It fixes the following kernel WARNING/Oops when executing echo "58003000.spi" > /sys/bus/platform/drivers/stm32-qspi/unbind : ------------[ cut here ]------------ WARNING: CPU: 1 PID: 496 at fs/kernfs/dir.c:1504 kernfs_remove_by_name_ns+0x9c/0xa4 kernfs: can not remove 'uevent', no directory Modules linked in: CPU: 1 PID: 496 Comm: sh Not tainted 5.3.0-rc1-00219-ga0e07bb51a37 #62 Hardware name: STM32 (Device Tree Support) [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [] (show_stack) from [] (dump_stack+0xb4/0xc8) [] (dump_stack) from [] (__warn.part.3+0xbc/0xd8) [] (__warn.part.3) from [] (warn_slowpath_fmt+0x68/0x8c) [] (warn_slowpath_fmt) from [] (kernfs_remove_by_name_ns+0x9c/0xa4) [] (kernfs_remove_by_name_ns) from [] (device_del+0x128/0x358) [] (device_del) from [] (device_unregister+0x24/0x64) [] (device_unregister) from [] (spi_unregister_controller+0x88/0xe8) [] (spi_unregister_controller) from [] (release_nodes+0x1bc/0x200) [] (release_nodes) from [] (device_release_driver_internal+0xec/0x1ac) [] (device_release_driver_internal) from [] (unbind_store+0x60/0xd4) [] (unbind_store) from [] (kernfs_fop_write+0xe8/0x1c4) [] (kernfs_fop_write) from [] (__vfs_write+0x2c/0x1c0) [] (__vfs_write) from [] (vfs_write+0xa4/0x184) [] (vfs_write) from [] (ksys_write+0x58/0xd0) [] (ksys_write) from [] (ret_fast_syscall+0x0/0x54) Exception stack(0xdd289fa8 to 0xdd289ff0) 9fa0: 0000006c 000e20e8 00000001 000e20e8 0000000d 00000000 9fc0: 0000006c 000e20e8 b6f87da0 00000004 0000000d 0000000d 00000000 00000000 9fe0: 00000004 bee639b0 b6f2286b b6eaf6c6 ---[ end trace 1b15df8a02d76aef ]--- ------------[ cut here ]------------ WARNING: CPU: 1 PID: 496 at fs/kernfs/dir.c:1504 kernfs_remove_by_name_ns+0x9c/0xa4 kernfs: can not remove 'online', no directory Modules linked in: CPU: 1 PID: 496 Comm: sh Tainted: G W 5.3.0-rc1-00219-ga0e07bb51a37 #62 Hardware name: STM32 (Device Tree Support) [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [] (show_stack) from [] (dump_stack+0xb4/0xc8) [] (dump_stack) from [] (__warn.part.3+0xbc/0xd8) [] (__warn.part.3) from [] (warn_slowpath_fmt+0x68/0x8c) [] (warn_slowpath_fmt) from [] (kernfs_remove_by_name_ns+0x9c/0xa4) [] (kernfs_remove_by_name_ns) from [] (device_remove_attrs+0x20/0x5c) [] (device_remove_attrs) from [] (device_del+0x134/0x358) [] (device_del) from [] (device_unregister+0x24/0x64) [] (device_unregister) from [] (spi_unregister_controller+0x88/0xe8) [] (spi_unregister_controller) from [] (release_nodes+0x1bc/0x200) [] (release_nodes) from [] (device_release_driver_internal+0xec/0x1ac) [] (device_release_driver_internal) from [] (unbind_store+0x60/0xd4) [] (unbind_store) from [] (kernfs_fop_write+0xe8/0x1c4) [] (kernfs_fop_write) from [] (__vfs_write+0x2c/0x1c0) [] (__vfs_write) from [] (vfs_write+0xa4/0x184) [] (vfs_write) from [] (ksys_write+0x58/0xd0) [] (ksys_write) from [] (ret_fast_syscall+0x0/0x54) Exception stack(0xdd289fa8 to 0xdd289ff0) 9fa0: 0000006c 000e20e8 00000001 000e20e8 0000000d 00000000 9fc0: 0000006c 000e20e8 b6f87da0 00000004 0000000d 0000000d 00000000 00000000 9fe0: 00000004 bee639b0 b6f2286b b6eaf6c6 ---[ end trace 1b15df8a02d76af0 ]--- 8<--- cut here --- Unable to handle kernel NULL pointer dereference at virtual address 00000050 pgd = e612f14d [00000050] *pgd=ff1f5835 Internal error: Oops: 17 [#1] SMP ARM Modules linked in: CPU: 1 PID: 496 Comm: sh Tainted: G W 5.3.0-rc1-00219-ga0e07bb51a37 #62 Hardware name: STM32 (Device Tree Support) PC is at kernfs_find_ns+0x8/0xfc LR is at kernfs_find_and_get_ns+0x30/0x48 pc : [] lr : [] psr: 40010013 sp : dd289dac ip : 00000000 fp : 00000000 r10: 00000000 r9 : def6ec58 r8 : dd289e54 r7 : 00000000 r6 : c0abb234 r5 : 00000000 r4 : c0d26a30 r3 : ddab5080 r2 : 00000000 r1 : c0abb234 r0 : 00000000 Flags: nZcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Control: 10c5387d Table: dd11c06a DAC: 00000051 Process sh (pid: 496, stack limit = 0xe13a592d) Stack: (0xdd289dac to 0xdd28a000) 9da0: c0d26a30 00000000 c0abb234 00000000 c02e4ac8 9dc0: 00000000 c0976b44 def6ec00 dea53810 dd289e54 c02e864c c0a61a48 c0a4a5ec 9de0: c0d630a8 def6ec00 c0d04c48 c02e86e0 def6ec00 de909338 c0d04c48 c05833b0 9e00: 00000000 c0638144 dd289e54 def59900 00000000 475b3ee5 def6ec00 00000000 9e20: def6ec00 def59b80 dd289e54 def59900 00000000 c05835f8 def6ec00 c0638dac 9e40: 0000000a dea53810 c0d04c48 c058c580 dea53810 def59500 def59b80 475b3ee5 9e60: ddc63e00 dea53810 dea3fe10 c0d63a0c dea53810 ddc63e00 dd289f78 dd240d10 9e80: 00000000 c0588a44 c0d59a20 0000000d c0d63a0c c0586840 0000000d dd240d00 9ea0: 00000000 00000000 ddc63e00 c02e64e8 00000000 00000000 c0d04c48 dd9bbcc0 9ec0: c02e6400 dd289f78 00000000 000e20e8 0000000d c0266b44 00000055 00000cc0 9ee0: 000000e3 000e3000 dd11c000 dd11c000 00000000 00000000 00000000 00000000 9f00: ffeee38c dff99688 00000000 475b3ee5 00000001 dd289fb0 ddab5080 ddaa5800 9f20: 00000817 000e30ec dd9e7720 475b3ee5 ddaa583c 0000000d dd9bbcc0 000e20e8 9f40: dd289f78 00000000 000e20e8 0000000d 00000000 c02694c0 00000000 00000000 9f60: c0d04c48 dd9bbcc0 00000000 00000000 dd9bbcc0 c0269710 00000000 00000000 9f80: 000a91f4 475b3ee5 0000006c 000e20e8 b6f87da0 00000004 c0101204 dd288000 9fa0: 00000004 c0101000 0000006c 000e20e8 00000001 000e20e8 0000000d 00000000 9fc0: 0000006c 000e20e8 b6f87da0 00000004 0000000d 0000000d 00000000 00000000 9fe0: 00000004 bee639b0 b6f2286b b6eaf6c6 600e0030 00000001 00000000 00000000 [] (kernfs_find_ns) from [] (0xdef6ec00) Code: ebf8eeab c0dc50b8 e92d40f0 e292c000 (e1d035b0) ---[ end trace 1b15df8a02d76af1 ]--- Fixes: a88eceb17ac7 ("spi: stm32-qspi: add spi_master_put in release function") Cc: Signed-off-by: Patrice Chotard Link: https://lore.kernel.org/r/20191004123606.17241-1-patrice.chotard@st.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 3db45180dcc141015415bc1af88c8e9590d21e7d Author: Frieder Schrempf Date: Mon Oct 7 07:23:02 2019 +0000 spi: spi-fsl-qspi: Clear TDH bits in FLSHCR register commit f6910679e17ad4915f008bd2c614d38052426f7c upstream. Later versions of the QSPI controller (e.g. in i.MX6UL/ULL and i.MX7) seem to have an additional TDH setting in the FLSHCR register, that needs to be set in accordance with the access mode that is used (DDR or SDR). Previous bootstages such as BootROM or bootloader might have used the DDR mode to access the flash. As we currently only use SDR mode, we need to make sure the TDH bits are cleared upon initialization. Fixes: 84d043185dbe ("spi: Add a driver for the Freescale/NXP QuadSPI controller") Cc: Signed-off-by: Frieder Schrempf Acked-by: Han Xu Link: https://lore.kernel.org/r/20191007071933.26786-1-frieder.schrempf@kontron.de Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 86d280b5709fea45ece6b47e1f30a2ff4800bee9 Author: Navid Emamdoost Date: Fri Oct 4 14:34:54 2019 -0500 crypto: user - fix memory leak in crypto_reportstat commit c03b04dcdba1da39903e23cc4d072abf8f68f2dd upstream. In crypto_reportstat, a new skb is created by nlmsg_new(). This skb is leaked if crypto_reportstat_alg() fails. Required release for skb is added. Fixes: cac5818c25d0 ("crypto: user - Implement a generic crypto statistics") Cc: Signed-off-by: Navid Emamdoost Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit ceddd48c8407c4d1c70a815ae229f34c9af44273 Author: Navid Emamdoost Date: Fri Oct 4 14:29:16 2019 -0500 crypto: user - fix memory leak in crypto_report commit ffdde5932042600c6807d46c1550b28b0db6a3bc upstream. In crypto_report, a new skb is created via nlmsg_new(). This skb should be released if crypto_report_alg() fails. Fixes: a38f7907b926 ("crypto: Add userspace configuration API") Cc: Signed-off-by: Navid Emamdoost Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 5128dd94438ec43dacbd947641aac8dea90bbf56 Author: Ard Biesheuvel Date: Wed Oct 23 11:50:44 2019 +0200 crypto: ecdh - fix big endian bug in ECC library commit f398243e9fd6a3a059c1ea7b380c40628dbf0c61 upstream. The elliptic curve arithmetic library used by the EC-DH KPP implementation assumes big endian byte order, and unconditionally reverses the byte and word order of multi-limb quantities. On big endian systems, the byte reordering is not necessary, while the word ordering needs to be retained. So replace the __swab64() invocation with a call to be64_to_cpu() which should do the right thing for both little and big endian builds. Fixes: 3c4b23901a0c ("crypto: ecdh - Add ECDH software support") Cc: # v4.9+ Signed-off-by: Ard Biesheuvel Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 3eb591bacccb1121f6914183b3f5b3583935c64a Author: Mark Salter Date: Mon Oct 21 11:29:49 2019 -0400 crypto: ccp - fix uninitialized list head commit 691505a803a7f223b2af621848d581259c61f77d upstream. A NULL-pointer dereference was reported in fedora bz#1762199 while reshaping a raid6 array after adding a fifth drive to an existing array. [ 47.343549] md/raid:md0: raid level 6 active with 3 out of 5 devices, algorithm 2 [ 47.804017] md0: detected capacity change from 0 to 7885289422848 [ 47.822083] Unable to handle kernel read from unreadable memory at virtual address 0000000000000000 ... [ 47.940477] CPU: 1 PID: 14210 Comm: md0_raid6 Tainted: G W 5.2.18-200.fc30.aarch64 #1 [ 47.949594] Hardware name: AMD Overdrive/Supercharger/To be filled by O.E.M., BIOS ROD1002C 04/08/2016 [ 47.958886] pstate: 00400085 (nzcv daIf +PAN -UAO) [ 47.963668] pc : __list_del_entry_valid+0x2c/0xa8 [ 47.968366] lr : ccp_tx_submit+0x84/0x168 [ccp] [ 47.972882] sp : ffff00001369b970 [ 47.976184] x29: ffff00001369b970 x28: ffff00001369bdb8 [ 47.981483] x27: 00000000ffffffff x26: ffff8003b758af70 [ 47.986782] x25: ffff8003b758b2d8 x24: ffff8003e6245818 [ 47.992080] x23: 0000000000000000 x22: ffff8003e62450c0 [ 47.997379] x21: ffff8003dfd6add8 x20: 0000000000000003 [ 48.002678] x19: ffff8003e6245100 x18: 0000000000000000 [ 48.007976] x17: 0000000000000000 x16: 0000000000000000 [ 48.013274] x15: 0000000000000000 x14: 0000000000000000 [ 48.018572] x13: ffff7e000ef83a00 x12: 0000000000000001 [ 48.023870] x11: ffff000010eff998 x10: 00000000000019a0 [ 48.029169] x9 : 0000000000000000 x8 : ffff8003e6245180 [ 48.034467] x7 : 0000000000000000 x6 : 000000000000003f [ 48.039766] x5 : 0000000000000040 x4 : ffff8003e0145080 [ 48.045064] x3 : dead000000000200 x2 : 0000000000000000 [ 48.050362] x1 : 0000000000000000 x0 : ffff8003e62450c0 [ 48.055660] Call trace: [ 48.058095] __list_del_entry_valid+0x2c/0xa8 [ 48.062442] ccp_tx_submit+0x84/0x168 [ccp] [ 48.066615] async_tx_submit+0x224/0x368 [async_tx] [ 48.071480] async_trigger_callback+0x68/0xfc [async_tx] [ 48.076784] ops_run_biofill+0x178/0x1e8 [raid456] [ 48.081566] raid_run_ops+0x248/0x818 [raid456] [ 48.086086] handle_stripe+0x864/0x1208 [raid456] [ 48.090781] handle_active_stripes.isra.0+0xb0/0x278 [raid456] [ 48.096604] raid5d+0x378/0x618 [raid456] [ 48.100602] md_thread+0xa0/0x150 [ 48.103905] kthread+0x104/0x130 [ 48.107122] ret_from_fork+0x10/0x18 [ 48.110686] Code: d2804003 f2fbd5a3 eb03003f 54000320 (f9400021) [ 48.116766] ---[ end trace 23f390a527f7ad77 ]--- ccp_tx_submit is passed a dma_async_tx_descriptor which is contained in a ccp_dma_desc and adds it to a ccp channel's pending list: list_del(&desc->entry); list_add_tail(&desc->entry, &chan->pending); The problem is that desc->entry may be uninitialized in the async_trigger_callback path where the descriptor was gotten from ccp_prep_dma_interrupt which got it from ccp_alloc_dma_desc which doesn't initialize the desc->entry list head. So, just initialize the list head to avoid the problem. Cc: Reported-by: Sahaj Sarup Signed-off-by: Mark Salter Acked-by: Gary R Hook Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit d6c7af7ba25ccab172e5cea58b664c4752661f22 Author: Ard Biesheuvel Date: Sat Oct 5 11:11:10 2019 +0200 crypto: geode-aes - switch to skcipher for cbc(aes) fallback commit 504582e8e40b90b8f8c58783e2d1e4f6a2b71a3a upstream. Commit 79c65d179a40e145 ("crypto: cbc - Convert to skcipher") updated the generic CBC template wrapper from a blkcipher to a skcipher algo, to get away from the deprecated blkcipher interface. However, as a side effect, drivers that instantiate CBC transforms using the blkcipher as a fallback no longer work, since skciphers can wrap blkciphers but not the other way around. This broke the geode-aes driver. So let's fix it by moving to the sync skcipher interface when allocating the fallback. At the same time, align with the generic API for ECB and CBC by rejecting inputs that are not a multiple of the AES block size. Fixes: 79c65d179a40e145 ("crypto: cbc - Convert to skcipher") Cc: # v4.20+ ONLY Signed-off-by: Ard Biesheuvel Signed-off-by: Florian Bezdeka Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 57bbc59435a1c387ff3adb86690a30b4ff0caa8b Author: Ayush Sawal Date: Fri Oct 4 10:50:58 2019 -0700 crypto: af_alg - cast ki_complete ternary op to int commit 64e7f852c47ce99f6c324c46d6a299a5a7ebead9 upstream. when libkcapi test is executed using HW accelerator, cipher operation return -74.Since af_alg_async_cb->ki_complete treat err as unsigned int, libkcapi receive 429467222 even though it expect -ve value. Hence its required to cast resultlen to int so that proper error is returned to libkcapi. AEAD one shot non-aligned test 2(libkcapi test) ./../bin/kcapi -x 10 -c "gcm(aes)" -i 7815d4b06ae50c9c56e87bd7 -k ea38ac0c9b9998c80e28fb496a2b88d9 -a "853f98a750098bec1aa7497e979e78098155c877879556bb51ddeb6374cbaefc" -t "c4ce58985b7203094be1d134c1b8ab0b" -q "b03692f86d1b8b39baf2abb255197c98" Fixes: d887c52d6ae4 ("crypto: algif_aead - overhaul memory management") Cc: Signed-off-by: Ayush Sawal Signed-off-by: Atul Gupta Signed-off-by: Herbert Xu Signed-off-by: Ayush Sawal Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 1fbac3215865fc92e316515a0568b49d00e46179 Author: Tudor Ambarus Date: Fri Oct 4 08:55:37 2019 +0000 crypto: atmel-aes - Fix IV handling when req->nbytes < ivsize commit 86ef1dfcb561473fbf5e199d58d18c55554d78be upstream. commit 394a9e044702 ("crypto: cfb - add missing 'chunksize' property") adds a test vector where the input length is smaller than the IV length (the second test vector). This revealed a NULL pointer dereference in the atmel-aes driver, that is caused by passing an incorrect offset in scatterwalk_map_and_copy() when atmel_aes_complete() is called. Do not save the IV in req->info of ablkcipher_request (or equivalently req->iv of skcipher_request) when req->nbytes < ivsize, because the IV will not be further used. While touching the code, modify the type of ivsize from int to unsigned int, to comply with the return type of crypto_ablkcipher_ivsize(). Fixes: 91308019ecb4 ("crypto: atmel-aes - properly set IV after {en,de}crypt") Cc: Signed-off-by: Tudor Ambarus Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit f9eae26b7b8b01a7e75bb6d64b872e5b8232397e Author: Christian Lamparter Date: Thu Oct 31 17:14:38 2019 +0100 crypto: crypto4xx - fix double-free in crypto4xx_destroy_sdr commit 746c908c4d72e49068ab216c3926d2720d71a90d upstream. This patch fixes a crash that can happen during probe when the available dma memory is not enough (this can happen if the crypto4xx is built as a module). The descriptor window mapping would end up being free'd twice, once in crypto4xx_build_pdr() and the second time in crypto4xx_destroy_sdr(). Fixes: 5d59ad6eea82 ("crypto: crypto4xx - fix crypto4xx_build_pdr, crypto4xx_build_sdr leak") Cc: Signed-off-by: Christian Lamparter Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 1d2ad2db173d2d8f86d090598d956024e174f8c5 Author: Sean Christopherson Date: Fri Nov 22 08:58:18 2019 -0800 KVM: x86: Grab KVM's srcu lock when setting nested state commit ad5996d9a0e8019c3ae5151e687939369acfe044 upstream. Acquire kvm->srcu for the duration of ->set_nested_state() to fix a bug where nVMX derefences ->memslots without holding ->srcu or ->slots_lock. The other half of nested migration, ->get_nested_state(), does not need to acquire ->srcu as it is a purely a dump of internal KVM (and CPU) state to userspace. Detected as an RCU lockdep splat that is 100% reproducible by running KVM's state_test selftest with CONFIG_PROVE_LOCKING=y. Note that the failing function, kvm_is_visible_gfn(), is only checking the validity of a gfn, it's not actually accessing guest memory (which is more or less unsupported during vmx_set_nested_state() due to incorrect MMU state), i.e. vmx_set_nested_state() itself isn't fundamentally broken. In any case, setting nested state isn't a fast path so there's no reason to go out of our way to avoid taking ->srcu. ============================= WARNING: suspicious RCU usage 5.4.0-rc7+ #94 Not tainted ----------------------------- include/linux/kvm_host.h:626 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by evmcs_test/10939: #0: ffff88826ffcb800 (&vcpu->mutex){+.+.}, at: kvm_vcpu_ioctl+0x85/0x630 [kvm] stack backtrace: CPU: 1 PID: 10939 Comm: evmcs_test Not tainted 5.4.0-rc7+ #94 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace: dump_stack+0x68/0x9b kvm_is_visible_gfn+0x179/0x180 [kvm] mmu_check_root+0x11/0x30 [kvm] fast_cr3_switch+0x40/0x120 [kvm] kvm_mmu_new_cr3+0x34/0x60 [kvm] nested_vmx_load_cr3+0xbd/0x1f0 [kvm_intel] nested_vmx_enter_non_root_mode+0xab8/0x1d60 [kvm_intel] vmx_set_nested_state+0x256/0x340 [kvm_intel] kvm_arch_vcpu_ioctl+0x491/0x11a0 [kvm] kvm_vcpu_ioctl+0xde/0x630 [kvm] do_vfs_ioctl+0xa2/0x6c0 ksys_ioctl+0x66/0x70 __x64_sys_ioctl+0x16/0x20 do_syscall_64+0x54/0x200 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x7f59a2b95f47 Fixes: 8fcc4b5923af5 ("kvm: nVMX: Introduce KVM_CAP_NESTED_STATE") Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 4313d9689b5ea7a693d7f4553548f56026a228a6 Author: Sean Christopherson Date: Fri Nov 22 12:15:49 2019 -0800 KVM: x86: Remove a spurious export of a static function commit 24885d1d79e2e83d49201aeae0bc59f1402fd4f1 upstream. A recent change inadvertently exported a static function, which results in modpost throwing a warning. Fix it. Fixes: cbbaa2727aa3 ("KVM: x86: fix presentation of TSX feature in ARCH_CAPABILITIES") Signed-off-by: Sean Christopherson Cc: stable@vger.kernel.org Reviewed-by: Jim Mattson Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit e2416da8c1ef201d3685442a0821f4ffb19727ad Author: Paolo Bonzini Date: Mon Nov 18 18:58:26 2019 +0100 KVM: x86: fix presentation of TSX feature in ARCH_CAPABILITIES commit cbbaa2727aa3ae9e0a844803da7cef7fd3b94f2b upstream. KVM does not implement MSR_IA32_TSX_CTRL, so it must not be presented to the guests. It is also confusing to have !ARCH_CAP_TSX_CTRL_MSR && !RTM && ARCH_CAP_TAA_NO: lack of MSR_IA32_TSX_CTRL suggests TSX was not hidden (it actually was), yet the value says that TSX is not vulnerable to microarchitectural data sampling. Fix both. Cc: stable@vger.kernel.org Tested-by: Jim Mattson Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit a3b791f6630036c95e7dafbf28ce48c25c3631c9 Author: Paolo Bonzini Date: Mon Nov 18 12:23:00 2019 -0500 KVM: x86: do not modify masked bits of shared MSRs commit de1fca5d6e0105c9d33924e1247e2f386efc3ece upstream. "Shared MSRs" are guest MSRs that are written to the host MSRs but keep their value until the next return to userspace. They support a mask, so that some bits keep the host value, but this mask is only used to skip an unnecessary MSR write and the value written to the MSR is always the guest MSR. Fix this and, while at it, do not update smsr->values[slot].curr if for whatever reason the wrmsr fails. This should only happen due to reserved bits, so the value written to smsr->values[slot].curr will not match when the user-return notifier and the host value will always be restored. However, it is untidy and in rare cases this can actually avoid spurious WRMSRs on return to userspace. Cc: stable@vger.kernel.org Reviewed-by: Jim Mattson Tested-by: Jim Mattson Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 1168da38fd2c7ca0f8feff167f9dd1e8b1f8801a Author: Zenghui Yu Date: Tue Oct 29 15:19:19 2019 +0800 KVM: arm/arm64: vgic: Don't rely on the wrong pending table commit ca185b260951d3b55108c0b95e188682d8a507b7 upstream. It's possible that two LPIs locate in the same "byte_offset" but target two different vcpus, where their pending status are indicated by two different pending tables. In such a scenario, using last_byte_offset optimization will lead KVM relying on the wrong pending table entry. Let us use last_ptr instead, which can be treated as a byte index into a pending table and also, can be vcpu specific. Fixes: 280771252c1b ("KVM: arm64: vgic-v3: KVM_DEV_ARM_VGIC_SAVE_PENDING_TABLES") Cc: stable@vger.kernel.org Signed-off-by: Zenghui Yu Signed-off-by: Marc Zyngier Acked-by: Eric Auger Link: https://lore.kernel.org/r/20191029071919.177-4-yuzenghui@huawei.com Signed-off-by: Greg Kroah-Hartman commit f10e76528a55137715c53be390a76b2d35b7a498 Author: Sean Christopherson Date: Fri Sep 27 14:45:16 2019 -0700 KVM: nVMX: Always write vmcs02.GUEST_CR3 during nested VM-Enter commit 04f11ef45810da5ae2542dd78cc353f3761bd2cb upstream. Write the desired L2 CR3 into vmcs02.GUEST_CR3 during nested VM-Enter instead of deferring the VMWRITE until vmx_set_cr3(). If the VMWRITE is deferred, then KVM can consume a stale vmcs02.GUEST_CR3 when it refreshes vmcs12->guest_cr3 during nested_vmx_vmexit() if the emulated VM-Exit occurs without actually entering L2, e.g. if the nested run is squashed because nested VM-Enter (from L1) is putting L2 into HLT. Note, the above scenario can occur regardless of whether L1 is intercepting HLT, e.g. L1 can intercept HLT and then re-enter L2 with vmcs.GUEST_ACTIVITY_STATE=HALTED. But practically speaking, a VMM will likely put a guest into HALTED if and only if it's not intercepting HLT. In an ideal world where EPT *requires* unrestricted guest (and vice versa), VMX could handle CR3 similar to how it handles RSP and RIP, e.g. mark CR3 dirty and conditionally load it at vmx_vcpu_run(). But the unrestricted guest silliness complicates the dirty tracking logic to the point that explicitly handling vmcs02.GUEST_CR3 during nested VM-Enter is a simpler overall implementation. Cc: stable@vger.kernel.org Reported-and-tested-by: Reto Buerki Tested-by: Vitaly Kuznetsov Reviewed-by: Liran Alon Signed-off-by: Sean Christopherson Reviewed-by: Jim Mattson Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit fe7399d2c65347e12f428f6bcffe2d42359b8718 Author: Greg Kurz Date: Fri Sep 27 13:53:38 2019 +0200 KVM: PPC: Book3S HV: XIVE: Set kvm->arch.xive when VPs are allocated commit e7d71c943040c23f2fd042033d319f56e84f845b upstream. If we cannot allocate the XIVE VPs in OPAL, the creation of a XIVE or XICS-on-XIVE device is aborted as expected, but we leave kvm->arch.xive set forever since the release method isn't called in this case. Any subsequent tentative to create a XIVE or XICS-on-XIVE for this VM will thus always fail (DoS). This is a problem for QEMU since it destroys and re-creates these devices when the VM is reset: the VM would be restricted to using the much slower emulated XIVE or XICS forever. As an alternative to adding rollback, do not assign kvm->arch.xive before making sure the XIVE VPs are allocated in OPAL. Cc: stable@vger.kernel.org # v5.2 Fixes: 5422e95103cf ("KVM: PPC: Book3S HV: XIVE: Replace the 'destroy' method by a 'release' method") Signed-off-by: Greg Kurz Reviewed-by: Cédric Le Goater Signed-off-by: Paul Mackerras Signed-off-by: Greg Kroah-Hartman commit 3a083ad6c1b8ecf2873eee2b76a8974930f112d6 Author: Greg Kurz Date: Wed Nov 13 17:46:19 2019 +0100 KVM: PPC: Book3S HV: XIVE: Fix potential page leak on error path commit 30486e72093ea2e594f44876b7a445c219449bce upstream. We need to check the host page size is big enough to accomodate the EQ. Let's do this before taking a reference on the EQ page to avoid a potential leak if the check fails. Cc: stable@vger.kernel.org # v5.2 Fixes: 13ce3297c576 ("KVM: PPC: Book3S HV: XIVE: Add controls for the EQ configuration") Signed-off-by: Greg Kurz Reviewed-by: Cédric Le Goater Signed-off-by: Paul Mackerras Signed-off-by: Greg Kroah-Hartman commit 736b0a255be589d1c1eb0f87953f8e3c867953b1 Author: Greg Kurz Date: Wed Nov 13 17:46:13 2019 +0100 KVM: PPC: Book3S HV: XIVE: Free previous EQ page when setting up a new one commit 31a88c82b466d2f31a44e21c479f45b4732ccfd0 upstream. The EQ page is allocated by the guest and then passed to the hypervisor with the H_INT_SET_QUEUE_CONFIG hcall. A reference is taken on the page before handing it over to the HW. This reference is dropped either when the guest issues the H_INT_RESET hcall or when the KVM device is released. But, the guest can legitimately call H_INT_SET_QUEUE_CONFIG several times, either to reset the EQ (vCPU hot unplug) or to set a new EQ (guest reboot). In both cases the existing EQ page reference is leaked because we simply overwrite it in the XIVE queue structure without calling put_page(). This is especially visible when the guest memory is backed with huge pages: start a VM up to the guest userspace, either reboot it or unplug a vCPU, quit QEMU. The leak is observed by comparing the value of HugePages_Free in /proc/meminfo before and after the VM is run. Ideally we'd want the XIVE code to handle the EQ page de-allocation at the platform level. This isn't the case right now because the various XIVE drivers have different allocation needs. It could maybe worth introducing hooks for this purpose instead of exposing XIVE internals to the drivers, but this is certainly a huge work to be done later. In the meantime, for easier backport, fix both vCPU unplug and guest reboot leaks by introducing a wrapper around xive_native_configure_queue() that does the necessary cleanup. Reported-by: Satheesh Rajendran Cc: stable@vger.kernel.org # v5.2 Fixes: 13ce3297c576 ("KVM: PPC: Book3S HV: XIVE: Add controls for the EQ configuration") Signed-off-by: Cédric Le Goater Signed-off-by: Greg Kurz Tested-by: Lijun Pan Signed-off-by: Paul Mackerras Signed-off-by: Greg Kroah-Hartman commit e5edc578b65f12275bf87990507558e2e5487f2d Author: Marek Szyprowski Date: Thu Sep 12 09:36:02 2019 +0200 arm64: dts: exynos: Revert "Remove unneeded address space mapping for soc node" commit bed903167ae5b5532eda5d7db26de451bd232da5 upstream. Commit ef72171b3621 ("arm64: dts: exynos: Remove unneeded address space mapping for soc node") changed the address and size cells in root node from 2 to 1, but /memory nodes for the affected boards were not updated. This went unnoticed on Exynos5433-based TM2(e) boards, because they use u-boot, which updates /memory node to the correct values. On the other hand, the mentioned commit broke boot on Exynos7-based Espresso board, which bootloader doesn't touch /memory node at all. This patch reverts commit ef72171b3621 ("arm64: dts: exynos: Remove unneeded address space mapping for soc node"), so Exynos5433 and Exynos7 SoCs again matches other ARM64 platforms with 64bit mappings in root node. Reported-by: Alim Akhtar Fixes: ef72171b3621 ("arm64: dts: exynos: Remove unneeded address space mapping for soc node") Signed-off-by: Marek Szyprowski Cc: # 5.3.x: 72ddcf6aa224 arm64: dts: exynos: Move GPU under /soc node for Exynos5433 Cc: # 5.3.x: ede87c3a2bdb arm64: dts: exynos: Move GPU under /soc node for Exynos7 Cc: # 4.18.x Tested-by: Alim Akhtar Signed-off-by: Krzysztof Kozlowski Signed-off-by: Greg Kroah-Hartman commit 65ca1003bd0efd3065bfacf539b8f95df85c9891 Author: Dan Carpenter Date: Fri Oct 4 13:22:51 2019 +0300 drm/i810: Prevent underflow in ioctl commit 4f69851fbaa26b155330be35ce8ac393e93e7442 upstream. The "used" variables here come from the user in the ioctl and it can be negative. It could result in an out of bounds write. Signed-off-by: Dan Carpenter Reviewed-by: Chris Wilson Signed-off-by: Chris Wilson Link: https://patchwork.freedesktop.org/patch/msgid/20191004102251.GC823@mwanda Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 527d16ef4a451f587fb125acb6e8e334377eeac5 Author: Sean Paul Date: Wed Sep 4 16:29:13 2019 -0400 drm: damage_helper: Fix race checking plane->state->fb commit 354c2d310082d1c384213ba76c3757dd3cd8755d upstream. Since the dirtyfb ioctl doesn't give us any hints as to which plane is scanning out the fb it's marking as damaged, we need to loop through planes to find it. Currently we just reach into plane state and check, but that can race with another commit changing the fb out from under us. This patch locks the plane before checking the fb and will release the lock if the plane is not displaying the dirty fb. Fixes: b9fc5e01d1ce ("drm: Add helper to implement legacy dirtyfb") Cc: Rob Clark Cc: Deepak Rawat Cc: Daniel Vetter Cc: Thomas Hellstrom Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Sean Paul Cc: David Airlie Cc: Daniel Vetter Cc: dri-devel@lists.freedesktop.org Cc: # v5.0+ Reported-by: Daniel Vetter Reviewed-by: Daniel Vetter Signed-off-by: Sean Paul Link: https://patchwork.freedesktop.org/patch/msgid/20190904202938.110207-1-sean@poorly.run Signed-off-by: Greg Kroah-Hartman commit 9036afa1c6367deeee07b1327033b41491f57bdc Author: Johan Hovold Date: Thu Oct 10 15:13:30 2019 +0200 drm/msm: fix memleak on release commit a64fc11b9a520c55ca34d82e5ca32274f49b6b15 upstream. If a process is interrupted while accessing the "gpu" debugfs file and the drm device struct_mutex is contended, release() could return early and fail to free related resources. Note that the return value from release() is ignored. Fixes: 4f776f4511c7 ("drm/msm/gpu: Convert the GPU show function to use the GPU state") Cc: stable # 4.18 Cc: Jordan Crouse Cc: Rob Clark Reviewed-by: Rob Clark Signed-off-by: Johan Hovold Signed-off-by: Sean Paul Link: https://patchwork.freedesktop.org/patch/msgid/20191010131333.23635-2-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit 60f4472f5432728d27f853a631612ca62249006d Author: Jan Kara Date: Tue Nov 5 17:44:07 2019 +0100 jbd2: Fix possible overflow in jbd2_log_space_left() commit add3efdd78b8a0478ce423bb9d4df6bd95e8b335 upstream. When number of free space in the journal is very low, the arithmetic in jbd2_log_space_left() could underflow resulting in very high number of free blocks and thus triggering assertion failure in transaction commit code complaining there's not enough space in the journal: J_ASSERT(journal->j_free > 1); Properly check for the low number of free blocks. CC: stable@vger.kernel.org Reviewed-by: Theodore Ts'o Signed-off-by: Jan Kara Link: https://lore.kernel.org/r/20191105164437.32602-1-jack@suse.cz Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit c3386e04a0ed2a129e1d6339665f7cba7791497a Author: Tejun Heo Date: Mon Nov 4 15:54:29 2019 -0800 kernfs: fix ino wrap-around detection commit e23f568aa63f64cd6b355094224cc9356c0f696b upstream. When the 32bit ino wraps around, kernfs increments the generation number to distinguish reused ino instances. The wrap-around detection tests whether the allocated ino is lower than what the cursor but the cursor is pointing to the next ino to allocate so the condition never triggers. Fix it by remembering the last ino and comparing against that. Signed-off-by: Tejun Heo Reviewed-by: Greg Kroah-Hartman Fixes: 4a3ef68acacf ("kernfs: implement i_generation") Cc: Namhyung Kim Cc: stable@vger.kernel.org # v4.14+ Signed-off-by: Greg Kroah-Hartman commit 457a65b5828824fb56233c73c9121453c613c5fb Author: J. Bruce Fields Date: Tue Nov 19 16:05:33 2019 -0500 nfsd: restore NFSv3 ACL support commit 7c149057d044c52ed1e1d4ee50cf412c8d0f7295 upstream. An error in e333f3bbefe3 left the nfsd_acl_program->pg_vers array empty, which effectively turned off the server's support for NFSv3 ACLs. Fixes: e333f3bbefe3 "nfsd: Allow containers to set supported nfs versions" Cc: stable@vger.kernel.org Cc: Trond Myklebust Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit 43c9831fea79935c2f17bce3aa28e7e4d4e8855c Author: Trond Myklebust Date: Wed Nov 27 17:05:51 2019 -0500 nfsd: Ensure CLONE persists data and metadata changes to the target file commit a25e3726b32c746c0098125d4c7463bb84df72bb upstream. The NFSv4.2 CLONE operation has implicit persistence requirements on the target file, since there is no protocol requirement that the client issue a separate operation to persist data. For that reason, we should call vfs_fsync_range() on the destination file after a successful call to vfs_clone_file_range(). Fixes: ffa0160a1039 ("nfsd: implement the NFSv4.2 CLONE operation") Signed-off-by: Trond Myklebust Cc: stable@vger.kernel.org # v4.5+ Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit ecd1251d4be8cd336df1f0dfc537aa8d9fd8dec1 Author: Jouni Hogander Date: Wed Nov 27 08:40:26 2019 +0200 can: slcan: Fix use-after-free Read in slcan_open commit 9ebd796e24008f33f06ebea5a5e6aceb68b51794 upstream. Slcan_open doesn't clean-up device which registration failed from the slcan_devs device list. On next open this list is iterated and freed device is accessed. Fix this by calling slc_free_netdev in error path. Driver/net/can/slcan.c is derived from slip.c. Use-after-free error was identified in slip_open by syzboz. Same bug is in slcan.c. Here is the trace from the Syzbot slip report: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x197/0x210 lib/dump_stack.c:118 print_address_description.constprop.0.cold+0xd4/0x30b mm/kasan/report.c:374 __kasan_report.cold+0x1b/0x41 mm/kasan/report.c:506 kasan_report+0x12/0x20 mm/kasan/common.c:634 __asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:132 sl_sync drivers/net/slip/slip.c:725 [inline] slip_open+0xecd/0x11b7 drivers/net/slip/slip.c:801 tty_ldisc_open.isra.0+0xa3/0x110 drivers/tty/tty_ldisc.c:469 tty_set_ldisc+0x30e/0x6b0 drivers/tty/tty_ldisc.c:596 tiocsetd drivers/tty/tty_io.c:2334 [inline] tty_ioctl+0xe8d/0x14f0 drivers/tty/tty_io.c:2594 vfs_ioctl fs/ioctl.c:46 [inline] file_ioctl fs/ioctl.c:509 [inline] do_vfs_ioctl+0xdb6/0x13e0 fs/ioctl.c:696 ksys_ioctl+0xab/0xd0 fs/ioctl.c:713 __do_sys_ioctl fs/ioctl.c:720 [inline] __se_sys_ioctl fs/ioctl.c:718 [inline] __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:718 do_syscall_64+0xfa/0x760 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe Fixes: ed50e1600b44 ("slcan: Fix memory leak in error path") Cc: Wolfgang Grandegger Cc: Marc Kleine-Budde Cc: David Miller Cc: Oliver Hartkopp Cc: Lukas Bulwahn Signed-off-by: Jouni Hogander Cc: linux-stable # >= v5.4 Acked-by: Oliver Hartkopp Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 88380137e5336bfc34a5bd066def4047e0c97e6d Author: Dmitry Torokhov Date: Fri Nov 22 12:42:20 2019 -0800 tty: vt: keyboard: reject invalid keycodes commit b2b2dd71e0859436d4e05b2f61f86140250ed3f8 upstream. Do not try to handle keycodes that are too big, otherwise we risk doing out-of-bounds writes: BUG: KASAN: global-out-of-bounds in clear_bit include/asm-generic/bitops-instrumented.h:56 [inline] BUG: KASAN: global-out-of-bounds in kbd_keycode drivers/tty/vt/keyboard.c:1411 [inline] BUG: KASAN: global-out-of-bounds in kbd_event+0xe6b/0x3790 drivers/tty/vt/keyboard.c:1495 Write of size 8 at addr ffffffff89a1b2d8 by task syz-executor108/1722 ... kbd_keycode drivers/tty/vt/keyboard.c:1411 [inline] kbd_event+0xe6b/0x3790 drivers/tty/vt/keyboard.c:1495 input_to_handler+0x3b6/0x4c0 drivers/input/input.c:118 input_pass_values.part.0+0x2e3/0x720 drivers/input/input.c:145 input_pass_values drivers/input/input.c:949 [inline] input_set_keycode+0x290/0x320 drivers/input/input.c:954 evdev_handle_set_keycode_v2+0xc4/0x120 drivers/input/evdev.c:882 evdev_do_ioctl drivers/input/evdev.c:1150 [inline] In this case we were dealing with a fuzzed HID device that declared over 12K buttons, and while HID layer should not be reporting to us such big keycodes, we should also be defensive and reject invalid data ourselves as well. Reported-by: syzbot+19340dff067c2d3835c0@syzkaller.appspotmail.com Signed-off-by: Dmitry Torokhov Cc: stable Link: https://lore.kernel.org/r/20191122204220.GA129459@dtor-ws Signed-off-by: Greg Kroah-Hartman commit ae91cc73705ba14e6bc921560c0809babffc995f Author: Pavel Shilovsky Date: Thu Oct 31 14:18:57 2019 -0700 CIFS: Fix SMB2 oplock break processing commit fa9c2362497fbd64788063288dc4e74daf977ebb upstream. Even when mounting modern protocol version the server may be configured without supporting SMB2.1 leases and the client uses SMB2 oplock to optimize IO performance through local caching. However there is a problem in oplock break handling that leads to missing a break notification on the client who has a file opened. It latter causes big latencies to other clients that are trying to open the same file. The problem reproduces when there are multiple shares from the same server mounted on the client. The processing code tries to match persistent and volatile file ids from the break notification with an open file but it skips all share besides the first one. Fix this by looking up in all shares belonging to the server that issued the oplock break. Cc: Stable Signed-off-by: Pavel Shilovsky Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 4b3f32ab5e3b6dc85e9be07953fbf05c37324d4a Author: Pavel Shilovsky Date: Wed Nov 27 16:18:39 2019 -0800 CIFS: Fix NULL-pointer dereference in smb2_push_mandatory_locks commit 6f582b273ec23332074d970a7fb25bef835df71f upstream. Currently when the client creates a cifsFileInfo structure for a newly opened file, it allocates a list of byte-range locks with a pointer to the new cfile and attaches this list to the inode's lock list. The latter happens before initializing all other fields, e.g. cfile->tlink. Thus a partially initialized cifsFileInfo structure becomes available to other threads that walk through the inode's lock list. One example of such a thread may be an oplock break worker thread that tries to push all cached byte-range locks. This causes NULL-pointer dereference in smb2_push_mandatory_locks() when accessing cfile->tlink: [598428.945633] BUG: kernel NULL pointer dereference, address: 0000000000000038 ... [598428.945749] Workqueue: cifsoplockd cifs_oplock_break [cifs] [598428.945793] RIP: 0010:smb2_push_mandatory_locks+0xd6/0x5a0 [cifs] ... [598428.945834] Call Trace: [598428.945870] ? cifs_revalidate_mapping+0x45/0x90 [cifs] [598428.945901] cifs_oplock_break+0x13d/0x450 [cifs] [598428.945909] process_one_work+0x1db/0x380 [598428.945914] worker_thread+0x4d/0x400 [598428.945921] kthread+0x104/0x140 [598428.945925] ? process_one_work+0x380/0x380 [598428.945931] ? kthread_park+0x80/0x80 [598428.945937] ret_from_fork+0x35/0x40 Fix this by reordering initialization steps of the cifsFileInfo structure: initialize all the fields first and then add the new byte-range lock list to the inode's lock list. Cc: Stable Signed-off-by: Pavel Shilovsky Reviewed-by: Aurelien Aptel Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 6e7c6a8b3cde9b2aed2ed94471097fa8dacb7160 Author: Kai-Heng Feng Date: Mon Sep 2 22:52:52 2019 +0800 x86/PCI: Avoid AMD FCH XHCI USB PME# from D0 defect commit 7e8ce0e2b036dbc6617184317983aea4f2c52099 upstream. The AMD FCH USB XHCI Controller advertises support for generating PME# while in D0. When in D0, it does signal PME# for USB 3.0 connect events, but not for USB 2.0 or USB 1.1 connect events, which means the controller doesn't wake correctly for those events. 00:10.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] FCH USB XHCI Controller [1022:7914] (rev 20) (prog-if 30 [XHCI]) Subsystem: Dell FCH USB XHCI Controller [1028:087e] Capabilities: [50] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Clear PCI_PM_CAP_PME_D0 in dev->pme_support to indicate the device will not assert PME# from D0 so we don't rely on it. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203673 Link: https://lore.kernel.org/r/20190902145252.32111-1-kai.heng.feng@canonical.com Signed-off-by: Kai-Heng Feng Signed-off-by: Bjorn Helgaas Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 0ee646b5f8debc583a51ede7bdcccd7da639ca21 Author: Joerg Roedel Date: Tue Nov 26 11:09:42 2019 +0100 x86/mm/32: Sync only to VMALLOC_END in vmalloc_sync_all() commit 9a62d20027da3164a22244d9f022c0c987261687 upstream. The job of vmalloc_sync_all() is to help the lazy freeing of vmalloc() ranges: before such vmap ranges are reused we make sure that they are unmapped from every task's page tables. This is really easy on pagetable setups where the kernel page tables are shared between all tasks - this is the case on 32-bit kernels with SHARED_KERNEL_PMD = 1. But on !SHARED_KERNEL_PMD 32-bit kernels this involves iterating over the pgd_list and clearing all pmd entries in the pgds that are cleared in the init_mm.pgd, which is the reference pagetable that the vmalloc() code uses. In that context the current practice of vmalloc_sync_all() iterating until FIX_ADDR_TOP is buggy: for (address = VMALLOC_START & PMD_MASK; address >= TASK_SIZE_MAX && address < FIXADDR_TOP; address += PMD_SIZE) { struct page *page; Because iterating up to FIXADDR_TOP will involve a lot of non-vmalloc address ranges: VMALLOC -> PKMAP -> LDT -> CPU_ENTRY_AREA -> FIX_ADDR This is mostly harmless for the FIX_ADDR and CPU_ENTRY_AREA ranges that don't clear their pmds, but it's lethal for the LDT range, which relies on having different mappings in different processes, and 'synchronizing' them in the vmalloc sense corrupts those pagetable entries (clearing them). This got particularly prominent with PTI, which turns SHARED_KERNEL_PMD off and makes this the dominant mapping mode on 32-bit. To make LDT working again vmalloc_sync_all() must only iterate over the volatile parts of the kernel address range that are identical between all processes. So the correct check in vmalloc_sync_all() is "address < VMALLOC_END" to make sure the VMALLOC areas are synchronized and the LDT mapping is not falsely overwritten. The CPU_ENTRY_AREA and the FIXMAP area are no longer synced either, but this is not really a proplem since their PMDs get established during bootup and never change. This change fixes the ldt_gdt selftest in my setup. [ mingo: Fixed up the changelog to explain the logic and modified the copying to only happen up until VMALLOC_END. ] Reported-by: Borislav Petkov Tested-by: Borislav Petkov Signed-off-by: Joerg Roedel Cc: Cc: Andy Lutomirski Cc: Borislav Petkov Cc: Dave Hansen Cc: Joerg Roedel Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: hpa@zytor.com Fixes: 7757d607c6b3: ("x86/pti: Allow CONFIG_PAGE_TABLE_ISOLATION for x86_32") Link: https://lkml.kernel.org/r/20191126111119.GA110513@gmail.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 97d439dbaab9582de0a659f1e86639ee5bddffb7 Author: Sean Young Date: Sat Sep 28 17:46:14 2019 -0300 media: rc: mark input device as pointing stick commit ce819649b03d932dc19b0cb6be513779bf64fad3 upstream. libinput refuses pointer movement from rc-core, since it believes it's not a pointer-type device: libinput error: event17 - Media Center Ed. eHome Infrared Remote Transceiver (1784:0008): libinput bug: REL_X/Y from a non-pointer device Fixes: 158bc148a31e ("media: rc: mce_kbd: input events via rc-core's input device") Fixes: 0ac5a603a732 ("media: rc: imon: report mouse events using rc-core's input device") Cc: stable@vger.kernel.org # 4.20+ Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 96a992ff50a1f2a0016dd8845025585961f12d05 Author: Navid Emamdoost Date: Thu Nov 21 14:01:11 2019 -0600 Input: Fix memory leak in psxpad_spi_probe In the implementation of psxpad_spi_probe() the allocated memory for pdev is leaked if psxpad_spi_init_ff() or input_register_polled_device() fail. The solution is using device managed allocation, like the one used for pad. Perform the allocation using devm_input_allocate_polled_device(). Fixes: 8be193c7b1f4 ("Input: add support for PlayStation 1/2 joypads connected via SPI") Signed-off-by: Navid Emamdoost Acked-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 32a51a2241de97f759385c88b3794c1f0ae60aae Author: Mike Leach Date: Mon Nov 4 11:12:42 2019 -0700 coresight: etm4x: Fix input validation for sysfs. commit 2fe6899e36aa174abefd017887f9cfe0cb60c43a upstream. A number of issues are fixed relating to sysfs input validation:- 1) bb_ctrl_store() - incorrect compare of bit select field to absolute value. Reworked per ETMv4 specification. 2) seq_event_store() - incorrect mask value - register has two event values. 3) cyc_threshold_store() - must mask with max before checking min otherwise wrapped values can set illegal value below min. 4) res_ctrl_store() - update to mask off all res0 bits. Reviewed-by: Leo Yan Reviewed-by: Mathieu Poirier Signed-off-by: Mike Leach Fixes: a77de2637c9eb ("coresight: etm4x: moving sysFS entries to a dedicated file") Cc: stable # 4.9+ Signed-off-by: Mathieu Poirier Link: https://lore.kernel.org/r/20191104181251.26732-6-mathieu.poirier@linaro.org Signed-off-by: Greg Kroah-Hartman commit 3f3fcf6b54ffd5e0aa30bda65089bea929696eb0 Author: Hans de Goede Date: Mon Dec 2 09:36:15 2019 -0800 Input: goodix - add upside-down quirk for Teclast X89 tablet commit df5b5e555b356662a5e4a23c6774fdfce8547d54 upstream. The touchscreen on the Teclast X89 is mounted upside down in relation to the display orientation (the touchscreen itself is mounted upright, but the display is mounted upside-down). Add a quirk for this so that we send coordinates which match the display orientation. Signed-off-by: Hans de Goede Reviewed-by: Bastien Nocera Link: https://lore.kernel.org/r/20191202085636.6650-1-hdegoede@redhat.com Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 052cccd1c15fe1e3372dc616eb72b71f0931f1d5 Author: Hans Verkuil Date: Mon Dec 2 10:08:12 2019 -0800 Input: synaptics-rmi4 - don't increment rmiaddr for SMBus transfers commit a284e11c371e446371675668d8c8120a27227339 upstream. This increment of rmi_smbus in rmi_smb_read/write_block() causes garbage to be read/written. The first read of SMB_MAX_COUNT bytes is fine, but after that it is nonsense. Trial-and-error showed that by dropping the increment of rmiaddr everything is fine and the F54 function properly works. I tried a hack with rmi_smb_write_block() as well (writing to the same F54 touchpad data area, then reading it back), and that suggests that there too the rmiaddr increment has to be dropped. It makes sense that if it has to be dropped for read, then it has to be dropped for write as well. It looks like the initial work with F54 was done using i2c, not smbus, and it seems nobody ever tested F54 with smbus. The other functions all read/write less than SMB_MAX_COUNT as far as I can tell, so this issue was never noticed with non-F54 functions. With this change I can read out the touchpad data correctly on my Lenovo X1 Carbon 6th Gen laptop. Signed-off-by: Hans Verkuil Link: https://lore.kernel.org/r/8dd22e21-4933-8e9c-a696-d281872c8de7@xs4all.nl Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 5bc5a8202764a02b8622fb76a40a262816529fbe Author: Lucas Stach Date: Mon Dec 2 09:37:00 2019 -0800 Input: synaptics-rmi4 - re-enable IRQs in f34v7_do_reflash commit 86bcd3a12999447faad60ec59c2d64d18d8e61ac upstream. F34 is a bit special as it reinitializes the device and related driver structs during the firmware update. This clears the fn_irq_mask which will then prevent F34 from receiving further interrupts, leading to timeouts during the firmware update. Make sure to reinitialize the IRQ enables at the appropriate times. The issue is in F34 code, but the commit in the fixes tag exposed the issue, as before this commit things would work by accident. Fixes: 363c53875aef (Input: synaptics-rmi4 - avoid processing unknown IRQs) Signed-off-by: Lucas Stach Link: https://lore.kernel.org/r/20191129133514.23224-1-l.stach@pengutronix.de Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit f0f0a342134e9bc81ea4f8397f5919c0e0fb2a5c Author: Hans Verkuil Date: Fri Nov 22 16:17:08 2019 -0800 Input: synaptics - switch another X1 Carbon 6 to RMI/SMbus commit fc1156f373e3927e0dcf06678906c367588bfdd6 upstream. Some Lenovo X1 Carbon Gen 6 laptops report LEN0091. Add this to the smbus_pnp_ids list. Signed-off-by: Hans Verkuil Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20191119105118.54285-2-hverkuil-cisco@xs4all.nl Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit fd76e1a85817cfca0e33ae8c39cc3f2436b7542a Author: Takashi Iwai Date: Mon Dec 2 08:49:47 2019 +0100 ALSA: hda: Modify stream stripe mask only when needed commit e38e486d66e2a3b902768fd71c32dbf10f77e1cb upstream. The recent commit in HD-audio stream management for changing the stripe control seems causing a regression on some platforms. The stripe control is currently used only by HDMI codec, and applying the stripe mask unconditionally may lead to scratchy and static noises as seen on some MacBooks. For addressing the regression, this patch changes the stream management code to apply the stripe mask conditionally only when the codec driver requested. Fixes: 9b6f7e7a296e ("ALSA: hda: program stripe bits for controller") BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=204477 Tested-by: Michael Pobega Cc: Link: https://lore.kernel.org/r/20191202074947.1617-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 459ebff5f0f5b2a9c45d060a980b6b711b4196b1 Author: Kai-Heng Feng Date: Wed Nov 20 16:20:35 2019 +0800 ALSA: hda - Add mute led support for HP ProBook 645 G4 commit e190de6941db14813032af87873f5550ad5764fe upstream. Mic mute led does not work on HP ProBook 645 G4. We can use CXT_FIXUP_MUTE_LED_GPIO fixup to support it. Signed-off-by: Kai-Heng Feng Cc: Link: https://lore.kernel.org/r/20191120082035.18937-1-kai.heng.feng@canonical.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 24bbab3d0f65e82d5c827451bf86b2b21aa1add4 Author: Takashi Iwai Date: Wed Dec 4 15:48:24 2019 +0100 ALSA: pcm: oss: Avoid potential buffer overflows commit 4cc8d6505ab82db3357613d36e6c58a297f57f7c upstream. syzkaller reported an invalid access in PCM OSS read, and this seems to be an overflow of the internal buffer allocated for a plugin. Since the rate plugin adjusts its transfer size dynamically, the calculation for the chained plugin might be bigger than the given buffer size in some extreme cases, which lead to such an buffer overflow as caught by KASAN. Fix it by limiting the max transfer size properly by checking against the destination size in each plugin transfer callback. Reported-by: syzbot+f153bde47a62e0b05f83@syzkaller.appspotmail.com Cc: Link: https://lore.kernel.org/r/20191204144824.17801-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit d99b365f36ba0ae9e73fcf4061bb5e0946582f19 Author: Kailang Yang Date: Tue Nov 26 17:04:23 2019 +0800 ALSA: hda/realtek - Dell headphone has noise on unmute for ALC236 commit e1e8c1fdce8b00fce08784d9d738c60ebf598ebc upstream. headphone have noise even the volume is very small. Let it fill up pcbeep hidden register to default value. The issue was gone. Fixes: 4344aec84bd8 ("ALSA: hda/realtek - New codec support for ALC256") Fixes: 736f20a70608 ("ALSA: hda/realtek - Add support for ALC236/ALC3204") Signed-off-by: Kailang Yang Cc: Link: https://lore.kernel.org/r/9ae47f23a64d4e41a9c81e263cd8a250@realtek.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit d7139481f4b5e52a35db6a61244bcf1e94b2b4be Author: Hui Wang Date: Thu Nov 21 10:54:27 2019 +0800 ALSA: hda/realtek - Enable the headset-mic on a Xiaomi's laptop commit 695d1ec3994f9de2cefae80ee2087c95d2e5a2f3 upstream. The headset on this machine is not defined, after applying the quirk ALC256_FIXUP_ASUS_HEADSET_MIC, the headset-mic works well BugLink: https://bugs.launchpad.net/bugs/1846148 Cc: Signed-off-by: Hui Wang Link: https://lore.kernel.org/r/20191121025427.8856-1-hui.wang@canonical.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 3f57722e57059015222644c7bc8c85c5dc1d06a6 Author: Jian-Hong Pan Date: Mon Nov 25 17:34:06 2019 +0800 ALSA: hda/realtek - Enable internal speaker of ASUS UX431FLC commit 436e25505f3458cc92c7f3c985e9cbc198a98209 upstream. Laptops like ASUS UX431FLC and UX431FL can share the same audio quirks. But UX431FLC needs one more step to enable the internal speaker: Pull the GPIO from CODEC to initialize the AMP. Fixes: 60083f9e94b2 ("ALSA: hda/realtek - Enable internal speaker & headset mic of ASUS UX431FL") Signed-off-by: Jian-Hong Pan Cc: Link: https://lore.kernel.org/r/20191125093405.5702-1-jian-hong@endlessm.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit a6bae0cefc34940ede720cf2eb04e87bd41e8757 Author: Trond Myklebust Date: Tue Nov 5 09:10:54 2019 -0500 SUNRPC: Avoid RPC delays when exiting suspend commit 66eb3add452aa1be65ad536da99fac4b8f620b74 upstream. Jon Hunter: "I have been tracking down another suspend/NFS related issue where again I am seeing random delays exiting suspend. The delays can be up to a couple minutes in the worst case and this is causing a suspend test we have to fail." Change the use of a deferrable work to a standard delayed one. Reported-by: Jon Hunter Tested-by: Jon Hunter Fixes: 7e0a0e38fcfea ("SUNRPC: Replace the queue timer with a delayed work function") Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit d123a552a2d8bff72638794140c050586f9b18c8 Author: Jens Axboe Date: Wed Dec 4 08:53:43 2019 -0700 io_uring: ensure req->submit is copied when req is deferred There's an issue with deferred requests through drain, where if we do need to defer, we're not copying over the sqe_submit state correctly. This can result in using uninitialized data when we then later go and submit the deferred request, like this check in __io_submit_sqe(): if (unlikely(s->index >= ctx->sq_entries)) return -EINVAL; with 's' being uninitialized, we can randomly fail this check. Fix this by copying sqe_submit state when we defer a request. Because it was fixed as part of a cleanup series in mainline, before anyone realized we had this issue. That removed the separate states of ->index vs ->submit.sqe. That series is not something I was comfortable putting into stable, hence the much simpler addition. Here's the patch in the series that fixes the same issue: commit cf6fd4bd559ee61a4454b161863c8de6f30f8dca Author: Pavel Begunkov Date: Mon Nov 25 23:14:39 2019 +0300 io_uring: inline struct sqe_submit Reported-by: Andres Freund Reported-by: Tomáš Chaloupka Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit c1d5ea02625731f97634d1f13ec88d680e9ecd47 Author: Miklos Szeredi Date: Tue Nov 12 11:49:04 2019 +0100 fuse: verify attributes commit eb59bd17d2fa6e5e84fba61a5ebdea984222e6d5 upstream. If a filesystem returns negative inode sizes, future reads on the file were causing the cpu to spin on truncate_pagecache. Create a helper to validate the attributes. This now does two things: - check the file mode - check if the file size fits in i_size without overflowing Reported-by: Arijit Banerjee Fixes: d8a5ba45457e ("[PATCH] FUSE - core") Cc: # v2.6.14 Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit d222c23f9ba682a844a5d5de301620d79ebb7a42 Author: Miklos Szeredi Date: Tue Nov 12 11:49:04 2019 +0100 fuse: verify nlink commit c634da718db9b2fac201df2ae1b1b095344ce5eb upstream. When adding a new hard link, make sure that i_nlink doesn't overflow. Fixes: ac45d61357e8 ("fuse: fix nlink after unlink") Cc: # v3.4 Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit 9beee25c38761f3d67de020475229eadc71524de Author: Jens Axboe Date: Mon Dec 2 18:49:10 2019 -0700 io_uring: transform send/recvmsg() -ERESTARTSYS to -EINTR commit 441cdbd5449b4923cd413d3ba748124f91388be9 upstream. We should never return -ERESTARTSYS to userspace, transform it into -EINTR. Cc: stable@vger.kernel.org # v5.3+ Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 22c9f7cbd0cf7050d1d9175e740d3b8225d0b496 Author: Wen Yang Date: Fri Nov 8 16:36:48 2019 +0800 i2c: core: fix use after free in of_i2c_notify [ Upstream commit a4c2fec16f5e6a5fee4865e6e0e91e2bc2d10f37 ] We can't use "adap->dev" after it has been freed. Fixes: 5bf4fa7daea6 ("i2c: break out OF support into separate file") Signed-off-by: Wen Yang Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 1c523e5d094a5cb91d85bee9ab92825bf4927e98 Author: Chuhong Yuan Date: Thu Nov 14 23:43:24 2019 +0800 net: ep93xx_eth: fix mismatch of request_mem_region in remove [ Upstream commit 3df70afe8d33f4977d0e0891bdcfb639320b5257 ] The driver calls release_resource in remove to match request_mem_region in probe, which is incorrect. Fix it by using the right one, release_mem_region. Signed-off-by: Chuhong Yuan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 20da23d766f5b4975391b9a6d81594ee6ad5e6d3 Author: David Howells Date: Thu Nov 14 18:41:03 2019 +0000 afs: Fix race in commit bulk status fetch [ Upstream commit a28f239e296767ebf4ec4ae8a9ecb57d0d444b3f ] When a lookup is done, the afs filesystem will perform a bulk status-fetch operation on the requested vnode (file) plus the next 49 other vnodes from the directory list (in AFS, directory contents are downloaded as blobs and parsed locally). When the results are received, it will speculatively populate the inode cache from the extra data. However, if the lookup races with another lookup on the same directory, but for a different file - one that's in the 49 extra fetches, then if the bulk status-fetch operation finishes first, it will try and update the inode from the other lookup. If this other inode is still in the throes of being created, however, this will cause an assertion failure in afs_apply_status(): BUG_ON(test_bit(AFS_VNODE_UNSET, &vnode->flags)); on or about fs/afs/inode.c:175 because it expects data to be there already that it can compare to. Fix this by skipping the update if the inode is being created as the creator will presumably set up the inode with the same information. Fixes: 39db9815da48 ("afs: Fix application of the results of a inline bulk status fetch") Signed-off-by: David Howells Reviewed-by: Marc Dionne Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit e2caaa11cbc1d931c5b8f6ccdf76cd7544f741c0 Author: Yonglong Liu Date: Thu Nov 14 10:32:41 2019 +0800 net: hns3: fix ETS bandwidth validation bug [ Upstream commit c2d56897819338eb0ba8b93184f7d10329b36653 ] Some device only support 4 TCs, but the driver check the total bandwidth of 8 TCs, so may cause wrong configurations write to the hw. This patch uses hdev->tc_max to instead HNAE3_MAX_TC to fix it. Fixes: e432abfb99e5 ("net: hns3: add common validation in hclge_dcb") Signed-off-by: Yonglong Liu Signed-off-by: Huazhong Tan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 8e5e98f908c687d309b7de8ae295e03de977d40a Author: Yunsheng Lin Date: Thu Nov 14 10:32:40 2019 +0800 net: hns3: reallocate SSU' buffer size when pfc_en changes [ Upstream commit aea8cfb35a82d6c2f3517c86694933ba766635e5 ] When a TC's PFC is disabled or enabled, the RX private buffer for this TC need to be changed too, otherwise this may cause packet dropped problem. This patch fixes it by calling hclge_buffer_alloc to reallocate buffer when pfc_en changes. Fixes: cacde272dd00 ("net: hns3: Add hclge_dcb module for the support of DCB feature") Signed-off-by: Yunsheng Lin Signed-off-by: Huazhong Tan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 3b735f5f62aae1b53edd8d0e57f3fd3b4cf31abd Author: Ulrich Hecht Date: Thu Nov 14 02:49:49 2019 +0100 ravb: implement MTU change while device is up [ Upstream commit 15fb35fa9ff456b81159033eba6397fcee85e671 ] Pre-allocates buffers sufficient for the maximum supported MTU (2026) in order to eliminate the possibility of resource exhaustion when changing the MTU while the device is up. Signed-off-by: Ulrich Hecht Reviewed-by: Sergei Shtylyov Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 7696b49eb96e06865c3f907e28d5a3f8b814c6c0 Author: Chuhong Yuan Date: Wed Nov 13 14:38:47 2019 +0800 rsxx: add missed destroy_workqueue calls in remove [ Upstream commit dcb77e4b274b8f13ac6482dfb09160cd2fae9a40 ] The driver misses calling destroy_workqueue in remove like what is done when probe fails. Add the missed calls to fix it. Signed-off-by: Chuhong Yuan Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 94fb895537c41354da885bb3de2aa75d1e2feb72 Author: Ilya Dryomov Date: Wed Nov 13 12:07:15 2019 +0100 rbd: silence bogus uninitialized warning in rbd_object_map_update_finish() [ Upstream commit 633739b2fedb6617d782ca252797b7a8ad754347 ] Some versions of gcc (so far 6.3 and 7.4) throw a warning: drivers/block/rbd.c: In function 'rbd_object_map_callback': drivers/block/rbd.c:2124:21: warning: 'current_state' may be used uninitialized in this function [-Wmaybe-uninitialized] (current_state == OBJECT_EXISTS && state == OBJECT_EXISTS_CLEAN)) drivers/block/rbd.c:2092:23: note: 'current_state' was declared here u8 state, new_state, current_state; ^~~~~~~~~~~~~ It's bogus because all current_state accesses are guarded by has_current_state. Reported-by: kbuild test robot Signed-off-by: Ilya Dryomov Reviewed-by: Dongsheng Yang Signed-off-by: Sasha Levin commit 0a053b9bee92b807df574bc94ec285e44e451543 Author: Vitaly Kuznetsov Date: Wed Nov 13 13:51:15 2019 +0100 selftests: kvm: fix build with glibc >= 2.30 [ Upstream commit e37f9f139f62deddff90c7298ae3a85026a71067 ] Glibc-2.30 gained gettid() wrapper, selftests fail to compile: lib/assert.c:58:14: error: static declaration of ‘gettid’ follows non-static declaration 58 | static pid_t gettid(void) | ^~~~~~ In file included from /usr/include/unistd.h:1170, from include/test_util.h:18, from lib/assert.c:10: /usr/include/bits/unistd_ext.h:34:16: note: previous declaration of ‘gettid’ was here 34 | extern __pid_t gettid (void) __THROW; | ^~~~~~ Signed-off-by: Vitaly Kuznetsov Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 7d9db769ef7a333510ee5cb10c26df23434dfe08 Author: Yunhao Tian Date: Wed Nov 13 13:27:25 2019 +0000 drm/sun4i: tcon: Set min division of TCON0_DCLK to 1. [ Upstream commit 0b8e7bbde5e7e2c419567e1ee29587dae3b78ee3 ] The datasheet of V3s (and various other chips) wrote that TCON0_DCLK_DIV can be >= 1 if only dclk is used, and must >= 6 if dclk1 or dclk2 is used. As currently neither dclk1 nor dclk2 is used (no writes to these bits), let's set minimal division to 1. If this minimal division is 6, some common dot clock frequencies can't be produced (e.g. 30MHz will not be possible and will fallback to 25MHz), which is obviously not an expected behaviour. Signed-off-by: Yunhao Tian Signed-off-by: Maxime Ripard Link: https://lore.kernel.org/linux-arm-kernel/MN2PR08MB57905AD8A00C08DA219377C989760@MN2PR08MB5790.namprd08.prod.outlook.com/ Signed-off-by: Sasha Levin commit e4d2c8420780a55b63577e78402bafb6a402e0cb Author: Xiaochen Shen Date: Thu Nov 7 06:36:36 2019 +0800 x86/resctrl: Fix potential lockdep warning [ Upstream commit c8eafe1495303bfd0eedaa8156b1ee9082ee9642 ] rdtgroup_cpus_write() and mkdir_rdt_prepare() call rdtgroup_kn_lock_live() -> kernfs_to_rdtgroup() to get 'rdtgrp', and then call the rdt_last_cmd_{clear,puts,...}() functions which will check if rdtgroup_mutex is held/requires its caller to hold rdtgroup_mutex. But if 'rdtgrp' returned from kernfs_to_rdtgroup() is NULL, rdtgroup_mutex is not held and calling rdt_last_cmd_{clear,puts,...}() will result in a self-incurred, potential lockdep warning. Remove the rdt_last_cmd_{clear,puts,...}() calls in these two paths. Just returning error should be sufficient to report to the user that the entry doesn't exist any more. [ bp: Massage. ] Fixes: 94457b36e8a5 ("x86/intel_rdt: Add diagnostics when writing the cpus file") Fixes: cfd0f34e4cd5 ("x86/intel_rdt: Add diagnostics when making directories") Signed-off-by: Xiaochen Shen Signed-off-by: Borislav Petkov Reviewed-by: Tony Luck Reviewed-by: Fenghua Yu Reviewed-by: Reinette Chatre Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: pei.p.jia@intel.com Cc: Thomas Gleixner Cc: x86-ml Link: https://lkml.kernel.org/r/1573079796-11713-1-git-send-email-xiaochen.shen@intel.com Signed-off-by: Sasha Levin commit c5e020ec2617e11ef2c04f469e00e8b106a8c63c Author: paulhsia Date: Wed Nov 13 01:17:14 2019 +0800 ALSA: pcm: Fix stream lock usage in snd_pcm_period_elapsed() [ Upstream commit f5cdc9d4003a2f66ea57b3edd3e04acc2b1a4439 ] If the nullity check for `substream->runtime` is outside of the lock region, it is possible to have a null runtime in the critical section if snd_pcm_detach_substream is called right before the lock. Signed-off-by: paulhsia Link: https://lore.kernel.org/r/20191112171715.128727-2-paulhsia@chromium.org Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit b9366c7cb7d0e5b302d337921c87ddc870bb6c3a Author: Alexander Shishkin Date: Tue Nov 5 09:57:02 2019 +0200 perf/core: Consistently fail fork on allocation failures [ Upstream commit 697d877849d4b34ab58d7078d6930bad0ef6fc66 ] Commit: 313ccb9615948 ("perf: Allocate context task_ctx_data for child event") makes the inherit path skip over the current event in case of task_ctx_data allocation failure. This, however, is inconsistent with allocation failures in perf_event_alloc(), which would abort the fork. Correct this by returning an error code on task_ctx_data allocation failure and failing the fork in that case. Signed-off-by: Alexander Shishkin Signed-off-by: Peter Zijlstra (Intel) Cc: Arnaldo Carvalho de Melo Cc: David Ahern Cc: Jiri Olsa Cc: Jiri Olsa Cc: Linus Torvalds Cc: Mark Rutland Cc: Namhyung Kim Cc: Stephane Eranian Cc: Thomas Gleixner Cc: Vince Weaver Link: https://lkml.kernel.org/r/20191105075702.60319-1-alexander.shishkin@linux.intel.com Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit bee9a556fe0a3d86b0072596a64c811e14adf9b7 Author: Vincent Guittot Date: Wed Oct 30 12:18:29 2019 +0100 sched/pelt: Fix update of blocked PELT ordering [ Upstream commit b90f7c9d2198d789709390280a43e0a46345682b ] update_cfs_rq_load_avg() can call cpufreq_update_util() to trigger an update of the frequency. Make sure that RT, DL and IRQ PELT signals have been updated before calling cpufreq. Signed-off-by: Vincent Guittot Signed-off-by: Peter Zijlstra (Intel) Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: dietmar.eggemann@arm.com Cc: dsmythies@telus.net Cc: juri.lelli@redhat.com Cc: mgorman@suse.de Cc: rostedt@goodmis.org Fixes: 371bf4273269 ("sched/rt: Add rt_rq utilization tracking") Fixes: 3727e0e16340 ("sched/dl: Add dl_rq utilization tracking") Fixes: 91c27493e78d ("sched/irq: Add IRQ utilization tracking") Link: https://lkml.kernel.org/r/1572434309-32512-1-git-send-email-vincent.guittot@linaro.org Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit c767cc7f9e22ea8fe2bae3c2c66d91436c1333b7 Author: Peter Zijlstra Date: Tue Oct 1 11:18:37 2019 +0200 sched/core: Avoid spurious lock dependencies [ Upstream commit ff51ff84d82aea5a889b85f2b9fb3aa2b8691668 ] While seemingly harmless, __sched_fork() does hrtimer_init(), which, when DEBUG_OBJETS, can end up doing allocations. This then results in the following lock order: rq->lock zone->lock.rlock batched_entropy_u64.lock Which in turn causes deadlocks when we do wakeups while holding that batched_entropy lock -- as the random code does. Solve this by moving __sched_fork() out from under rq->lock. This is safe because nothing there relies on rq->lock, as also evident from the other __sched_fork() callsite. Signed-off-by: Peter Zijlstra (Intel) Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Qian Cai Cc: Thomas Gleixner Cc: akpm@linux-foundation.org Cc: bigeasy@linutronix.de Cc: cl@linux.com Cc: keescook@chromium.org Cc: penberg@kernel.org Cc: rientjes@google.com Cc: thgarnie@google.com Cc: tytso@mit.edu Cc: will@kernel.org Fixes: b7d5dc21072c ("random: add a spinlock_t to struct batched_entropy") Link: https://lkml.kernel.org/r/20191001091837.GK4536@hirez.programming.kicks-ass.net Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit 47c7888200bcb909b673bf080d52c05c90e4320d Author: Pan Bian Date: Tue Nov 12 17:04:54 2019 -0800 Input: cyttsp4_core - fix use after free bug [ Upstream commit 79aae6acbef16f720a7949f8fc6ac69816c79d62 ] The device md->input is used after it is released. Setting the device data to NULL is unnecessary as the device is never used again. Instead, md->input should be assigned NULL to avoid accessing the freed memory accidently. Besides, checking md->si against NULL is superfluous as it points to a variable address, which cannot be NULL. Signed-off-by: Pan Bian Link: https://lore.kernel.org/r/1572936379-6423-1-git-send-email-bianpan2016@163.com Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit bc6024b4273dcb39eebc0fc26de164185d1933cd Author: Junichi Nomura Date: Tue Nov 12 07:19:58 2019 +0000 block: check bi_size overflow before merge [ Upstream commit e3a5d8e386c3fb973fa75f2403622a8f3640ec06 ] __bio_try_merge_page() may merge a page to bio without bio_full() check and cause bi_size overflow. The overflow typically ends up with sd_init_command() warning on zero segment request with call trace like this: ------------[ cut here ]------------ WARNING: CPU: 2 PID: 1986 at drivers/scsi/scsi_lib.c:1025 scsi_init_io+0x156/0x180 CPU: 2 PID: 1986 Comm: kworker/2:1H Kdump: loaded Not tainted 5.4.0-rc7 #1 Workqueue: kblockd blk_mq_run_work_fn RIP: 0010:scsi_init_io+0x156/0x180 RSP: 0018:ffffa11487663bf0 EFLAGS: 00010246 RAX: 00000000002be0a0 RBX: ffff8e6e9ff30118 RCX: 0000000000000000 RDX: 00000000ffffffe1 RSI: 0000000000000000 RDI: ffff8e6e9ff30118 RBP: ffffa11487663c18 R08: ffffa11487663d28 R09: ffff8e6e9ff30150 R10: 0000000000000001 R11: 0000000000000000 R12: ffff8e6e9ff30000 R13: 0000000000000001 R14: ffff8e74a1cf1800 R15: ffff8e6e9ff30000 FS: 0000000000000000(0000) GS:ffff8e6ea7680000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fff18cf0fe8 CR3: 0000000659f0a001 CR4: 00000000001606e0 Call Trace: sd_init_command+0x326/0xb40 [sd_mod] scsi_queue_rq+0x502/0xaa0 ? blk_mq_get_driver_tag+0xe7/0x120 blk_mq_dispatch_rq_list+0x256/0x5a0 ? elv_rb_del+0x24/0x30 ? deadline_remove_request+0x7b/0xc0 blk_mq_do_dispatch_sched+0xa3/0x140 blk_mq_sched_dispatch_requests+0xfb/0x170 __blk_mq_run_hw_queue+0x81/0x130 blk_mq_run_work_fn+0x1b/0x20 process_one_work+0x179/0x390 worker_thread+0x4f/0x3e0 kthread+0x105/0x140 ? max_active_store+0x80/0x80 ? kthread_bind+0x20/0x20 ret_from_fork+0x35/0x40 ---[ end trace f9036abf5af4a4d3 ]--- blk_update_request: I/O error, dev sdd, sector 2875552 op 0x1:(WRITE) flags 0x0 phys_seg 0 prio class 0 XFS (sdd1): writeback error on sector 2875552 __bio_try_merge_page() should check the overflow before actually doing merge. Fixes: 07173c3ec276c ("block: enable multipage bvecs") Reviewed-by: Christoph Hellwig Reviewed-by: Ming Lei Reviewed-by: Hannes Reinecke Signed-off-by: Jun'ichi Nomura Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 167e868a33217d41562f04f8473485554873a4fd Author: Xiaodong Xu Date: Mon Nov 11 15:05:46 2019 -0800 xfrm: release device reference for invalid state [ Upstream commit 4944a4b1077f74d89073624bd286219d2fcbfce3 ] An ESP packet could be decrypted in async mode if the input handler for this packet returns -EINPROGRESS in xfrm_input(). At this moment the device reference in skb is held. Later xfrm_input() will be invoked again to resume the processing. If the transform state is still valid it would continue to release the device reference and there won't be a problem; however if the transform state is not valid when async resumption happens, the packet will be dropped while the device reference is still being held. When the device is deleted for some reason and the reference to this device is not properly released, the kernel will keep logging like: unregister_netdevice: waiting for ppp2 to become free. Usage count = 1 The issue is observed when running IPsec traffic over a PPPoE device based on a bridge interface. By terminating the PPPoE connection on the server end for multiple times, the PPPoE device on the client side will eventually get stuck on the above warning message. This patch will check the async mode first and continue to release device reference in async resumption, before it is dropped due to invalid state. v2: Do not assign address family from outer_mode in the transform if the state is invalid v3: Release device reference in the error path instead of jumping to resume Fixes: 4ce3dbe397d7b ("xfrm: Fix xfrm_input() to verify state is valid when (encap_type < 0)") Signed-off-by: Xiaodong Xu Reported-by: Bo Chen Tested-by: Bo Chen Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit ec98a14c8fadb826f609653cc187b464a81cdba6 Author: Stephan Gerhold Date: Sun Nov 10 17:19:15 2019 +0100 NFC: nxp-nci: Fix NULL pointer dereference after I2C communication error [ Upstream commit a71a29f50de1ef97ab55c151a1598eb12dde379d ] I2C communication errors (-EREMOTEIO) during the IRQ handler of nxp-nci result in a NULL pointer dereference at the moment: BUG: kernel NULL pointer dereference, address: 0000000000000000 Oops: 0002 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 355 Comm: irq/137-nxp-nci Not tainted 5.4.0-rc6 #1 RIP: 0010:skb_queue_tail+0x25/0x50 Call Trace: nci_recv_frame+0x36/0x90 [nci] nxp_nci_i2c_irq_thread_fn+0xd1/0x285 [nxp_nci_i2c] ? preempt_count_add+0x68/0xa0 ? irq_forced_thread_fn+0x80/0x80 irq_thread_fn+0x20/0x60 irq_thread+0xee/0x180 ? wake_threads_waitq+0x30/0x30 kthread+0xfb/0x130 ? irq_thread_check_affinity+0xd0/0xd0 ? kthread_park+0x90/0x90 ret_from_fork+0x1f/0x40 Afterward the kernel must be rebooted to work properly again. This happens because it attempts to call nci_recv_frame() with skb == NULL. However, unlike nxp_nci_fw_recv_frame(), nci_recv_frame() does not have any NULL checks for skb, causing the NULL pointer dereference. Change the code to call only nxp_nci_fw_recv_frame() in case of an error. Make sure to log it so it is obvious that a communication error occurred. The error above then becomes: nxp-nci_i2c i2c-NXP1001:00: NFC: Read failed with error -121 nci: __nci_request: wait_for_completion_interruptible_timeout failed 0 nxp-nci_i2c i2c-NXP1001:00: NFC: Read failed with error -121 Fixes: 6be88670fc59 ("NFC: nxp-nci_i2c: Add I2C support to NXP NCI driver") Signed-off-by: Stephan Gerhold Reviewed-by: Andy Shevchenko Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 15940941a564353de6f4dba7348e0537f83fb627 Author: Chiou, Cooper Date: Fri Nov 8 15:13:49 2019 +0800 ALSA: hda: Add Cometlake-S PCI ID [ Upstream commit b73a58549ea37a44434c7afab3c7ad9af210cfd9 ] Add HD Audio Device PCI ID for the Intel Cometlake-S platform Signed-off-by: Chiou, Cooper Link: https://lore.kernel.org/r/20191108071349.12840-1-cooper.chiou@intel.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 04e3a412b61e6886791e9359c1e1110ba0e90dfb Author: Al Viro Date: Sun Nov 3 12:07:15 2019 -0500 ecryptfs: fix unlink and rmdir in face of underlying fs modifications [ Upstream commit bcf0d9d4b76976f892154efdfc509b256fd898e8 ] A problem similar to the one caught in commit 74dd7c97ea2a ("ecryptfs_rename(): verify that lower dentries are still OK after lock_rename()") exists for unlink/rmdir as well. Instead of playing with dget_parent() of underlying dentry of victim and hoping it's the same as underlying dentry of our directory, do the following: * find the underlying dentry of victim * find the underlying directory of victim's parent (stable since the victim is ecryptfs dentry and inode of its parent is held exclusive by the caller). * lock the inode of dentry underlying the victim's parent * check that underlying dentry of victim is still hashed and has the right parent - it can be moved, but it can't be moved to/from the directory we are holding exclusive. So while ->d_parent itself might not be stable, the result of comparison is. If the check passes, everything is fine - underlying directory is locked, underlying victim is still a child of that directory and we can go ahead and feed them to vfs_unlink(). As in the current mainline we need to pin the underlying dentry of victim, so that it wouldn't go negative under us, but that's the only temporary reference that needs to be grabbed there. Underlying dentry of parent won't go away (it's pinned by the parent, which is held by caller), so there's no need to grab it. The same problem (with the same solution) exists for rmdir. Moreover, rename gets simpler and more robust with the same "don't bother with dget_parent()" approach. Fixes: 74dd7c97ea2 "ecryptfs_rename(): verify that lower dentries are still OK after lock_rename()" Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit 6309d4077ec1adac5901c5de0bbd9a46af22d755 Author: Al Viro Date: Sat Nov 2 13:11:41 2019 -0400 audit_get_nd(): don't unlock parent too early [ Upstream commit 69924b89687a2923e88cc42144aea27868913d0e ] if the child has been negative and just went positive under us, we want coherent d_is_positive() and ->d_inode. Don't unlock the parent until we'd done that work... Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit e2ed4758d04cb205ab7b57e8b576b738dec504d2 Author: Al Viro Date: Fri Nov 8 22:08:29 2019 -0500 exportfs_decode_fh(): negative pinned may become positive without the parent locked [ Upstream commit a2ece088882666e1dc7113744ac912eb161e3f87 ] Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit 3cb1b371263ab30a71f220eeeee50d2e23b7d88a Author: Al Viro Date: Sun Nov 10 11:53:27 2019 -0500 cgroup: don't put ERR_PTR() into fc->root [ Upstream commit 630faf81b3e61bcc90dc6d8b497800657d2752a5 ] the caller of ->get_tree() expects NULL left there on error... Reported-by: Thibaut Sautereau Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit d939c419cfebdd8280897d6f6fd5d7a6220a37a6 Author: Mordechay Goodstein Date: Thu Nov 7 13:51:47 2019 +0200 iwlwifi: pcie: don't consider IV len in A-MSDU [ Upstream commit cb1a4badf59275eb7221dcec621e8154917eabd1 ] From gen2 PN is totally offloaded to hardware (also the space for the IV isn't part of the skb). As you can see in mvm/mac80211.c:3545, the MAC for cipher types CCMP/GCMP doesn't set IEEE80211_KEY_FLAG_PUT_IV_SPACE for gen2 NICs. This causes all the AMSDU data to be corrupted with cipher enabled. Signed-off-by: Mordechay Goodstein Signed-off-by: Luca Coelho Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit 08f9495c6db349edac74c7e69f7c078596ca86d2 Author: Wenpeng Liang Date: Fri Nov 1 10:33:30 2019 +0800 RDMA/hns: Correct the value of srq_desc_size [ Upstream commit 411c1e6774e2e1f96b1ccce4f119376b94ade3e4 ] srq_desc_size should be rounded up to pow of two before used, or related calculation may cause allocating wrong size of memory for srq buffer. Fixes: c7bcb13442e1 ("RDMA/hns: Add SRQ support for hip08 kernel mode") Link: https://lore.kernel.org/r/1572575610-52530-3-git-send-email-liweihang@hisilicon.com Signed-off-by: Wenpeng Liang Signed-off-by: Weihang Li Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 43cb8b2eaaf7a062b9ec396e2fc15acd1125a999 Author: Sirong Wang Date: Fri Nov 1 10:33:29 2019 +0800 RDMA/hns: Correct the value of HNS_ROCE_HEM_CHUNK_LEN [ Upstream commit 531eb45b3da4267fc2a64233ba256c8ffb02edd2 ] Size of pointer to buf field of struct hns_roce_hem_chunk should be considered when calculating HNS_ROCE_HEM_CHUNK_LEN, or sg table size will be larger than expected when allocating hem. Fixes: 9a4435375cd1 ("IB/hns: Add driver files for hns RoCE driver") Link: https://lore.kernel.org/r/1572575610-52530-2-git-send-email-liweihang@hisilicon.com Signed-off-by: Sirong Wang Signed-off-by: Weihang Li Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 8a53fbc15d1c84ce4a08b4642de06ebaf4d867d9 Author: Thomas Bogendoerfer Date: Thu Oct 31 10:46:04 2019 +0100 MIPS: SGI-IP27: fix exception handler replication [ Upstream commit 637346748245e94c877aa746e6fe0d7079b7736a ] Commit 775b089aeffa ("MIPS: tlbex: Remove cpu_has_local_ebase") removed generating tlb refill handlers for every CPU, which was needed for generating per node exception handlers on IP27. Instead of resurrecting (and fixing) refill handler generation, we simply copy all exception vectors from the boot node to the other nodes. Also remove the config option since the memory tradeoff for expection handler replication is just 8k per node. Signed-off-by: Thomas Bogendoerfer Signed-off-by: Paul Burton Cc: Ralf Baechle Cc: Paul Burton Cc: James Hogan Cc: linux-mips@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Sasha Levin commit 1c484ca8a34da08e21fd378e7e10c36f5dee8b36 Author: Al Viro Date: Fri Oct 25 00:03:11 2019 -0400 autofs: fix a leak in autofs_expire_indirect() [ Upstream commit 03ad0d703df75c43f78bd72e16124b5b94a95188 ] if the second call of should_expire() in there ends up grabbing and returning a new reference to dentry, we need to drop it before continuing. Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit 72712b93e5a7ed4317d01ead06372755d9cff0dd Author: Guillem Jover Date: Wed Aug 21 05:38:20 2019 +0200 aio: Fix io_pgetevents() struct __compat_aio_sigset layout [ Upstream commit 97eba80fcca754856d09e048f469db22773bec68 ] This type is used to pass the sigset_t from userland to the kernel, but it was using the kernel native pointer type for the member representing the compat userland pointer to the userland sigset_t. This messes up the layout, and makes the kernel eat up both the userland pointer and the size members into the kernel pointer, and then reads garbage into the kernel sigsetsize. Which makes the sigset_t size consistency check fail, and consequently the syscall always returns -EINVAL. This breaks both libaio and strace on 32-bit userland running on 64-bit kernels. And there are apparently no users in the wild of the current broken layout (at least according to codesearch.debian.org and a brief check over github.com search). So it looks safe to fix this directly in the kernel, instead of either letting userland deal with this permanently with the additional overhead or trying to make the syscall infer what layout userland used, even though this is also being worked around in libaio to temporarily cope with kernels that have not yet been fixed. We use a proper compat_uptr_t instead of a compat_sigset_t pointer. Fixes: 7a074e96dee6 ("aio: implement io_pgetevents") Signed-off-by: Guillem Jover Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit 92f7ba8315dab58f911f569dad610fc1ee428ff5 Author: Chuhong Yuan Date: Mon Nov 18 10:48:33 2019 +0800 serial: ifx6x60: add missed pm_runtime_disable commit 50b2b571c5f3df721fc81bf9a12c521dfbe019ba upstream. The driver forgets to call pm_runtime_disable in remove. Add the missed calls to fix it. Signed-off-by: Chuhong Yuan Cc: stable Link: https://lore.kernel.org/r/20191118024833.21587-1-hslester96@gmail.com Signed-off-by: Greg Kroah-Hartman commit 778a1d195d76e04cfb5ad5e1a522e5773c4b877a Author: Fabrice Gasnier Date: Thu Nov 21 09:10:49 2019 +0100 serial: stm32: fix clearing interrupt error flags commit 1250ed7114a977cdc2a67a0c09d6cdda63970eb9 upstream. The interrupt clear flag register is a "write 1 to clear" register. So, only writing ones allows to clear flags: - Replace buggy stm32_clr_bits() by a simple write to clear error flags - Replace useless read/modify/write stm32_set_bits() routine by a simple write to clear TC (transfer complete) flag. Fixes: 4f01d833fdcd ("serial: stm32: fix rx error handling") Signed-off-by: Fabrice Gasnier Cc: stable Link: https://lore.kernel.org/r/1574323849-1909-1-git-send-email-fabrice.gasnier@st.com Signed-off-by: Greg Kroah-Hartman commit 365da5d0b18089a7950e4fec283adbd968c8bfe8 Author: Jiangfeng Xiao Date: Wed Nov 20 23:18:53 2019 +0800 serial: serial_core: Perform NULL checks for break_ctl ops commit 7d73170e1c282576419f8b50a771f1fcd2b81a94 upstream. Doing fuzz test on sbsa uart device, causes a kernel crash due to NULL pointer dereference: ------------[ cut here ]------------ Unable to handle kernel paging request at virtual address fffffffffffffffc pgd = ffffffe331723000 [fffffffffffffffc] *pgd=0000002333595003, *pud=0000002333595003, *pmd=00000 Internal error: Oops: 96000005 [#1] PREEMPT SMP Modules linked in: ping(O) jffs2 rtos_snapshot(O) pramdisk(O) hisi_sfc(O) Drv_Nandc_K(O) Drv_SysCtl_K(O) Drv_SysClk_K(O) bsp_reg(O) hns3(O) hns3_uio_enet(O) hclgevf(O) hclge(O) hnae3(O) mdio_factory(O) mdio_registry(O) mdio_dev(O) mdio(O) hns3_info(O) rtos_kbox_panic(O) uart_suspend(O) rsm(O) stp llc tunnel4 xt_tcpudp ipt_REJECT nf_reject_ipv4 iptable_filter ip_tables x_tables sd_mod xhci_plat_hcd xhci_pci xhci_hcd usbmon usbhid usb_storage ohci_platform ohci_pci ohci_hcd hid_generic hid ehci_platform ehci_pci ehci_hcd vfat fat usbcore usb_common scsi_mod yaffs2multi(O) ext4 jbd2 ext2 mbcache ofpart i2c_dev i2c_core uio ubi nand nand_ecc nand_ids cfi_cmdset_0002 cfi_cmdset_0001 cfi_probe gen_probe cmdlinepart chipreg mtdblock mtd_blkdevs mtd nfsd auth_rpcgss oid_registry nfsv3 nfs nfs_acl lockd sunrpc grace autofs4 CPU: 2 PID: 2385 Comm: tty_fuzz_test Tainted: G O 4.4.193 #1 task: ffffffe32b23f110 task.stack: ffffffe32bda4000 PC is at uart_break_ctl+0x44/0x84 LR is at uart_break_ctl+0x34/0x84 pc : [] lr : [] pstate: 80000005 sp : ffffffe32bda7cc0 x29: ffffffe32bda7cc0 x28: ffffffe32b23f110 x27: ffffff8393402000 x26: 0000000000000000 x25: ffffffe32b233f40 x24: ffffffc07a8ec680 x23: 0000000000005425 x22: 00000000ffffffff x21: ffffffe33ed73c98 x20: 0000000000000000 x19: ffffffe33ed94168 x18: 0000000000000004 x17: 0000007f92ae9d30 x16: ffffff8392fa6064 x15: 0000000000000010 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000020 x10: 0000007ffdac1708 x9 : 0000000000000078 x8 : 000000000000001d x7 : 0000000052a64887 x6 : ffffffe32bda7e08 x5 : ffffffe32b23c000 x4 : 0000005fbc5b0000 x3 : ffffff83938d5018 x2 : 0000000000000080 x1 : ffffffe32b23c040 x0 : ffffff83934428f8 virtual start addr offset is 38ac00000 module base offset is 2cd4cf1000 linear region base offset is : 0 Process tty_fuzz_test (pid: 2385, stack limit = 0xffffffe32bda4000) Stack: (0xffffffe32bda7cc0 to 0xffffffe32bda8000) 7cc0: ffffffe32bda7cf0 ffffff8393177718 ffffffc07a8ec680 ffffff8393196054 7ce0: 000000001739f2e0 0000007ffdac1978 ffffffe32bda7d20 ffffff8393179a1c 7d00: 0000000000000000 ffffff8393c0a000 ffffffc07a8ec680 cb88537fdc8ba600 7d20: ffffffe32bda7df0 ffffff8392fa5a40 ffffff8393c0a000 0000000000005425 7d40: 0000007ffdac1978 ffffffe32b233f40 ffffff8393178dcc 0000000000000003 7d60: 000000000000011d 000000000000001d ffffffe32b23f110 000000000000029e 7d80: ffffffe34fe8d5d0 0000000000000000 ffffffe32bda7e14 cb88537fdc8ba600 7da0: ffffffe32bda7e30 ffffff8393042cfc ffffff8393c41720 ffffff8393c46410 7dc0: ffffff839304fa68 ffffffe32b233f40 0000000000005425 0000007ffdac1978 7de0: 000000000000011d cb88537fdc8ba600 ffffffe32bda7e70 ffffff8392fa60cc 7e00: 0000000000000000 ffffffe32b233f40 ffffffe32b233f40 0000000000000003 7e20: 0000000000005425 0000007ffdac1978 ffffffe32bda7e70 ffffff8392fa60b0 7e40: 0000000000000280 ffffffe32b233f40 ffffffe32b233f40 0000000000000003 7e60: 0000000000005425 cb88537fdc8ba600 0000000000000000 ffffff8392e02e78 7e80: 0000000000000280 0000005fbc5b0000 ffffffffffffffff 0000007f92ae9d3c 7ea0: 0000000060000000 0000000000000015 0000000000000003 0000000000005425 7ec0: 0000007ffdac1978 0000000000000000 00000000a54c910e 0000007f92b95014 7ee0: 0000007f92b95090 0000000052a64887 000000000000001d 0000000000000078 7f00: 0000007ffdac1708 0000000000000020 0000000000000000 0000000000000000 7f20: 0000000000000000 0000000000000010 000000556acf0090 0000007f92ae9d30 7f40: 0000000000000004 000000556acdef10 0000000000000000 000000556acdebd0 7f60: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 7f80: 0000000000000000 0000000000000000 0000000000000000 0000007ffdac1840 7fa0: 000000556acdedcc 0000007ffdac1840 0000007f92ae9d3c 0000000060000000 7fc0: 0000000000000000 0000000000000000 0000000000000003 000000000000001d 7fe0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 Call trace: Exception stack(0xffffffe32bda7ab0 to 0xffffffe32bda7bf0) 7aa0: 0000000000001000 0000007fffffffff 7ac0: ffffffe32bda7cc0 ffffff8393196098 0000000080000005 0000000000000025 7ae0: ffffffe32b233f40 ffffff83930d777c ffffffe32bda7b30 ffffff83930d777c 7b00: ffffffe32bda7be0 ffffff83938d5000 ffffffe32bda7be0 ffffffe32bda7c20 7b20: ffffffe32bda7b60 ffffff83930d777c ffffffe32bda7c10 ffffff83938d5000 7b40: ffffffe32bda7c10 ffffffe32bda7c50 ffffff8393c0a000 ffffffe32b23f110 7b60: ffffffe32bda7b70 ffffff8392e09df4 ffffffe32bda7bb0 cb88537fdc8ba600 7b80: ffffff83934428f8 ffffffe32b23c040 0000000000000080 ffffff83938d5018 7ba0: 0000005fbc5b0000 ffffffe32b23c000 ffffffe32bda7e08 0000000052a64887 7bc0: 000000000000001d 0000000000000078 0000007ffdac1708 0000000000000020 7be0: 0000000000000000 0000000000000000 [] uart_break_ctl+0x44/0x84 [] send_break+0xa0/0x114 [] tty_ioctl+0xc50/0xe84 [] do_vfs_ioctl+0xc4/0x6e8 [] SyS_ioctl+0x68/0x9c [] __sys_trace_return+0x0/0x4 Code: b9410ea0 34000160 f9408aa0 f9402814 (b85fc280) ---[ end trace 8606094f1960c5e0 ]--- Kernel panic - not syncing: Fatal exception Fix this problem by adding NULL checks prior to calling break_ctl ops. Signed-off-by: Jiangfeng Xiao Cc: stable Link: https://lore.kernel.org/r/1574263133-28259-1-git-send-email-xiaojiangfeng@huawei.com Signed-off-by: Greg Kroah-Hartman commit a3e92048809e4aee684d29d3ba27dc180420d58a Author: Vincent Whitchurch Date: Mon Nov 18 10:25:47 2019 +0100 serial: pl011: Fix DMA ->flush_buffer() commit f6a196477184b99a31d16366a8e826558aa11f6d upstream. PL011's ->flush_buffer() implementation releases and reacquires the port lock. Due to a race condition here, data can end up being added to the circular buffer but neither being discarded nor being sent out. This leads to, for example, tcdrain(2) waiting indefinitely. Process A Process B uart_flush_buffer() - acquire lock - circ_clear - pl011_flush_buffer() -- release lock -- dmaengine_terminate_all() uart_write() - acquire lock - add chars to circ buffer - start_tx() -- start DMA - release lock -- acquire lock -- turn off DMA -- release lock // Data in circ buffer but DMA is off According to the comment in the code, the releasing of the lock around dmaengine_terminate_all() is to avoid a deadlock with the DMA engine callback. However, since the time this code was written, the DMA engine API documentation seems to have been clarified to say that dmaengine_terminate_all() (in the identically implemented but differently named dmaengine_terminate_async() variant) does not wait for any running complete callback to be completed and can even be called from a complete callback. So there is no possibility of deadlock if the DMA engine driver implements this API correctly. So we should be able to just remove this release and reacquire of the lock to prevent the aforementioned race condition. Signed-off-by: Vincent Whitchurch Cc: stable Link: https://lore.kernel.org/r/20191118092547.32135-1-vincent.whitchurch@axis.com Signed-off-by: Greg Kroah-Hartman commit df091b597a588a49525e71a1d3aabd08a01fda67 Author: Jeffrey Hugo Date: Mon Oct 21 08:46:16 2019 -0700 tty: serial: msm_serial: Fix flow control commit b027ce258369cbfa88401a691c23dad01deb9f9b upstream. hci_qca interfaces to the wcn3990 via a uart_dm on the msm8998 mtp and Lenovo Miix 630 laptop. As part of initializing the wcn3990, hci_qca disables flow, configures the uart baudrate, and then reenables flow - at which point an event is expected to be received over the uart from the wcn3990. It is observed that this event comes after the baudrate change but before hci_qca re-enables flow. This is unexpected, and is a result of msm_reset() being broken. According to the uart_dm hardware documentation, it is recommended that automatic hardware flow control be enabled by setting RX_RDY_CTL. Auto hw flow control will manage RFR based on the configured watermark. When there is space to receive data, the hw will assert RFR. When the watermark is hit, the hw will de-assert RFR. The hardware documentation indicates that RFR can me manually managed via CR when RX_RDY_CTL is not set. SET_RFR asserts RFR, and RESET_RFR de-asserts RFR. msm_reset() is broken because after resetting the hardware, it unconditionally asserts RFR via SET_RFR. This enables flow regardless of the current configuration, and would undo a previous flow disable operation. It should instead de-assert RFR via RESET_RFR to block flow until the hardware is reconfigured. msm_serial should rely on the client to specify that flow should be enabled, either via mctrl() or the termios structure, and only assert RFR in response to those triggers. Fixes: 04896a77a97b ("msm_serial: serial driver for MSM7K onboard serial peripheral.") Signed-off-by: Jeffrey Hugo Reviewed-by: Bjorn Andersson Cc: stable Reviewed-by: Andy Gross Link: https://lore.kernel.org/r/20191021154616.25457-1-jeffrey.l.hugo@gmail.com Signed-off-by: Greg Kroah-Hartman commit 0015612c1780142be656a2e2821a7a70e071aafb Author: Peng Fan Date: Tue Nov 5 05:51:10 2019 +0000 tty: serial: fsl_lpuart: use the sg count from dma_map_sg commit 487ee861de176090b055eba5b252b56a3b9973d6 upstream. The dmaengine_prep_slave_sg needs to use sg count returned by dma_map_sg, not use sport->dma_tx_nents, because the return value of dma_map_sg is not always same with "nents". When enabling iommu for lpuart + edma, iommu framework may concatenate two sgs into one. Fixes: 6250cc30c4c4e ("tty: serial: fsl_lpuart: Use scatter/gather DMA for Tx") Cc: Signed-off-by: Peng Fan Link: https://lore.kernel.org/r/1572932977-17866-1-git-send-email-peng.fan@nxp.com Signed-off-by: Greg Kroah-Hartman commit 09330cc92055b2787c4461c9acade2302f89c14e Author: Michał Mirosław Date: Sat Aug 10 10:42:48 2019 +0200 usb: gadget: u_serial: add missing port entry locking commit daf82bd24e308c5a83758047aff1bd81edda4f11 upstream. gserial_alloc_line() misses locking (for a release barrier) while resetting port entry on TTY allocation failure. Fix this. Cc: stable@vger.kernel.org Signed-off-by: Michał Mirosław Reviewed-by: Greg Kroah-Hartman Tested-by: Ladislav Michl Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit bf4c4d71b74e2d85985a304d4df1dee8450df05f Author: Dmitry Safonov Date: Thu Nov 21 00:03:03 2019 +0000 time: Zero the upper 32-bits in __kernel_timespec on 32-bit commit 7b8474466ed97be458c825f34a85f2c2b84c3f95 upstream. On compat interfaces, the high order bits of nanoseconds should be zeroed out. This is because the application code or the libc do not guarantee zeroing of these. If used without zeroing, kernel might be at risk of using timespec values incorrectly. Originally it was handled correctly, but lost during is_compat_syscall() cleanup. Revert the condition back to check CONFIG_64BIT. Fixes: 98f76206b335 ("compat: Cleanup in_compat_syscall() callers") Reported-by: Ben Hutchings Signed-off-by: Dmitry Safonov Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20191121000303.126523-1-dima@arista.com Signed-off-by: Greg Kroah-Hartman commit d91eb29a24cc7a3c790b8d82b8010712e9460900 Author: Arnd Bergmann Date: Fri Nov 8 21:34:29 2019 +0100 lp: fix sparc64 LPSETTIMEOUT ioctl commit 45a2d64696b11913bcf1087b041740edbade3e21 upstream. The layout of struct timeval is different on sparc64 from anything else, and the patch I did long ago failed to take this into account. Change it now to handle sparc64 user space correctly again. Quite likely nobody cares about parallel ports on sparc64, but there is no reason not to fix it. Cc: stable@vger.kernel.org Fixes: 9a450484089d ("lp: support 64-bit time_t user space") Signed-off-by: Arnd Bergmann Link: https://lore.kernel.org/r/20191108203435.112759-7-arnd@arndb.de Signed-off-by: Greg Kroah-Hartman commit 17def6dff9fa9d14038573ca307211e8d3e08883 Author: Tuowen Zhao Date: Wed Oct 16 15:06:27 2019 -0600 sparc64: implement ioremap_uc commit 38e45d81d14e5f78cd67922596b1c37b4c22ec74 upstream. On sparc64, the whole physical IO address space is accessible using physically addressed loads and stores. *_uc does nothing like the others. Cc: # v4.19+ Reported-by: kbuild test robot Signed-off-by: Tuowen Zhao Acked-by: David S. Miller Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman commit 7d52c8212fa557e3437228b268ad848db7da6608 Author: Adrian Hunter Date: Wed Nov 13 14:02:06 2019 +0200 perf scripts python: exported-sql-viewer.py: Fix use of TRUE with SQLite commit af833988c088d3fed3e7188e7c3dd9ca17178dc3 upstream. Prior to version 3.23 SQLite does not support TRUE or FALSE, so always use 1 and 0 for SQLite. Fixes: 26c11206f433 ("perf scripts python: exported-sql-viewer.py: Use new 'has_calls' column") Signed-off-by: Adrian Hunter Cc: Jiri Olsa Cc: stable@vger.kernel.org # v5.3+ Link: http://lore.kernel.org/lkml/20191113120206.26957-1-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo [Adrian: backported to v5.3, v5.4] Signed-off-by: Adrian Hunter Signed-off-by: Greg Kroah-Hartman commit d28f2e4ddd8a704d8b86c38241576ed2d57c7cff Author: Jon Hunter Date: Wed Sep 25 15:12:29 2019 +0100 arm64: tegra: Fix 'active-low' warning for Jetson TX1 regulator commit 1e5e929c009559bd7e898ac8e17a5d01037cb057 upstream. Commit 34993594181d ("arm64: tegra: Enable HDMI on Jetson TX1") added a regulator for HDMI on the Jetson TX1 platform. This regulator has an active high enable, but the GPIO specifier for enabling the regulator incorrectly defines it as active-low. This causes the following warning to occur on boot ... WARNING KERN regulator@10 GPIO handle specifies active low - ignored The fixed-regulator binding does not use the active-low flag from the gpio specifier and purely relies of the presence of the 'enable-active-high' property to determine if it is active high or low (if this property is omitted). Fix this warning by setting the GPIO to active-high in the GPIO specifier which aligns with the presense of the 'enable-active-high' property. Fixes: 34993594181d ("arm64: tegra: Enable HDMI on Jetson TX1") Signed-off-by: Jon Hunter Signed-off-by: Thierry Reding Signed-off-by: Greg Kroah-Hartman commit 9c11993ad2542c314023f282efea363996b378a0 Author: Navid Emamdoost Date: Fri Sep 13 19:08:11 2019 -0500 rsi: release skb if rsi_prepare_beacon fails commit d563131ef23cbc756026f839a82598c8445bc45f upstream. In rsi_send_beacon, if rsi_prepare_beacon fails the allocated skb should be released. Signed-off-by: Navid Emamdoost Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman