commit 2519374d2a6b8aa5d395393f21e74232409c2e82 Author: Greg Kroah-Hartman Date: Wed Jul 31 07:25:04 2019 +0200 Linux 5.2.5 commit 19a732f71d46681bb9de5f96a59bc06d55213684 Author: Jens Axboe Date: Sat Jul 20 08:37:31 2019 -0600 io_uring: don't use iov_iter_advance() for fixed buffers commit bd11b3a391e3df6fa958facbe4b3f9f4cca9bd49 upstream. Hrvoje reports that when a large fixed buffer is registered and IO is being done to the latter pages of said buffer, the IO submission time is much worse: reading to the start of the buffer: 11238 ns reading to the end of the buffer: 1039879 ns In fact, it's worse by two orders of magnitude. The reason for that is how io_uring figures out how to setup the iov_iter. We point the iter at the first bvec, and then use iov_iter_advance() to fast-forward to the offset within that buffer we need. However, that is abysmally slow, as it entails iterating the bvecs that we setup as part of buffer registration. There's really no need to use this generic helper, as we know it's a BVEC type iterator, and we also know that each bvec is PAGE_SIZE in size, apart from possibly the first and last. Hence we can just use a shift on the offset to find the right index, and then adjust the iov_iter appropriately. After this fix, the timings are: reading to the start of the buffer: 10135 ns reading to the end of the buffer: 1377 ns Or about an 755x improvement for the tail page. Reported-by: Hrvoje Zeba Tested-by: Hrvoje Zeba Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 4686e134619cf7fc3eaf5edb3da400e3a9a751d2 Author: Zhengyuan Liu Date: Tue Jul 16 23:26:14 2019 +0800 io_uring: fix counter inc/dec mismatch in async_list commit f7b76ac9d17e16e44feebb6d2749fec92bfd6dd4 upstream. We could queue a work for each req in defer and link list without increasing async_list->cnt, so we shouldn't decrease it while exiting from workqueue as well if we didn't process the req in async list. Thanks to Jens Axboe for his guidance. Fixes: 31b515106428 ("io_uring: allow workqueue item to handle multiple buffered requests") Signed-off-by: Zhengyuan Liu Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 119be19fa6b647a9c70bd5d396c183b3c832f07b Author: Jens Axboe Date: Thu Jul 25 10:20:18 2019 -0600 io_uring: ensure ->list is initialized for poll commands commit 36703247d5f52a679df9da51192b6950fe81689f upstream. Daniel reports that when testing an http server that uses io_uring to poll for incoming connections, sometimes it hard crashes. This is due to an uninitialized list member for the io_uring request. Normally this doesn't trigger and none of the test cases caught it. Reported-by: Daniel Kozak Tested-by: Daniel Kozak Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 91b4f2b6bbfd658122a5641f6fbed0a9c68c457d Author: Zhengyuan Liu Date: Thu Jul 18 20:44:00 2019 +0800 io_uring: add a memory barrier before atomic_read commit c0e48f9dea9129aa11bec3ed13803bcc26e96e49 upstream. There is a hang issue while using fio to do some basic test. The issue can be easily reproduced using the below script: while true do fio --ioengine=io_uring -rw=write -bs=4k -numjobs=1 \ -size=1G -iodepth=64 -name=uring --filename=/dev/zero done After several minutes (or more), fio would block at io_uring_enter->io_cqring_wait in order to waiting for previously committed sqes to be completed and can't return to user anymore until we send a SIGTERM to fio. After receiving SIGTERM, fio hangs at io_ring_ctx_wait_and_kill with a backtrace like this: [54133.243816] Call Trace: [54133.243842] __schedule+0x3a0/0x790 [54133.243868] schedule+0x38/0xa0 [54133.243880] schedule_timeout+0x218/0x3b0 [54133.243891] ? sched_clock+0x9/0x10 [54133.243903] ? wait_for_completion+0xa3/0x130 [54133.243916] ? _raw_spin_unlock_irq+0x2c/0x40 [54133.243930] ? trace_hardirqs_on+0x3f/0xe0 [54133.243951] wait_for_completion+0xab/0x130 [54133.243962] ? wake_up_q+0x70/0x70 [54133.243984] io_ring_ctx_wait_and_kill+0xa0/0x1d0 [54133.243998] io_uring_release+0x20/0x30 [54133.244008] __fput+0xcf/0x270 [54133.244029] ____fput+0xe/0x10 [54133.244040] task_work_run+0x7f/0xa0 [54133.244056] do_exit+0x305/0xc40 [54133.244067] ? get_signal+0x13b/0xbd0 [54133.244088] do_group_exit+0x50/0xd0 [54133.244103] get_signal+0x18d/0xbd0 [54133.244112] ? _raw_spin_unlock_irqrestore+0x36/0x60 [54133.244142] do_signal+0x34/0x720 [54133.244171] ? exit_to_usermode_loop+0x7e/0x130 [54133.244190] exit_to_usermode_loop+0xc0/0x130 [54133.244209] do_syscall_64+0x16b/0x1d0 [54133.244221] entry_SYSCALL_64_after_hwframe+0x49/0xbe The reason is that we had added a req to ctx->pending_async at the very end, but it didn't get a chance to be processed. How could this happen? fio#cpu0 wq#cpu1 io_add_to_prev_work io_sq_wq_submit_work atomic_read() <<< 1 atomic_dec_return() << 1->0 list_empty(); <<< true; list_add_tail() atomic_read() << 0 or 1? As atomic_ops.rst states, atomic_read does not guarantee that the runtime modification by any other thread is visible yet, so we must take care of that with a proper implicit or explicit memory barrier. This issue was detected with the help of Jackie's Fixes: 31b515106428 ("io_uring: allow workqueue item to handle multiple buffered requests") Signed-off-by: Zhengyuan Liu Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 7e37ded00e8cb2bd46326450670bd99be0e4771f Author: Linus Torvalds Date: Thu Jul 11 09:54:40 2019 -0700 access: avoid the RCU grace period for the temporary subjective credentials commit d7852fbd0f0423937fa287a598bfde188bb68c22 upstream. It turns out that 'access()' (and 'faccessat()') can cause a lot of RCU work because it installs a temporary credential that gets allocated and freed for each system call. The allocation and freeing overhead is mostly benign, but because credentials can be accessed under the RCU read lock, the freeing involves a RCU grace period. Which is not a huge deal normally, but if you have a lot of access() calls, this causes a fair amount of seconday damage: instead of having a nice alloc/free patterns that hits in hot per-CPU slab caches, you have all those delayed free's, and on big machines with hundreds of cores, the RCU overhead can end up being enormous. But it turns out that all of this is entirely unnecessary. Exactly because access() only installs the credential as the thread-local subjective credential, the temporary cred pointer doesn't actually need to be RCU free'd at all. Once we're done using it, we can just free it synchronously and avoid all the RCU overhead. So add a 'non_rcu' flag to 'struct cred', which can be set by users that know they only use it in non-RCU context (there are other potential users for this). We can make it a union with the rcu freeing list head that we need for the RCU case, so this doesn't need any extra storage. Note that this also makes 'get_current_cred()' clear the new non_rcu flag, in case we have filesystems that take a long-term reference to the cred and then expect the RCU delayed freeing afterwards. It's not entirely clear that this is required, but it makes for clear semantics: the subjective cred remains non-RCU as long as you only access it synchronously using the thread-local accessors, but you _can_ use it as a generic cred if you want to. It is possible that we should just remove the whole RCU markings for ->cred entirely. Only ->real_cred is really supposed to be accessed through RCU, and the long-term cred copies that nfs uses might want to explicitly re-enable RCU freeing if required, rather than have get_current_cred() do it implicitly. But this is a "minimal semantic changes" change for the immediate problem. Acked-by: Peter Zijlstra (Intel) Acked-by: Eric Dumazet Acked-by: Paul E. McKenney Cc: Oleg Nesterov Cc: Jan Glauber Cc: Jiri Kosina Cc: Jayachandran Chandrasekharan Nair Cc: Greg KH Cc: Kees Cook Cc: David Howells Cc: Miklos Szeredi Cc: Al Viro Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 872c54664f545d08a37917a63db1d9a819a8bc0b Author: Chris Wilson Date: Tue Jun 18 08:41:35 2019 +0100 drm/i915: Make the semaphore saturation mask global commit 44d89409a12eb8333735958509d7d591b461d13d upstream. The idea behind keeping the saturation mask local to a context backfired spectacularly. The premise with the local mask was that we would be more proactive in attempting to use semaphores after each time the context idled, and that all new contexts would attempt to use semaphores ignoring the current state of the system. This turns out to be horribly optimistic. If the system state is still oversaturated and the existing workloads have all stopped using semaphores, the new workloads would attempt to use semaphores and be deprioritised behind real work. The new contexts would not switch off using semaphores until their initial batch of low priority work had completed. Given sufficient backload load of equal user priority, this would completely starve the new work of any GPU time. To compensate, remove the local tracking in favour of keeping it as global state on the engine -- once the system is saturated and semaphores are disabled, everyone stops attempting to use semaphores until the system is idle again. One of the reason for preferring local context tracking was that it worked with virtual engines, so for switching to global state we could either do a complete check of all the virtual siblings or simply disable semaphores for those requests. This takes the simpler approach of disabling semaphores on virtual engines. The downside is that the decision that the engine is saturated is a local measure -- we are only checking whether or not this context was scheduled in a timely fashion, it may be legitimately delayed due to user priorities. We still have the same dilemma though, that we do not want to employ the semaphore poll unless it will be used. v2: Explain why we need to assume the worst wrt virtual engines. Fixes: ca6e56f654e7 ("drm/i915: Disable semaphore busywaits on saturated systems") Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin Cc: Dmitry Rogozhkin Cc: Dmitry Ermilov Reviewed-by: Tvrtko Ursulin Link: https://patchwork.freedesktop.org/patch/msgid/20190618074153.16055-8-chris@chris-wilson.co.uk Signed-off-by: Joonas Lahtinen Signed-off-by: Greg Kroah-Hartman commit e8bbd6178866ea21cffc2eddb2a0de3159ffba26 Author: Arnd Bergmann Date: Mon Jul 22 13:41:20 2019 +0200 structleak: disable STRUCTLEAK_BYREF in combination with KASAN_STACK commit 173e6ee21e2b3f477f07548a79c43b8d9cfbb37d upstream. The combination of KASAN_STACK and GCC_PLUGIN_STRUCTLEAK_BYREF leads to much larger kernel stack usage, as seen from the warnings about functions that now exceed the 2048 byte limit: drivers/media/i2c/tvp5150.c:253:1: error: the frame size of 3936 bytes is larger than 2048 bytes drivers/media/tuners/r820t.c:1327:1: error: the frame size of 2816 bytes is larger than 2048 bytes drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c:16552:1: error: the frame size of 3144 bytes is larger than 2048 bytes [-Werror=frame-larger-than=] fs/ocfs2/aops.c:1892:1: error: the frame size of 2088 bytes is larger than 2048 bytes fs/ocfs2/dlm/dlmrecovery.c:737:1: error: the frame size of 2088 bytes is larger than 2048 bytes fs/ocfs2/namei.c:1677:1: error: the frame size of 2584 bytes is larger than 2048 bytes fs/ocfs2/super.c:1186:1: error: the frame size of 2640 bytes is larger than 2048 bytes fs/ocfs2/xattr.c:3678:1: error: the frame size of 2176 bytes is larger than 2048 bytes net/bluetooth/l2cap_core.c:7056:1: error: the frame size of 2144 bytes is larger than 2048 bytes [-Werror=frame-larger-than=] net/bluetooth/l2cap_core.c: In function 'l2cap_recv_frame': net/bridge/br_netlink.c:1505:1: error: the frame size of 2448 bytes is larger than 2048 bytes net/ieee802154/nl802154.c:548:1: error: the frame size of 2232 bytes is larger than 2048 bytes net/wireless/nl80211.c:1726:1: error: the frame size of 2224 bytes is larger than 2048 bytes net/wireless/nl80211.c:2357:1: error: the frame size of 4584 bytes is larger than 2048 bytes net/wireless/nl80211.c:5108:1: error: the frame size of 2760 bytes is larger than 2048 bytes net/wireless/nl80211.c:6472:1: error: the frame size of 2112 bytes is larger than 2048 bytes The structleak plugin was previously disabled for CONFIG_COMPILE_TEST, but meant we missed some bugs, so this time we should address them. The frame size warnings are distracting, and risking a kernel stack overflow is generally not beneficial to performance, so it may be best to disallow that particular combination. This can be done by turning off either one. I picked the dependency in GCC_PLUGIN_STRUCTLEAK_BYREF and GCC_PLUGIN_STRUCTLEAK_BYREF_ALL, as this option is designed to make uninitialized stack usage less harmful when enabled on its own, but it also prevents KASAN from detecting those cases in which it was in fact needed. KASAN_STACK is currently implied by KASAN on gcc, but could be made a user selectable option if we want to allow combining (non-stack) KASAN with GCC_PLUGIN_STRUCTLEAK_BYREF. Note that it would be possible to specifically address the files that print the warning, but presumably the overall stack usage is still significantly higher than in other configurations, so this would not address the full problem. I could not test this with CONFIG_INIT_STACK_ALL, which may or may not suffer from a similar problem. Fixes: 81a56f6dcd20 ("gcc-plugins: structleak: Generalize to all variable types") Signed-off-by: Arnd Bergmann Link: https://lore.kernel.org/r/20190722114134.3123901-1-arnd@arndb.de Signed-off-by: Kees Cook Signed-off-by: Greg Kroah-Hartman commit 3432861666523e3e86fd5dec0d90b7b6cbda7506 Author: Dan Williams Date: Wed Jul 17 18:08:15 2019 -0700 libnvdimm/bus: Stop holding nvdimm_bus_list_mutex over __nd_ioctl() commit b70d31d054ee3a6fc1034b9d7fc0ae1e481aa018 upstream. In preparation for fixing a deadlock between wait_for_bus_probe_idle() and the nvdimm_bus_list_mutex arrange for __nd_ioctl() without nvdimm_bus_list_mutex held. This also unifies the 'dimm' and 'bus' level ioctls into a common nd_ioctl() preamble implementation. Marked for -stable as it is a pre-requisite for a follow-on fix. Cc: Fixes: bf9bccc14c05 ("libnvdimm: pmem label sets and namespace instantiation") Cc: Vishal Verma Tested-by: Jane Chu Link: https://lore.kernel.org/r/156341209518.292348.7183897251740665198.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Dan Williams Signed-off-by: Greg Kroah-Hartman commit f61303db9d679226ca24857a344d40290031ec71 Author: Dan Williams Date: Wed Jul 17 18:08:03 2019 -0700 libnvdimm/region: Register badblocks before namespaces commit 700cd033a82d466ad8f9615f9985525e45f8960a upstream. Namespace activation expects to be able to reference region badblocks. The following warning sometimes triggers when asynchronous namespace activation races in front of the completion of namespace probing. Move all possible namespace probing after region badblocks initialization. Otherwise, lockdep sometimes catches the uninitialized state of the badblocks seqlock with stack trace signatures like: INFO: trying to register non-static key. pmem2: detected capacity change from 0 to 136365211648 the code is fine but needs lockdep annotation. turning off the locking correctness validator. CPU: 9 PID: 358 Comm: kworker/u80:5 Tainted: G OE 5.2.0-rc4+ #3382 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.0.0 02/06/2015 Workqueue: events_unbound async_run_entry_fn Call Trace: dump_stack+0x85/0xc0 pmem1.12: detected capacity change from 0 to 8589934592 register_lock_class+0x56a/0x570 ? check_object+0x140/0x270 __lock_acquire+0x80/0x1710 ? __mutex_lock+0x39d/0x910 lock_acquire+0x9e/0x180 ? nd_pfn_validate+0x28f/0x440 [libnvdimm] badblocks_check+0x93/0x1f0 ? nd_pfn_validate+0x28f/0x440 [libnvdimm] nd_pfn_validate+0x28f/0x440 [libnvdimm] ? lockdep_hardirqs_on+0xf0/0x180 nd_dax_probe+0x9a/0x120 [libnvdimm] nd_pmem_probe+0x6d/0x180 [nd_pmem] nvdimm_bus_probe+0x90/0x2c0 [libnvdimm] Fixes: 48af2f7e52f4 ("libnvdimm, pfn: during init, clear errors...") Cc: Cc: Vishal Verma Reviewed-by: Vishal Verma Link: https://lore.kernel.org/r/156341208365.292348.1547528796026249120.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Dan Williams Signed-off-by: Greg Kroah-Hartman commit ce4e36ece2032fc5caa0b935a86250d0b0a2fb0d Author: Dan Williams Date: Wed Jul 17 18:07:58 2019 -0700 libnvdimm/bus: Prevent duplicate device_unregister() calls commit 8aac0e2338916e273ccbd438a2b7a1e8c61749f5 upstream. A multithreaded namespace creation/destruction stress test currently fails with signatures like the following: sysfs group 'power' not found for kobject 'dax1.1' RIP: 0010:sysfs_remove_group+0x76/0x80 Call Trace: device_del+0x73/0x370 device_unregister+0x16/0x50 nd_async_device_unregister+0x1e/0x30 [libnvdimm] async_run_entry_fn+0x39/0x160 process_one_work+0x23c/0x5e0 worker_thread+0x3c/0x390 BUG: kernel NULL pointer dereference, address: 0000000000000020 RIP: 0010:klist_put+0x1b/0x6c Call Trace: klist_del+0xe/0x10 device_del+0x8a/0x2c9 ? __switch_to_asm+0x34/0x70 ? __switch_to_asm+0x40/0x70 device_unregister+0x44/0x4f nd_async_device_unregister+0x22/0x2d [libnvdimm] async_run_entry_fn+0x47/0x15a process_one_work+0x1a2/0x2eb worker_thread+0x1b8/0x26e Use the kill_device() helper to atomically resolve the race of multiple threads issuing kill, device_unregister(), requests. Reported-by: Jane Chu Reported-by: Erwin Tsaur Fixes: 4d88a97aa9e8 ("libnvdimm, nvdimm: dimm driver and base libnvdimm device-driver...") Cc: Link: https://github.com/pmem/ndctl/issues/96 Tested-by: Tested-by: Jane Chu Link: https://lore.kernel.org/r/156341207846.292348.10435719262819764054.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Dan Williams Signed-off-by: Greg Kroah-Hartman commit d0ed1dbc8a54bc8c527bb420fd9e7c7bee93b415 Author: Dan Williams Date: Wed Jul 17 18:07:53 2019 -0700 drivers/base: Introduce kill_device() commit 00289cd87676e14913d2d8492d1ce05c4baafdae upstream. The libnvdimm subsystem arranges for devices to be destroyed as a result of a sysfs operation. Since device_unregister() cannot be called from an actively running sysfs attribute of the same device libnvdimm arranges for device_unregister() to be performed in an out-of-line async context. The driver core maintains a 'dead' state for coordinating its own racing async registration / de-registration requests. Rather than add local 'dead' state tracking infrastructure to libnvdimm device objects, export the existing state tracking via a new kill_device() helper. The kill_device() helper simply marks the device as dead, i.e. that it is on its way to device_del(), or returns that the device was already dead. This can be used in advance of calling device_unregister() for subsystems like libnvdimm that might need to handle multiple user threads racing to delete a device. This refactoring does not change any behavior, but it is a pre-requisite for follow-on fixes and therefore marked for -stable. Cc: Greg Kroah-Hartman Cc: "Rafael J. Wysocki" Fixes: 4d88a97aa9e8 ("libnvdimm, nvdimm: dimm driver and base libnvdimm device-driver...") Cc: Tested-by: Jane Chu Reviewed-by: Greg Kroah-Hartman Link: https://lore.kernel.org/r/156341207332.292348.14959761496009347574.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Dan Williams Signed-off-by: Greg Kroah-Hartman commit 32e5133912ff141128a8795ae8abb85d209dfc20 Author: Joerg Roedel Date: Tue Jul 23 09:51:00 2019 +0200 iommu/iova: Fix compilation error with !CONFIG_IOMMU_IOVA commit 201c1db90cd643282185a00770f12f95da330eca upstream. The stub function for !CONFIG_IOMMU_IOVA needs to be 'static inline'. Fixes: effa467870c76 ('iommu/vt-d: Don't queue_iova() if there is no flush queue') Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit 0ce35762bad71d077b7a582338a4e40ec0d3fc04 Author: Chris Wilson Date: Sat Jul 20 19:08:48 2019 +0100 iommu/iova: Remove stale cached32_node commit 9eed17d37c77171cf5ffb95c4257f87df3cd4c8f upstream. Since the cached32_node is allowed to be advanced above dma_32bit_pfn (to provide a shortcut into the limited range), we need to be careful to remove the to be freed node if it is the cached32_node. [ 48.477773] BUG: KASAN: use-after-free in __cached_rbnode_delete_update+0x68/0x110 [ 48.477812] Read of size 8 at addr ffff88870fc19020 by task kworker/u8:1/37 [ 48.477843] [ 48.477879] CPU: 1 PID: 37 Comm: kworker/u8:1 Tainted: G U 5.2.0+ #735 [ 48.477915] Hardware name: Intel Corporation NUC7i5BNK/NUC7i5BNB, BIOS BNKBL357.86A.0052.2017.0918.1346 09/18/2017 [ 48.478047] Workqueue: i915 __i915_gem_free_work [i915] [ 48.478075] Call Trace: [ 48.478111] dump_stack+0x5b/0x90 [ 48.478137] print_address_description+0x67/0x237 [ 48.478178] ? __cached_rbnode_delete_update+0x68/0x110 [ 48.478212] __kasan_report.cold.3+0x1c/0x38 [ 48.478240] ? __cached_rbnode_delete_update+0x68/0x110 [ 48.478280] ? __cached_rbnode_delete_update+0x68/0x110 [ 48.478308] __cached_rbnode_delete_update+0x68/0x110 [ 48.478344] private_free_iova+0x2b/0x60 [ 48.478378] iova_magazine_free_pfns+0x46/0xa0 [ 48.478403] free_iova_fast+0x277/0x340 [ 48.478443] fq_ring_free+0x15a/0x1a0 [ 48.478473] queue_iova+0x19c/0x1f0 [ 48.478597] cleanup_page_dma.isra.64+0x62/0xb0 [i915] [ 48.478712] __gen8_ppgtt_cleanup+0x63/0x80 [i915] [ 48.478826] __gen8_ppgtt_cleanup+0x42/0x80 [i915] [ 48.478940] __gen8_ppgtt_clear+0x433/0x4b0 [i915] [ 48.479053] __gen8_ppgtt_clear+0x462/0x4b0 [i915] [ 48.479081] ? __sg_free_table+0x9e/0xf0 [ 48.479116] ? kfree+0x7f/0x150 [ 48.479234] i915_vma_unbind+0x1e2/0x240 [i915] [ 48.479352] i915_vma_destroy+0x3a/0x280 [i915] [ 48.479465] __i915_gem_free_objects+0xf0/0x2d0 [i915] [ 48.479579] __i915_gem_free_work+0x41/0xa0 [i915] [ 48.479607] process_one_work+0x495/0x710 [ 48.479642] worker_thread+0x4c7/0x6f0 [ 48.479687] ? process_one_work+0x710/0x710 [ 48.479724] kthread+0x1b2/0x1d0 [ 48.479774] ? kthread_create_worker_on_cpu+0xa0/0xa0 [ 48.479820] ret_from_fork+0x1f/0x30 [ 48.479864] [ 48.479907] Allocated by task 631: [ 48.479944] save_stack+0x19/0x80 [ 48.479994] __kasan_kmalloc.constprop.6+0xc1/0xd0 [ 48.480038] kmem_cache_alloc+0x91/0xf0 [ 48.480082] alloc_iova+0x2b/0x1e0 [ 48.480125] alloc_iova_fast+0x58/0x376 [ 48.480166] intel_alloc_iova+0x90/0xc0 [ 48.480214] intel_map_sg+0xde/0x1f0 [ 48.480343] i915_gem_gtt_prepare_pages+0xb8/0x170 [i915] [ 48.480465] huge_get_pages+0x232/0x2b0 [i915] [ 48.480590] ____i915_gem_object_get_pages+0x40/0xb0 [i915] [ 48.480712] __i915_gem_object_get_pages+0x90/0xa0 [i915] [ 48.480834] i915_gem_object_prepare_write+0x2d6/0x330 [i915] [ 48.480955] create_test_object.isra.54+0x1a9/0x3e0 [i915] [ 48.481075] igt_shared_ctx_exec+0x365/0x3c0 [i915] [ 48.481210] __i915_subtests.cold.4+0x30/0x92 [i915] [ 48.481341] __run_selftests.cold.3+0xa9/0x119 [i915] [ 48.481466] i915_live_selftests+0x3c/0x70 [i915] [ 48.481583] i915_pci_probe+0xe7/0x220 [i915] [ 48.481620] pci_device_probe+0xe0/0x180 [ 48.481665] really_probe+0x163/0x4e0 [ 48.481710] device_driver_attach+0x85/0x90 [ 48.481750] __driver_attach+0xa5/0x180 [ 48.481796] bus_for_each_dev+0xda/0x130 [ 48.481831] bus_add_driver+0x205/0x2e0 [ 48.481882] driver_register+0xca/0x140 [ 48.481927] do_one_initcall+0x6c/0x1af [ 48.481970] do_init_module+0x106/0x350 [ 48.482010] load_module+0x3d2c/0x3ea0 [ 48.482058] __do_sys_finit_module+0x110/0x180 [ 48.482102] do_syscall_64+0x62/0x1f0 [ 48.482147] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 48.482190] [ 48.482224] Freed by task 37: [ 48.482273] save_stack+0x19/0x80 [ 48.482318] __kasan_slab_free+0x12e/0x180 [ 48.482363] kmem_cache_free+0x70/0x140 [ 48.482406] __free_iova+0x1d/0x30 [ 48.482445] fq_ring_free+0x15a/0x1a0 [ 48.482490] queue_iova+0x19c/0x1f0 [ 48.482624] cleanup_page_dma.isra.64+0x62/0xb0 [i915] [ 48.482749] __gen8_ppgtt_cleanup+0x63/0x80 [i915] [ 48.482873] __gen8_ppgtt_cleanup+0x42/0x80 [i915] [ 48.482999] __gen8_ppgtt_clear+0x433/0x4b0 [i915] [ 48.483123] __gen8_ppgtt_clear+0x462/0x4b0 [i915] [ 48.483250] i915_vma_unbind+0x1e2/0x240 [i915] [ 48.483378] i915_vma_destroy+0x3a/0x280 [i915] [ 48.483500] __i915_gem_free_objects+0xf0/0x2d0 [i915] [ 48.483622] __i915_gem_free_work+0x41/0xa0 [i915] [ 48.483659] process_one_work+0x495/0x710 [ 48.483704] worker_thread+0x4c7/0x6f0 [ 48.483748] kthread+0x1b2/0x1d0 [ 48.483787] ret_from_fork+0x1f/0x30 [ 48.483831] [ 48.483868] The buggy address belongs to the object at ffff88870fc19000 [ 48.483868] which belongs to the cache iommu_iova of size 40 [ 48.483920] The buggy address is located 32 bytes inside of [ 48.483920] 40-byte region [ffff88870fc19000, ffff88870fc19028) [ 48.483964] The buggy address belongs to the page: [ 48.484006] page:ffffea001c3f0600 refcount:1 mapcount:0 mapping:ffff8888181a91c0 index:0x0 compound_mapcount: 0 [ 48.484045] flags: 0x8000000000010200(slab|head) [ 48.484096] raw: 8000000000010200 ffffea001c421a08 ffffea001c447e88 ffff8888181a91c0 [ 48.484141] raw: 0000000000000000 0000000000120012 00000001ffffffff 0000000000000000 [ 48.484188] page dumped because: kasan: bad access detected [ 48.484230] [ 48.484265] Memory state around the buggy address: [ 48.484314] ffff88870fc18f00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 48.484361] ffff88870fc18f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 48.484406] >ffff88870fc19000: fb fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc [ 48.484451] ^ [ 48.484494] ffff88870fc19080: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 48.484530] ffff88870fc19100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108602 Fixes: e60aa7b53845 ("iommu/iova: Extend rbtree node caching") Signed-off-by: Chris Wilson Cc: Robin Murphy Cc: Joerg Roedel Cc: Joerg Roedel Cc: # v4.15+ Reviewed-by: Robin Murphy Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit 8498d00472bfe08a94625da502ebdbae129aad9e Author: Dmitry Safonov Date: Tue Jul 16 22:38:05 2019 +0100 iommu/vt-d: Don't queue_iova() if there is no flush queue commit effa467870c7612012885df4e246bdb8ffd8e44c upstream. Intel VT-d driver was reworked to use common deferred flushing implementation. Previously there was one global per-cpu flush queue, afterwards - one per domain. Before deferring a flush, the queue should be allocated and initialized. Currently only domains with IOMMU_DOMAIN_DMA type initialize their flush queue. It's probably worth to init it for static or unmanaged domains too, but it may be arguable - I'm leaving it to iommu folks. Prevent queuing an iova flush if the domain doesn't have a queue. The defensive check seems to be worth to keep even if queue would be initialized for all kinds of domains. And is easy backportable. On 4.19.43 stable kernel it has a user-visible effect: previously for devices in si domain there were crashes, on sata devices: BUG: spinlock bad magic on CPU#6, swapper/0/1 lock: 0xffff88844f582008, .magic: 00000000, .owner: /-1, .owner_cpu: 0 CPU: 6 PID: 1 Comm: swapper/0 Not tainted 4.19.43 #1 Call Trace: dump_stack+0x61/0x7e spin_bug+0x9d/0xa3 do_raw_spin_lock+0x22/0x8e _raw_spin_lock_irqsave+0x32/0x3a queue_iova+0x45/0x115 intel_unmap+0x107/0x113 intel_unmap_sg+0x6b/0x76 __ata_qc_complete+0x7f/0x103 ata_qc_complete+0x9b/0x26a ata_qc_complete_multiple+0xd0/0xe3 ahci_handle_port_interrupt+0x3ee/0x48a ahci_handle_port_intr+0x73/0xa9 ahci_single_level_irq_intr+0x40/0x60 __handle_irq_event_percpu+0x7f/0x19a handle_irq_event_percpu+0x32/0x72 handle_irq_event+0x38/0x56 handle_edge_irq+0x102/0x121 handle_irq+0x147/0x15c do_IRQ+0x66/0xf2 common_interrupt+0xf/0xf RIP: 0010:__do_softirq+0x8c/0x2df The same for usb devices that use ehci-pci: BUG: spinlock bad magic on CPU#0, swapper/0/1 lock: 0xffff88844f402008, .magic: 00000000, .owner: /-1, .owner_cpu: 0 CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.19.43 #4 Call Trace: dump_stack+0x61/0x7e spin_bug+0x9d/0xa3 do_raw_spin_lock+0x22/0x8e _raw_spin_lock_irqsave+0x32/0x3a queue_iova+0x77/0x145 intel_unmap+0x107/0x113 intel_unmap_page+0xe/0x10 usb_hcd_unmap_urb_setup_for_dma+0x53/0x9d usb_hcd_unmap_urb_for_dma+0x17/0x100 unmap_urb_for_dma+0x22/0x24 __usb_hcd_giveback_urb+0x51/0xc3 usb_giveback_urb_bh+0x97/0xde tasklet_action_common.isra.4+0x5f/0xa1 tasklet_action+0x2d/0x30 __do_softirq+0x138/0x2df irq_exit+0x7d/0x8b smp_apic_timer_interrupt+0x10f/0x151 apic_timer_interrupt+0xf/0x20 RIP: 0010:_raw_spin_unlock_irqrestore+0x17/0x39 Cc: David Woodhouse Cc: Joerg Roedel Cc: Lu Baolu Cc: iommu@lists.linux-foundation.org Cc: # 4.14+ Fixes: 13cf01744608 ("iommu/vt-d: Make use of iova deferred flushing") Signed-off-by: Dmitry Safonov Reviewed-by: Lu Baolu Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit 654da1b1f0260a3bcce6bac651a59ba52f357209 Author: Zhengyuan Liu Date: Sat Jul 13 11:58:26 2019 +0800 io_uring: fix the sequence comparison in io_sequence_defer commit dbd0f6d6c2a11eb9c31ca9cd454f95bb5713e92e upstream. sq->cached_sq_head and cq->cached_cq_tail are both unsigned int. If cached_sq_head overflows before cached_cq_tail, then we may miss a barrier req. As cached_cq_tail always follows cached_sq_head, the NQ should be enough. Cc: stable@vger.kernel.org Fixes: de0617e46717 ("io_uring: add support for marking commands as draining") Signed-off-by: Zhengyuan Liu Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit e9921197ba25139942bcced068ff7321efef12d0 Author: Suraj Jitindar Singh Date: Wed Jul 3 11:20:21 2019 +1000 powerpc/pmu: Set pmcregs_in_use in paca when running as LPAR commit 28d2a6e6684d9851905f379816d8a4d03587ed94 upstream. The ability to run nested guests under KVM means that a guest can also act as a hypervisor for it's own nested guest. Currently ppc_set_pmu_inuse() assumes that either FW_FEATURE_LPAR is set, indicating a guest environment, and so sets the pmcregs_in_use flag in the lppaca, or that it isn't set, indicating a hypervisor environment, and so sets the pmcregs_in_use flag in the paca. The pmcregs_in_use flag in the lppaca is used to communicate this information to a hypervisor and so must be set in a guest environment. The pmcregs_in_use flag in the paca is used by KVM code to determine whether the host state of the performance monitoring unit (PMU) must be saved and restored when running a guest. Thus when a guest also acts as a hypervisor it must set this bit in both places since it needs to ensure both that the real hypervisor saves it's PMU registers when it runs (requires pmcregs_in_use flag in lppaca), and that it saves it's own PMU registers when running a nested guest (requires pmcregs_in_use flag in paca). Modify ppc_set_pmu_inuse() so that the pmcregs_in_use bit is set in both the lppaca and the paca when a guest (LPAR) is running with the capability of running it's own guests (CONFIG_KVM_BOOK3S_HV_POSSIBLE). Fixes: 95a6432ce903 ("KVM: PPC: Book3S HV: Streamlined guest entry/exit path on P9 for radix guests") Cc: stable@vger.kernel.org # v4.20+ Signed-off-by: Suraj Jitindar Singh Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20190703012022.15644-2-sjitindarsingh@gmail.com Signed-off-by: Greg Kroah-Hartman commit 8716e8d122e12799eff9e92c05fdabba31d47b2f Author: Michael Neuling Date: Fri Jul 19 15:05:02 2019 +1000 powerpc/tm: Fix oops on sigreturn on systems without TM commit f16d80b75a096c52354c6e0a574993f3b0dfbdfe upstream. On systems like P9 powernv where we have no TM (or P8 booted with ppc_tm=off), userspace can construct a signal context which still has the MSR TS bits set. The kernel tries to restore this context which results in the following crash: Unexpected TM Bad Thing exception at c0000000000022fc (msr 0x8000000102a03031) tm_scratch=800000020280f033 Oops: Unrecoverable exception, sig: 6 [#1] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries Modules linked in: CPU: 0 PID: 1636 Comm: sigfuz Not tainted 5.2.0-11043-g0a8ad0ffa4 #69 NIP: c0000000000022fc LR: 00007fffb2d67e48 CTR: 0000000000000000 REGS: c00000003fffbd70 TRAP: 0700 Not tainted (5.2.0-11045-g7142b497d8) MSR: 8000000102a03031 CR: 42004242 XER: 00000000 CFAR: c0000000000022e0 IRQMASK: 0 GPR00: 0000000000000072 00007fffb2b6e560 00007fffb2d87f00 0000000000000669 GPR04: 00007fffb2b6e728 0000000000000000 0000000000000000 00007fffb2b6f2a8 GPR08: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR12: 0000000000000000 00007fffb2b76900 0000000000000000 0000000000000000 GPR16: 00007fffb2370000 00007fffb2d84390 00007fffea3a15ac 000001000a250420 GPR20: 00007fffb2b6f260 0000000010001770 0000000000000000 0000000000000000 GPR24: 00007fffb2d843a0 00007fffea3a14a0 0000000000010000 0000000000800000 GPR28: 00007fffea3a14d8 00000000003d0f00 0000000000000000 00007fffb2b6e728 NIP [c0000000000022fc] rfi_flush_fallback+0x7c/0x80 LR [00007fffb2d67e48] 0x7fffb2d67e48 Call Trace: Instruction dump: e96a0220 e96a02a8 e96a0330 e96a03b8 394a0400 4200ffdc 7d2903a6 e92d0c00 e94d0c08 e96d0c10 e82d0c18 7db242a6 <4c000024> 7db243a6 7db142a6 f82d0c18 The problem is the signal code assumes TM is enabled when CONFIG_PPC_TRANSACTIONAL_MEM is enabled. This may not be the case as with P9 powernv or if `ppc_tm=off` is used on P8. This means any local user can crash the system. Fix the problem by returning a bad stack frame to the user if they try to set the MSR TS bits with sigreturn() on systems where TM is not supported. Found with sigfuz kernel selftest on P9. This fixes CVE-2019-13648. Fixes: 2b0a576d15e0 ("powerpc: Add new transactional memory state to the signal context") Cc: stable@vger.kernel.org # v3.9 Reported-by: Praveen Pandey Signed-off-by: Michael Neuling Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20190719050502.405-1-mikey@neuling.org Signed-off-by: Greg Kroah-Hartman commit dde60fe53d7e35c7d70067ebad66347143348ec1 Author: Suraj Jitindar Singh Date: Wed Jul 10 15:20:18 2019 +1000 powerpc/mm: Limit rma_size to 1TB when running without HV mode commit da0ef93310e67ae6902efded60b6724dab27a5d1 upstream. The virtual real mode addressing (VRMA) mechanism is used when a partition is using HPT (Hash Page Table) translation and performs real mode accesses (MSR[IR|DR] = 0) in non-hypervisor mode. In this mode effective address bits 0:23 are treated as zero (i.e. the access is aliased to 0) and the access is performed using an implicit 1TB SLB entry. The size of the RMA (Real Memory Area) is communicated to the guest as the size of the first memory region in the device tree. And because of the mechanism described above can be expected to not exceed 1TB. In the event that the host erroneously represents the RMA as being larger than 1TB, guest accesses in real mode to memory addresses above 1TB will be aliased down to below 1TB. This means that a memory access performed in real mode may differ to one performed in virtual mode for the same memory address, which would likely have unintended consequences. To avoid this outcome have the guest explicitly limit the size of the RMA to the current maximum, which is 1TB. This means that even if the first memory block is larger than 1TB, only the first 1TB should be accessed in real mode. Fixes: c610d65c0ad0 ("powerpc/pseries: lift RTAS limit for hash") Cc: stable@vger.kernel.org # v4.16+ Signed-off-by: Suraj Jitindar Singh Tested-by: Satheesh Rajendran Reviewed-by: David Gibson Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20190710052018.14628-1-sjitindarsingh@gmail.com Signed-off-by: Greg Kroah-Hartman commit f5fa311323f2631ca567debfd9a9f26e1314c2e6 Author: Gautham R. Shenoy Date: Wed Jul 17 16:05:24 2019 +0530 powerpc/xive: Fix loop exit-condition in xive_find_target_in_mask() commit 4d202c8c8ed3822327285747db1765967110b274 upstream. xive_find_target_in_mask() has the following for(;;) loop which has a bug when @first == cpumask_first(@mask) and condition 1 fails to hold for every CPU in @mask. In this case we loop forever in the for-loop. first = cpu; for (;;) { if (cpu_online(cpu) && xive_try_pick_target(cpu)) // condition 1 return cpu; cpu = cpumask_next(cpu, mask); if (cpu == first) // condition 2 break; if (cpu >= nr_cpu_ids) // condition 3 cpu = cpumask_first(mask); } This is because, when @first == cpumask_first(@mask), we never hit the condition 2 (cpu == first) since prior to this check, we would have executed "cpu = cpumask_next(cpu, mask)" which will set the value of @cpu to a value greater than @first or to nr_cpus_ids. When this is coupled with the fact that condition 1 is not met, we will never exit this loop. This was discovered by the hard-lockup detector while running LTP test concurrently with SMT switch tests. watchdog: CPU 12 detected hard LOCKUP on other CPUs 68 watchdog: CPU 12 TB:85587019220796, last SMP heartbeat TB:85578827223399 (15999ms ago) watchdog: CPU 68 Hard LOCKUP watchdog: CPU 68 TB:85587019361273, last heartbeat TB:85576815065016 (19930ms ago) CPU: 68 PID: 45050 Comm: hxediag Kdump: loaded Not tainted 4.18.0-100.el8.ppc64le #1 NIP: c0000000006f5578 LR: c000000000cba9ec CTR: 0000000000000000 REGS: c000201fff3c7d80 TRAP: 0100 Not tainted (4.18.0-100.el8.ppc64le) MSR: 9000000002883033 CR: 24028424 XER: 00000000 CFAR: c0000000006f558c IRQMASK: 1 GPR00: c0000000000afc58 c000201c01c43400 c0000000015ce500 c000201cae26ec18 GPR04: 0000000000000800 0000000000000540 0000000000000800 00000000000000f8 GPR08: 0000000000000020 00000000000000a8 0000000080000000 c00800001a1beed8 GPR12: c0000000000b1410 c000201fff7f4c00 0000000000000000 0000000000000000 GPR16: 0000000000000000 0000000000000000 0000000000000540 0000000000000001 GPR20: 0000000000000048 0000000010110000 c00800001a1e3780 c000201cae26ed18 GPR24: 0000000000000000 c000201cae26ed8c 0000000000000001 c000000001116bc0 GPR28: c000000001601ee8 c000000001602494 c000201cae26ec18 000000000000001f NIP [c0000000006f5578] find_next_bit+0x38/0x90 LR [c000000000cba9ec] cpumask_next+0x2c/0x50 Call Trace: [c000201c01c43400] [c000201cae26ec18] 0xc000201cae26ec18 (unreliable) [c000201c01c43420] [c0000000000afc58] xive_find_target_in_mask+0x1b8/0x240 [c000201c01c43470] [c0000000000b0228] xive_pick_irq_target.isra.3+0x168/0x1f0 [c000201c01c435c0] [c0000000000b1470] xive_irq_startup+0x60/0x260 [c000201c01c43640] [c0000000001d8328] __irq_startup+0x58/0xf0 [c000201c01c43670] [c0000000001d844c] irq_startup+0x8c/0x1a0 [c000201c01c436b0] [c0000000001d57b0] __setup_irq+0x9f0/0xa90 [c000201c01c43760] [c0000000001d5aa0] request_threaded_irq+0x140/0x220 [c000201c01c437d0] [c00800001a17b3d4] bnx2x_nic_load+0x188c/0x3040 [bnx2x] [c000201c01c43950] [c00800001a187c44] bnx2x_self_test+0x1fc/0x1f70 [bnx2x] [c000201c01c43a90] [c000000000adc748] dev_ethtool+0x11d8/0x2cb0 [c000201c01c43b60] [c000000000b0b61c] dev_ioctl+0x5ac/0xa50 [c000201c01c43bf0] [c000000000a8d4ec] sock_do_ioctl+0xbc/0x1b0 [c000201c01c43c60] [c000000000a8dfb8] sock_ioctl+0x258/0x4f0 [c000201c01c43d20] [c0000000004c9704] do_vfs_ioctl+0xd4/0xa70 [c000201c01c43de0] [c0000000004ca274] sys_ioctl+0xc4/0x160 [c000201c01c43e30] [c00000000000b388] system_call+0x5c/0x70 Instruction dump: 78aad182 54a806be 3920ffff 78a50664 794a1f24 7d294036 7d43502a 7d295039 4182001c 48000034 78a9d182 79291f24 <7d23482a> 2fa90000 409e0020 38a50040 To fix this, move the check for condition 2 after the check for condition 3, so that we are able to break out of the loop soon after iterating through all the CPUs in the @mask in the problem case. Use do..while() to achieve this. Fixes: 243e25112d06 ("powerpc/xive: Native exploitation of the XIVE interrupt controller") Cc: stable@vger.kernel.org # v4.12+ Reported-by: Indira P. Joga Signed-off-by: Gautham R. Shenoy Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/1563359724-13931-1-git-send-email-ego@linux.vnet.ibm.com Signed-off-by: Greg Kroah-Hartman commit 5b5b3340a105abe65993fa1b3c3359c98371dacb Author: Shawn Anastasio Date: Wed Jul 17 18:54:37 2019 -0500 powerpc/dma: Fix invalid DMA mmap behavior commit b4fc36e60f25cf22bf8b7b015a701015740c3743 upstream. The refactor of powerpc DMA functions in commit 6666cc17d780 ("powerpc/dma: remove dma_nommu_mmap_coherent") incorrectly changes the way DMA mappings are handled on powerpc. Since this change, all mapped pages are marked as cache-inhibited through the default implementation of arch_dma_mmap_pgprot. This differs from the previous behavior of only marking pages in noncoherent mappings as cache-inhibited and has resulted in sporadic system crashes in certain hardware configurations and workloads (see Bugzilla). This commit restores the previous correct behavior by providing an implementation of arch_dma_mmap_pgprot that only marks pages in noncoherent mappings as cache-inhibited. As this behavior should be universal for all powerpc platforms a new file, dma-generic.c, was created to store it. Fixes: 6666cc17d780 ("powerpc/dma: remove dma_nommu_mmap_coherent") # NOTE: fixes commit 6666cc17d780 released in v5.1. # Consider a stable tag: # Cc: stable@vger.kernel.org # v5.1+ # NOTE: fixes commit 6666cc17d780 released in v5.1. # Consider a stable tag: # Cc: stable@vger.kernel.org # v5.1+ Cc: stable@vger.kernel.org # v5.1+ Signed-off-by: Shawn Anastasio Reviewed-by: Alexey Kardashevskiy Reviewed-by: Christoph Hellwig Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20190717235437.12908-1-shawn@anastas.io Signed-off-by: Greg Kroah-Hartman commit 2180be3072a5688722bf4ca2f90cc6a64f9f9629 Author: Hui Wang Date: Thu Jul 25 14:57:37 2019 +0800 ALSA: hda - Add a conexant codec entry to let mute led work commit 3f8809499bf02ef7874254c5e23fc764a47a21a0 upstream. This conexant codec isn't in the supported codec list yet, the hda generic driver can drive this codec well, but on a Lenovo machine with mute/mic-mute leds, we need to apply CXT_FIXUP_THINKPAD_ACPI to make the leds work. After adding this codec to the list, the driver patch_conexant.c will apply THINKPAD_ACPI to this machine. Cc: stable@vger.kernel.org Signed-off-by: Hui Wang Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit b411e4f44303b5839f49ccd5d4f58a7ff8e46d06 Author: Takashi Iwai Date: Fri Jul 19 10:27:54 2019 +0200 ALSA: hda - Fix intermittent CORB/RIRB stall on Intel chips commit 2756d9143aa517b97961e85412882b8ce31371a6 upstream. It turned out that the recent Intel HD-audio controller chips show a significant stall during the system PM resume intermittently. It doesn't happen so often and usually it may read back successfully after one or more seconds, but in some rare worst cases the driver went into fallback mode. After trial-and-error, we found out that the communication stall seems covered by issuing the sync after each verb write, as already done for AMD and other chipsets. So this patch enables the write-sync flag for the recent Intel chips, Skylake and onward, as a workaround. Also, since Broxton and co have the very same driver flags as Skylake, refer to the Skylake driver flags instead of defining the same contents again for simplification. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=201901 Reported-and-tested-by: Todd Brandt Cc: Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 65a96bb655ecd6a5a39aeebd2ad6fd3e983c3b4c Author: Takashi Iwai Date: Fri Jul 19 10:55:05 2019 +0200 ALSA: pcm: Fix refcount_inc() on zero usage commit 0e279dcea0ec897af1c979ebee4ec92b461793f5 upstream. The recent rewrite of PCM link lock management introduced the refcount in snd_pcm_group object, managed by the kernel refcount_t API. This caused unexpected kernel warnings when the kernel is built with CONFIG_REFCOUNT_FULL=y. As the warning line indicates, the problem is obviously that we start with refcount=0 and do refcount_inc() for adding each PCM link, while refcount_t API doesn't like refcount_inc() performed on zero. For adapting the proper refcount_t usage, this patch changes the logic slightly: - The initial refcount is 1, assuming the single list entry - The refcount is incremented / decremented at each PCM link addition and deletion - ... which allows us concentrating only on the refcount as a release condition Fixes: f57f3df03a8e ("ALSA: pcm: More fine-grained PCM link locking") BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=204221 Reported-and-tested-by: Duncan Overbruck Cc: Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit b8e0b3ea392a7da38d46ca393c7a4e36364d45d7 Author: Kai-Heng Feng Date: Thu Jul 18 17:53:13 2019 +0800 ALSA: line6: Fix wrong altsetting for LINE6_PODHD500_1 commit 70256b42caaf3e13c2932c2be7903a73fbe8bb8b upstream. Commit 7b9584fa1c0b ("staging: line6: Move altsetting to properties") set a wrong altsetting for LINE6_PODHD500_1 during refactoring. Set the correct altsetting number to fix the issue. BugLink: https://bugs.launchpad.net/bugs/1790595 Fixes: 7b9584fa1c0b ("staging: line6: Move altsetting to properties") Signed-off-by: Kai-Heng Feng Cc: Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 38c1eed50a8526691e7399387175888cf900c005 Author: Ding Xiang Date: Tue Jul 23 15:44:41 2019 +0800 ALSA: ac97: Fix double free of ac97_codec_device commit 607975b30db41aad6edc846ed567191aa6b7d893 upstream. put_device will call ac97_codec_release to free ac97_codec_device and other resources, so remove the kfree and other redundant code. Fixes: 74426fbff66e ("ALSA: ac97: add an ac97 bus") Signed-off-by: Ding Xiang Cc: Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit e24e8d9ae65d363bf9466952330ff1c170d11557 Author: Sébastien Szymanski Date: Tue May 7 17:27:12 2019 +0200 drm/panel: Add support for Armadeus ST0700 Adapt commit c479450f61c7f1f248c9a54aedacd2a6ca521ff8 upstream. This patch adds support for the Armadeus ST0700 Adapt. It comes with a Santek ST0700I5Y-RBSLW 7.0" WVGA (800x480) TFT and an adapter board so that it can be connected on the TFT header of Armadeus Dev boards. Cc: stable@vger.kernel.org # v4.19 Reviewed-by: Rob Herring Signed-off-by: Sébastien Szymanski Signed-off-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/20190507152713.27494-1-sebastien.szymanski@armadeus.com Signed-off-by: Greg Kroah-Hartman commit 25b3a749643db0cd079b5c4c3d79a6aaaa14ab67 Author: Kefeng Wang Date: Thu Jul 11 21:27:57 2019 +0800 hpet: Fix division by zero in hpet_time_div() commit 0c7d37f4d9b8446956e97b7c5e61173cdb7c8522 upstream. The base value in do_div() called by hpet_time_div() is truncated from unsigned long to uint32_t, resulting in a divide-by-zero exception. UBSAN: Undefined behaviour in ../drivers/char/hpet.c:572:2 division by zero CPU: 1 PID: 23682 Comm: syz-executor.3 Not tainted 4.4.184.x86_64+ #4 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014 0000000000000000 b573382df1853d00 ffff8800a3287b98 ffffffff81ad7561 ffff8800a3287c00 ffffffff838b35b0 ffffffff838b3860 ffff8800a3287c20 0000000000000000 ffff8800a3287bb0 ffffffff81b8f25e ffffffff838b35a0 Call Trace: [] __dump_stack lib/dump_stack.c:15 [inline] [] dump_stack+0xc1/0x120 lib/dump_stack.c:51 [] ubsan_epilogue+0x12/0x8d lib/ubsan.c:166 [] __ubsan_handle_divrem_overflow+0x282/0x2c8 lib/ubsan.c:262 [] hpet_time_div drivers/char/hpet.c:572 [inline] [] hpet_ioctl_common drivers/char/hpet.c:663 [inline] [] hpet_ioctl_common.cold+0xa8/0xad drivers/char/hpet.c:577 [] hpet_ioctl+0xc6/0x180 drivers/char/hpet.c:676 [] vfs_ioctl fs/ioctl.c:43 [inline] [] file_ioctl fs/ioctl.c:470 [inline] [] do_vfs_ioctl+0x6e0/0xf70 fs/ioctl.c:605 [] SYSC_ioctl fs/ioctl.c:622 [inline] [] SyS_ioctl+0x94/0xc0 fs/ioctl.c:613 [] tracesys_phase2+0x90/0x95 The main C reproducer autogenerated by syzkaller, syscall(__NR_mmap, 0x20000000, 0x1000000, 3, 0x32, -1, 0); memcpy((void*)0x20000100, "/dev/hpet\000", 10); syscall(__NR_openat, 0xffffffffffffff9c, 0x20000100, 0, 0); syscall(__NR_ioctl, r[0], 0x40086806, 0x40000000000000); Fix it by using div64_ul(). Signed-off-by: Kefeng Wang Signed-off-by: Zhang HongJun Cc: stable Reviewed-by: Arnd Bergmann Link: https://lore.kernel.org/r/20190711132757.130092-1-wangkefeng.wang@huawei.com Signed-off-by: Greg Kroah-Hartman commit 4559d613e5647401a180eb64e799af83efc1c987 Author: Arseny Solokha Date: Tue Jul 16 18:12:36 2019 +0700 eeprom: make older eeprom drivers select NVMEM_SYSFS commit 1b5621832f9bd9899370ea6928462cd02ebe7dc0 upstream. misc/eeprom/{at24,at25,eeprom_93xx46} drivers all register their corresponding devices in the nvmem framework in compat mode which requires nvmem sysfs interface to be present. The latter, however, has been split out from nvmem under a separate Kconfig in commit ae0c2d725512 ("nvmem: core: add NVMEM_SYSFS Kconfig"). As a result, probing certain I2C-attached EEPROMs now fails with at24: probe of 0-0050 failed with error -38 because of a stub implementation of nvmem_sysfs_setup_compat() in drivers/nvmem/nvmem.h. Update the nvmem dependency for these drivers so they could load again: at24 0-0050: 32768 byte 24c256 EEPROM, writable, 64 bytes/write Cc: Adrian Bunk Cc: Bartosz Golaszewski Cc: Srinivas Kandagatla Cc: stable@vger.kernel.org # v5.2+ Signed-off-by: Arseny Solokha Link: https://lore.kernel.org/r/20190716111236.27803-1-asolokha@kb.kras.ru Signed-off-by: Greg Kroah-Hartman commit f524108c09671ba0ce62ab7303fc9c16126cf12a Author: Alexander Usyskin Date: Fri Jul 12 12:58:14 2019 +0300 mei: me: add mule creek canyon (EHL) device ids commit 1be8624a0cbef720e8da39a15971e01abffc865b upstream. Add Mule Creek Canyon (PCH) MEI device ids for Elkhart Lake (EHL) Platform. Signed-off-by: Alexander Usyskin Signed-off-by: Tomas Winkler Cc: stable Link: https://lore.kernel.org/r/20190712095814.20746-1-tomas.winkler@intel.com Signed-off-by: Greg Kroah-Hartman commit ccfad1fdd347aaaf80ec385c796dbe98dc27ef6a Author: YueHaibing Date: Mon Jul 8 15:13:56 2019 +0800 fpga-manager: altera-ps-spi: Fix build error commit 3d139703d397f6281368047ba7ad1c8bf95aa8ab upstream. If BITREVERSE is m and FPGA_MGR_ALTERA_PS_SPI is y, build fails: drivers/fpga/altera-ps-spi.o: In function `altera_ps_write': altera-ps-spi.c:(.text+0x4ec): undefined reference to `byte_rev_table' Select BITREVERSE to fix this. Reported-by: Hulk Robot Fixes: fcfe18f885f6 ("fpga-manager: altera-ps-spi: use bitrev8x4") Signed-off-by: YueHaibing Cc: stable Acked-by: Moritz Fischer Link: https://lore.kernel.org/r/20190708071356.50928-1-yuehaibing@huawei.com Signed-off-by: Greg Kroah-Hartman commit 726e76ea93307306bc468a4c918102ff5b2c56f6 Author: Hridya Valsaraju Date: Mon Jul 15 12:18:04 2019 -0700 binder: prevent transactions to context manager from its own process. commit 49ed96943a8e0c62cc5a9b0a6cfc88be87d1fcec upstream. Currently, a transaction to context manager from its own process is prevented by checking if its binder_proc struct is the same as that of the sender. However, this would not catch cases where the process opens the binder device again and uses the new fd to send a transaction to the context manager. Reported-by: syzbot+8b3c354d33c4ac78bfad@syzkaller.appspotmail.com Signed-off-by: Hridya Valsaraju Acked-by: Todd Kjos Cc: stable Link: https://lore.kernel.org/r/20190715191804.112933-1-hridya@google.com Signed-off-by: Greg Kroah-Hartman commit 01ca6aed36d0f7573854fb5c504696b2314a12f5 Author: Martijn Coenen Date: Tue Jul 9 13:09:23 2019 +0200 binder: Set end of SG buffer area properly. commit a56587065094fd96eb4c2b5ad65571daad32156d upstream. In case the target node requests a security context, the extra_buffers_size is increased with the size of the security context. But, that size is not available for use by regular scatter-gather buffers; make sure the ending of that buffer is marked correctly. Acked-by: Todd Kjos Fixes: ec74136ded79 ("binder: create node flag to request sender's security context") Signed-off-by: Martijn Coenen Cc: stable@vger.kernel.org # 5.1+ Link: https://lore.kernel.org/r/20190709110923.220736-1-maco@android.com Signed-off-by: Greg Kroah-Hartman commit ea449923454a69e75bade4dad45d66ee5198c73e Author: Eiichi Tsukata Date: Mon Jul 22 17:32:16 2019 +0900 x86/stacktrace: Prevent access_ok() warnings in arch_stack_walk_user() commit 2af7c85714d8cafadf925d55441458eae312cd6b upstream. When arch_stack_walk_user() is called from atomic contexts, access_ok() can trigger the following warning if compiled with CONFIG_DEBUG_ATOMIC_SLEEP=y. Reproducer: // CONFIG_DEBUG_ATOMIC_SLEEP=y # cd /sys/kernel/debug/tracing # echo 1 > options/userstacktrace # echo 1 > events/irq/irq_handler_entry/enable WARNING: CPU: 0 PID: 2649 at arch/x86/kernel/stacktrace.c:103 arch_stack_walk_user+0x6e/0xf6 CPU: 0 PID: 2649 Comm: bash Not tainted 5.3.0-rc1+ #99 RIP: 0010:arch_stack_walk_user+0x6e/0xf6 Call Trace: stack_trace_save_user+0x10a/0x16d trace_buffer_unlock_commit_regs+0x185/0x240 trace_event_buffer_commit+0xec/0x330 trace_event_raw_event_irq_handler_entry+0x159/0x1e0 __handle_irq_event_percpu+0x22d/0x440 handle_irq_event_percpu+0x70/0x100 handle_irq_event+0x5a/0x8b handle_edge_irq+0x12f/0x3f0 handle_irq+0x34/0x40 do_IRQ+0xa6/0x1f0 common_interrupt+0xf/0xf Fix it by calling __range_not_ok() directly instead of access_ok() as copy_from_user_nmi() does. This is fine here because the actual copy is inside a pagefault disabled region. Reported-by: Juri Lelli Signed-off-by: Eiichi Tsukata Signed-off-by: Thomas Gleixner Link: https://lkml.kernel.org/r/20190722083216.16192-2-devel@etsukata.com Signed-off-by: Greg Kroah-Hartman commit eb134f33319eb36b708bf0bb87acc60645eb40d3 Author: Zhenzhong Duan Date: Thu Jul 25 10:39:09 2019 +0800 x86/speculation/mds: Apply more accurate check on hypervisor platform commit 517c3ba00916383af6411aec99442c307c23f684 upstream. X86_HYPER_NATIVE isn't accurate for checking if running on native platform, e.g. CONFIG_HYPERVISOR_GUEST isn't set or "nopv" is enabled. Checking the CPU feature bit X86_FEATURE_HYPERVISOR to determine if it's running on native platform is more accurate. This still doesn't cover the platforms on which X86_FEATURE_HYPERVISOR is unsupported, e.g. VMware, but there is nothing which can be done about this scenario. Fixes: 8a4b06d391b0 ("x86/speculation/mds: Add sysfs reporting for MDS") Signed-off-by: Zhenzhong Duan Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/1564022349-17338-1-git-send-email-zhenzhong.duan@oracle.com Signed-off-by: Greg Kroah-Hartman commit ae995a18ecfc852a5000c35f43fc74672488890a Author: Hans de Goede Date: Sun Jul 21 17:24:18 2019 +0200 x86/sysfb_efi: Add quirks for some devices with swapped width and height commit d02f1aa39189e0619c3525d5cd03254e61bf606a upstream. Some Lenovo 2-in-1s with a detachable keyboard have a portrait screen but advertise a landscape resolution and pitch, resulting in a messed up display if the kernel tries to show anything on the efifb (because of the wrong pitch). Fix this by adding a new DMI match table for devices which need to have their width and height swapped. At first it was tried to use the existing table for overriding some of the efifb parameters, but some of the affected devices have variants with different LCD resolutions which will not work with hardcoded override values. Reference: https://bugzilla.redhat.com/show_bug.cgi?id=1730783 Signed-off-by: Hans de Goede Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20190721152418.11644-1-hdegoede@redhat.com Signed-off-by: Greg Kroah-Hartman commit 117d3b1d5e3150064b5c83db8eb879f950cb7e05 Author: Ondrej Mosnacek Date: Tue Jul 23 08:50:59 2019 +0200 selinux: check sidtab limit before adding a new entry commit acbc372e6109c803cbee4733769d02008381740f upstream. We need to error out when trying to add an entry above SIDTAB_MAX in sidtab_reverse_lookup() to avoid overflow on the odd chance that this happens. Cc: stable@vger.kernel.org Fixes: ee1a84fdfeed ("selinux: overhaul sidtab to fix bug and improve performance") Signed-off-by: Ondrej Mosnacek Reviewed-by: Kees Cook Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit e459c059b044f8f91c43eb0612e98e85a73a1c41 Author: Qu Wenruo Date: Mon Jul 1 05:12:46 2019 +0000 btrfs: inode: Don't compress if NODATASUM or NODATACOW set commit 42c16da6d684391db83788eb680accd84f6c2083 upstream. As btrfs(5) specified: Note If nodatacow or nodatasum are enabled, compression is disabled. If NODATASUM or NODATACOW set, we should not compress the extent. Normally NODATACOW is detected properly in run_delalloc_range() so compression won't happen for NODATACOW. However for NODATASUM we don't have any check, and it can cause compressed extent without csum pretty easily, just by: mkfs.btrfs -f $dev mount $dev $mnt -o nodatasum touch $mnt/foobar mount -o remount,datasum,compress $mnt xfs_io -f -c "pwrite 0 128K" $mnt/foobar And in fact, we have a bug report about corrupted compressed extent without proper data checksum so even RAID1 can't recover the corruption. (https://bugzilla.kernel.org/show_bug.cgi?id=199707) Running compression without proper checksum could cause more damage when corruption happens, as compressed data could make the whole extent unreadable, so there is no need to allow compression for NODATACSUM. The fix will refactor the inode compression check into two parts: - inode_can_compress() As the hard requirement, checked at btrfs_run_delalloc_range(), so no compression will happen for NODATASUM inode at all. - inode_need_compress() As the soft requirement, checked at btrfs_run_delalloc_range() and compress_file_range(). Reported-by: James Harvey CC: stable@vger.kernel.org # 4.4+ Signed-off-by: Qu Wenruo Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 0c247d6d410f708559f00cf8210847fcf417e3e7 Author: Hans Verkuil Date: Thu Jul 11 04:53:25 2019 -0400 media: videodev2.h: change V4L2_PIX_FMT_BGRA444 define: fourcc was already in use commit 22be8233b34f4f468934c5fefcbe6151766fb8f2 upstream. The V4L2_PIX_FMT_BGRA444 define clashed with the pre-existing V4L2_PIX_FMT_SGRBG12 which strangely enough used the same fourcc, even though that fourcc made no sense for a Bayer format. In any case, you can't have duplicates, so change the fourcc of V4L2_PIX_FMT_BGRA444. Signed-off-by: Hans Verkuil Cc: # for v5.2 and up Fixes: 6c84f9b1d2900 ("media: v4l: Add definitions for missing 16-bit RGB4444 formats") Reviewed-by: Laurent Pinchart Reviewed-by: Kieran Bingham Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 373108886c3120cb92f50b92016087d9b562575b Author: Cédric Le Goater Date: Thu Jul 18 23:51:54 2019 +0200 KVM: PPC: Book3S HV: XIVE: fix rollback when kvmppc_xive_create fails commit 9798f4ea71eaf8eaad7e688c5b298528089c7bf8 upstream. The XIVE device structure is now allocated in kvmppc_xive_get_device() and kfree'd in kvmppc_core_destroy_vm(). In case of an OPAL error when allocating the XIVE VPs, the kfree() call in kvmppc_xive_*create() will result in a double free and corrupt the host memory. Fixes: 5422e95103cf ("KVM: PPC: Book3S HV: XIVE: Replace the 'destroy' method by a 'release' method") Cc: stable@vger.kernel.org # v5.2+ Signed-off-by: Cédric Le Goater Tested-by: Michael Ellerman Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/6ea6998b-a890-2511-01d1-747d7621eb19@kaod.org Signed-off-by: Greg Kroah-Hartman commit 13135247b77192d51e7bd6f95220e645ab1b6537 Author: Suraj Jitindar Singh Date: Wed Jul 3 11:20:22 2019 +1000 KVM: PPC: Book3S HV: Save and restore guest visible PSSCR bits on pseries commit c8b4083db915dfe5a3b4a755ad2317e0509b43f1 upstream. The Performance Stop Status and Control Register (PSSCR) is used to control the power saving facilities of the processor. This register has various fields, some of which can be modified only in hypervisor state, and others which can be modified in both hypervisor and privileged non-hypervisor state. The bits which can be modified in privileged non-hypervisor state are referred to as guest visible. Currently the L0 hypervisor saves and restores both it's own host value as well as the guest value of the PSSCR when context switching between the hypervisor and guest. However a nested hypervisor running it's own nested guests (as indicated by kvmhv_on_pseries()) doesn't context switch the PSSCR register. That means if a nested (L2) guest modifies the PSSCR then the L1 guest hypervisor will run with that modified value, and if the L1 guest hypervisor modifies the PSSCR and then goes to run the nested (L2) guest again then the L2 PSSCR value will be lost. Fix this by having the (L1) nested hypervisor save and restore both its host and the guest PSSCR value when entering and exiting a nested (L2) guest. Note that only the guest visible parts of the PSSCR are context switched since this is all the L1 nested hypervisor can access, this is fine however as these are the only fields the L0 hypervisor provides guest control of anyway and so all other fields are ignored. This could also have been implemented by adding the PSSCR register to the hv_regs passed to the L0 hypervisor as input to the H_ENTER_NESTED hcall, however this would have meant updating the structure layout and thus required modifications to both the L0 and L1 kernels. Whereas the approach used doesn't require L0 kernel modifications while achieving the same result. Fixes: 95a6432ce903 ("KVM: PPC: Book3S HV: Streamlined guest entry/exit path on P9 for radix guests") Cc: stable@vger.kernel.org # v4.20+ Signed-off-by: Suraj Jitindar Singh Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20190703012022.15644-3-sjitindarsingh@gmail.com Signed-off-by: Greg Kroah-Hartman commit 08ab7cccafa6c1d022b9a35f7641d0bdaca64b0f Author: Suraj Jitindar Singh Date: Wed Jul 3 11:20:20 2019 +1000 KVM: PPC: Book3S HV: Always save guest pmu for guest capable of nesting commit 63279eeb7f93abb1692573c26f1e038e1a87358b upstream. The performance monitoring unit (PMU) registers are saved on guest exit when the guest has set the pmcregs_in_use flag in its lppaca, if it exists, or unconditionally if it doesn't. If a nested guest is being run then the hypervisor doesn't, and in most cases can't, know if the PMU registers are in use since it doesn't know the location of the lppaca for the nested guest, although it may have one for its immediate guest. This results in the values of these registers being lost across nested guest entry and exit in the case where the nested guest was making use of the performance monitoring facility while it's nested guest hypervisor wasn't. Further more the hypervisor could interrupt a guest hypervisor between when it has loaded up the PMU registers and it calling H_ENTER_NESTED or between returning from the nested guest to the guest hypervisor and the guest hypervisor reading the PMU registers, in kvmhv_p9_guest_entry(). This means that it isn't sufficient to just save the PMU registers when entering or exiting a nested guest, but that it is necessary to always save the PMU registers whenever a guest is capable of running nested guests to ensure the register values aren't lost in the context switch. Ensure the PMU register values are preserved by always saving their value into the vcpu struct when a guest is capable of running nested guests. This should have minimal performance impact however any impact can be avoided by booting a guest with "-machine pseries,cap-nested-hv=false" on the qemu commandline. Fixes: 95a6432ce903 ("KVM: PPC: Book3S HV: Streamlined guest entry/exit path on P9 for radix guests") Cc: stable@vger.kernel.org # v4.20+ Signed-off-by: Suraj Jitindar Singh Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20190703012022.15644-1-sjitindarsingh@gmail.com Signed-off-by: Greg Kroah-Hartman commit ca7e6b286333749abd7ccc3f413b518a5405f512 Author: Wanpeng Li Date: Mon Jul 22 12:26:20 2019 +0800 KVM: X86: Fix fpu state crash in kvm guest commit e751732486eb3f159089a64d1901992b1357e7cc upstream. The idea before commit 240c35a37 (which has just been reverted) was that we have the following FPU states: userspace (QEMU) guest --------------------------------------------------------------------------- processor vcpu->arch.guest_fpu >>> KVM_RUN: kvm_load_guest_fpu vcpu->arch.user_fpu processor >>> preempt out vcpu->arch.user_fpu current->thread.fpu >>> preempt in vcpu->arch.user_fpu processor >>> back to userspace >>> kvm_put_guest_fpu processor vcpu->arch.guest_fpu --------------------------------------------------------------------------- With the new lazy model we want to get the state back to the processor when schedule in from current->thread.fpu. Reported-by: Thomas Lambertz Reported-by: anthony Tested-by: anthony Cc: Paolo Bonzini Cc: Radim Krčmář Cc: Thomas Lambertz Cc: anthony Cc: stable@vger.kernel.org Fixes: 5f409e20b (x86/fpu: Defer FPU state load until return to userspace) Signed-off-by: Wanpeng Li [Add a comment in front of the warning. - Paolo] Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 71f9fbd354ce1863df43226029fe0d62e8107473 Author: Lucas Stach Date: Fri Jul 19 10:44:07 2019 +0200 usb: usb251xb: Reallow swap-dx-lanes to apply to the upstream port commit 4849ee6129702dcb05d36f9c7c61b4661fcd751f upstream. This is a partial revert of 73d31def1aab "usb: usb251xb: Create a ports field collector method", which broke a existing devicetree (arch/arm64/boot/dts/freescale/imx8mq.dtsi). There is no reason why the swap-dx-lanes property should not apply to the upstream port. The reason given in the breaking commit was that it's inconsitent with respect to other port properties, but in fact it is not. All other properties which only apply to the downstream ports explicitly reject port 0, so there is pretty strong precedence that the driver referred to the upstream port as port 0. So there is no inconsistency in this property at all, other than the swapping being also applicable to the upstream port. CC: stable@vger.kernel.org #5.2 Signed-off-by: Lucas Stach Link: https://lore.kernel.org/r/20190719084407.28041-3-l.stach@pengutronix.de Signed-off-by: Greg Kroah-Hartman commit b1f55b18d4dcc5b2fcad30ee376f43c111e7094d Author: Lucas Stach Date: Fri Jul 19 10:44:06 2019 +0200 Revert "usb: usb251xb: Add US port lanes inversion property" commit 79f6fafad4e2a874015cb67d735f9f87f1834367 upstream. This property isn't needed and not yet used anywhere. The swap-dx-lanes property is perfectly fine for doing the swap on the upstream port lanes. CC: stable@vger.kernel.org #5.2 Signed-off-by: Lucas Stach Link: https://lore.kernel.org/r/20190719084407.28041-2-l.stach@pengutronix.de Signed-off-by: Greg Kroah-Hartman commit c061554d812b5593310fd5daa0aacf3b38821e50 Author: Lucas Stach Date: Fri Jul 19 10:44:05 2019 +0200 Revert "usb: usb251xb: Add US lanes inversion dts-bindings" commit bafe64e5f0edaa689e72e2f8dc236641da37fed4 upstream. This reverts commit 3342ce35a1, as there is no need for this separate property and it breaks compatibility with existing devicetree files (arch/arm64/boot/dts/freescale/imx8mq.dtsi). CC: stable@vger.kernel.org #5.2 Fixes: 3342ce35a183 ("usb: usb251xb: Add US lanes inversion dts-bindings") Signed-off-by: Lucas Stach Link: https://lore.kernel.org/r/20190719084407.28041-1-l.stach@pengutronix.de Signed-off-by: Greg Kroah-Hartman commit 16ea412d40cc174c2284965ec0c265c251016d24 Author: Ryan Kennedy Date: Thu Jul 4 11:35:28 2019 -0400 usb: pci-quirks: Correct AMD PLL quirk detection commit f3dccdaade4118070a3a47bef6b18321431f9ac6 upstream. The AMD PLL USB quirk is incorrectly enabled on newer Ryzen chipsets. The logic in usb_amd_find_chipset_info currently checks for unaffected chipsets rather than affected ones. This broke once a new chipset was added in e788787ef. It makes more sense to reverse the logic so it won't need to be updated as new chipsets are added. Note that the core of the workaround in usb_amd_quirk_pll does correctly check the chipset. Signed-off-by: Ryan Kennedy Fixes: e788787ef4f9 ("usb:xhci:Add quirk for Certain failing HP keyboard on reset after resume") Cc: stable Acked-by: Alan Stern Link: https://lore.kernel.org/r/20190704153529.9429-2-ryan5544@gmail.com Signed-off-by: Greg Kroah-Hartman commit d9dd384c6c7b25ca56cf46b1760330d5e6fa6b31 Author: Phong Tran Date: Wed Jul 24 09:06:01 2019 +0700 usb: wusbcore: fix unbalanced get/put cluster_id commit f90bf1ece48a736097ea224430578fe586a9544c upstream. syzboot reported that https://syzkaller.appspot.com/bug?extid=fd2bd7df88c606eea4ef There is not consitency parameter in cluste_id_get/put calling. In case of getting the id with result is failure, the wusbhc->cluster_id will not be updated and this can not be used for wusb_cluster_id_put(). Tested report https://groups.google.com/d/msg/syzkaller-bugs/0znZopp3-9k/oxOrhLkLEgAJ Reproduce and gdb got the details: 139 addr = wusb_cluster_id_get(); (gdb) n 140 if (addr == 0) (gdb) print addr $1 = 254 '\376' (gdb) n 142 result = __hwahc_set_cluster_id(hwahc, addr); (gdb) print result $2 = -71 (gdb) break wusb_cluster_id_put Breakpoint 3 at 0xffffffff836e3f20: file drivers/usb/wusbcore/wusbhc.c, line 384. (gdb) s Thread 2 hit Breakpoint 3, wusb_cluster_id_put (id=0 '\000') at drivers/usb/wusbcore/wusbhc.c:384 384 id = 0xff - id; (gdb) n 385 BUG_ON(id >= CLUSTER_IDS); (gdb) print id $3 = 255 '\377' Reported-by: syzbot+fd2bd7df88c606eea4ef@syzkaller.appspotmail.com Signed-off-by: Phong Tran Cc: stable Link: https://lore.kernel.org/r/20190724020601.15257-1-tranmanphong@gmail.com Signed-off-by: Greg Kroah-Hartman commit 3c2faef16e1616fcf24cabcd15c22adf261d7e65 Author: Yoshihiro Shimoda Date: Mon Jul 22 19:58:25 2019 +0900 usb-storage: Add a limitation for blk_queue_max_hw_sectors() commit d74ffae8b8dd17eaa8b82fc163e6aa2076dc8fb1 upstream. This patch fixes an issue that the following error happens on swiotlb environment: xhci-hcd ee000000.usb: swiotlb buffer is full (sz: 524288 bytes), total 32768 (slots), used 1338 (slots) On the kernel v5.1, block settings of a usb-storage with SuperSpeed were the following so that the block layer will allocate buffers up to 64 KiB, and then the issue didn't happen. max_segment_size = 65536 max_hw_sectors_kb = 1024 After the commit 09324d32d2a0 ("block: force an unlimited segment size on queues with a virt boundary") is applied, the block settings are the following. So, the block layer will allocate buffers up to 1024 KiB, and then the issue happens: max_segment_size = 4294967295 max_hw_sectors_kb = 1024 To fix the issue, the usb-storage driver checks the maximum size of a mapping for the device and then adjusts the max_hw_sectors_kb if required. After this patch is applied, the block settings will be the following, and then the issue doesn't happen. max_segment_size = 4294967295 max_hw_sectors_kb = 256 Fixes: 09324d32d2a0 ("block: force an unlimited segment size on queues with a virt boundary") Cc: stable Signed-off-by: Yoshihiro Shimoda Acked-by: Alan Stern Reviewed-by: Christoph Hellwig Link: https://lore.kernel.org/r/1563793105-20597-1-git-send-email-yoshihiro.shimoda.uh@renesas.com Signed-off-by: Greg Kroah-Hartman commit ddc2ea0c281bfa75dfedeba1a336ce449a7b9480 Author: Mathias Nyman Date: Thu Jul 25 11:54:21 2019 +0300 xhci: Fix crash if scatter gather is used with Immediate Data Transfer (IDT). commit d39b5bad8658d6d94cb2d98a44a7e159db4f5030 upstream. A second regression was found in the immediate data transfer (IDT) support which was added to 5.2 kernel IDT is used to transfer small amounts of data (up to 8 bytes) in the field normally used for data dma address, thus avoiding dma mapping. If the data was not already dma mapped, then IDT support assumed data was in urb->transfer_buffer, and did not take into accound that even small amounts of data (8 bytes) can be in a scatterlist instead. This caused a NULL pointer dereference when sg_dma_len() was used with non-dma mapped data. Solve this by not using IDT if scatter gather buffer list is used. Fixes: 33e39350ebd2 ("usb: xhci: add Immediate Data Transfer support") Cc: # v5.2 Reported-by: Maik Stohn Tested-by: Maik Stohn CC: Nicolas Saenz Julienne Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/1564044861-1445-1-git-send-email-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit ca40a74b28eb2272189286a71dc7338da9733e46 Author: Arnd Bergmann Date: Mon Jul 15 11:27:49 2019 +0200 locking/lockdep: Hide unused 'class' variable [ Upstream commit 68037aa78208f34bda4e5cd76c357f718b838cbb ] The usage is now hidden in an #ifdef, so we need to move the variable itself in there as well to avoid this warning: kernel/locking/lockdep_proc.c:203:21: error: unused variable 'class' [-Werror,-Wunused-variable] Signed-off-by: Arnd Bergmann Signed-off-by: Peter Zijlstra (Intel) Cc: Andrew Morton Cc: Bart Van Assche Cc: Linus Torvalds Cc: Paul E. McKenney Cc: Peter Zijlstra Cc: Qian Cai Cc: Thomas Gleixner Cc: Waiman Long Cc: Will Deacon Cc: Will Deacon Cc: Yuyang Du Cc: frederic@kernel.org Fixes: 68d41d8c94a3 ("locking/lockdep: Fix lock used or unused stats error") Link: https://lkml.kernel.org/r/20190715092809.736834-1-arnd@arndb.de Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit 12b4d230660f507729cdac4dba7a371c4fbf2aa7 Author: Huang Ying Date: Thu Jul 11 20:55:33 2019 -0700 mm, swap: fix race between swapoff and some swap operations [ Upstream commit eb085574a7526c4375965c5fbf7e5b0c19cdd336 ] When swapin is performed, after getting the swap entry information from the page table, system will swap in the swap entry, without any lock held to prevent the swap device from being swapoff. This may cause the race like below, CPU 1 CPU 2 ----- ----- do_swap_page swapin_readahead __read_swap_cache_async swapoff swapcache_prepare p->swap_map = NULL __swap_duplicate p->swap_map[?] /* !!! NULL pointer access */ Because swapoff is usually done when system shutdown only, the race may not hit many people in practice. But it is still a race need to be fixed. To fix the race, get_swap_device() is added to check whether the specified swap entry is valid in its swap device. If so, it will keep the swap entry valid via preventing the swap device from being swapoff, until put_swap_device() is called. Because swapoff() is very rare code path, to make the normal path runs as fast as possible, rcu_read_lock/unlock() and synchronize_rcu() instead of reference count is used to implement get/put_swap_device(). >From get_swap_device() to put_swap_device(), RCU reader side is locked, so synchronize_rcu() in swapoff() will wait until put_swap_device() is called. In addition to swap_map, cluster_info, etc. data structure in the struct swap_info_struct, the swap cache radix tree will be freed after swapoff, so this patch fixes the race between swap cache looking up and swapoff too. Races between some other swap cache usages and swapoff are fixed too via calling synchronize_rcu() between clearing PageSwapCache() and freeing swap cache data structure. Another possible method to fix this is to use preempt_off() + stop_machine() to prevent the swap device from being swapoff when its data structure is being accessed. The overhead in hot-path of both methods is similar. The advantages of RCU based method are, 1. stop_machine() may disturb the normal execution code path on other CPUs. 2. File cache uses RCU to protect its radix tree. If the similar mechanism is used for swap cache too, it is easier to share code between them. 3. RCU is used to protect swap cache in total_swapcache_pages() and exit_swap_address_space() already. The two mechanisms can be merged to simplify the logic. Link: http://lkml.kernel.org/r/20190522015423.14418-1-ying.huang@intel.com Fixes: 235b62176712 ("mm/swap: add cluster lock") Signed-off-by: "Huang, Ying" Reviewed-by: Andrea Parri Not-nacked-by: Hugh Dickins Cc: Andrea Arcangeli Cc: Paul E. McKenney Cc: Daniel Jordan Cc: Michal Hocko Cc: Minchan Kim Cc: Johannes Weiner Cc: Tim Chen Cc: Mel Gorman Cc: Jérôme Glisse Cc: Yang Shi Cc: David Rientjes Cc: Rik van Riel Cc: Jan Kara Cc: Dave Jiang Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 2a8d344726e38daad54a72df16d940f055eb8b41 Author: Konstantin Khlebnikov Date: Thu Jul 11 21:00:07 2019 -0700 mm: use down_read_killable for locking mmap_sem in access_remote_vm [ Upstream commit 1e426fe28261b03f297992e89da3320b42816f4e ] This function is used by ptrace and proc files like /proc/pid/cmdline and /proc/pid/environ. Access_remote_vm never returns error codes, all errors are ignored and only size of successfully read data is returned. So, if current task was killed we'll simply return 0 (bytes read). Mmap_sem could be locked for a long time or forever if something goes wrong. Using a killable lock permits cleanup of stuck tasks and simplifies investigation. Link: http://lkml.kernel.org/r/156007494202.3335.16782303099589302087.stgit@buzz Signed-off-by: Konstantin Khlebnikov Reviewed-by: Michal Koutný Acked-by: Oleg Nesterov Acked-by: Michal Hocko Cc: Alexey Dobriyan Cc: Matthew Wilcox Cc: Cyrill Gorcunov Cc: Kirill Tkhai Cc: Al Viro Cc: Roman Gushchin Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit f61d5f5006d9f2954c4b8c644626ec2b982bba71 Author: Yuyang Du Date: Tue Jul 9 18:15:22 2019 +0800 locking/lockdep: Fix lock used or unused stats error [ Upstream commit 68d41d8c94a31dfb8233ab90b9baf41a2ed2da68 ] The stats variable nr_unused_locks is incremented every time a new lock class is register and decremented when the lock is first used in __lock_acquire(). And after all, it is shown and checked in lockdep_stats. However, under configurations that either CONFIG_TRACE_IRQFLAGS or CONFIG_PROVE_LOCKING is not defined: The commit: 091806515124b20 ("locking/lockdep: Consolidate lock usage bit initialization") missed marking the LOCK_USED flag at IRQ usage initialization because as mark_usage() is not called. And the commit: 886532aee3cd42d ("locking/lockdep: Move mark_lock() inside CONFIG_TRACE_IRQFLAGS && CONFIG_PROVE_LOCKING") further made mark_lock() not defined such that the LOCK_USED cannot be marked at all when the lock is first acquired. As a result, we fix this by not showing and checking the stats under such configurations for lockdep_stats. Reported-by: Qian Cai Signed-off-by: Yuyang Du Signed-off-by: Peter Zijlstra (Intel) Cc: Andrew Morton Cc: Linus Torvalds Cc: Paul E. McKenney Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Will Deacon Cc: arnd@arndb.de Cc: frederic@kernel.org Link: https://lkml.kernel.org/r/20190709101522.9117-1-duyuyang@gmail.com Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit 9ddc746cf21bace3adc61eb60fe7ca3b2b59d555 Author: Konstantin Khlebnikov Date: Thu Jul 11 20:59:50 2019 -0700 proc: use down_read_killable mmap_sem for /proc/pid/maps [ Upstream commit 8a713e7df3352b8d9392476e9cf29e4e185dac32 ] Do not remain stuck forever if something goes wrong. Using a killable lock permits cleanup of stuck tasks and simplifies investigation. This function is also used for /proc/pid/smaps. Link: http://lkml.kernel.org/r/156007493160.3335.14447544314127417266.stgit@buzz Signed-off-by: Konstantin Khlebnikov Reviewed-by: Roman Gushchin Reviewed-by: Cyrill Gorcunov Reviewed-by: Kirill Tkhai Acked-by: Michal Hocko Cc: Alexey Dobriyan Cc: Al Viro Cc: Matthew Wilcox Cc: Michal Koutný Cc: Oleg Nesterov Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit ba64866b8b4f9a517a7312a575ab06a84ac3c0bb Author: Arnd Bergmann Date: Fri Jul 12 11:06:33 2019 +0200 cxgb4: reduce kernel stack usage in cudbg_collect_mem_region() [ Upstream commit 752c2ea2d8e7c23b0f64e2e7d4337f3604d44c9f ] The cudbg_collect_mem_region() and cudbg_read_fw_mem() both use several hundred kilobytes of kernel stack space. One gets inlined into the other, which causes the stack usage to be combined beyond the warning limit when building with clang: drivers/net/ethernet/chelsio/cxgb4/cudbg_lib.c:1057:12: error: stack frame size of 1244 bytes in function 'cudbg_collect_mem_region' [-Werror,-Wframe-larger-than=] Restructuring cudbg_collect_mem_region() lets clang do the same optimization that gcc does and reuse the stack slots as it can see that the large variables are never used together. A better fix might be to avoid using cudbg_meminfo on the stack altogether, but that requires a larger rewrite. Fixes: a1c69520f785 ("cxgb4: collect MC memory dump") Signed-off-by: Arnd Bergmann Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 7766ce7e9e1e882779f944904a07fa7880e61d4e Author: Konstantin Khlebnikov Date: Thu Jul 11 21:00:03 2019 -0700 proc: use down_read_killable mmap_sem for /proc/pid/map_files [ Upstream commit cd9e2bb8271c971d9f37c722be2616c7f8ba0664 ] Do not remain stuck forever if something goes wrong. Using a killable lock permits cleanup of stuck tasks and simplifies investigation. It seems ->d_revalidate() could return any error (except ECHILD) to abort validation and pass error as result of lookup sequence. [akpm@linux-foundation.org: fix proc_map_files_lookup() return value, per Andrei] Link: http://lkml.kernel.org/r/156007493995.3335.9595044802115356911.stgit@buzz Signed-off-by: Konstantin Khlebnikov Reviewed-by: Roman Gushchin Reviewed-by: Cyrill Gorcunov Reviewed-by: Kirill Tkhai Acked-by: Michal Hocko Cc: Alexey Dobriyan Cc: Al Viro Cc: Matthew Wilcox Cc: Michal Koutný Cc: Oleg Nesterov Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit e1e84958b11d388586e968dce6f1c65d573c29f0 Author: Konstantin Khlebnikov Date: Thu Jul 11 21:00:00 2019 -0700 proc: use down_read_killable mmap_sem for /proc/pid/clear_refs [ Upstream commit c46038017fbdcac627b670c9d4176f1d0c2f5fa3 ] Do not remain stuck forever if something goes wrong. Using a killable lock permits cleanup of stuck tasks and simplifies investigation. Replace the only unkillable mmap_sem lock in clear_refs_write(). Link: http://lkml.kernel.org/r/156007493826.3335.5424884725467456239.stgit@buzz Signed-off-by: Konstantin Khlebnikov Reviewed-by: Roman Gushchin Reviewed-by: Cyrill Gorcunov Reviewed-by: Kirill Tkhai Acked-by: Michal Hocko Cc: Alexey Dobriyan Cc: Al Viro Cc: Matthew Wilcox Cc: Michal Koutný Cc: Oleg Nesterov Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 69b30136d75be422721d9b223d477c25c8f5f1d5 Author: Konstantin Khlebnikov Date: Thu Jul 11 20:59:56 2019 -0700 proc: use down_read_killable mmap_sem for /proc/pid/pagemap [ Upstream commit ad80b932c57d85fd6377f97f359b025baf179a87 ] Do not remain stuck forever if something goes wrong. Using a killable lock permits cleanup of stuck tasks and simplifies investigation. Link: http://lkml.kernel.org/r/156007493638.3335.4872164955523928492.stgit@buzz Signed-off-by: Konstantin Khlebnikov Reviewed-by: Roman Gushchin Reviewed-by: Cyrill Gorcunov Reviewed-by: Kirill Tkhai Acked-by: Michal Hocko Cc: Alexey Dobriyan Cc: Al Viro Cc: Matthew Wilcox Cc: Michal Koutný Cc: Oleg Nesterov Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit cf30a361a65b9a50251eefd5945c6efd7099a7ec Author: Konstantin Khlebnikov Date: Thu Jul 11 20:59:53 2019 -0700 proc: use down_read_killable mmap_sem for /proc/pid/smaps_rollup [ Upstream commit a26a97815548574213fd37f29b4b78ccc6d9ed20 ] Do not remain stuck forever if something goes wrong. Using a killable lock permits cleanup of stuck tasks and simplifies investigation. Link: http://lkml.kernel.org/r/156007493429.3335.14666825072272692455.stgit@buzz Signed-off-by: Konstantin Khlebnikov Reviewed-by: Roman Gushchin Reviewed-by: Cyrill Gorcunov Reviewed-by: Kirill Tkhai Acked-by: Michal Hocko Cc: Alexey Dobriyan Cc: Al Viro Cc: Matthew Wilcox Cc: Michal Koutný Cc: Oleg Nesterov Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit ba56ef5fc677828fc5bf0d8d9ce393005046b924 Author: Jean-Philippe Brucker Date: Thu Jul 11 20:58:50 2019 -0700 mm/mmu_notifier: use hlist_add_head_rcu() [ Upstream commit 543bdb2d825fe2400d6e951f1786d92139a16931 ] Make mmu_notifier_register() safer by issuing a memory barrier before registering a new notifier. This fixes a theoretical bug on weakly ordered CPUs. For example, take this simplified use of notifiers by a driver: my_struct->mn.ops = &my_ops; /* (1) */ mmu_notifier_register(&my_struct->mn, mm) ... hlist_add_head(&mn->hlist, &mm->mmu_notifiers); /* (2) */ ... Once mmu_notifier_register() releases the mm locks, another thread can invalidate a range: mmu_notifier_invalidate_range() ... hlist_for_each_entry_rcu(mn, &mm->mmu_notifiers, hlist) { if (mn->ops->invalidate_range) The read side relies on the data dependency between mn and ops to ensure that the pointer is properly initialized. But the write side doesn't have any dependency between (1) and (2), so they could be reordered and the readers could dereference an invalid mn->ops. mmu_notifier_register() does take all the mm locks before adding to the hlist, but those have acquire semantics which isn't sufficient. By calling hlist_add_head_rcu() instead of hlist_add_head() we update the hlist using a store-release, ensuring that readers see prior initialization of my_struct. This situation is better illustated by litmus test MP+onceassign+derefonce. Link: http://lkml.kernel.org/r/20190502133532.24981-1-jean-philippe.brucker@arm.com Fixes: cddb8a5c14aa ("mmu-notifiers: core") Signed-off-by: Jean-Philippe Brucker Cc: Jérôme Glisse Cc: Michal Hocko Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit d9428ac0cd216faf7dc266e61c047e81fba99797 Author: Shakeel Butt Date: Thu Jul 11 20:55:52 2019 -0700 memcg, fsnotify: no oom-kill for remote memcg charging [ Upstream commit ec165450968b26298bd1c373de37b0ab6d826b33 ] Commit d46eb14b735b ("fs: fsnotify: account fsnotify metadata to kmemcg") added remote memcg charging for fanotify and inotify event objects. The aim was to charge the memory to the listener who is interested in the events but without triggering the OOM killer. Otherwise there would be security concerns for the listener. At the time, oom-kill trigger was not in the charging path. A parallel work added the oom-kill back to charging path i.e. commit 29ef680ae7c2 ("memcg, oom: move out_of_memory back to the charge path"). So to not trigger oom-killer in the remote memcg, explicitly add __GFP_RETRY_MAYFAIL to the fanotigy and inotify event allocations. Link: http://lkml.kernel.org/r/20190514212259.156585-2-shakeelb@google.com Signed-off-by: Shakeel Butt Reviewed-by: Roman Gushchin Acked-by: Jan Kara Cc: Johannes Weiner Cc: Vladimir Davydov Cc: Michal Hocko Cc: Amir Goldstein Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 0ebe6d4221a190ae56ca547715707f96851b4772 Author: Andy Lutomirski Date: Thu Jul 11 20:57:43 2019 -0700 mm/gup.c: remove some BUG_ONs from get_gate_page() [ Upstream commit b5d1c39f34d1c9bca0c4b9ae2e339fbbe264a9c7 ] If we end up without a PGD or PUD entry backing the gate area, don't BUG -- just fail gracefully. It's not entirely implausible that this could happen some day on x86. It doesn't right now even with an execute-only emulated vsyscall page because the fixmap shares the PUD, but the core mm code shouldn't rely on that particular detail to avoid OOPSing. Link: http://lkml.kernel.org/r/a1d9f4efb75b9d464e59fd6af00104b21c58f6f7.1561610798.git.luto@kernel.org Signed-off-by: Andy Lutomirski Reviewed-by: Kees Cook Reviewed-by: Andrew Morton Cc: Florian Weimer Cc: Jann Horn Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit ffd51eba9112438382acd9850a2bc3f29bb57b65 Author: Guenter Roeck Date: Thu Jul 11 20:57:46 2019 -0700 mm/gup.c: mark undo_dev_pagemap as __maybe_unused [ Upstream commit 790c73690c2bbecb3f6f8becbdb11ddc9bcff8cc ] Several mips builds generate the following build warning. mm/gup.c:1788:13: warning: 'undo_dev_pagemap' defined but not used The function is declared unconditionally but only called from behind various ifdefs. Mark it __maybe_unused. Link: http://lkml.kernel.org/r/1562072523-22311-1-git-send-email-linux@roeck-us.net Signed-off-by: Guenter Roeck Reviewed-by: Andrew Morton Cc: Stephen Rothwell Cc: Robin Murphy Cc: Kirill A. Shutemov Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 8aaa5eef4cff96025180c7e8893dbbe186a9681d Author: Huang Ying Date: Thu Jul 11 20:55:44 2019 -0700 mm/mincore.c: fix race between swapoff and mincore [ Upstream commit aeb309b81c6bada783c3695528a3e10748e97285 ] Via commit 4b3ef9daa4fc ("mm/swap: split swap cache into 64MB trunks"), after swapoff, the address_space associated with the swap device will be freed. So swap_address_space() users which touch the address_space need some kind of mechanism to prevent the address_space from being freed during accessing. When mincore processes an unmapped range for swapped shmem pages, it doesn't hold the lock to prevent swap device from being swapped off. So the following race is possible: CPU1 CPU2 do_mincore() swapoff() walk_page_range() mincore_unmapped_range() __mincore_unmapped_range mincore_page as = swap_address_space() ... exit_swap_address_space() ... kvfree(spaces) find_get_page(as) The address space may be accessed after being freed. To fix the race, get_swap_device()/put_swap_device() is used to enclose find_get_page() to check whether the swap entry is valid and prevent the swap device from being swapoff during accessing. Link: http://lkml.kernel.org/r/20190611020510.28251-1-ying.huang@intel.com Fixes: 4b3ef9daa4fc ("mm/swap: split swap cache into 64MB trunks") Signed-off-by: "Huang, Ying" Reviewed-by: Andrew Morton Acked-by: Michal Hocko Cc: Hugh Dickins Cc: Paul E. McKenney Cc: Minchan Kim Cc: Johannes Weiner Cc: Tim Chen Cc: Mel Gorman Cc: Jérôme Glisse Cc: Andrea Arcangeli Cc: Yang Shi Cc: David Rientjes Cc: Rik van Riel Cc: Jan Kara Cc: Dave Jiang Cc: Daniel Jordan Cc: Andrea Parri Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 04ce274994ea50d60ce6c858441b3484dc6ecc04 Author: Christoph Hellwig Date: Thu Jul 11 20:55:26 2019 -0700 9p: pass the correct prototype to read_cache_page [ Upstream commit f053cbd4366051d7eb6ba1b8d529d20f719c2963 ] Fix the callback 9p passes to read_cache_page to actually have the proper type expected. Casting around function pointers can easily hide typing bugs, and defeats control flow protection. Link: http://lkml.kernel.org/r/20190520055731.24538-5-hch@lst.de Signed-off-by: Christoph Hellwig Reviewed-by: Kees Cook Cc: Sami Tolvanen Cc: Nick Desaulniers Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit d90e2ab5f4b257baf7e5821ca5fef5272ce33971 Author: Dmitry Vyukov Date: Thu Jul 11 20:53:39 2019 -0700 mm/kmemleak.c: fix check for softirq context [ Upstream commit 6ef9056952532c3b746de46aa10d45b4d7797bd8 ] in_softirq() is a wrong predicate to check if we are in a softirq context. It also returns true if we have BH disabled, so objects are falsely stamped with "softirq" comm. The correct predicate is in_serving_softirq(). If user does cat from /sys/kernel/debug/kmemleak previously they would see this, which is clearly wrong, this is system call context (see the comm): unreferenced object 0xffff88805bd661c0 (size 64): comm "softirq", pid 0, jiffies 4294942959 (age 12.400s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 ff ff ff ff 00 00 00 00 ................ 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 ................ backtrace: [<0000000007dcb30c>] kmemleak_alloc_recursive include/linux/kmemleak.h:55 [inline] [<0000000007dcb30c>] slab_post_alloc_hook mm/slab.h:439 [inline] [<0000000007dcb30c>] slab_alloc mm/slab.c:3326 [inline] [<0000000007dcb30c>] kmem_cache_alloc_trace+0x13d/0x280 mm/slab.c:3553 [<00000000969722b7>] kmalloc include/linux/slab.h:547 [inline] [<00000000969722b7>] kzalloc include/linux/slab.h:742 [inline] [<00000000969722b7>] ip_mc_add1_src net/ipv4/igmp.c:1961 [inline] [<00000000969722b7>] ip_mc_add_src+0x36b/0x400 net/ipv4/igmp.c:2085 [<00000000a4134b5f>] ip_mc_msfilter+0x22d/0x310 net/ipv4/igmp.c:2475 [<00000000d20248ad>] do_ip_setsockopt.isra.0+0x19fe/0x1c00 net/ipv4/ip_sockglue.c:957 [<000000003d367be7>] ip_setsockopt+0x3b/0xb0 net/ipv4/ip_sockglue.c:1246 [<000000003c7c76af>] udp_setsockopt+0x4e/0x90 net/ipv4/udp.c:2616 [<000000000c1aeb23>] sock_common_setsockopt+0x3e/0x50 net/core/sock.c:3130 [<000000000157b92b>] __sys_setsockopt+0x9e/0x120 net/socket.c:2078 [<00000000a9f3d058>] __do_sys_setsockopt net/socket.c:2089 [inline] [<00000000a9f3d058>] __se_sys_setsockopt net/socket.c:2086 [inline] [<00000000a9f3d058>] __x64_sys_setsockopt+0x26/0x30 net/socket.c:2086 [<000000001b8da885>] do_syscall_64+0x7c/0x1a0 arch/x86/entry/common.c:301 [<00000000ba770c62>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 now they will see this: unreferenced object 0xffff88805413c800 (size 64): comm "syz-executor.4", pid 8960, jiffies 4294994003 (age 14.350s) hex dump (first 32 bytes): 00 7a 8a 57 80 88 ff ff e0 00 00 01 00 00 00 00 .z.W............ 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 ................ backtrace: [<00000000c5d3be64>] kmemleak_alloc_recursive include/linux/kmemleak.h:55 [inline] [<00000000c5d3be64>] slab_post_alloc_hook mm/slab.h:439 [inline] [<00000000c5d3be64>] slab_alloc mm/slab.c:3326 [inline] [<00000000c5d3be64>] kmem_cache_alloc_trace+0x13d/0x280 mm/slab.c:3553 [<0000000023865be2>] kmalloc include/linux/slab.h:547 [inline] [<0000000023865be2>] kzalloc include/linux/slab.h:742 [inline] [<0000000023865be2>] ip_mc_add1_src net/ipv4/igmp.c:1961 [inline] [<0000000023865be2>] ip_mc_add_src+0x36b/0x400 net/ipv4/igmp.c:2085 [<000000003029a9d4>] ip_mc_msfilter+0x22d/0x310 net/ipv4/igmp.c:2475 [<00000000ccd0a87c>] do_ip_setsockopt.isra.0+0x19fe/0x1c00 net/ipv4/ip_sockglue.c:957 [<00000000a85a3785>] ip_setsockopt+0x3b/0xb0 net/ipv4/ip_sockglue.c:1246 [<00000000ec13c18d>] udp_setsockopt+0x4e/0x90 net/ipv4/udp.c:2616 [<0000000052d748e3>] sock_common_setsockopt+0x3e/0x50 net/core/sock.c:3130 [<00000000512f1014>] __sys_setsockopt+0x9e/0x120 net/socket.c:2078 [<00000000181758bc>] __do_sys_setsockopt net/socket.c:2089 [inline] [<00000000181758bc>] __se_sys_setsockopt net/socket.c:2086 [inline] [<00000000181758bc>] __x64_sys_setsockopt+0x26/0x30 net/socket.c:2086 [<00000000d4b73623>] do_syscall_64+0x7c/0x1a0 arch/x86/entry/common.c:301 [<00000000c1098bec>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 Link: http://lkml.kernel.org/r/20190517171507.96046-1-dvyukov@gmail.com Signed-off-by: Dmitry Vyukov Acked-by: Catalin Marinas Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 109460c0c7932b2792925e30427266a78e24b1cb Author: Sam Ravnborg Date: Thu Jul 11 20:52:52 2019 -0700 sh: prevent warnings when using iounmap [ Upstream commit 733f0025f0fb43e382b84db0930ae502099b7e62 ] When building drm/exynos for sh, as part of an allmodconfig build, the following warning triggered: exynos7_drm_decon.c: In function `decon_remove': exynos7_drm_decon.c:769:24: warning: unused variable `ctx' struct decon_context *ctx = dev_get_drvdata(&pdev->dev); The ctx variable is only used as argument to iounmap(). In sh - allmodconfig CONFIG_MMU is not defined so it ended up in: \#define __iounmap(addr) do { } while (0) \#define iounmap __iounmap Fix the warning by introducing a static inline function for iounmap. This is similar to several other architectures. Link: http://lkml.kernel.org/r/20190622114208.24427-1-sam@ravnborg.org Signed-off-by: Sam Ravnborg Reviewed-by: Geert Uytterhoeven Cc: Yoshinori Sato Cc: Rich Felker Cc: Will Deacon Cc: Mark Brown Cc: Inki Dae Cc: Krzysztof Kozlowski Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 182141b212149daf988569de95f750c4a57a2cda Author: Minwoo Im Date: Fri Jul 12 02:04:47 2019 +0900 nvme: fix NULL deref for fabrics options [ Upstream commit 7d30c81b80ea9b0812d27030a46a5bf4c4e328f5 ] git://git.infradead.org/nvme.git nvme-5.3 branch now causes the following NULL deref oops. Check the ctrl->opts first before the deref. [ 16.337581] BUG: kernel NULL pointer dereference, address: 0000000000000056 [ 16.338551] #PF: supervisor read access in kernel mode [ 16.338551] #PF: error_code(0x0000) - not-present page [ 16.338551] PGD 0 P4D 0 [ 16.338551] Oops: 0000 [#1] SMP PTI [ 16.338551] CPU: 2 PID: 1035 Comm: kworker/u16:5 Not tainted 5.2.0-rc6+ #1 [ 16.338551] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.11.2-0-gf9626ccb91-prebuilt.qemu-project.org 04/01/2014 [ 16.338551] Workqueue: nvme-wq nvme_scan_work [nvme_core] [ 16.338551] RIP: 0010:nvme_validate_ns+0xc9/0x7e0 [nvme_core] [ 16.338551] Code: c0 49 89 c5 0f 84 00 07 00 00 48 8b 7b 58 e8 be 48 39 c1 48 3d 00 f0 ff ff 49 89 45 18 0f 87 a4 06 00 00 48 8b 93 70 0a 00 00 <80> 7a 56 00 74 0c 48 8b 40 68 83 48 3c 08 49 8b 45 18 48 89 c6 bf [ 16.338551] RSP: 0018:ffffc900024c7d10 EFLAGS: 00010283 [ 16.338551] RAX: ffff888135a30720 RBX: ffff88813a4fd1f8 RCX: 0000000000000007 [ 16.338551] RDX: 0000000000000000 RSI: ffffffff8256dd38 RDI: ffff888135a30720 [ 16.338551] RBP: 0000000000000001 R08: 0000000000000007 R09: ffff88813aa6a840 [ 16.338551] R10: 0000000000000001 R11: 000000000002d060 R12: ffff88813a4fd1f8 [ 16.338551] R13: ffff88813a77f800 R14: ffff88813aa35180 R15: 0000000000000001 [ 16.338551] FS: 0000000000000000(0000) GS:ffff88813ba80000(0000) knlGS:0000000000000000 [ 16.338551] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 16.338551] CR2: 0000000000000056 CR3: 000000000240a002 CR4: 0000000000360ee0 [ 16.338551] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 16.338551] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 16.338551] Call Trace: [ 16.338551] nvme_scan_work+0x2c0/0x340 [nvme_core] [ 16.338551] ? __switch_to_asm+0x40/0x70 [ 16.338551] ? _raw_spin_unlock_irqrestore+0x18/0x30 [ 16.338551] ? try_to_wake_up+0x408/0x450 [ 16.338551] process_one_work+0x20b/0x3e0 [ 16.338551] worker_thread+0x1f9/0x3d0 [ 16.338551] ? cancel_delayed_work+0xa0/0xa0 [ 16.338551] kthread+0x117/0x120 [ 16.338551] ? kthread_stop+0xf0/0xf0 [ 16.338551] ret_from_fork+0x3a/0x50 [ 16.338551] Modules linked in: nvme nvme_core [ 16.338551] CR2: 0000000000000056 [ 16.338551] ---[ end trace b9bf761a93e62d84 ]--- [ 16.338551] RIP: 0010:nvme_validate_ns+0xc9/0x7e0 [nvme_core] [ 16.338551] Code: c0 49 89 c5 0f 84 00 07 00 00 48 8b 7b 58 e8 be 48 39 c1 48 3d 00 f0 ff ff 49 89 45 18 0f 87 a4 06 00 00 48 8b 93 70 0a 00 00 <80> 7a 56 00 74 0c 48 8b 40 68 83 48 3c 08 49 8b 45 18 48 89 c6 bf [ 16.338551] RSP: 0018:ffffc900024c7d10 EFLAGS: 00010283 [ 16.338551] RAX: ffff888135a30720 RBX: ffff88813a4fd1f8 RCX: 0000000000000007 [ 16.338551] RDX: 0000000000000000 RSI: ffffffff8256dd38 RDI: ffff888135a30720 [ 16.338551] RBP: 0000000000000001 R08: 0000000000000007 R09: ffff88813aa6a840 [ 16.338551] R10: 0000000000000001 R11: 000000000002d060 R12: ffff88813a4fd1f8 [ 16.338551] R13: ffff88813a77f800 R14: ffff88813aa35180 R15: 0000000000000001 [ 16.338551] FS: 0000000000000000(0000) GS:ffff88813ba80000(0000) knlGS:0000000000000000 [ 16.338551] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 16.338551] CR2: 0000000000000056 CR3: 000000000240a002 CR4: 0000000000360ee0 [ 16.338551] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 16.338551] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Fixes: 958f2a0f8121 ("nvme-tcp: set the STABLE_WRITES flag when data digests are enabled") Cc: Christoph Hellwig Cc: Keith Busch Reviewed-by: Sagi Grimberg Signed-off-by: Minwoo Im Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit e9094b6117362ff8b020f26cff02d67bf30112d0 Author: Wenwen Wang Date: Thu Jul 11 14:22:02 2019 -0500 block/bio-integrity: fix a memory leak bug [ Upstream commit e7bf90e5afe3aa1d1282c1635a49e17a32c4ecec ] In bio_integrity_prep(), a kernel buffer is allocated through kmalloc() to hold integrity metadata. Later on, the buffer will be attached to the bio structure through bio_integrity_add_page(), which returns the number of bytes of integrity metadata attached. Due to unexpected situations, bio_integrity_add_page() may return 0. As a result, bio_integrity_prep() needs to be terminated with 'false' returned to indicate this error. However, the allocated kernel buffer is not freed on this execution path, leading to a memory leak. To fix this issue, free the allocated buffer before returning from bio_integrity_prep(). Reviewed-by: Ming Lei Acked-by: Martin K. Petersen Signed-off-by: Wenwen Wang Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit cdc73257a41a85b34db158c136f602ea71eaea74 Author: YueHaibing Date: Thu Jul 4 14:27:25 2019 +0800 platform/x86: Fix PCENGINES_APU2 Kconfig warning [ Upstream commit 7d67c8ac25fbc66ee254aa3e33329d1c9bc152ce ] Fix Kconfig warning for PCENGINES_APU2 symbol: WARNING: unmet direct dependencies detected for GPIO_AMD_FCH Depends on [n]: GPIOLIB [=n] && HAS_IOMEM [=y] Selected by [y]: - PCENGINES_APU2 [=y] && X86 [=y] && X86_PLATFORM_DEVICES [=y] && INPUT [=y] && INPUT_KEYBOARD [=y] && LEDS_CLASS [=y] WARNING: unmet direct dependencies detected for KEYBOARD_GPIO_POLLED Depends on [n]: !UML && INPUT [=y] && INPUT_KEYBOARD [=y] && GPIOLIB [=n] Selected by [y]: - PCENGINES_APU2 [=y] && X86 [=y] && X86_PLATFORM_DEVICES [=y] && INPUT [=y] && INPUT_KEYBOARD [=y] && LEDS_CLASS [=y] Add GPIOLIB dependency to fix it. Reported-by: Hulk Robot Fixes: f8eb0235f659 ("x86: pcengines apuv2 gpio/leds/keys platform driver") Signed-off-by: YueHaibing Signed-off-by: Andy Shevchenko Signed-off-by: Sasha Levin commit 3916be4f0bdc1829c7d48c1bb13aeb32292a2238 Author: Oliver O'Halloran Date: Thu Jul 11 01:05:17 2019 +1000 powerpc/eeh: Handle hugepages in ioremap space [ Upstream commit 33439620680be5225c1b8806579a291e0d761ca0 ] In commit 4a7b06c157a2 ("powerpc/eeh: Handle hugepages in ioremap space") support for using hugepages in the vmalloc and ioremap areas was enabled for radix. Unfortunately this broke EEH MMIO error checking. Detection works by inserting a hook which checks the results of the ioreadXX() set of functions. When a read returns a 0xFFs response we need to check for an error which we do by mapping the (virtual) MMIO address back to a physical address, then mapping physical address to a PCI device via an interval tree. When translating virt -> phys we currently assume the ioremap space is only populated by PAGE_SIZE mappings. If a hugepage mapping is found we emit a WARN_ON(), but otherwise handles the check as though a normal page was found. In pathalogical cases such as copying a buffer containing a lot of 0xFFs from BAR memory this can result in the system not booting because it's too busy printing WARN_ON()s. There's no real reason to assume huge pages can't be present and we're prefectly capable of handling them, so do that. Fixes: 4a7b06c157a2 ("powerpc/eeh: Handle hugepages in ioremap space") Reported-by: Sachin Sant Signed-off-by: Oliver O'Halloran Tested-by: Sachin Sant Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20190710150517.27114-1-oohall@gmail.com Signed-off-by: Sasha Levin commit 7f6367122bb6caa485968316b86e014089a47f70 Author: David Windsor Date: Tue Apr 2 08:37:10 2019 -0400 dlm: check if workqueues are NULL before flushing/destroying [ Upstream commit b355516f450703c9015316e429b66a93dfff0e6f ] If the DLM lowcomms stack is shut down before any DLM traffic can be generated, flush_workqueue() and destroy_workqueue() can be called on empty send and/or recv workqueues. Insert guard conditionals to only call flush_workqueue() and destroy_workqueue() on workqueues that are not NULL. Signed-off-by: David Windsor Signed-off-by: David Teigland Signed-off-by: Sasha Levin commit fca30d485c6f38fdf2e95663fceb6e558c90452b Author: morten petersen Date: Mon Jul 8 11:41:54 2019 +0000 mailbox: handle failed named mailbox channel request [ Upstream commit 25777e5784a7b417967460d4fcf9660d05a0c320 ] Previously, if mbox_request_channel_byname was used with a name which did not exist in the "mbox-names" property of a mailbox client, the mailbox corresponding to the last entry in the "mbox-names" list would be incorrectly selected. With this patch, -EINVAL is returned if the named mailbox is not found. Signed-off-by: Morten Borup Petersen Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit 171fc85b0933cfe82576e3073e7773f66045e113 Author: Ocean Chen Date: Mon Jul 8 12:34:56 2019 +0800 f2fs: avoid out-of-range memory access [ Upstream commit 56f3ce675103e3fb9e631cfb4131fc768bc23e9a ] blkoff_off might over 512 due to fs corrupt or security vulnerability. That should be checked before being using. Use ENTRIES_IN_SUM to protect invalid value in cur_data_blkoff. Signed-off-by: Ocean Chen Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit afa4990b08d0f4e1d7701ede5954dedaf6a63541 Author: Heng Xiao Date: Wed Jul 3 10:29:57 2019 +0800 f2fs: fix to avoid long latency during umount [ Upstream commit 6e0cd4a9dd4df1a0afcb454f1e654b5c80685913 ] In umount, we give an constand time to handle pending discard, previously, in __issue_discard_cmd() we missed to check timeout condition in loop, result in delaying long time, fix it. Signed-off-by: Heng Xiao [Chao Yu: add commit message] Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 9dd7d2cdef1457cf67d02667c1b907b51f21912c Author: Gerd Rausch Date: Thu Jun 27 09:21:44 2019 -0700 rds: Accept peer connection reject messages due to incompatible version [ Upstream commit 8c6166cfc9cd48e93d9176561e50b63cef4330d5 ] Prior to commit d021fabf525ff ("rds: rdma: add consumer reject") function "rds_rdma_cm_event_handler_cmn" would always honor a rejected connection attempt by issuing a "rds_conn_drop". The commit mentioned above added a "break", eliminating the "fallthrough" case and made the "rds_conn_drop" rather conditional: Now it only happens if a "consumer defined" reject (i.e. "rdma_reject") carries an integer-value of "1" inside "private_data": if (!conn) break; err = (int *)rdma_consumer_reject_data(cm_id, event, &len); if (!err || (err && ((*err) == RDS_RDMA_REJ_INCOMPAT))) { pr_warn("RDS/RDMA: conn <%pI6c, %pI6c> rejected, dropping connection\n", &conn->c_laddr, &conn->c_faddr); conn->c_proposed_version = RDS_PROTOCOL_COMPAT_VERSION; rds_conn_drop(conn); } rdsdebug("Connection rejected: %s\n", rdma_reject_msg(cm_id, event->status)); break; /* FALLTHROUGH */ A number of issues are worth mentioning here: #1) Previous versions of the RDS code simply rejected a connection by calling "rdma_reject(cm_id, NULL, 0);" So the value of the payload in "private_data" will not be "1", but "0". #2) Now the code has become dependent on host byte order and sizing. If one peer is big-endian, the other is little-endian, or there's a difference in sizeof(int) (e.g. ILP64 vs LP64), the *err check does not work as intended. #3) There is no check for "len" to see if the data behind *err is even valid. Luckily, it appears that the "rdma_reject(cm_id, NULL, 0)" will always carry 148 bytes of zeroized payload. But that should probably not be relied upon here. #4) With the added "break;", we might as well drop the misleading "/* FALLTHROUGH */" comment. This commit does _not_ address issue #2, as the sender would have to agree on a byte order as well. Here is the sequence of messages in this observed error-scenario: Host-A is pre-QoS changes (excluding the commit mentioned above) Host-B is post-QoS changes (including the commit mentioned above) #1 Host-B issues a connection request via function "rds_conn_path_transition" connection state transitions to "RDS_CONN_CONNECTING" #2 Host-A rejects the incompatible connection request (from #1) It does so by calling "rdma_reject(cm_id, NULL, 0);" #3 Host-B receives an "RDMA_CM_EVENT_REJECTED" event (from #2) But since the code is changed in the way described above, it won't drop the connection here, simply because "*err == 0". #4 Host-A issues a connection request #5 Host-B receives an "RDMA_CM_EVENT_CONNECT_REQUEST" event and ends up calling "rds_ib_cm_handle_connect". But since the state is already in "RDS_CONN_CONNECTING" (as of #1) it will end up issuing a "rdma_reject" without dropping the connection: if (rds_conn_state(conn) == RDS_CONN_CONNECTING) { /* Wait and see - our connect may still be succeeding */ rds_ib_stats_inc(s_ib_connect_raced); } goto out; #6 Host-A receives an "RDMA_CM_EVENT_REJECTED" event (from #5), drops the connection and tries again (goto #4) until it gives up. Tested-by: Zhu Yanjun Signed-off-by: Gerd Rausch Signed-off-by: Santosh Shilimkar Signed-off-by: Sasha Levin commit 65dfe3fafd1ce222e68b7821cae5bbc928aeb199 Author: Josef Bacik Date: Thu Mar 7 21:37:18 2019 +0000 block: init flush rq ref count to 1 [ Upstream commit b554db147feea39617b533ab6bca247c91c6198a ] We discovered a problem in newer kernels where a disconnect of a NBD device while the flush request was pending would result in a hang. This is because the blk mq timeout handler does if (!refcount_inc_not_zero(&rq->ref)) return true; to determine if it's ok to run the timeout handler for the request. Flush_rq's don't have a ref count set, so we'd skip running the timeout handler for this request and it would just sit there in limbo forever. Fix this by always setting the refcount of any request going through blk_init_rq() to 1. I tested this with a nbd-server that dropped flush requests to verify that it hung, and then tested with this patch to verify I got the timeout as expected and the error handling kicked in. Thanks, Signed-off-by: Josef Bacik Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 14deb9df67c3544cc6a975dd0e3d2a88d3333085 Author: Masahiro Yamada Date: Fri Jul 5 19:01:43 2019 +0900 powerpc/boot: add {get, put}_unaligned_be32 to xz_config.h [ Upstream commit 9e005b761e7ad153dcf40a6cba1d681fe0830ac6 ] The next commit will make the way of passing CONFIG options more robust. Unfortunately, it would uncover another hidden issue; without this commit, skiroot_defconfig would be broken like this: | WRAP arch/powerpc/boot/zImage.pseries | arch/powerpc/boot/wrapper.a(decompress.o): In function `bcj_powerpc.isra.10': | decompress.c:(.text+0x720): undefined reference to `get_unaligned_be32' | decompress.c:(.text+0x7a8): undefined reference to `put_unaligned_be32' | make[1]: *** [arch/powerpc/boot/Makefile;383: arch/powerpc/boot/zImage.pseries] Error 1 | make: *** [arch/powerpc/Makefile;295: zImage] Error 2 skiroot_defconfig is the only defconfig that enables CONFIG_KERNEL_XZ for ppc, which has never been correctly built before. I figured out the root cause in lib/decompress_unxz.c: | #ifdef CONFIG_PPC | # define XZ_DEC_POWERPC | #endif CONFIG_PPC is undefined here in the ppc bootwrapper because autoconf.h is not included except by arch/powerpc/boot/serial.c XZ_DEC_POWERPC is not defined, therefore, bcj_powerpc() is not compiled for the bootwrapper. With the next commit passing CONFIG_PPC correctly, we would realize that {get,put}_unaligned_be32 was missing. Unlike the other decompressors, the ppc bootwrapper duplicates all the necessary helpers in arch/powerpc/boot/. The other architectures define __KERNEL__ and pull in helpers for building the decompressors. If ppc bootwrapper had defined __KERNEL__, lib/xz/xz_private.h would have included : | #ifdef __KERNEL__ | # include | # include | # include However, doing so would cause tons of definition conflicts since the bootwrapper has duplicated everything. I just added copies of {get,put}_unaligned_be32, following the bootwrapper coding convention. Signed-off-by: Masahiro Yamada Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20190705100144.28785-1-yamada.masahiro@socionext.com Signed-off-by: Sasha Levin commit 6c63d45e473fdc3a26c63e1f6a321181b5e094eb Author: Michael Ellerman Date: Mon Jul 8 16:02:19 2019 +1000 powerpc/irq: Don't WARN continuously in arch_local_irq_restore() [ Upstream commit 0fc12c022ad25532b66bf6f6c818ee1c1d63e702 ] When CONFIG_PPC_IRQ_SOFT_MASK_DEBUG is enabled (uncommon), we have a series of WARN_ON's in arch_local_irq_restore(). These are "should never happen" conditions, but if they do happen they can flood the console and render the system unusable. So switch them to WARN_ON_ONCE(). Fixes: e2b36d591720 ("powerpc/64: Don't trace code that runs with the soft irq mask unreconciled") Fixes: 9b81c0211c24 ("powerpc/64s: make PACA_IRQ_HARD_DIS track MSR[EE] closely") Fixes: 7c0482e3d055 ("powerpc/irq: Fix another case of lazy IRQ state getting out of sync") Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20190708061046.7075-1-mpe@ellerman.id.au Signed-off-by: Sasha Levin commit 74da3cda61724e7744d1e315409d1f61e62adb4a Author: Mikhail Skorzhinskii Date: Thu Jul 4 09:59:18 2019 +0200 nvme-tcp: set the STABLE_WRITES flag when data digests are enabled [ Upstream commit 958f2a0f8121ae36a5cbff383ab94fadf1fba5eb ] There was a few false alarms sighted on target side about wrong data digest while performing high throughput load to XFS filesystem shared through NVMoF TCP. This flag tells the rest of the kernel to ensure that the data buffer does not change while the write is in flight. It incurs a performance penalty, so only enable it when it is actually needed, i.e. when we are calculating data digests. Although even with this change in place, ext2 users can steel experience false positives, as ext2 is not respecting this flag. This may be apply to vfat as well. Signed-off-by: Mikhail Skorzhinskii Signed-off-by: Mike Playle Reviewed-by: Sagi Grimberg Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 552d0f52c22d393ec0898a33691a0f902b7eb37c Author: Jackie Liu Date: Mon Jul 8 13:41:12 2019 +0800 io_uring: fix io_sq_thread_stop running in front of io_sq_thread [ Upstream commit a4c0b3decb33fb4a2b5ecc6234a50680f0b21e7d ] INFO: task syz-executor.5:8634 blocked for more than 143 seconds. Not tainted 5.2.0-rc5+ #3 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. syz-executor.5 D25632 8634 8224 0x00004004 Call Trace: context_switch kernel/sched/core.c:2818 [inline] __schedule+0x658/0x9e0 kernel/sched/core.c:3445 schedule+0x131/0x1d0 kernel/sched/core.c:3509 schedule_timeout+0x9a/0x2b0 kernel/time/timer.c:1783 do_wait_for_common+0x35e/0x5a0 kernel/sched/completion.c:83 __wait_for_common kernel/sched/completion.c:104 [inline] wait_for_common kernel/sched/completion.c:115 [inline] wait_for_completion+0x47/0x60 kernel/sched/completion.c:136 kthread_stop+0xb4/0x150 kernel/kthread.c:559 io_sq_thread_stop fs/io_uring.c:2252 [inline] io_finish_async fs/io_uring.c:2259 [inline] io_ring_ctx_free fs/io_uring.c:2770 [inline] io_ring_ctx_wait_and_kill+0x268/0x880 fs/io_uring.c:2834 io_uring_release+0x5d/0x70 fs/io_uring.c:2842 __fput+0x2e4/0x740 fs/file_table.c:280 ____fput+0x15/0x20 fs/file_table.c:313 task_work_run+0x17e/0x1b0 kernel/task_work.c:113 tracehook_notify_resume include/linux/tracehook.h:185 [inline] exit_to_usermode_loop arch/x86/entry/common.c:168 [inline] prepare_exit_to_usermode+0x402/0x4f0 arch/x86/entry/common.c:199 syscall_return_slowpath+0x110/0x440 arch/x86/entry/common.c:279 do_syscall_64+0x126/0x140 arch/x86/entry/common.c:304 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x412fb1 Code: 80 3b 7c 0f 84 c7 02 00 00 c7 85 d0 00 00 00 00 00 00 00 48 8b 05 cf a6 24 00 49 8b 14 24 41 b9 cb 2a 44 00 48 89 ee 48 89 df <48> 85 c0 4c 0f 45 c8 45 31 c0 31 c9 e8 0e 5b 00 00 85 c0 41 89 c7 RSP: 002b:00007ffe7ee6a180 EFLAGS: 00000293 ORIG_RAX: 0000000000000003 RAX: 0000000000000000 RBX: 0000000000000004 RCX: 0000000000412fb1 RDX: 0000001b2d920000 RSI: 0000000000000000 RDI: 0000000000000003 RBP: 0000000000000001 R08: 00000000f3a3e1f8 R09: 00000000f3a3e1fc R10: 00007ffe7ee6a260 R11: 0000000000000293 R12: 000000000075c9a0 R13: 000000000075c9a0 R14: 0000000000024c00 R15: 000000000075bf2c ============================================= There is an wrong logic, when kthread_park running in front of io_sq_thread. CPU#0 CPU#1 io_sq_thread_stop: int kthread(void *_create): kthread_park() __kthread_parkme(self); <<< Wrong kthread_stop() << wait for self->exited << clear_bit KTHREAD_SHOULD_PARK ret = threadfn(data); | |- io_sq_thread |- kthread_should_park() << false |- schedule() <<< nobody wake up stuck CPU#0 stuck CPU#1 So, use a new variable sqo_thread_started to ensure that io_sq_thread run first, then io_sq_thread_stop. Reported-by: syzbot+94324416c485d422fe15@syzkaller.appspotmail.com Suggested-by: Jens Axboe Signed-off-by: Jackie Liu Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 68a96697dacb48f4f9196c9279f7622957be4801 Author: Mikhail Skorzhinskii Date: Mon Jul 8 12:31:29 2019 +0200 nvme-tcp: don't use sendpage for SLAB pages [ Upstream commit 37c15219599f7a4baa73f6e3432afc69ba7cc530 ] According to commit a10674bf2406 ("tcp: detecting the misuse of .sendpage for Slab objects") and previous discussion, tcp_sendpage should not be used for pages that is managed by SLAB, as SLAB is not taking page reference counters into consideration. Signed-off-by: Mikhail Skorzhinskii Reviewed-by: Sagi Grimberg Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 63e6e5bfa0eb039d171d9ea3546ed586ddd42345 Author: Christoph Hellwig Date: Wed Jul 3 09:54:44 2019 -0700 nvme-pci: limit max_hw_sectors based on the DMA max mapping size [ Upstream commit 7637de311bd2124b298a072852448b940d8a34b9 ] When running a NVMe device that is attached to a addressing challenged PCIe root port that requires bounce buffering, our request sizes can easily overflow the swiotlb bounce buffer size. Limit the maximum I/O size to the limit exposed by the DMA mapping subsystem. Signed-off-by: Christoph Hellwig Reported-by: Atish Patra Tested-by: Atish Patra Reviewed-by: Sagi Grimberg Signed-off-by: Sasha Levin commit 37c3c50d46eca40ae635750d5cd9a2d36e1a60df Author: Alan Mikhak Date: Mon Jul 8 10:05:11 2019 -0700 nvme-pci: check for NULL return from pci_alloc_p2pmem() [ Upstream commit bfac8e9f55cf62a000b643a0081488badbe92d96 ] Modify nvme_alloc_sq_cmds() to call pci_free_p2pmem() to free the memory it allocated using pci_alloc_p2pmem() in case pci_p2pmem_virt_to_bus() returns null. Makes sure not to call pci_free_p2pmem() if pci_alloc_p2pmem() returned NULL, which can happen if CONFIG_PCI_P2PDMA is not configured. The current implementation is not expected to leak since pci_p2pmem_virt_to_bus() is expected to fail only if pci_alloc_p2pmem() returns null. However, checking the return value of pci_alloc_p2pmem() is more explicit. Signed-off-by: Alan Mikhak Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 16c2bdf840b0837d40547e6a9cd2d848708f2754 Author: Dag Moxnes Date: Tue Jul 9 13:50:26 2019 +0200 RDMA/core: Fix race when resolving IP address [ Upstream commit d8d9ec7dc5abbb3f11d866e983c4984f5c2de9d6 ] Use the neighbour lock when copying the MAC address from the neighbour data struct in dst_fetch_ha. When not using the lock, it is possible for the function to race with neigh_update(), causing it to copy an torn MAC address: rdma_resolve_addr() rdma_resolve_ip() addr_resolve() addr_resolve_neigh() fetch_ha() dst_fetch_ha() memcpy(dev_addr->dst_dev_addr, n->ha, MAX_ADDR_LEN) and net_ioctl() arp_ioctl() arp_rec_delete() arp_invalidate() neigh_update() __neigh_update() memcpy(&neigh->ha, lladdr, dev->addr_len) It is possible to provoke this error by calling rdma_resolve_addr() in a tight loop, while deleting the corresponding ARP entry in another tight loop. Fixes: 51d45974515c ("infiniband: addr: Consolidate code to fetch neighbour hardware address from dst.") Signed-off-by: Dag Moxnes Signed-off-by: Håkon Bugge Reviewed-by: Jason Gunthorpe Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit f5ae4c3fd3b8facd1fd2286c7e2b6c11e66dfb50 Author: Leo Yan Date: Mon Jul 8 22:39:35 2019 +0800 perf intel-bts: Fix potential NULL pointer dereference found by the smatch tool [ Upstream commit 1d481458816d9424c8a05833ce0ebe72194a350e ] Based on the following report from Smatch, fix the potential NULL pointer dereference check. tools/perf/util/intel-bts.c:898 intel_bts_process_auxtrace_info() error: we previously assumed 'session->itrace_synth_opts' could be null (see line 894) tools/perf/util/intel-bts.c:899 intel_bts_process_auxtrace_info() warn: variable dereferenced before check 'session->itrace_synth_opts' (see line 898) tools/perf/util/intel-bts.c 894 if (session->itrace_synth_opts && session->itrace_synth_opts->set) { 895 bts->synth_opts = *session->itrace_synth_opts; 896 } else { 897 itrace_synth_opts__set_default(&bts->synth_opts, 898 session->itrace_synth_opts->default_no_sample); ^^^^^^^^^^^^^^^^^^^^^^^^^^ 899 if (session->itrace_synth_opts) ^^^^^^^^^^^^^^^^^^^^^^^^^^ 900 bts->synth_opts.thread_stack = 901 session->itrace_synth_opts->thread_stack; 902 } 'session->itrace_synth_opts' is impossible to be a NULL pointer in intel_bts_process_auxtrace_info(), thus this patch removes the NULL test for 'session->itrace_synth_opts'. Signed-off-by: Leo Yan Acked-by: Adrian Hunter Cc: Alexander Shishkin Cc: Andi Kleen Cc: Jiri Olsa Cc: Mathieu Poirier Cc: Namhyung Kim Cc: Suzuki Poulouse Cc: linux-arm-kernel@lists.infradead.org Link: http://lkml.kernel.org/r/20190708143937.7722-3-leo.yan@linaro.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 145aecd0c33402cb61b9d9a155000cd4646c908d Author: YueHaibing Date: Fri Jun 14 23:40:44 2019 +0800 PCI: dwc: pci-dra7xx: Fix compilation when !CONFIG_GPIOLIB [ Upstream commit 381ed79c8655a40268ee7391f716edd90c5c3a97 ] If CONFIG_GPIOLIB is not selected the compilation results in the following build errors: drivers/pci/controller/dwc/pci-dra7xx.c: In function dra7xx_pcie_probe: drivers/pci/controller/dwc/pci-dra7xx.c:777:10: error: implicit declaration of function devm_gpiod_get_optional; did you mean devm_regulator_get_optional? [-Werror=implicit-function-declaration] reset = devm_gpiod_get_optional(dev, NULL, GPIOD_OUT_HIGH); drivers/pci/controller/dwc/pci-dra7xx.c:778:45: error: ‘GPIOD_OUT_HIGH’ undeclared (first use in this function); did you mean ‘GPIOF_INIT_HIGH’? reset = devm_gpiod_get_optional(dev, NULL, GPIOD_OUT_HIGH); ^~~~~~~~~~~~~~ GPIOF_INIT_HIGH Fix them by including the appropriate header file. Reported-by: Hulk Robot Signed-off-by: YueHaibing [lorenzo.pieralisi@arm.com: commit log] Signed-off-by: Lorenzo Pieralisi Acked-by: Kishon Vijay Abraham I Signed-off-by: Sasha Levin commit 3cce892efc71913b724c341d6f66f610aaa24ba4 Author: Konstantin Taranov Date: Thu Jun 27 16:06:43 2019 +0200 RDMA/rxe: Fill in wc byte_len with IB_WC_RECV_RDMA_WITH_IMM [ Upstream commit bdce1290493caa3f8119f24b5dacc3fb7ca27389 ] Calculate the correct byte_len on the receiving side when a work completion is generated with IB_WC_RECV_RDMA_WITH_IMM opcode. According to the IBA byte_len must indicate the number of written bytes, whereas it was always equal to zero for the IB_WC_RECV_RDMA_WITH_IMM opcode, even though data was transferred. Fixes: 8700e3e7c485 ("Soft RoCE driver") Signed-off-by: Konstantin Taranov Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 342aed7dd4e62fbf92df3ffa971cfba90da169e5 Author: Leo Yan Date: Mon Jul 8 22:39:34 2019 +0800 perf hists browser: Fix potential NULL pointer dereference found by the smatch tool [ Upstream commit ceb75476db1617a88cc29b09839acacb69aa076e ] Based on the following report from Smatch, fix the potential NULL pointer dereference check. tools/perf/ui/browsers/hists.c:641 hist_browser__run() error: we previously assumed 'hbt' could be null (see line 625) tools/perf/ui/browsers/hists.c:3088 perf_evsel__hists_browse() error: we previously assumed 'browser->he_selection' could be null (see line 2902) tools/perf/ui/browsers/hists.c:3272 perf_evsel_menu__run() error: we previously assumed 'hbt' could be null (see line 3260) This patch firstly validating the pointers before access them, so can fix potential NULL pointer dereference. Signed-off-by: Leo Yan Acked-by: Jiri Olsa Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Andi Kleen Cc: Mathieu Poirier Cc: Namhyung Kim Cc: Suzuki Poulouse Cc: linux-arm-kernel@lists.infradead.org Link: http://lkml.kernel.org/r/20190708143937.7722-2-leo.yan@linaro.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 073f1c0c2c2fdcd2da13bbf88346ec115a47b2a5 Author: Leo Yan Date: Tue Jul 2 18:34:13 2019 +0800 perf annotate: Fix dereferencing freed memory found by the smatch tool [ Upstream commit 600c787dbf6521d8d07ee717ab7606d5070103ea ] Based on the following report from Smatch, fix the potential dereferencing freed memory check. tools/perf/util/annotate.c:1125 disasm_line__parse() error: dereferencing freed memory 'namep' tools/perf/util/annotate.c 1100 static int disasm_line__parse(char *line, const char **namep, char **rawp) 1101 { 1102 char tmp, *name = ltrim(line); [...] 1114 *namep = strdup(name); 1115 1116 if (*namep == NULL) 1117 goto out_free_name; [...] 1124 out_free_name: 1125 free((void *)namep); ^^^^^ 1126 *namep = NULL; ^^^^^^ 1127 return -1; 1128 } If strdup() fails to allocate memory space for *namep, we don't need to free memory with pointer 'namep', which is resident in data structure disasm_line::ins::name; and *namep is NULL pointer for this failure, so it's pointless to assign NULL to *namep again. Committer note: Freeing namep, which is the address of the first entry of the 'struct ins' that is the first member of struct disasm_line would in fact free that disasm_line instance, if it was allocated via malloc/calloc, which, later, would a dereference of freed memory. Signed-off-by: Leo Yan Acked-by: Jiri Olsa Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Alexey Budankov Cc: Alexios Zavras Cc: Andi Kleen Cc: Changbin Du Cc: David S. Miller Cc: Davidlohr Bueso Cc: Eric Saint-Etienne Cc: Jin Yao Cc: Konstantin Khlebnikov Cc: Mathieu Poirier Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Rasmus Villemoes Cc: Song Liu Cc: Suzuki Poulouse Cc: Thomas Gleixner Cc: Thomas Richter Cc: linux-arm-kernel@lists.infradead.org Link: http://lkml.kernel.org/r/20190702103420.27540-5-leo.yan@linaro.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 01d66420f6fcfc3a5c590809ef0f86375834c81b Author: Leo Yan Date: Tue Jul 2 18:34:16 2019 +0800 perf map: Fix potential NULL pointer dereference found by smatch tool [ Upstream commit 363bbaef63ffebcc745239fe80a953ebb5ac9ec9 ] Based on the following report from Smatch, fix the potential NULL pointer dereference check. tools/perf/util/map.c:479 map__fprintf_srccode() error: we previously assumed 'state' could be null (see line 466) tools/perf/util/map.c 465 /* Avoid redundant printing */ 466 if (state && 467 state->srcfile && 468 !strcmp(state->srcfile, srcfile) && 469 state->line == line) { 470 free(srcfile); 471 return 0; 472 } 473 474 srccode = find_sourceline(srcfile, line, &len); 475 if (!srccode) 476 goto out_free_line; 477 478 ret = fprintf(fp, "|%-8d %.*s", line, len, srccode); 479 state->srcfile = srcfile; ^^^^^^^ 480 state->line = line; ^^^^^^^ This patch validates 'state' pointer before access its elements. Signed-off-by: Leo Yan Acked-by: Jiri Olsa Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Alexey Budankov Cc: Alexios Zavras Cc: Andi Kleen Cc: Changbin Du Cc: David S. Miller Cc: Davidlohr Bueso Cc: Eric Saint-Etienne Cc: Jin Yao Cc: Konstantin Khlebnikov Cc: Mathieu Poirier Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Rasmus Villemoes Cc: Song Liu Cc: Suzuki Poulouse Cc: Thomas Gleixner Cc: Thomas Richter Cc: linux-arm-kernel@lists.infradead.org Fixes: dd2e18e9ac20 ("perf tools: Support 'srccode' output") Link: http://lkml.kernel.org/r/20190702103420.27540-8-leo.yan@linaro.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 263cd6e7437218c9082432732dd1741a535754d7 Author: Leo Yan Date: Tue Jul 2 18:34:17 2019 +0800 perf session: Fix potential NULL pointer dereference found by the smatch tool [ Upstream commit f3c8d90757724982e5f07cd77d315eb64ca145ac ] Based on the following report from Smatch, fix the potential NULL pointer dereference check. tools/perf/util/session.c:1252 dump_read() error: we previously assumed 'evsel' could be null (see line 1249) tools/perf/util/session.c 1240 static void dump_read(struct perf_evsel *evsel, union perf_event *event) 1241 { 1242 struct read_event *read_event = &event->read; 1243 u64 read_format; 1244 1245 if (!dump_trace) 1246 return; 1247 1248 printf(": %d %d %s %" PRIu64 "\n", event->read.pid, event->read.tid, 1249 evsel ? perf_evsel__name(evsel) : "FAIL", 1250 event->read.value); 1251 1252 read_format = evsel->attr.read_format; ^^^^^^^ 'evsel' could be NULL pointer, for this case this patch directly bails out without dumping read_event. Signed-off-by: Leo Yan Acked-by: Jiri Olsa Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Alexey Budankov Cc: Alexios Zavras Cc: Andi Kleen Cc: Changbin Du Cc: David S. Miller Cc: Davidlohr Bueso Cc: Eric Saint-Etienne Cc: Jin Yao Cc: Konstantin Khlebnikov Cc: Mathieu Poirier Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Rasmus Villemoes Cc: Song Liu Cc: Suzuki Poulouse Cc: Thomas Gleixner Cc: Thomas Richter Cc: linux-arm-kernel@lists.infradead.org Link: http://lkml.kernel.org/r/20190702103420.27540-9-leo.yan@linaro.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 28090547c425078edc0a2950c97a470f3b9e6b8e Author: Leo Yan Date: Tue Jul 2 18:34:14 2019 +0800 perf trace: Fix potential NULL pointer dereference found by the smatch tool [ Upstream commit 7a6d49dc8cad8fa1f3d63994102af8f9ae9c859f ] Based on the following report from Smatch, fix the potential NULL pointer dereference check. tools/perf/builtin-trace.c:1044 thread_trace__new() error: we previously assumed 'ttrace' could be null (see line 1041). tools/perf/builtin-trace.c 1037 static struct thread_trace *thread_trace__new(void) 1038 { 1039 struct thread_trace *ttrace = zalloc(sizeof(struct thread_trace)); 1040 1041 if (ttrace) 1042 ttrace->files.max = -1; 1043 1044 ttrace->syscall_stats = intlist__new(NULL); ^^^^^^^^ 1045 1046 return ttrace; 1047 } Signed-off-by: Leo Yan Acked-by: Jiri Olsa Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Alexey Budankov Cc: Alexios Zavras Cc: Andi Kleen Cc: Changbin Du Cc: David S. Miller Cc: Davidlohr Bueso Cc: Eric Saint-Etienne Cc: Jin Yao Cc: Konstantin Khlebnikov Cc: Mathieu Poirier Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Rasmus Villemoes Cc: Song Liu Cc: Suzuki Poulouse Cc: Thomas Gleixner Cc: Thomas Richter Cc: linux-arm-kernel@lists.infradead.org Link: http://lkml.kernel.org/r/20190702103420.27540-6-leo.yan@linaro.org [ Just made it look like other tools/perf constructors, same end result ] Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit ae66773a08c801592ebb66ea50336bc35d048146 Author: Leo Yan Date: Tue Jul 2 18:34:12 2019 +0800 perf top: Fix potential NULL pointer dereference detected by the smatch tool [ Upstream commit 111442cfc8abdeaa7ec1407f07ef7b3e5f76654e ] Based on the following report from Smatch, fix the potential NULL pointer dereference check. tools/perf/builtin-top.c:109 perf_top__parse_source() warn: variable dereferenced before check 'he' (see line 103) tools/perf/builtin-top.c:233 perf_top__show_details() warn: variable dereferenced before check 'he' (see line 228) tools/perf/builtin-top.c 101 static int perf_top__parse_source(struct perf_top *top, struct hist_entry *he) 102 { 103 struct perf_evsel *evsel = hists_to_evsel(he->hists); ^^^^ 104 struct symbol *sym; 105 struct annotation *notes; 106 struct map *map; 107 int err = -1; 108 109 if (!he || !he->ms.sym) 110 return -1; This patch moves the values assignment after validating pointer 'he'. Signed-off-by: Leo Yan Acked-by: Jiri Olsa Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Alexey Budankov Cc: Alexios Zavras Cc: Andi Kleen Cc: Changbin Du Cc: David S. Miller Cc: Davidlohr Bueso Cc: Eric Saint-Etienne Cc: Jin Yao Cc: Konstantin Khlebnikov Cc: Mathieu Poirier Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Rasmus Villemoes Cc: Song Liu Cc: Suzuki Poulouse Cc: Thomas Gleixner Cc: Thomas Richter Cc: linux-arm-kernel@lists.infradead.org Link: http://lkml.kernel.org/r/20190702103420.27540-4-leo.yan@linaro.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 5a4b4efa9d7b39e00147c732f9118f3cef88cca1 Author: Mathieu Desnoyers Date: Sun Jun 30 09:56:13 2019 -0400 rseq/selftests: Fix Thumb mode build failure on arm32 [ Upstream commit ee8a84c60bcc1f1615bd9cb3edfe501e26cdc85b ] Using ".arm .inst" for the arm signature introduces build issues for programs compiled in Thumb mode because the assembler stays in the arm mode for the rest of the inline assembly. Revert to using a ".word" to express the signature as data instead. The choice of signature is a valid trap instruction on arm32 little endian, where both code and data are little endian. ARMv6+ big endian (BE8) generates mixed endianness code vs data: little-endian code and big-endian data. The data value of the signature needs to have its byte order reversed to generate the trap instruction. Prior to ARMv6, -mbig-endian generates big-endian code and data (which match), so the endianness of the data representation of the signature should not be reversed. However, the choice between BE32 and BE8 is done by the linker, so we cannot know whether code and data endianness will be mixed before the linker is invoked. So rather than try to play tricks with the linker, the rseq signature is simply data (not a trap instruction) prior to ARMv6 on big endian. This is why the signature is expressed as data (.word) rather than as instruction (.inst) in assembler. Because a ".word" is used to emit the signature, it will be interpreted as a literal pool by a disassembler, not as an actual instruction. Considering that the signature is not meant to be executed except in scenarios where the program execution is completely bogus, this should not be an issue. Signed-off-by: Mathieu Desnoyers Acked-by: Will Deacon CC: Peter Zijlstra CC: Thomas Gleixner CC: Joel Fernandes CC: Catalin Marinas CC: Dave Watson CC: Will Deacon CC: Shuah Khan CC: Andi Kleen CC: linux-kselftest@vger.kernel.org CC: "H . Peter Anvin" CC: Chris Lameter CC: Russell King CC: Michael Kerrisk CC: "Paul E . McKenney" CC: Paul Turner CC: Boqun Feng CC: Josh Triplett CC: Steven Rostedt CC: Ben Maurer CC: linux-api@vger.kernel.org CC: Andy Lutomirski CC: Andrew Morton CC: Linus Torvalds CC: Carlos O'Donell CC: Florian Weimer Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit 025c3912f5704da2d8096c296a1c4521db4340fe Author: Leo Yan Date: Tue Jul 2 18:34:11 2019 +0800 perf stat: Fix use-after-freed pointer detected by the smatch tool [ Upstream commit c74b05030edb3b52f4208d8415b8c933bc509a29 ] Based on the following report from Smatch, fix the use-after-freed pointer. tools/perf/builtin-stat.c:1353 add_default_attributes() warn: passing freed memory 'str'. The pointer 'str' has been freed but later it is still passed into the function parse_events_print_error(). This patch fixes this use-after-freed issue. Signed-off-by: Leo Yan Acked-by: Jiri Olsa Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Alexey Budankov Cc: Alexios Zavras Cc: Andi Kleen Cc: Changbin Du Cc: Davidlohr Bueso Cc: David S. Miller Cc: Eric Saint-Etienne Cc: Jin Yao Cc: Konstantin Khlebnikov Cc: linux-arm-kernel@lists.infradead.org Cc: Mathieu Poirier Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Rasmus Villemoes Cc: Song Liu Cc: Suzuki Poulouse Cc: Thomas Gleixner Cc: Thomas Richter Link: http://lkml.kernel.org/r/20190702103420.27540-3-leo.yan@linaro.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit ec6806965e676c8012aa00070babae85cdbd476a Author: Numfor Mbiziwo-Tiapo Date: Tue Jul 2 10:37:15 2019 -0700 perf test mmap-thread-lookup: Initialize variable to suppress memory sanitizer warning [ Upstream commit 4e4cf62b37da5ff45c904a3acf242ab29ed5881d ] Running the 'perf test' command after building perf with a memory sanitizer causes a warning that says: WARNING: MemorySanitizer: use-of-uninitialized-value... in mmap-thread-lookup.c Initializing the go variable to 0 silences this harmless warning. Committer warning: This was harmless, just a simple test writing whatever was at that sizeof(int) memory area just to signal another thread blocked reading that file created with pipe(). Initialize it tho so that we don't get this warning. Signed-off-by: Numfor Mbiziwo-Tiapo Cc: Alexander Shishkin Cc: Ian Rogers Cc: Jiri Olsa Cc: Mark Drayton Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Song Liu Cc: Stephane Eranian Link: http://lkml.kernel.org/r/20190702173716.181223-1-nums@google.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 67d42e6ab9034b579fa2fc9dc2c1051aa873d34e Author: Hou Zhiqiang Date: Fri Jul 5 17:56:34 2019 +0800 PCI: mobiveil: Use the 1st inbound window for MEM inbound transactions [ Upstream commit f7fee1b42fe4f8171a4b1cad05c61907c33c53f6 ] The inbound and outbound windows have completely separate control registers sets in the host controller MMIO space. Windows control register are accessed through an MMIO base address and an offset that depends on the window index. Since inbound and outbound windows control registers are completely separate there is no real need to use different window indexes in the inbound/outbound windows initialization routines to prevent clashing. To fix this inconsistency, change the MEM inbound window index to 0, mirroring the outbound window set-up. Signed-off-by: Hou Zhiqiang [lorenzo.pieralisi@arm.com: update commit log] Signed-off-by: Lorenzo Pieralisi Reviewed-by: Minghuan Lian Reviewed-by: Subrahmanya Lingappa Signed-off-by: Sasha Levin commit ed100a9da66ea0e3344d6a2f4d5e4c5fbd3b786d Author: Hou Zhiqiang Date: Fri Jul 5 17:56:38 2019 +0800 PCI: mobiveil: Initialize Primary/Secondary/Subordinate bus numbers [ Upstream commit 6f3ab451aa5c2cbff33197d82fe8489cbd55ad91 ] The reset value of Primary, Secondary and Subordinate bus numbers is zero which is a broken setup. Program a sensible default value for Primary/Secondary/Subordinate bus numbers. Signed-off-by: Hou Zhiqiang Signed-off-by: Lorenzo Pieralisi Reviewed-by: Minghuan Lian Reviewed-by: Subrahmanya Lingappa Signed-off-by: Sasha Levin commit e8596ac7d1e92ae221314cc3bf0a5674a7763625 Author: Vasily Gorbik Date: Fri Jun 28 19:22:47 2019 +0200 kallsyms: exclude kasan local symbols on s390 [ Upstream commit 33177f01ca3fe550146bb9001bec2fd806b2f40c ] gcc asan instrumentation emits the following sequence to store frame pc when the kernel is built with CONFIG_RELOCATABLE: debug/vsprintf.s: .section .data.rel.ro.local,"aw" .align 8 .LC3: .quad .LASANPC4826@GOTOFF .text .align 8 .type number, @function number: .LASANPC4826: and in case reloc is issued for LASANPC label it also gets into .symtab with the same address as actual function symbol: $ nm -n vmlinux | grep 0000000001397150 0000000001397150 t .LASANPC4826 0000000001397150 t number In the end kernel backtraces are almost unreadable: [ 143.748476] Call Trace: [ 143.748484] ([<000000002da3e62c>] .LASANPC2671+0x114/0x190) [ 143.748492] [<000000002eca1a58>] .LASANPC2612+0x110/0x160 [ 143.748502] [<000000002de9d830>] print_address_description+0x80/0x3b0 [ 143.748511] [<000000002de9dd64>] __kasan_report+0x15c/0x1c8 [ 143.748521] [<000000002ecb56d4>] strrchr+0x34/0x60 [ 143.748534] [<000003ff800a9a40>] kasan_strings+0xb0/0x148 [test_kasan] [ 143.748547] [<000003ff800a9bba>] kmalloc_tests_init+0xe2/0x528 [test_kasan] [ 143.748555] [<000000002da2117c>] .LASANPC4069+0x354/0x748 [ 143.748563] [<000000002dbfbb16>] do_init_module+0x136/0x3b0 [ 143.748571] [<000000002dbff3f4>] .LASANPC3191+0x2164/0x25d0 [ 143.748580] [<000000002dbffc4c>] .LASANPC3196+0x184/0x1b8 [ 143.748587] [<000000002ecdf2ec>] system_call+0xd8/0x2d8 Since LASANPC labels are not even unique and get into .symtab only due to relocs filter them out in kallsyms. Signed-off-by: Vasily Gorbik Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin commit 1e764667b01e5361bf491507eed785a399481857 Author: Hou Zhiqiang Date: Fri Jul 5 17:56:35 2019 +0800 PCI: mobiveil: Fix the Class Code field [ Upstream commit 0122af0a08243f344a438f924e5c2486486555b3 ] Fix up the Class Code field in PCI configuration space and set it to PCI_CLASS_BRIDGE_PCI. Move the Class Code fixup to function mobiveil_host_init() where it belongs. Fixes: 9af6bcb11e12 ("PCI: mobiveil: Add Mobiveil PCIe Host Bridge IP driver") Signed-off-by: Hou Zhiqiang Signed-off-by: Lorenzo Pieralisi Reviewed-by: Minghuan Lian Reviewed-by: Subrahmanya Lingappa Signed-off-by: Sasha Levin commit fd0b95493bc25ee27e026adc4ebec99997b5411a Author: Hou Zhiqiang Date: Fri Jul 5 17:56:31 2019 +0800 PCI: mobiveil: Fix PCI base address in MEM/IO outbound windows [ Upstream commit f99536e9d2f55996038158a6559d4254a7cc1693 ] The outbound memory windows PCI base addresses should be taken from the 'ranges' property of DT node to setup MEM/IO outbound windows decoding correctly instead of being hardcoded to zero. Update the code to retrieve the PCI base address for each range and use it to program the outbound windows address decoders Fixes: 9af6bcb11e12 ("PCI: mobiveil: Add Mobiveil PCIe Host Bridge IP driver") Signed-off-by: Hou Zhiqiang Signed-off-by: Lorenzo Pieralisi Reviewed-by: Minghuan Lian Reviewed-by: Subrahmanya Lingappa Signed-off-by: Sasha Levin commit c99f2733039630de30b9165cda29a15cf9eb4f2b Author: Sean Christopherson Date: Fri Jun 7 11:55:34 2019 -0700 KVM: nVMX: Stash L1's CR3 in vmcs01.GUEST_CR3 on nested entry w/o EPT [ Upstream commit f087a02941feacf7d6f097522bc67c602fda18e6 ] KVM does not have 100% coverage of VMX consistency checks, i.e. some checks that cause VM-Fail may only be detected by hardware during a nested VM-Entry. In such a case, KVM must restore L1's state to the pre-VM-Enter state as L2's state has already been loaded into KVM's software model. L1's CR3 and PDPTRs in particular are loaded from vmcs01.GUEST_*. But when EPT is disabled, the associated fields hold KVM's shadow values, not L1's "real" values. Fortunately, when EPT is disabled the PDPTRs come from memory, i.e. are not cached in the VMCS. Which leaves CR3 as the sole anomaly. A previously applied workaround to handle CR3 was to force nested early checks if EPT is disabled: commit 2b27924bb1d48 ("KVM: nVMX: always use early vmcs check when EPT is disabled") Forcing nested early checks is undesirable as doing so adds hundreds of cycles to every nested VM-Entry. Rather than take this performance hit, handle CR3 by overwriting vmcs01.GUEST_CR3 with L1's CR3 during nested VM-Entry when EPT is disabled *and* nested early checks are disabled. By stuffing vmcs01.GUEST_CR3, nested_vmx_restore_host_state() will naturally restore the correct vcpu->arch.cr3 from vmcs01.GUEST_CR3. These shenanigans work because nested_vmx_restore_host_state() does a full kvm_mmu_reset_context(), i.e. unloads the current MMU, which guarantees vmcs01.GUEST_CR3 will be rewritten with a new shadow CR3 prior to re-entering L1. vcpu->arch.root_mmu.root_hpa is set to INVALID_PAGE via: nested_vmx_restore_host_state() -> kvm_mmu_reset_context() -> kvm_mmu_unload() -> kvm_mmu_free_roots() kvm_mmu_unload() has WARN_ON(root_hpa != INVALID_PAGE), i.e. we can bank on 'root_hpa == INVALID_PAGE' unless the implementation of kvm_mmu_reset_context() is changed. On the way into L1, VMCS.GUEST_CR3 is guaranteed to be written (on a successful entry) via: vcpu_enter_guest() -> kvm_mmu_reload() -> kvm_mmu_load() -> kvm_mmu_load_cr3() -> vmx_set_cr3() Stuff vmcs01.GUEST_CR3 if and only if nested early checks are disabled as a "late" VM-Fail should never happen win that case (KVM WARNs), and the conditional write avoids the need to restore the correct GUEST_CR3 when nested_vmx_check_vmentry_hw() fails. Signed-off-by: Sean Christopherson Message-Id: <20190607185534.24368-1-sean.j.christopherson@intel.com> Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 77177ba55bb30453d4c32f6299c8087efe8dde72 Author: James Morse Date: Tue Jun 18 16:17:33 2019 +0100 arm64: assembler: Switch ESB-instruction with a vanilla nop if !ARM64_HAS_RAS [ Upstream commit 2b68a2a963a157f024c67c0697b16f5f792c8a35 ] The ESB-instruction is a nop on CPUs that don't implement the RAS extensions. This lets us use it in places like the vectors without having to use alternatives. If someone disables CONFIG_ARM64_RAS_EXTN, this instruction still has its RAS extensions behaviour, but we no longer read DISR_EL1 as this register does depend on alternatives. This could go wrong if we want to synchronize an SError from a KVM guest. On a CPU that has the RAS extensions, but the KConfig option was disabled, we consume the pending SError with no chance of ever reading it. Hide the ESB-instruction behind the CONFIG_ARM64_RAS_EXTN option, outputting a regular nop if the feature has been disabled. Reported-by: Julien Thierry Signed-off-by: James Morse Signed-off-by: Marc Zyngier Signed-off-by: Sasha Levin commit bf257a7b0294dc1f190acfbd2e8040f964d1d82a Author: Valentine Fatiev Date: Sun Jun 30 16:48:41 2019 +0300 IB/ipoib: Add child to parent list only if device initialized [ Upstream commit 91b01061fef9c57d2f5b712a6322ef51061f4efd ] Despite failure in ipoib_dev_init() we continue with initialization flow and creation of child device. It causes to the situation where this child device is added too early to parent device list. Change the logic, so in case of failure we properly return error from ipoib_dev_init() and add child only in success path. Fixes: eaeb39842508 ("IB/ipoib: Move init code to ndo_init") Signed-off-by: Valentine Fatiev Reviewed-by: Feras Daoud Signed-off-by: Leon Romanovsky Reviewed-by: Jason Gunthorpe Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 86f4ce0db73688c6df3dca09e3a5403d588b532b Author: Aneesh Kumar K.V Date: Tue May 28 11:06:24 2019 +0530 powerpc/mm: Handle page table allocation failures [ Upstream commit 2230ebf6e6dd0b7751e2921b40f6cfe34f09bb16 ] This fixes kernel crash that arises due to not handling page table allocation failures while allocating hugetlb page table. Fixes: e2b3d202d1db ("powerpc: Switch 16GB and 16MB explicit hugepages to a different page table format") Signed-off-by: Aneesh Kumar K.V Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit a5382200c616de6175d35ef2ac9ae4a2cd319f0a Author: Parav Pandit Date: Sun Jun 30 10:52:52 2019 +0300 IB/mlx5: Fixed reporting counters on 2nd port for Dual port RoCE [ Upstream commit 2f40cf30c8644360d37287861d5288f00eab35e5 ] Currently during dual port IB device registration in below code flow, ib_register_device() ib_device_register_sysfs() ib_setup_port_attrs() add_port() get_counter_table() get_perf_mad() process_mad() mlx5_ib_process_mad() mlx5_ib_process_mad() fails on 2nd port when both the ports are not fully setup at the device level (because 2nd port is unaffiliated). As a result, get_perf_mad() registers different PMA counter group for 1st and 2nd port, namely pma_counter_ext and pma_counter. However both ports have the same capability and counter offsets. Due to this when counters are read by the user via sysfs in below code flow, counters are queried from wrong location from the device mainly from PPCNT instead of VPORT counters. show_pma_counter() get_perf_mad() process_mad() mlx5_ib_process_mad() process_pma_cmd() This shows all zero counters for 2nd port. To overcome this, process_pma_cmd() is invoked, and when unaffiliated port is not yet setup during device registration phase, make the query on the first port. while at it, only process_pma_cmd() needs to work on the native port number and underlying mdev, so shift the get, put calls to where its needed inside process_pma_cmd(). Fixes: 212f2a87b74f ("IB/mlx5: Route MADs for dual port RoCE") Signed-off-by: Parav Pandit Reviewed-by: Daniel Jurgens Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 70e770a81aed1b515be6100deb06acc019136ccb Author: Geert Uytterhoeven Date: Mon Jun 24 14:35:39 2019 +0200 serial: sh-sci: Fix TX DMA buffer flushing and workqueue races [ Upstream commit 8493eab02608b0e82f67b892aa72882e510c31d0 ] When uart_flush_buffer() is called, the .flush_buffer() callback zeroes the tx_dma_len field. This may race with the work queue function handling transmit DMA requests: 1. If the buffer is flushed before the first DMA API call, dmaengine_prep_slave_single() may be called with a zero length, causing the DMA request to never complete, leading to messages like: rcar-dmac e7300000.dma-controller: Channel Address Error happen and, with debug enabled: sh-sci e6e88000.serial: sci_dma_tx_work_fn: ffff800639b55000: 0...0, cookie 126 and DMA timeouts. 2. If the buffer is flushed after the first DMA API call, but before the second, dma_sync_single_for_device() may be called with a zero length, causing the transmit data not to be flushed to RAM, and leading to stale data being output. Fix this by: 1. Letting sci_dma_tx_work_fn() return immediately if the transmit buffer is empty, 2. Extending the critical section to cover all DMA preparational work, so tx_dma_len stays consistent for all of it, 3. Using local copies of circ_buf.head and circ_buf.tail, to make sure they match the actual operation above. Reported-by: Eugeniu Rosca Suggested-by: Yoshihiro Shimoda Signed-off-by: Geert Uytterhoeven Reviewed-by: Eugeniu Rosca Tested-by: Eugeniu Rosca Link: https://lore.kernel.org/r/20190624123540.20629-2-geert+renesas@glider.be Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 1dffbe1fffb93b6447e999cb0e915d650bfe181a Author: Geert Uytterhoeven Date: Mon Jun 24 14:35:40 2019 +0200 serial: sh-sci: Terminate TX DMA during buffer flushing [ Upstream commit 775b7ffd7d6d5db320d99b0a485c51e04dfcf9f1 ] While the .flush_buffer() callback clears sci_port.tx_dma_len since commit 1cf4a7efdc71cab8 ("serial: sh-sci: Fix race condition causing garbage during shutdown"), it does not terminate a transmit DMA operation that may be in progress. Fix this by terminating any pending DMA operations, and resetting the corresponding cookie. Signed-off-by: Geert Uytterhoeven Reviewed-by: Eugeniu Rosca Tested-by: Eugeniu Rosca Link: https://lore.kernel.org/r/20190624123540.20629-3-geert+renesas@glider.be Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 66c3a603d6829be4e8a33031c2a5f242f7a694af Author: Liu, Changcheng Date: Fri Jun 28 14:16:13 2019 +0800 RDMA/i40iw: Set queue pair state when being queried [ Upstream commit 2e67e775845373905d2c2aecb9062c2c4352a535 ] The API for ib_query_qp requires the driver to set qp_state and cur_qp_state on return, add the missing sets. Fixes: d37498417947 ("i40iw: add files for iwarp interface") Signed-off-by: Changcheng Liu Acked-by: Shiraz Saleem Reviewed-by: Jason Gunthorpe Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 8e86a540c654f241cc3ee6541811beba1b031490 Author: Masahiro Yamada Date: Tue May 21 22:13:24 2019 +0900 powerpc/mm: mark more tlb functions as __always_inline [ Upstream commit 6d3ca7e73642ce17398f4cd5df1780da4a1ccdaf ] With CONFIG_OPTIMIZE_INLINING enabled, Laura Abbott reported error with gcc 9.1.1: arch/powerpc/mm/book3s64/radix_tlb.c: In function '_tlbiel_pid': arch/powerpc/mm/book3s64/radix_tlb.c:104:2: warning: asm operand 3 probably doesn't match constraints 104 | asm volatile(PPC_TLBIEL(%0, %4, %3, %2, %1) | ^~~ arch/powerpc/mm/book3s64/radix_tlb.c:104:2: error: impossible constraint in 'asm' Fixing _tlbiel_pid() is enough to address the warning above, but I inlined more functions to fix all potential issues. To meet the "i" (immediate) constraint for the asm operands, functions propagating "ric" must be always inlined. Fixes: 9012d011660e ("compiler: allow all arches to enable CONFIG_OPTIMIZE_INLINING") Reported-by: Laura Abbott Signed-off-by: Masahiro Yamada Reviewed-by: Christophe Leroy Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit d97cfca8faa49344252174c2e3194cc45496e170 Author: Christian Lamparter Date: Sat Jun 15 17:23:13 2019 +0200 powerpc/4xx/uic: clear pending interrupt after irq type/pol change [ Upstream commit 3ab3a0689e74e6aa5b41360bc18861040ddef5b1 ] When testing out gpio-keys with a button, a spurious interrupt (and therefore a key press or release event) gets triggered as soon as the driver enables the irq line for the first time. This patch clears any potential bogus generated interrupt that was caused by the switching of the associated irq's type and polarity. Signed-off-by: Christian Lamparter Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit d3d8bd3cfa37bcc4b884b34bc61ed4edf7abab95 Author: Mathieu Malaterre Date: Tue Jun 4 13:00:36 2019 +1000 powerpc: silence a -Wcast-function-type warning in dawr_write_file_bool [ Upstream commit 548c54acba5bd1388d50727a9a126a42d0cd4ad0 ] In commit c1fe190c0672 ("powerpc: Add force enable of DAWR on P9 option") the following piece of code was added: smp_call_function((smp_call_func_t)set_dawr, &null_brk, 0); Since GCC 8 this triggers the following warning about incompatible function types: arch/powerpc/kernel/hw_breakpoint.c:408:21: error: cast between incompatible function types from 'int (*)(struct arch_hw_breakpoint *)' to 'void (*)(void *)' [-Werror=cast-function-type] Since the warning is there for a reason, and should not be hidden behind a cast, provide an intermediate callback function to avoid the warning. Fixes: c1fe190c0672 ("powerpc: Add force enable of DAWR on P9 option") Suggested-by: Christoph Hellwig Signed-off-by: Mathieu Malaterre Signed-off-by: Michael Neuling Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit 4453eb78fe79898b55d4c9ff56efcd813eb0fbcb Author: Sahitya Tummala Date: Thu Jun 6 15:08:13 2019 +0530 f2fs: fix is_idle() check for discard type [ Upstream commit 56659ce838456c6f2315ce8a4bd686ac4b23e9d1 ] The discard thread should issue upto dpolicy->max_requests at once and wait for all those discard requests at once it reaches dpolicy->max_requests. It should then sleep for dpolicy->min_interval timeout before issuing the next batch of discard requests. But in the current code of is_idle(), it checks for dcc_info->queued_discard and aborts issuing the discard batch of max_requests. This dcc_info->queued_discard will be true always once one discard command is issued. It is thus resulting into this type of discard request pattern - - Issue discard request#1 - is_idle() returns false, discard thread waits for request#1 and then sleeps for min_interval 50ms. - Issue discard request#2 - is_idle() returns false, discard thread waits for request#2 and then sleeps for min_interval 50ms. - and so on for all other discard requests, assuming f2fs is idle w.r.t other conditions. With this fix, the pattern will look like this - - Issue discard request#1 - Issue discard request#2 and so on upto max_requests of 8 - Issue discard request#8 - wait for min_interval 50ms. Signed-off-by: Sahitya Tummala Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 4af197342ba42a95c88ece2d8359c4cf404afa76 Author: Johannes Berg Date: Fri May 24 21:54:14 2019 +0200 um: Silence lockdep complaint about mmap_sem [ Upstream commit 80bf6ceaf9310b3f61934c69b382d4912deee049 ] When we get into activate_mm(), lockdep complains that we're doing something strange: WARNING: possible circular locking dependency detected 5.1.0-10252-gb00152307319-dirty #121 Not tainted ------------------------------------------------------ inside.sh/366 is trying to acquire lock: (____ptrval____) (&(&p->alloc_lock)->rlock){+.+.}, at: flush_old_exec+0x703/0x8d7 but task is already holding lock: (____ptrval____) (&mm->mmap_sem){++++}, at: flush_old_exec+0x6c5/0x8d7 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&mm->mmap_sem){++++}: [...] __lock_acquire+0x12ab/0x139f lock_acquire+0x155/0x18e down_write+0x3f/0x98 flush_old_exec+0x748/0x8d7 load_elf_binary+0x2ca/0xddb [...] -> #0 (&(&p->alloc_lock)->rlock){+.+.}: [...] __lock_acquire+0x12ab/0x139f lock_acquire+0x155/0x18e _raw_spin_lock+0x30/0x83 flush_old_exec+0x703/0x8d7 load_elf_binary+0x2ca/0xddb [...] other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&mm->mmap_sem); lock(&(&p->alloc_lock)->rlock); lock(&mm->mmap_sem); lock(&(&p->alloc_lock)->rlock); *** DEADLOCK *** 2 locks held by inside.sh/366: #0: (____ptrval____) (&sig->cred_guard_mutex){+.+.}, at: __do_execve_file+0x12d/0x869 #1: (____ptrval____) (&mm->mmap_sem){++++}, at: flush_old_exec+0x6c5/0x8d7 stack backtrace: CPU: 0 PID: 366 Comm: inside.sh Not tainted 5.1.0-10252-gb00152307319-dirty #121 Stack: [...] Call Trace: [<600420de>] show_stack+0x13b/0x155 [<6048906b>] dump_stack+0x2a/0x2c [<6009ae64>] print_circular_bug+0x332/0x343 [<6009c5c6>] check_prev_add+0x669/0xdad [<600a06b4>] __lock_acquire+0x12ab/0x139f [<6009f3d0>] lock_acquire+0x155/0x18e [<604a07e0>] _raw_spin_lock+0x30/0x83 [<60151e6a>] flush_old_exec+0x703/0x8d7 [<601a8eb8>] load_elf_binary+0x2ca/0xddb [...] I think it's because in exec_mmap() we have down_read(&old_mm->mmap_sem); ... task_lock(tsk); ... activate_mm(active_mm, mm); (which does down_write(&mm->mmap_sem)) I'm not really sure why lockdep throws in the whole knowledge about the task lock, but it seems that old_mm and mm shouldn't ever be the same (and it doesn't deadlock) so tell lockdep that they're different. Signed-off-by: Johannes Berg Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin commit 2df1bd94412c9b3522aa5b5950f1ec5219ef432e Author: Ira Weiny Date: Wed Jun 5 14:49:22 2019 -0700 mm/swap: fix release_pages() when releasing devmap pages [ Upstream commit c5d6c45e90c49150670346967971e14576afd7f1 ] release_pages() is an optimized version of a loop around put_page(). Unfortunately for devmap pages the logic is not entirely correct in release_pages(). This is because device pages can be more than type MEMORY_DEVICE_PUBLIC. There are in fact 4 types, private, public, FS DAX, and PCI P2PDMA. Some of these have specific needs to "put" the page while others do not. This logic to handle any special needs is contained in put_devmap_managed_page(). Therefore all devmap pages should be processed by this function where we can contain the correct logic for a page put. Handle all device type pages within release_pages() by calling put_devmap_managed_page() on all devmap pages. If put_devmap_managed_page() returns true the page has been put and we continue with the next page. A false return of put_devmap_managed_page() means the page did not require special processing and should fall to "normal" processing. This was found via code inspection while determining if release_pages() and the new put_user_pages() could be interchangeable.[1] [1] https://lkml.kernel.org/r/20190523172852.GA27175@iweiny-DESK2.sc.intel.com Link: https://lkml.kernel.org/r/20190605214922.17684-1-ira.weiny@intel.com Cc: Jérôme Glisse Cc: Michal Hocko Reviewed-by: Dan Williams Reviewed-by: John Hubbard Signed-off-by: Ira Weiny Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 7891d8a7448d1accf1394c555983796542d6b2d1 Author: Axel Lin Date: Wed Jun 26 21:30:07 2019 +0800 mfd: hi655x-pmic: Fix missing return value check for devm_regmap_init_mmio_clk [ Upstream commit 7efd105c27fd2323789b41b64763a0e33ed79c08 ] Since devm_regmap_init_mmio_clk can fail, add return value checking. Signed-off-by: Axel Lin Acked-by: Chen Feng Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 4c0f6d486fb7a400350c5402ef1573426704f542 Author: Arnd Bergmann Date: Mon May 20 10:06:25 2019 +0100 mfd: arizona: Fix undefined behavior [ Upstream commit 5da6cbcd2f395981aa9bfc571ace99f1c786c985 ] When the driver is used with a subdevice that is disabled in the kernel configuration, clang gets a little confused about the control flow and fails to notice that n_subdevs is only uninitialized when subdevs is NULL, and we check for that, leading to a false-positive warning: drivers/mfd/arizona-core.c:1423:19: error: variable 'n_subdevs' is uninitialized when used here [-Werror,-Wuninitialized] subdevs, n_subdevs, NULL, 0, NULL); ^~~~~~~~~ drivers/mfd/arizona-core.c:999:15: note: initialize the variable 'n_subdevs' to silence this warning int n_subdevs, ret, i; ^ = 0 Ideally, we would rearrange the code to avoid all those early initializations and have an explicit exit in each disabled case, but it's much easier to chicken out and add one more initialization here to shut up the warning. Signed-off-by: Arnd Bergmann Reviewed-by: Nathan Chancellor Signed-off-by: Charles Keepax Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 8c0948e4be879cd97cb88e43cd90d126d8bbf1a7 Author: Robert Hancock Date: Tue Jun 4 16:35:43 2019 -0600 mfd: core: Set fwnode for created devices [ Upstream commit c176c6d7e932662668bcaec2d763657096589d85 ] The logic for setting the of_node on devices created by mfd did not set the fwnode pointer to match, which caused fwnode-based APIs to malfunction on these devices since the fwnode pointer was null. Fix this. Signed-off-by: Robert Hancock Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 5fd2751507d7daa2f3873a083782be9559cf36d6 Author: Daniel Gomez Date: Sat May 11 12:03:58 2019 +0200 mfd: madera: Add missing of table registration [ Upstream commit 5aa3709c0a5c026735b0ddd4ec80810a23d65f5b ] MODULE_DEVICE_TABLE(of, ) should be called to complete DT OF mathing mechanism and register it. Before this patch: modinfo ./drivers/mfd/madera.ko | grep alias After this patch: modinfo ./drivers/mfd/madera.ko | grep alias alias: of:N*T*Ccirrus,wm1840C* alias: of:N*T*Ccirrus,wm1840 alias: of:N*T*Ccirrus,cs47l91C* alias: of:N*T*Ccirrus,cs47l91 alias: of:N*T*Ccirrus,cs47l90C* alias: of:N*T*Ccirrus,cs47l90 alias: of:N*T*Ccirrus,cs47l85C* alias: of:N*T*Ccirrus,cs47l85 alias: of:N*T*Ccirrus,cs47l35C* alias: of:N*T*Ccirrus,cs47l35 Reported-by: Javier Martinez Canillas Signed-off-by: Daniel Gomez Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 0ca2305a1c9079f7eb0d9a0de05c2862cb81deb2 Author: Gwendal Grignou Date: Fri May 17 16:38:55 2019 -0700 mfd: cros_ec: Register cros_ec_lid_angle driver when presented [ Upstream commit 1bb407f17c5316888c3c446e26cb2bb78943f236 ] Register driver when EC indicates has precise lid angle calculation code running. Fix incorrect extra resource allocation in cros_ec_sensors_register(). Signed-off-by: Gwendal Grignou Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit e7d6ecc8dffbbd58fce1f807084b63f9b34a837a Author: Naveen N. Rao Date: Thu Jun 27 00:08:01 2019 +0530 recordmcount: Fix spurious mcount entries on powerpc [ Upstream commit 80e5302e4bc85a6b685b7668c36c6487b5f90e9a ] An impending change to enable HAVE_C_RECORDMCOUNT on powerpc leads to warnings such as the following: # modprobe kprobe_example ftrace-powerpc: Not expected bl: opcode is 3c4c0001 WARNING: CPU: 0 PID: 227 at kernel/trace/ftrace.c:2001 ftrace_bug+0x90/0x318 Modules linked in: CPU: 0 PID: 227 Comm: modprobe Not tainted 5.2.0-rc6-00678-g1c329100b942 #2 NIP: c000000000264318 LR: c00000000025d694 CTR: c000000000f5cd30 REGS: c000000001f2b7b0 TRAP: 0700 Not tainted (5.2.0-rc6-00678-g1c329100b942) MSR: 900000010282b033 CR: 28228222 XER: 00000000 CFAR: c0000000002642fc IRQMASK: 0 NIP [c000000000264318] ftrace_bug+0x90/0x318 LR [c00000000025d694] ftrace_process_locs+0x4f4/0x5e0 Call Trace: [c000000001f2ba40] [0000000000000004] 0x4 (unreliable) [c000000001f2bad0] [c00000000025d694] ftrace_process_locs+0x4f4/0x5e0 [c000000001f2bb90] [c00000000020ff10] load_module+0x25b0/0x30c0 [c000000001f2bd00] [c000000000210cb0] sys_finit_module+0xc0/0x130 [c000000001f2be20] [c00000000000bda4] system_call+0x5c/0x70 Instruction dump: 419e0018 2f83ffff 419e00bc 2f83ffea 409e00cc 4800001c 0fe00000 3c62ff96 39000001 39400000 386386d0 480000c4 <0fe00000> 3ce20003 39000001 3c62ff96 ---[ end trace 4c438d5cebf78381 ]--- ftrace failed to modify [] 0xc0080000012a0008 actual: 01:00:4c:3c Initializing ftrace call sites ftrace record flags: 2000000 (0) expected tramp: c00000000006af4c Looking at the relocation records in __mcount_loc shows a few spurious entries: RELOCATION RECORDS FOR [__mcount_loc]: OFFSET TYPE VALUE 0000000000000000 R_PPC64_ADDR64 .text.unlikely+0x0000000000000008 0000000000000008 R_PPC64_ADDR64 .text.unlikely+0x0000000000000014 0000000000000010 R_PPC64_ADDR64 .text.unlikely+0x0000000000000060 0000000000000018 R_PPC64_ADDR64 .text.unlikely+0x00000000000000b4 0000000000000020 R_PPC64_ADDR64 .init.text+0x0000000000000008 0000000000000028 R_PPC64_ADDR64 .init.text+0x0000000000000014 The first entry in each section is incorrect. Looking at the relocation records, the spurious entries correspond to the R_PPC64_ENTRY records: RELOCATION RECORDS FOR [.text.unlikely]: OFFSET TYPE VALUE 0000000000000000 R_PPC64_REL64 .TOC.-0x0000000000000008 0000000000000008 R_PPC64_ENTRY *ABS* 0000000000000014 R_PPC64_REL24 _mcount The problem is that we are not validating the return value from get_mcountsym() in sift_rel_mcount(). With this entry, mcountsym is 0, but Elf_r_sym(relp) also ends up being 0. Fix this by ensuring mcountsym is valid before processing the entry. Signed-off-by: Naveen N. Rao Acked-by: Steven Rostedt (VMware) Tested-by: Satheesh Rajendran Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit 800eb38a885bc8928ffa831cae2e48f4fe693b6b Author: Masahiro Yamada Date: Tue Jun 25 15:54:19 2019 +0900 fixdep: check return value of printf() and putchar() [ Upstream commit 6f9ac9f4427ec0470ccffbf852cfaf326677cc21 ] When there is not enough space on your storage device, the build will fail with 'No space left on device' error message. The reason is obvious from the message, so you will free up some disk space, then you will resume the build. However, sometimes you may still see a mysterious error message: unterminated call to function 'wildcard': missing ')'. If you run out of the disk space, fixdep may end up with generating incomplete .*.cmd files. For example, if the disk-full error occurs while fixdep is running print_dep(), the .*.cmd might be truncated like this: $(wildcard include/config/ When you run 'make' next time, this broken .*.cmd will be included, then Make will terminate parsing since it is a wrong syntax. Once this happens, you need to run 'make clean' or delete the broken .*.cmd file manually. Even if you do not see any error message, the .*.cmd files after any error could be potentially incomplete, and unreliable. You may miss the re-compilation due to missing header dependency. If printf() cannot output the string for disk shortage or whatever reason, it returns a negative value, but currently fixdep does not check it at all. Consequently, fixdep *successfully* generates a broken .*.cmd file. Make never notices that since fixdep exits with 0, which means success. Given the intended usage of fixdep, it must respect the return value of not only malloc(), but also printf() and putchar(). This seems a long-standing issue since the introduction of fixdep. In old days, Kbuild tried to provide an extra safety by letting fixdep output to a temporary file and renaming it after everything is done: scripts/basic/fixdep $(depfile) $@ '$(make-cmd)' > $(dot-target).tmp;\ rm -f $(depfile); \ mv -f $(dot-target).tmp $(dot-target).cmd) It was no help to avoid the current issue; fixdep successfully created a truncated tmp file, which would be renamed to a .*.cmd file. This problem should be fixed by propagating the error status to the build system because: [1] Since commit 9c2af1c7377a ("kbuild: add .DELETE_ON_ERROR special target"), Make will delete the target automatically on any failure in the recipe. [2] Since commit 392885ee82d3 ("kbuild: let fixdep directly write to .*.cmd files"), .*.cmd file is included only when the corresponding target already exists. Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin commit 2fac004c41505b20429c9c7a35852baa1da73713 Author: Nathan Lynch Date: Fri Jun 21 01:05:18 2019 -0500 powerpc/rtas: retry when cpu offline races with suspend/migration [ Upstream commit 9fb603050ffd94f8127df99c699cca2f575eb6a0 ] The protocol for suspending or migrating an LPAR requires all present processor threads to enter H_JOIN. So if we have threads offline, we have to temporarily bring them up. This can race with administrator actions such as SMT state changes. As of dfd718a2ed1f ("powerpc/rtas: Fix a potential race between CPU-Offline & Migration"), rtas_ibm_suspend_me() accounts for this, but errors out with -EBUSY for what almost certainly is a transient condition in any reasonable scenario. Callers of rtas_ibm_suspend_me() already retry when -EAGAIN is returned, and it is typical during a migration for that to happen repeatedly for several minutes polling the H_VASI_STATE hcall result before proceeding to the next stage. So return -EAGAIN instead of -EBUSY when this race is encountered. Additionally: logging this event is still appropriate but use pr_info instead of pr_err; and remove use of unlikely() while here as this is not a hot path at all. Fixes: dfd718a2ed1f ("powerpc/rtas: Fix a potential race between CPU-Offline & Migration") Signed-off-by: Nathan Lynch Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit dcce5f7010b74f6ad1fde2af1190ca1b394bb5c8 Author: Naveen N. Rao Date: Thu Jun 27 15:29:40 2019 +0530 powerpc/xmon: Fix disabling tracing while in xmon [ Upstream commit aaf06665f7ea3ee9f9754e16c1a507a89f1de5b1 ] Commit ed49f7fd6438d ("powerpc/xmon: Disable tracing when entering xmon") added code to disable recording trace entries while in xmon. The commit introduced a variable 'tracing_enabled' to record if tracing was enabled on xmon entry, and used this to conditionally enable tracing during exit from xmon. However, we are not checking the value of 'fromipi' variable in xmon_core() when setting 'tracing_enabled'. Due to this, when secondary cpus enter xmon, they will see tracing as being disabled already and tracing won't be re-enabled on exit. Fix the same. Fixes: ed49f7fd6438d ("powerpc/xmon: Disable tracing when entering xmon") Signed-off-by: Naveen N. Rao Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit efade83292691afb4a95d163cb33cdef8232c206 Author: Qian Cai Date: Thu Jun 6 09:58:13 2019 -0400 powerpc/cacheflush: fix variable set but not used [ Upstream commit 04db3ede40ae4fc23a5c4237254c4a53bbe4c1f2 ] The powerpc's flush_cache_vmap() is defined as a macro and never use both of its arguments, so it will generate a compilation warning, lib/ioremap.c: In function 'ioremap_page_range': lib/ioremap.c:203:16: warning: variable 'start' set but not used [-Wunused-but-set-variable] Fix it by making it an inline function. Signed-off-by: Qian Cai Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit 44c6b91580a8b7d616c74870b7765d2f6bbb3473 Author: Brian Masney Date: Mon May 20 04:58:46 2019 -0400 dt-bindings: backlight: lm3630a: correct schema validation [ Upstream commit ef4db28c1f45cda6989bc8a8e45294894786d947 ] The '#address-cells' and '#size-cells' properties were not defined in the lm3630a bindings and would cause the following error when attempting to validate the examples against the schema: Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.example.dt.yaml: '#address-cells', '#size-cells' do not match any of the regexes: '^led@[01]$', 'pinctrl-[0-9]+' Correct this by adding those two properties. While we're here, move the ti,linear-mapping-mode property to the led@[01] child nodes to correct the following validation error: Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.example.dt.yaml: led@0: 'ti,linear-mapping-mode' does not match any of the regexes: 'pinctrl-[0-9]+' Fixes: 32fcb75c66a0 ("dt-bindings: backlight: Add lm3630a bindings") Signed-off-by: Brian Masney Reported-by: Rob Herring Acked-by: Daniel Thompson Acked-by: Dan Murphy [robh: also drop maxItems from child reg] Signed-off-by: Rob Herring Signed-off-by: Sasha Levin commit 5d691a4b82ad0910e3b8824e992204f42a1d6131 Author: Bastien Nocera Date: Thu Jun 27 09:20:45 2019 +0200 iio: iio-utils: Fix possible incorrect mask calculation [ Upstream commit 208a68c8393d6041a90862992222f3d7943d44d6 ] On some machines, iio-sensor-proxy was returning all 0's for IIO sensor values. It turns out that the bits_used for this sensor is 32, which makes the mask calculation: *mask = (1 << 32) - 1; If the compiler interprets the 1 literals as 32-bit ints, it generates undefined behavior depending on compiler version and optimization level. On my system, it optimizes out the shift, so the mask value becomes *mask = (1) - 1; With a mask value of 0, iio-sensor-proxy will always return 0 for every axis. Avoid incorrect 0 values caused by compiler optimization. See original fix by Brett Dutro in iio-sensor-proxy: https://github.com/hadess/iio-sensor-proxy/commit/9615ceac7c134d838660e209726cd86aa2064fd3 Signed-off-by: Bastien Nocera Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit fae39a0c5cd3e0e1c4508a7f3f862e482773cb03 Author: Bharat Kumar Gogada Date: Wed Jun 12 15:47:59 2019 +0530 PCI: xilinx-nwl: Fix Multi MSI data programming [ Upstream commit 181fa434d0514e40ebf6e9721f2b72700287b6e2 ] According to the PCI Local Bus specification Revision 3.0, section 6.8.1.3 (Message Control for MSI), endpoints that are Multiple Message Capable as defined by bits [3:1] in the Message Control for MSI can request a number of vectors that is power of two aligned. As specified in section 6.8.1.6 "Message data for MSI", the Multiple Message Enable field (bits [6:4] of the Message Control register) defines the number of low order message data bits the function is permitted to modify to generate its system software allocated vectors. The MSI controller in the Xilinx NWL PCIe controller supports a number of MSI vectors specified through a bitmap and the hwirq number for an MSI, that is the value written in the MSI data TLP is determined by the bitmap allocation. For instance, in a situation where two endpoints sitting on the PCI bus request the following MSI configuration, with the current PCI Xilinx bitmap allocation code (that does not align MSI vector allocation on a power of two boundary): Endpoint #1: Requesting 1 MSI vector - allocated bitmap bits 0 Endpoint #2: Requesting 2 MSI vectors - allocated bitmap bits [1,2] The bitmap value(s) corresponds to the hwirq number that is programmed into the Message Data for MSI field in the endpoint MSI capability and is detected by the root complex to fire the corresponding MSI irqs. The value written in Message Data for MSI field corresponds to the first bit allocated in the bitmap for Multi MSI vectors. The current Xilinx NWL MSI allocation code allows a bitmap allocation that is not a power of two boundaries, so endpoint #2, is allowed to toggle Message Data bit[0] to differentiate between its two vectors (meaning that the MSI data will be respectively 0x0 and 0x1 for the two vectors allocated to endpoint #2). This clearly aliases with the Endpoint #1 vector allocation, resulting in a broken Multi MSI implementation. Update the code to allocate MSI bitmap ranges with a power of two alignment, fixing the bug. Fixes: ab597d35ef11 ("PCI: xilinx-nwl: Add support for Xilinx NWL PCIe Host Controller") Suggested-by: Marc Zyngier Signed-off-by: Bharat Kumar Gogada [lorenzo.pieralisi@arm.com: updated commit log] Signed-off-by: Lorenzo Pieralisi Acked-by: Marc Zyngier Signed-off-by: Sasha Levin commit 542bb544bbdb37ca7366e25c9074744da46fb399 Author: Neil Armstrong Date: Wed Jun 5 11:02:15 2019 +0200 phy: meson-g12a-usb3-pcie: disable locking for cr_regmap [ Upstream commit 5fc2aa3ec9efad97dd7c316f3c8e4c6268bbed9b ] Locking is not needed for the phy_g12a_usb3_pcie_cr_bus_read/write() and currently it causes the following BUG because of the usage of the regmap_read_poll_timeout() running in spinlock_irq, configured by regmap fast_io. Simply disable locking in the cr_regmap config since it's only used from the PHY init callback function. BUG: sleeping function called from invalid context at drivers/phy/amlogic/phy-meson-g12a-usb3-pcie.c:85 in_atomic(): 1, irqs_disabled(): 128, pid: 60, name: kworker/3:1 [snip] Workqueue: events deferred_probe_work_func Call trace: dump_backtrace+0x0/0x190 show_stack+0x14/0x20 dump_stack+0x90/0xb4 ___might_sleep+0xec/0x110 __might_sleep+0x50/0x88 phy_g12a_usb3_pcie_cr_bus_addr.isra.0+0x80/0x1a8 phy_g12a_usb3_pcie_cr_bus_read+0x34/0x1d8 _regmap_read+0x60/0xe0 _regmap_update_bits+0xc4/0x110 regmap_update_bits_base+0x60/0x90 phy_g12a_usb3_pcie_init+0xdc/0x210 phy_init+0x74/0xd0 dwc3_meson_g12a_probe+0x2cc/0x4d0 platform_drv_probe+0x50/0xa0 really_probe+0x20c/0x3b8 driver_probe_device+0x68/0x150 __device_attach_driver+0xa8/0x170 bus_for_each_drv+0x64/0xc8 __device_attach+0xd8/0x158 device_initial_probe+0x10/0x18 bus_probe_device+0x90/0x98 deferred_probe_work_func+0x94/0xe8 process_one_work+0x1e0/0x338 worker_thread+0x230/0x458 kthread+0x134/0x138 ret_from_fork+0x10/0x1c Fixes: 36077e16c050 ("phy: amlogic: Add Amlogic G12A USB3 + PCIE Combo PHY Driver") Signed-off-by: Neil Armstrong Tested-by: Kevin Hilman Signed-off-by: Kishon Vijay Abraham I Signed-off-by: Sasha Levin commit 667b1d0b964d6a05dd329dafff348657a63c4821 Author: Will Deacon Date: Tue Jun 18 14:10:48 2019 +0100 genksyms: Teach parser about 128-bit built-in types [ Upstream commit a222061b85234d8a44486a46bd4df7e2cda52385 ] __uint128_t crops up in a few files that export symbols to modules, so teach genksyms about it and the other GCC built-in 128-bit integer types so that we don't end up skipping the CRC generation for some symbols due to the parser failing to spot them: | WARNING: EXPORT symbol "kernel_neon_begin" [vmlinux] version | generation failed, symbol will not be versioned. | ld: arch/arm64/kernel/fpsimd.o: relocation R_AARCH64_ABS32 against | `__crc_kernel_neon_begin' can not be used when making a shared | object | ld: arch/arm64/kernel/fpsimd.o:(.data+0x0): dangerous relocation: | unsupported relocation Reported-by: Arnd Bergmann Signed-off-by: Will Deacon Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin commit b7eb5a63ab6442f6a03353461d5133f29a76bc8b Author: Nathan Chancellor Date: Tue Jun 11 11:43:31 2019 -0700 kbuild: Add -Werror=unknown-warning-option to CLANG_FLAGS [ Upstream commit 589834b3a0097a4908f4112eac0ca2feb486fa32 ] In commit ebcc5928c5d9 ("arm64: Silence gcc warnings about arch ABI drift"), the arm64 Makefile added -Wno-psabi to KBUILD_CFLAGS, which is a GCC only option so clang rightfully complains: warning: unknown warning option '-Wno-psabi' [-Wunknown-warning-option] https://clang.llvm.org/docs/DiagnosticsReference.html#wunknown-warning-option However, by default, this is merely a warning so the build happily goes on with a slew of these warnings in the process. Commit c3f0d0bc5b01 ("kbuild, LLVMLinux: Add -Werror to cc-option to support clang") worked around this behavior in cc-option by adding -Werror so that unknown flags cause an error. However, this all happens silently and when an unknown flag is added to the build unconditionally like -Wno-psabi, cc-option will always fail because there is always an unknown flag in the list of flags. This manifested as link time failures in the arm64 libstub because -fno-stack-protector didn't get added to KBUILD_CFLAGS. To avoid these weird cryptic failures in the future, make clang behave like gcc and immediately error when it encounters an unknown flag by adding -Werror=unknown-warning-option to CLANG_FLAGS. This can be added unconditionally for clang because it is supported by at least 3.0.0, according to godbolt [1] and 4.0.0, according to its documentation [2], which is far earlier than we typically support. [1]: https://godbolt.org/z/7F7rm3 [2]: https://releases.llvm.org/4.0.0/tools/clang/docs/DiagnosticsReference.html#wunknown-warning-option Link: https://github.com/ClangBuiltLinux/linux/issues/511 Link: https://github.com/ClangBuiltLinux/linux/issues/517 Suggested-by: Peter Smith Signed-off-by: Nathan Chancellor Tested-by: Nick Desaulniers Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin commit 1b5fbb2d3ab5971435341b4d1df8cc14a2326c59 Author: Fabrice Gasnier Date: Mon Jun 17 09:53:01 2019 +0200 i2c: stm32f7: fix the get_irq error cases [ Upstream commit 79b4499524ed659fb76323efc30f3dc03967c88f ] During probe, return the "get_irq" error value instead of -EINVAL which allows the driver to be deferred probed if needed. Fix also the case where of_irq_get() returns a negative value. Note : On failure of_irq_get() returns 0 or a negative value while platform_get_irq() returns a negative value. Fixes: aeb068c57214 ("i2c: i2c-stm32f7: add driver") Reviewed-by: Pierre-Yves MORDRET Signed-off-by: Fabien Dessenne Signed-off-by: Fabrice Gasnier Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit a96db791e00a88782984bac1fdd690fae82d3553 Author: Marek Vasut Date: Mon May 27 00:51:51 2019 +0200 PCI: sysfs: Ignore lockdep for remove attribute [ Upstream commit dc6b698a86fe40a50525433eb8e92a267847f6f9 ] With CONFIG_PROVE_LOCKING=y, using sysfs to remove a bridge with a device below it causes a lockdep warning, e.g., # echo 1 > /sys/class/pci_bus/0000:00/device/0000:00:00.0/remove ============================================ WARNING: possible recursive locking detected ... pci_bus 0000:01: busn_res: [bus 01] is released The remove recursively removes the subtree below the bridge. Each call uses a different lock so there's no deadlock, but the locks were all created with the same lockdep key so the lockdep checker can't tell them apart. Mark the "remove" sysfs attribute with __ATTR_IGNORE_LOCKDEP() as it is safe to ignore the lockdep check between different "remove" kernfs instances. There's discussion about a similar issue in USB at [1], which resulted in 356c05d58af0 ("sysfs: get rid of some lockdep false positives") and e9b526fe7048 ("i2c: suppress lockdep warning on delete_device"), which do basically the same thing for USB "remove" and i2c "delete_device" files. [1] https://lore.kernel.org/r/Pine.LNX.4.44L0.1204251436140.1206-100000@iolanthe.rowland.org Link: https://lore.kernel.org/r/20190526225151.3865-1-marek.vasut@gmail.com Signed-off-by: Marek Vasut [bhelgaas: trim commit log, details at above links] Signed-off-by: Bjorn Helgaas Cc: Geert Uytterhoeven Cc: Phil Edworthy Cc: Simon Horman Cc: Tejun Heo Cc: Wolfram Sang Signed-off-by: Sasha Levin commit ff33d296df0e5a7e412410d6ed8f5ff9064061f9 Author: Yoshihiro Shimoda Date: Mon Jun 10 15:23:55 2019 +0900 phy: renesas: rcar-gen3-usb2: fix imbalance powered flag [ Upstream commit 5c9dc6379f539c68a0fdd39e39a9d359545649e9 ] The powered flag should be set for any other phys anyway. Also the flag should be locked by the channel. Otherwise, after we have revised the device tree for the usb phy, the following warning happened during a second system suspend. And if the driver doesn't lock the flag, an imbalance is possible when enabling the regulator during system resume. So, this patch fixes the issues. < The warning > [ 56.026531] unbalanced disables for USB20_VBUS0 [ 56.031108] WARNING: CPU: 3 PID: 513 at drivers/regulator/core.c:2593 _regula tor_disable+0xe0/0x1c0 [ 56.040146] Modules linked in: rcar_du_drm rcar_lvds drm_kms_helper drm drm_p anel_orientation_quirks vsp1 videobuf2_vmalloc videobuf2_dma_contig videobuf2_me mops videobuf2_v4l2 videobuf2_common videodev snd_soc_rcar renesas_usbhs snd_soc _audio_graph_card media snd_soc_simple_card_utils crct10dif_ce renesas_usb3 snd_ soc_ak4613 rcar_fcp pwm_rcar usb_dmac phy_rcar_gen3_usb3 pwm_bl ipv6 [ 56.074047] CPU: 3 PID: 513 Comm: kworker/u16:19 Not tainted 5.2.0-rc3-00001- g5f20a19 #6 [ 56.082129] Hardware name: Renesas Salvator-X board based on r8a7795 ES2.0+ ( DT) [ 56.089524] Workqueue: events_unbound async_run_entry_fn [ 56.094832] pstate: 40000005 (nZcv daif -PAN -UAO) [ 56.099617] pc : _regulator_disable+0xe0/0x1c0 [ 56.104054] lr : _regulator_disable+0xe0/0x1c0 [ 56.108489] sp : ffff0000121c3ae0 [ 56.111796] x29: ffff0000121c3ae0 x28: 0000000000000000 [ 56.117102] x27: 0000000000000000 x26: ffff000010fe0e60 [ 56.122407] x25: 0000000000000002 x24: 0000000000000001 [ 56.127712] x23: 0000000000000002 x22: ffff8006f99d4000 [ 56.133017] x21: ffff8006f99cc000 x20: ffff8006f9846800 [ 56.138322] x19: ffff8006f9846800 x18: ffffffffffffffff [ 56.143626] x17: 0000000000000000 x16: 0000000000000000 [ 56.148931] x15: ffff0000112f96c8 x14: ffff0000921c37f7 [ 56.154235] x13: ffff0000121c3805 x12: ffff000011312000 [ 56.159540] x11: 0000000005f5e0ff x10: ffff0000112f9f20 [ 56.164844] x9 : ffff0000112d3018 x8 : 00000000000001ad [ 56.170149] x7 : 00000000ffffffcc x6 : ffff8006ff768180 [ 56.175453] x5 : ffff8006ff768180 x4 : 0000000000000000 [ 56.180758] x3 : ffff8006ff76ef10 x2 : ffff8006ff768180 [ 56.186062] x1 : 3d2eccbaead8fb00 x0 : 0000000000000000 [ 56.191367] Call trace: [ 56.193808] _regulator_disable+0xe0/0x1c0 [ 56.197899] regulator_disable+0x40/0x78 [ 56.201820] rcar_gen3_phy_usb2_power_off+0x3c/0x50 [ 56.206692] phy_power_off+0x48/0xd8 [ 56.210263] usb_phy_roothub_power_off+0x30/0x50 [ 56.214873] usb_phy_roothub_suspend+0x1c/0x50 [ 56.219311] hcd_bus_suspend+0x13c/0x168 [ 56.223226] generic_suspend+0x4c/0x58 [ 56.226969] usb_suspend_both+0x1ac/0x238 [ 56.230972] usb_suspend+0xcc/0x170 [ 56.234455] usb_dev_suspend+0x10/0x18 [ 56.238199] dpm_run_callback.isra.6+0x20/0x68 [ 56.242635] __device_suspend+0x110/0x308 [ 56.246637] async_suspend+0x24/0xa8 [ 56.250205] async_run_entry_fn+0x40/0xf8 [ 56.254210] process_one_work+0x1e0/0x320 [ 56.258211] worker_thread+0x40/0x450 [ 56.261867] kthread+0x124/0x128 [ 56.265094] ret_from_fork+0x10/0x18 [ 56.268661] ---[ end trace 86d7ec5de5c517af ]--- [ 56.273290] phy phy-ee080200.usb-phy.10: phy poweroff failed --> -5 Reported-by: Geert Uytterhoeven Fixes: 549b6b55b005 ("phy: renesas: rcar-gen3-usb2: enable/disable independent irqs") Signed-off-by: Yoshihiro Shimoda Reviewed-by: Geert Uytterhoeven Tested-by: Geert Uytterhoeven Reviewed-by: Simon Horman Signed-off-by: Kishon Vijay Abraham I Signed-off-by: Sasha Levin commit f24ce1c295b0f03be5862e296e6b83affa36f376 Author: Stefan Roese Date: Thu Jun 20 08:24:19 2019 +0200 serial: mctrl_gpio: Check if GPIO property exisits before requesting it [ Upstream commit d99482673f950817b30caf3fcdfb31179b050ce1 ] This patch adds a check for the GPIOs property existence, before the GPIO is requested. This fixes an issue seen when the 8250 mctrl_gpio support is added (2nd patch in this patch series) on x86 platforms using ACPI. Here Mika's comments from 2016-08-09: " I noticed that with v4.8-rc1 serial console of some of our Broxton systems does not work properly anymore. I'm able to see output but input does not work. I bisected it down to commit 4ef03d328769eddbfeca1f1c958fdb181a69c341 ("tty/serial/8250: use mctrl_gpio helpers"). The reason why it fails is that in ACPI we do not have names for GPIOs (except when _DSD is used) so we use the "idx" to index into _CRS GPIO resources. Now mctrl_gpio_init_noauto() goes through a list of GPIOs calling devm_gpiod_get_index_optional() passing "idx" of 0 for each. The UART device in Broxton has following (simplified) ACPI description: Device (URT4) { ... Name (_CRS, ResourceTemplate () { GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly, "\\_SB.GPO0", 0x00, ResourceConsumer) { 0x003A } GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly, "\\_SB.GPO0", 0x00, ResourceConsumer) { 0x003D } }) In this case it finds the first GPIO (0x003A which happens to be RX pin for that UART), turns it into GPIO which then breaks input for the UART device. This also breaks systems with bluetooth connected to UART (those typically have some GPIOs in their _CRS). Any ideas how to fix this? We cannot just drop the _CRS index lookup fallback because that would break many existing machines out there so maybe we can limit this to only DT enabled machines. Or alternatively probe if the property first exists before trying to acquire the GPIOs (using device_property_present()). " This patch implements the fix suggested by Mika in his statement above. Signed-off-by: Stefan Roese Reviewed-by: Mika Westerberg Reviewed-by: Andy Shevchenko Tested-by: Yegor Yefremov Cc: Mika Westerberg Cc: Andy Shevchenko Cc: Yegor Yefremov Cc: Greg Kroah-Hartman Cc: Giulio Benetti Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 29aed715d251f4da9cc0660229c2c328f157f80a Author: Sean Paul Date: Mon Jun 17 16:12:51 2019 -0400 drm/msm: Depopulate platform on probe failure [ Upstream commit 4368a1539c6b41ac3cddc06f5a5117952998804c ] add_display_components() calls of_platform_populate, and we depopluate on pdev remove, but not when probe fails. So if we get a probe deferral in one of the components, we won't depopulate the platform. This causes the core to keep references to devices which should be destroyed, which causes issues when those same devices try to re-initialize on the next probe attempt. I think this is the reason we had issues with the gmu's device-managed resources on deferral (worked around in commit 94e3a17f33a5). Reviewed-by: Rob Clark Signed-off-by: Sean Paul Link: https://patchwork.freedesktop.org/patch/msgid/20190617201301.133275-3-sean@poorly.run Signed-off-by: Sasha Levin commit 1b404f35dfa3934f5db3c8cf97832ea811ff53e0 Author: Alexey Kardashevskiy Date: Wed Jun 5 13:38:14 2019 +1000 powerpc/pci/of: Fix OF flags parsing for 64bit BARs [ Upstream commit df5be5be8735ef2ae80d5ae1f2453cd81a035c4b ] When the firmware does PCI BAR resource allocation, it passes the assigned addresses and flags (prefetch/64bit/...) via the "reg" property of a PCI device device tree node so the kernel does not need to do resource allocation. The flags are stored in resource::flags - the lower byte stores PCI_BASE_ADDRESS_SPACE/etc bits and the other bytes are IORESOURCE_IO/etc. Some flags from PCI_BASE_ADDRESS_xxx and IORESOURCE_xxx are duplicated, such as PCI_BASE_ADDRESS_MEM_PREFETCH/PCI_BASE_ADDRESS_MEM_TYPE_64/etc. When parsing the "reg" property, we copy the prefetch flag but we skip on PCI_BASE_ADDRESS_MEM_TYPE_64 which leaves the flags out of sync. The missing IORESOURCE_MEM_64 flag comes into play under 2 conditions: 1. we remove PCI_PROBE_ONLY for pseries (by hacking pSeries_setup_arch() or by passing "/chosen/linux,pci-probe-only"); 2. we request resource alignment (by passing pci=resource_alignment= via the kernel cmd line to request PAGE_SIZE alignment or defining ppc_md.pcibios_default_alignment which returns anything but 0). Note that the alignment requests are ignored if PCI_PROBE_ONLY is enabled. With 1) and 2), the generic PCI code in the kernel unconditionally decides to: - reassign the BARs in pci_specified_resource_alignment() (works fine) - write new BARs to the device - this fails for 64bit BARs as the generic code looks at IORESOURCE_MEM_64 (not set) and writes only lower 32bits of the BAR and leaves the upper 32bit unmodified which breaks BAR mapping in the hypervisor. This fixes the issue by copying the flag. This is useful if we want to enforce certain BAR alignment per platform as handling subpage sized BARs is proven to cause problems with hotplug (SLOF already aligns BARs to 64k). Signed-off-by: Alexey Kardashevskiy Reviewed-by: Sam Bobroff Reviewed-by: Oliver O'Halloran Reviewed-by: Shawn Anastasio Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit 9a08330437d65334e3ca600ef4fdb49177f9f880 Author: Jordan Crouse Date: Fri May 31 16:09:38 2019 -0600 drm/msm/adreno: Ensure that the zap shader region is big enough [ Upstream commit 6672e11cad662ce6631e04c38f92a140a99c042c ] Before loading the zap shader we should ensure that the reserved memory region is big enough to hold the loaded file. Signed-off-by: Jordan Crouse Reviewed-by: Bjorn Andersson Reviewed-by: Jeffrey Hugo Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 3543f9977de4888da88fc9085e6357db88e9fcca Author: Eugene Korenevsky Date: Thu Jun 6 00:19:16 2019 +0300 kvm: vmx: segment limit check: use access length [ Upstream commit fdb28619a8f033c13f5d9b9e8b5536bb6e68a2c3 ] There is an imperfection in get_vmx_mem_address(): access length is ignored when checking the limit. To fix this, pass access length as a function argument. The access length is usually obvious since it is used by callers after get_vmx_mem_address() call, but for vmread/vmwrite it depends on the state of 64-bit mode. Signed-off-by: Eugene Korenevsky Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 09878d15216ee86d4e0c63d7ec6cdadb699cae45 Author: Sean Christopherson Date: Tue May 7 08:36:24 2019 -0700 KVM: nVMX: Intercept VMWRITEs to GUEST_{CS,SS}_AR_BYTES [ Upstream commit b643780562af5378ef7fe731c65b8f93e49c59c6 ] VMMs frequently read the guest's CS and SS AR bytes to detect 64-bit mode and CPL respectively, but effectively never write said fields once the VM is initialized. Intercepting VMWRITEs for the two fields saves ~55 cycles in copy_shadow_to_vmcs12(). Because some Intel CPUs, e.g. Haswell, drop the reserved bits of the guest access rights fields on VMWRITE, exposing the fields to L1 for VMREAD but not VMWRITE leads to inconsistent behavior between L1 and L2. On hardware that drops the bits, L1 will see the stripped down value due to reading the value from hardware, while L2 will see the full original value as stored by KVM. To avoid such an inconsistency, emulate the behavior on all CPUS, but only for intercepted VMWRITEs so as to avoid introducing pointless latency into copy_shadow_to_vmcs12(), e.g. if the emulation were added to vmcs12_write_any(). Since the AR_BYTES emulation is done only for intercepted VMWRITE, if a future patch (re)exposed AR_BYTES for both VMWRITE and VMREAD, then KVM would end up with incosistent behavior on pre-Haswell hardware, e.g. KVM would drop the reserved bits on intercepted VMWRITE, but direct VMWRITE to the shadow VMCS would not drop the bits. Add a WARN in the shadow field initialization to detect any attempt to expose an AR_BYTES field without updating vmcs12_write_any(). Note, emulation of the AR_BYTES reserved bit behavior is based on a patch[1] from Jim Mattson that applied the emulation to all writes to vmcs12 so that live migration across different generations of hardware would not introduce divergent behavior. But given that live migration of nested state has already been enabled, that ship has sailed (not to mention that no sane VMM will be affected by this behavior). [1] https://patchwork.kernel.org/patch/10483321/ Cc: Jim Mattson Cc: Liran Alon Signed-off-by: Sean Christopherson Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit b0e98a3b9bec63400865bf49d07156ce377780ff Author: Raul E Rangel Date: Mon Jun 17 14:10:13 2019 -0600 mmc: sdhci: sdhci-pci-o2micro: Check if controller supports 8-bit width [ Upstream commit de23f0b757766d9fae59df97da6e8bdc5b231351 ] The O2 controller supports 8-bit EMMC access. JESD84-B51 section A.6.3.a defines the bus testing procedure that `mmc_select_bus_width()` implements. This is used to determine the actual bus width of the eMMC. Signed-off-by: Raul E Rangel Acked-by: Adrian Hunter Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit fd094a14290d716d901e99c356010d9ecba02d78 Author: Eugene Korenevsky Date: Thu Jun 6 00:17:39 2019 +0300 kvm: vmx: fix limit checking in get_vmx_mem_address() [ Upstream commit c1a9acbc5295e278d788e9f7510f543bc9864fa2 ] Intel SDM vol. 3, 5.3: The processor causes a general-protection exception (or, if the segment is SS, a stack-fault exception) any time an attempt is made to access the following addresses in a segment: - A byte at an offset greater than the effective limit - A word at an offset greater than the (effective-limit – 1) - A doubleword at an offset greater than the (effective-limit – 3) - A quadword at an offset greater than the (effective-limit – 7) Therefore, the generic limit checking error condition must be exn = (off > limit + 1 - access_len) = (off + access_len - 1 > limit) but not exn = (off + access_len > limit) as for now. Also avoid integer overflow of `off` at 32-bit KVM by casting it to u64. Note: access length is currently sizeof(u64) which is incorrect. This will be fixed in the subsequent patch. Signed-off-by: Eugene Korenevsky Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit e5415333692ec09187ad9bee1cb6115fdc667fad Author: Enric Balletbo i Serra Date: Thu Jun 13 17:01:07 2019 +0200 usb: dwc3: Fix core validation in probe, move after clocks are enabled [ Upstream commit dc1b5d9aed1794b5a1c6b0da46e372cc09974cbc ] The required clocks needs to be enabled before the first register access. After commit fe8abf332b8f ("usb: dwc3: support clocks and resets for DWC3 core"), this happens when the dwc3_core_is_valid function is called, but the mentioned commit adds that call in the wrong place, before the clocks are enabled. So, move that call after the clk_bulk_enable() to ensure the clocks are enabled and the reset deasserted. I detected this while, as experiment, I tried to move the clocks and resets from the glue layer to the DWC3 core on a Samsung Chromebook Plus. That was not detected before because, in most cases, the glue layer initializes SoC-specific things and then populates the child "snps,dwc3" with those clocks already enabled. Fixes: b873e2d0ea1ef ("usb: dwc3: Do core validation early on probe") Signed-off-by: Enric Balletbo i Serra Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit 4b2163461e306768c0fa3418094d16b0bd6d7d16 Author: Andrzej Pietrasiewicz Date: Mon Jun 3 19:05:28 2019 +0200 usb: gadget: Zero ffs_io_data [ Upstream commit 508595515f4bcfe36246e4a565cf280937aeaade ] In some cases the "Allocate & copy" block in ffs_epfile_io() is not executed. Consequently, in such a case ffs_alloc_buffer() is never called and struct ffs_io_data is not initialized properly. This in turn leads to problems when ffs_free_buffer() is called at the end of ffs_epfile_io(). This patch uses kzalloc() instead of kmalloc() in the aio case and memset() in non-aio case to properly initialize struct ffs_io_data. Signed-off-by: Andrzej Pietrasiewicz Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit d9dbb3c00483afb626f8a6ba644244c6bdfcc43a Author: Serge Semin Date: Wed May 8 13:44:41 2019 +0300 tty: serial_core: Set port active bit in uart_port_activate [ Upstream commit 13b18d35909707571af9539f7731389fbf0feb31 ] A bug was introduced by commit b3b576461864 ("tty: serial_core: convert uart_open to use tty_port_open"). It caused a constant warning printed into the system log regarding the tty and port counter mismatch: [ 21.644197] ttyS ttySx: tty_port_close_start: tty->count = 1 port count = 2 in case if session hangup was detected so the warning is printed starting from the second open-close iteration. Particularly the problem was discovered in situation when there is a serial tty device without hardware back-end being setup. It is considered by the tty-serial subsystems as a hardware problem with session hang up. In this case uart_startup() will return a positive value with TTY_IO_ERROR flag set in corresponding tty_struct instance. The same value will get passed to be returned from the activate() callback and then being returned from tty_port_open(). But since in this case tty_port_block_til_ready() isn't called the TTY_PORT_ACTIVE flag isn't set (while the method had been called before tty_port_open conversion was introduced and the rest of the subsystem code expected the bit being set in this case), which prevents the uart_hangup() method to perform any cleanups including the tty port counter setting to zero. So the next attempt to open/close the tty device will discover the counters mismatch. In order to fix the problem we need to manually set the TTY_PORT_ACTIVE flag in case if uart_startup() returned a positive value. In this case the hang up procedure will perform a full set of cleanup actions including the port ref-counter resetting. Fixes: b3b576461864 "tty: serial_core: convert uart_open to use tty_port_open" Signed-off-by: Serge Semin Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit c9712e3338098359a82c3f5d198c92688fa6cd26 Author: Shubhrajyoti Datta Date: Wed Jun 12 13:14:38 2019 +0200 serial: uartps: Use the same dynamic major number for all ports [ Upstream commit ab262666018de6f4e206b021386b93ed0c164316 ] Let kernel to find out major number dynamically for the first device and then reuse it for other instances. This fixes the issue that each uart is registered with a different major number. After the patch: crw------- 1 root root 253, 0 Jun 10 08:31 /dev/ttyPS0 crw--w---- 1 root root 253, 1 Jan 1 1970 /dev/ttyPS1 Fixes: 024ca329bfb9 ("serial: uartps: Register own uart console and driver structures") Signed-off-by: Shubhrajyoti Datta Signed-off-by: Michal Simek Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit e3d4d2459c472d12aa067b2ff03a47183c07adea Author: Sergey Organov Date: Tue Jun 11 15:05:24 2019 +0300 serial: imx: fix locking in set_termios() [ Upstream commit 4e828c3e09201512be5ee162393f334321f7cf01 ] imx_uart_set_termios() called imx_uart_rts_active(), or imx_uart_rts_inactive() before taking port->port.lock. As a consequence, sport->port.mctrl that these functions modify could have been changed without holding port->port.lock. Moved locking of port->port.lock above the calls to fix the issue. Signed-off-by: Sergey Organov Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 943ab89e8ccbe7f725367549853d895dff49979d Author: Alexandru Ardelean Date: Wed May 29 16:01:08 2019 +0300 iio: adxl372: fix iio_triggered_buffer_{pre,post}enable positions [ Upstream commit 0e4f0b42f42d88507b48282c8915f502551534e4 ] The iio_triggered_buffer_{predisable,postenable} functions attach/detach the poll functions. For the predisable hook, the disable code should occur before detaching the poll func, and for the postenable hook, the poll func should be attached before the enable code. Signed-off-by: Alexandru Ardelean Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 5c92bf4d717392a41cc0df0e5c2e917810f1d829 Author: Yurii Pavlovskyi Date: Tue May 14 20:54:50 2019 +0200 platform/x86: asus-wmi: Increase input buffer size of WMI methods [ Upstream commit 98e865a522983f2afde075648ec9d15ea4bb9194 ] The asus-nb-wmi driver is matched by WMI alias but fails to load on TUF Gaming series laptops producing multiple ACPI errors in the kernel log. The input buffer for WMI method invocation size is 2 dwords, whereas 3 are expected by this model. FX505GM: .. Method (WMNB, 3, Serialized) { P8XH (Zero, 0x11) CreateDWordField (Arg2, Zero, IIA0) CreateDWordField (Arg2, 0x04, IIA1) CreateDWordField (Arg2, 0x08, IIA2) Local0 = (Arg1 & 0xFFFFFFFF) ... Compare with older K54C: ... Method (WMNB, 3, NotSerialized) { CreateDWordField (Arg2, 0x00, IIA0) CreateDWordField (Arg2, 0x04, IIA1) Local0 = (Arg1 & 0xFFFFFFFF) ... Increase buffer size to 3 dwords. No negative consequences of this change are expected, as the input buffer size is not verified. The original function is replaced by a wrapper for a new method passing value 0 for the last parameter. The new function will be used to control RGB keyboard backlight. Signed-off-by: Yurii Pavlovskyi Reviewed-by: Daniel Drake Signed-off-by: Andy Shevchenko Signed-off-by: Sasha Levin commit 1a93cdd8c9a44aa49328a75b2ddcc84029dbb242 Author: Douglas Anderson Date: Fri Jun 14 15:47:29 2019 -0700 drm/rockchip: Properly adjust to a true clock in adjusted_mode [ Upstream commit 99b9683f2142b20bad78e61f7f829e8714e45685 ] When fixing up the clock in vop_crtc_mode_fixup() we're not doing it quite correctly. Specifically if we've got the true clock 266666667 Hz, we'll perform this calculation: 266666667 / 1000 => 266666 Later when we try to set the clock we'll do clk_set_rate(266666 * 1000). The common clock framework won't actually pick the proper clock in this case since it always wants clocks <= the specified one. Let's solve this by using DIV_ROUND_UP. Fixes: b59b8de31497 ("drm/rockchip: return a true clock rate to adjusted_mode") Signed-off-by: Douglas Anderson Signed-off-by: Sean Paul Reviewed-by: Yakir Yang Signed-off-by: Heiko Stuebner Link: https://patchwork.freedesktop.org/patch/msgid/20190614224730.98622-1-dianders@chromium.org Signed-off-by: Sasha Levin commit 724f88e5ed64608d71d378688ce5dc4b4bfb9281 Author: Florian Fainelli Date: Mon Jun 10 15:54:37 2019 -0700 dma-remap: Avoid de-referencing NULL atomic_pool [ Upstream commit 4b4b077cbd0a998aebaa72c199e06b8a4c8dcfee ] With architectures allowing the kernel to be placed almost arbitrarily in memory (e.g.: ARM64), it is possible to have the kernel resides at physical addresses above 4GB, resulting in neither the default CMA area, nor the atomic pool from successfully allocating. This does not prevent specific peripherals from working though, one example is XHCI, which still operates correctly. Trouble comes when the XHCI driver gets suspended and resumed, since we can now trigger the following NPD: [ 12.664170] usb usb1: root hub lost power or was reset [ 12.669387] usb usb2: root hub lost power or was reset [ 12.674662] Unable to handle kernel NULL pointer dereference at virtual address 00000008 [ 12.682896] pgd = ffffffc1365a7000 [ 12.686386] [00000008] *pgd=0000000136500003, *pud=0000000136500003, *pmd=0000000000000000 [ 12.694897] Internal error: Oops: 96000006 [#1] SMP [ 12.699843] Modules linked in: [ 12.702980] CPU: 0 PID: 1499 Comm: pml Not tainted 4.9.135-1.13pre #51 [ 12.709577] Hardware name: BCM97268DV (DT) [ 12.713736] task: ffffffc136bb6540 task.stack: ffffffc1366cc000 [ 12.719740] PC is at addr_in_gen_pool+0x4/0x48 [ 12.724253] LR is at __dma_free+0x64/0xbc [ 12.728325] pc : [] lr : [] pstate: 60000145 [ 12.735825] sp : ffffffc1366cf990 [ 12.739196] x29: ffffffc1366cf990 x28: ffffffc1366cc000 [ 12.744608] x27: 0000000000000000 x26: ffffffc13a8568c8 [ 12.750020] x25: 0000000000000000 x24: ffffff80098f9000 [ 12.755433] x23: 000000013a5ff000 x22: ffffff8009c57000 [ 12.760844] x21: ffffffc13a856810 x20: 0000000000000000 [ 12.766255] x19: 0000000000001000 x18: 000000000000000a [ 12.771667] x17: 0000007f917553e0 x16: 0000000000001002 [ 12.777078] x15: 00000000000a36cb x14: ffffff80898feb77 [ 12.782490] x13: ffffffffffffffff x12: 0000000000000030 [ 12.787899] x11: 00000000fffffffe x10: ffffff80098feb7f [ 12.793311] x9 : 0000000005f5e0ff x8 : 65776f702074736f [ 12.798723] x7 : 6c2062756820746f x6 : ffffff80098febb1 [ 12.804134] x5 : ffffff800809797c x4 : 0000000000000000 [ 12.809545] x3 : 000000013a5ff000 x2 : 0000000000000fff [ 12.814955] x1 : ffffff8009c57000 x0 : 0000000000000000 [ 12.820363] [ 12.821907] Process pml (pid: 1499, stack limit = 0xffffffc1366cc020) [ 12.828421] Stack: (0xffffffc1366cf990 to 0xffffffc1366d0000) [ 12.834240] f980: ffffffc1366cf9e0 ffffff80086004d0 [ 12.842186] f9a0: ffffffc13ab08238 0000000000000010 ffffff80097c2218 ffffffc13a856810 [ 12.850131] f9c0: ffffff8009c57000 000000013a5ff000 0000000000000008 000000013a5ff000 [ 12.858076] f9e0: ffffffc1366cfa50 ffffff80085f9250 ffffffc13ab08238 0000000000000004 [ 12.866021] fa00: ffffffc13ab08000 ffffff80097b6000 ffffffc13ab08130 0000000000000001 [ 12.873966] fa20: 0000000000000008 ffffffc13a8568c8 0000000000000000 ffffffc1366cc000 [ 12.881911] fa40: ffffffc13ab08130 0000000000000001 ffffffc1366cfa90 ffffff80085e3de8 [ 12.889856] fa60: ffffffc13ab08238 0000000000000000 ffffffc136b75b00 0000000000000000 [ 12.897801] fa80: 0000000000000010 ffffff80089ccb92 ffffffc1366cfac0 ffffff80084ad040 [ 12.905746] faa0: ffffffc13a856810 0000000000000000 ffffff80084ad004 ffffff80084b91a8 [ 12.913691] fac0: ffffffc1366cfae0 ffffff80084b91b4 ffffffc13a856810 ffffff80080db5cc [ 12.921636] fae0: ffffffc1366cfb20 ffffff80084b96bc ffffffc13a856810 0000000000000010 [ 12.929581] fb00: ffffffc13a856870 0000000000000000 ffffffc13a856810 ffffff800984d2b8 [ 12.937526] fb20: ffffffc1366cfb50 ffffff80084baa70 ffffff8009932ad0 ffffff800984d260 [ 12.945471] fb40: 0000000000000010 00000002eff0a065 ffffffc1366cfbb0 ffffff80084bafbc [ 12.953415] fb60: 0000000000000010 0000000000000003 ffffff80098fe000 0000000000000000 [ 12.961360] fb80: ffffff80097b6000 ffffff80097b6dc8 ffffff80098c12b8 ffffff80098c12f8 [ 12.969306] fba0: ffffff8008842000 ffffff80097b6dc8 ffffffc1366cfbd0 ffffff80080e0d88 [ 12.977251] fbc0: 00000000fffffffb ffffff80080e10bc ffffffc1366cfc60 ffffff80080e16a8 [ 12.985196] fbe0: 0000000000000000 0000000000000003 ffffff80097b6000 ffffff80098fe9f0 [ 12.993140] fc00: ffffff80097d4000 ffffff8008983802 0000000000000123 0000000000000040 [ 13.001085] fc20: ffffff8008842000 ffffffc1366cc000 ffffff80089803c2 00000000ffffffff [ 13.009029] fc40: 0000000000000000 0000000000000000 ffffffc1366cfc60 0000000000040987 [ 13.016974] fc60: ffffffc1366cfcc0 ffffff80080dfd08 0000000000000003 0000000000000004 [ 13.024919] fc80: 0000000000000003 ffffff80098fea08 ffffffc136577ec0 ffffff80089803c2 [ 13.032864] fca0: 0000000000000123 0000000000000001 0000000500000002 0000000000040987 [ 13.040809] fcc0: ffffffc1366cfd00 ffffff80083a89d4 0000000000000004 ffffffc136577ec0 [ 13.048754] fce0: ffffffc136610cc0 ffffffffffffffea ffffffc1366cfeb0 ffffffc136610cd8 [ 13.056700] fd00: ffffffc1366cfd10 ffffff800822a614 ffffffc1366cfd40 ffffff80082295d4 [ 13.064645] fd20: 0000000000000004 ffffffc136577ec0 ffffffc136610cc0 0000000021670570 [ 13.072590] fd40: ffffffc1366cfd80 ffffff80081b5d10 ffffff80097b6000 ffffffc13aae4200 [ 13.080536] fd60: ffffffc1366cfeb0 0000000000000004 0000000021670570 0000000000000004 [ 13.088481] fd80: ffffffc1366cfe30 ffffff80081b6b20 ffffffc13aae4200 0000000000000000 [ 13.096427] fda0: 0000000000000004 0000000021670570 ffffffc1366cfeb0 ffffffc13a838200 [ 13.104371] fdc0: 0000000000000000 000000000000000a ffffff80097b6000 0000000000040987 [ 13.112316] fde0: ffffffc1366cfe20 ffffff80081b3af0 ffffffc13a838200 0000000000000000 [ 13.120261] fe00: ffffffc1366cfe30 ffffff80081b6b0c ffffffc13aae4200 0000000000000000 [ 13.128206] fe20: 0000000000000004 0000000000040987 ffffffc1366cfe70 ffffff80081b7dd8 [ 13.136151] fe40: ffffff80097b6000 ffffffc13aae4200 ffffffc13aae4200 fffffffffffffff7 [ 13.144096] fe60: 0000000021670570 ffffffc13a8c63c0 0000000000000000 ffffff8008083180 [ 13.152042] fe80: ffffffffffffff1d 0000000021670570 ffffffffffffffff 0000007f917ad9b8 [ 13.159986] fea0: 0000000020000000 0000000000000015 0000000000000000 0000000000040987 [ 13.167930] fec0: 0000000000000001 0000000021670570 0000000000000004 0000000000000000 [ 13.175874] fee0: 0000000000000888 0000440110000000 000000000000006d 0000000000000003 [ 13.183819] ff00: 0000000000000040 ffffff80ffffffc8 0000000000000000 0000000000000020 [ 13.191762] ff20: 0000000000000000 0000000000000000 0000000000000001 0000000000000000 [ 13.199707] ff40: 0000000000000000 0000007f917553e0 0000000000000000 0000000000000004 [ 13.207651] ff60: 0000000021670570 0000007f91835480 0000000000000004 0000007f91831638 [ 13.215595] ff80: 0000000000000004 00000000004b0de0 00000000004b0000 0000000000000000 [ 13.223539] ffa0: 0000000000000000 0000007fc92ac8c0 0000007f9175d178 0000007fc92ac8c0 [ 13.231483] ffc0: 0000007f917ad9b8 0000000020000000 0000000000000001 0000000000000040 [ 13.239427] ffe0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 13.247360] Call trace: [ 13.249866] Exception stack(0xffffffc1366cf7a0 to 0xffffffc1366cf8d0) [ 13.256386] f7a0: 0000000000001000 0000007fffffffff ffffffc1366cf990 ffffff80083c0df8 [ 13.264331] f7c0: 0000000060000145 ffffff80089b5001 ffffffc13ab08130 0000000000000001 [ 13.272275] f7e0: 0000000000000008 ffffffc13a8568c8 0000000000000000 0000000000000000 [ 13.280220] f800: ffffffc1366cf960 ffffffc1366cf960 ffffffc1366cf930 00000000ffffffd8 [ 13.288165] f820: ffffff8009931ac0 4554535953425553 4544006273753d4d 3831633d45434956 [ 13.296110] f840: ffff003832313a39 ffffff800845926c ffffffc1366cf880 0000000000040987 [ 13.304054] f860: 0000000000000000 ffffff8009c57000 0000000000000fff 000000013a5ff000 [ 13.311999] f880: 0000000000000000 ffffff800809797c ffffff80098febb1 6c2062756820746f [ 13.319944] f8a0: 65776f702074736f 0000000005f5e0ff ffffff80098feb7f 00000000fffffffe [ 13.327884] f8c0: 0000000000000030 ffffffffffffffff [ 13.332835] [] addr_in_gen_pool+0x4/0x48 [ 13.338398] [] xhci_mem_cleanup+0xc8/0x51c [ 13.344137] [] xhci_resume+0x308/0x65c [ 13.349524] [] xhci_brcm_resume+0x84/0x8c [ 13.355174] [] platform_pm_resume+0x3c/0x64 [ 13.360997] [] dpm_run_callback+0x5c/0x15c [ 13.366732] [] device_resume+0xc0/0x190 [ 13.372205] [] dpm_resume+0x144/0x2cc [ 13.377504] [] dpm_resume_end+0x20/0x34 [ 13.382980] [] suspend_devices_and_enter+0x104/0x704 [ 13.389585] [] pm_suspend+0x320/0x53c [ 13.394881] [] state_store+0xbc/0xe0 [ 13.400094] [] kobj_attr_store+0x14/0x24 [ 13.405655] [] sysfs_kf_write+0x60/0x70 [ 13.411128] [] kernfs_fop_write+0x130/0x194 [ 13.416954] [] __vfs_write+0x60/0x150 [ 13.422254] [] vfs_write+0xc8/0x164 [ 13.427376] [] SyS_write+0x70/0xc8 [ 13.432412] [] el0_svc_naked+0x34/0x38 [ 13.437800] Code: 92800173 97f6fb9e 17fffff5 d1000442 (f8408c03) [ 13.444033] ---[ end trace 2effe12f909ce205 ]--- The call path leading to this problem is xhci_mem_cleanup() -> dma_free_coherent() -> dma_free_from_pool() -> addr_in_gen_pool. If the atomic_pool is NULL, we can't possibly have the address in the atomic pool anyway, so guard against that. Signed-off-by: Florian Fainelli Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit e26242e226785f6148689673ec281f89b0bf2931 Author: Nathan Lynch Date: Tue Jun 11 23:45:05 2019 -0500 powerpc/pseries/mobility: prevent cpu hotplug during DT update [ Upstream commit e59a175faa8df9d674247946f2a5a9c29c835725 ] CPU online/offline code paths are sensitive to parts of the device tree (various cpu node properties, cache nodes) that can be changed as a result of a migration. Prevent CPU hotplug while the device tree potentially is inconsistent. Fixes: 410bccf97881 ("powerpc/pseries: Partition migration in the kernel") Signed-off-by: Nathan Lynch Reviewed-by: Gautham R. Shenoy Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit 23c2c8bdfa698a73a83e5e22e64c24f1a5be629c Author: Tomi Valkeinen Date: Mon Jun 10 16:57:39 2019 +0300 drm/bridge: tfp410: fix use of cancel_delayed_work_sync [ Upstream commit b1622cb3be4557fd086831ca7426eafe5f1acc2e ] We use delayed_work in HPD handling, and cancel any scheduled work in tfp410_fini using cancel_delayed_work_sync(). However, we have only initialized the delayed work if we actually have a HPD interrupt configured in the DT, but in the tfp410_fini, we always cancel the work, possibly causing a WARN(). Fix this by doing the cancel only if we actually had the delayed work set up. Signed-off-by: Tomi Valkeinen Signed-off-by: Andrzej Hajda Link: https://patchwork.freedesktop.org/patch/msgid/20190610135739.6077-2-tomi.valkeinen@ti.com Signed-off-by: Sasha Levin commit 141075746c8200d735bcd13b6145bc8983087bc3 Author: John Paul Adrian Glaubitz Date: Tue Jun 11 17:38:37 2019 +0200 sunhv: Fix device naming inconsistency between sunhv_console and sunhv_reg [ Upstream commit 07a6d63eb1b54b5fb38092780fe618dfe1d96e23 ] In d5a2aa24, the name in struct console sunhv_console was changed from "ttyS" to "ttyHV" while the name in struct uart_ops sunhv_pops remained unchanged. This results in the hypervisor console device to be listed as "ttyHV0" under /proc/consoles while the device node is still named "ttyS0": root@osaka:~# cat /proc/consoles ttyHV0 -W- (EC p ) 4:64 tty0 -WU (E ) 4:1 root@osaka:~# readlink /sys/dev/char/4:64 ../../devices/root/f02836f0/f0285690/tty/ttyS0 root@osaka:~# This means that any userland code which tries to determine the name of the device file of the hypervisor console device can not rely on the information provided by /proc/consoles. In particular, booting current versions of debian- installer inside a SPARC LDOM will fail with the installer unable to determine the console device. After renaming the device in struct uart_ops sunhv_pops to "ttyHV" as well, the inconsistency is fixed and it is possible again to determine the name of the device file of the hypervisor console device by reading the contents of /proc/console: root@osaka:~# cat /proc/consoles ttyHV0 -W- (EC p ) 4:64 tty0 -WU (E ) 4:1 root@osaka:~# readlink /sys/dev/char/4:64 ../../devices/root/f02836f0/f0285690/tty/ttyHV0 root@osaka:~# With this change, debian-installer works correctly when installing inside a SPARC LDOM. Signed-off-by: John Paul Adrian Glaubitz Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 91bac7fe5eb15a814312b0b532df193e51b09d01 Author: Hariprasad Kelam Date: Thu Jun 13 08:02:08 2019 +0530 drm/amd/display: fix compilation error [ Upstream commit 88099f53cc3717437f5fc9cf84205c5b65118377 ] this patch fixes below compilation error drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_hw_sequencer.c: In function ‘dcn10_apply_ctx_for_surface’: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_hw_sequencer.c:2378:3: error: implicit declaration of function ‘udelay’ [-Werror=implicit-function-declaration] udelay(underflow_check_delay_us); Signed-off-by: Hariprasad Kelam Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 506549767261d1a38718eae6ee8ccbb0c719bd71 Author: Yoshihiro Shimoda Date: Tue May 28 14:04:02 2019 +0900 phy: renesas: rcar-gen2: Fix memory leak at error paths [ Upstream commit d4a36e82924d3305a17ac987a510f3902df5a4b2 ] This patch fixes memory leak at error paths of the probe function. In for_each_child_of_node, if the loop returns, the driver should call of_put_node() before returns. Reported-by: Julia Lawall Fixes: 1233f59f745b237 ("phy: Renesas R-Car Gen2 PHY driver") Signed-off-by: Yoshihiro Shimoda Reviewed-by: Geert Uytterhoeven Signed-off-by: Kishon Vijay Abraham I Signed-off-by: Sasha Levin commit 123bcb4ea3b635c51b2c082e98126e5e0b75b969 Author: Samson Tam Date: Tue May 28 14:44:40 2019 -0400 drm/amd/display: set link->dongle_max_pix_clk to 0 on a disconnect [ Upstream commit 233d87a579b8adcc6da5823fa507ecb6675e7562 ] [Why] Found issue in EDID Emulation where if we connect a display using a passive HDMI-DP dongle, disconnect it and then try to emulate a display using DP, we could not see 4K modes. This was because on a disconnect, dongle_max_pix_clk was still set so when we emulate using DP, in dc_link_validate_mode_timing(), it would think we were still using a dongle and limit the modes we support. [How] In dc_link_detect(), set dongle_max_pix_clk to 0 when we detect a hotplug out ( if new_connection_type = dc_connection_none ). Signed-off-by: Samson Tam Reviewed-by: Jun Lei Acked-by: Bhawanpreet Lakha Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 8afce646df193bbaabdd75894c71f3bcb46f83ca Author: David Riley Date: Mon Jun 10 14:18:10 2019 -0700 drm/virtio: Add memory barriers for capset cache. [ Upstream commit 9ff3a5c88e1f1ab17a31402b96d45abe14aab9d7 ] After data is copied to the cache entry, atomic_set is used indicate that the data is the entry is valid without appropriate memory barriers. Similarly the read side was missing the corresponding memory barriers. Signed-off-by: David Riley Link: http://patchwork.freedesktop.org/patch/msgid/20190610211810.253227-5-davidriley@chromium.org Signed-off-by: Gerd Hoffmann Signed-off-by: Sasha Levin commit 63f02a45405d7ef502fd30d581a363a3bce56920 Author: Wesley Chalmers Date: Thu May 16 12:40:25 2019 -0400 drm/amd/display: Update link rate from DPCD 10 [ Upstream commit 53c81fc7875bc2dca358485dac3999e14ec91a00 ] [WHY] Some panels return a link rate of 0 (unknown) in DPCD 0. In this case, an appropriate mode cannot be set, and certain panels will show corruption as they are forced to use a mode they do not support. [HOW] Read DPCD 10 in the case where supported link rate from DPCD 0 is unknown, and pass that value on to the reported link rate. This re-introduces behaviour present in previous versions that appears to have been accidentally removed. Signed-off-by: Wesley Chalmers Reviewed-by: Anthony Koo Acked-by: Bhawanpreet Lakha Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit bdd2a87af3116e103cb19b86a5115470444dc357 Author: Nicholas Kazlauskas Date: Tue Jun 4 15:21:14 2019 -0400 drm/amd/display: Always allocate initial connector state state [ Upstream commit f04bee34d6e35df26cbb2d65e801adfd0d8fe20d ] [Why] Unlike our regular connectors, MST connectors don't start off with an initial connector state. This causes a NULL pointer dereference to occur when attaching the bpc property since it tries to modify the connector state. We need an initial connector state on the connector to avoid the crash. [How] Use our reset helper to allocate an initial state and reset the values to their defaults. We were already doing this before, just not for MST connectors. Signed-off-by: Nicholas Kazlauskas Reviewed-by: Leo Li Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 3ba9ffa4b4ece4d92bf3935578115e7d6dc452cc Author: Alan Mikhak Date: Thu May 23 14:47:59 2019 -0700 PCI: endpoint: Allocate enough space for fixed size BAR [ Upstream commit f16fb16ed16c7f561e9c41c9ae4107c7f6aa553c ] PCI endpoint test function code should honor the .bar_fixed_size parameter from underlying endpoint controller drivers or results may be unexpected. In pci_epf_test_alloc_space(), check if BAR being used for test register space is a fixed size BAR. If so, allocate the required fixed size. Signed-off-by: Alan Mikhak Signed-off-by: Lorenzo Pieralisi Acked-by: Kishon Vijay Abraham I Signed-off-by: Sasha Levin commit d7d97f4696916fa6010e15d0730a6c4e8e765f2e Author: Rautkoski Kimmo EXT Date: Fri May 24 09:19:22 2019 +0000 serial: 8250: Fix TX interrupt handling condition [ Upstream commit db1b5bc047b3cadaedab3826bba82c3d9e023c4b ] Interrupt handler checked THRE bit (transmitter holding register empty) in LSR to detect if TX fifo is empty. In case when there is only receive interrupts the TX handling got called because THRE bit in LSR is set when there is no transmission (FIFO empty). TX handling caused TX stop, which in RS-485 half-duplex mode actually resets receiver FIFO. This is not desired during reception because of possible data loss. The fix is to check if THRI is set in IER in addition of the TX fifo status. THRI in IER is set when TX is started and cleared when TX is stopped. This ensures that TX handling is only called when there is really transmission on going and an interrupt for THRE and not when there are only RX interrupts. Signed-off-by: Kimmo Rautkoski Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit f3399d6e5def2877ad6febd973012a9816b5e3ba Author: Jorge Ramirez-Ortiz Date: Mon Jun 10 19:23:08 2019 +0200 tty: serial: msm_serial: avoid system lockup condition [ Upstream commit ba3684f99f1b25d2a30b6956d02d339d7acb9799 ] The function msm_wait_for_xmitr can be taken with interrupts disabled. In order to avoid a potential system lockup - demonstrated under stress testing conditions on SoC QCS404/5 - make sure we wait for a bounded amount of time. Tested on SoC QCS404. Signed-off-by: Jorge Ramirez-Ortiz Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit f0728a6e34ee4dbb846945824d582ad258eca99a Author: Kefeng Wang Date: Fri May 31 21:37:33 2019 +0800 tty/serial: digicolor: Fix digicolor-usart already registered warning [ Upstream commit c7ad9ba0611c53cfe194223db02e3bca015f0674 ] When modprobe/rmmod/modprobe module, if platform_driver_register() fails, the kernel complained, proc_dir_entry 'driver/digicolor-usart' already registered WARNING: CPU: 1 PID: 5636 at fs/proc/generic.c:360 proc_register+0x19d/0x270 Fix this by adding uart_unregister_driver() when platform_driver_register() fails. Reported-by: Hulk Robot Signed-off-by: Kefeng Wang Acked-by: Baruch Siach Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 5b885e012f60cea6e78e0d812eb5ea2e19539351 Author: Wang Hai Date: Wed May 15 22:37:25 2019 +0800 memstick: Fix error cleanup path of memstick_init [ Upstream commit 65f1a0d39c289bb6fc85635528cd36c4b07f560e ] If bus_register fails. On its error handling path, it has cleaned up what it has done. There is no need to call bus_unregister again. Otherwise, if bus_unregister is called, issues such as null-ptr-deref will arise. Syzkaller report this: kobject_add_internal failed for memstick (error: -12 parent: bus) BUG: KASAN: null-ptr-deref in sysfs_remove_file_ns+0x1b/0x40 fs/sysfs/file.c:467 Read of size 8 at addr 0000000000000078 by task syz-executor.0/4460 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0xa9/0x10e lib/dump_stack.c:113 __kasan_report+0x171/0x18d mm/kasan/report.c:321 kasan_report+0xe/0x20 mm/kasan/common.c:614 sysfs_remove_file_ns+0x1b/0x40 fs/sysfs/file.c:467 sysfs_remove_file include/linux/sysfs.h:519 [inline] bus_remove_file+0x6c/0x90 drivers/base/bus.c:145 remove_probe_files drivers/base/bus.c:599 [inline] bus_unregister+0x6e/0x100 drivers/base/bus.c:916 ? 0xffffffffc1590000 memstick_init+0x7a/0x1000 [memstick] do_one_initcall+0xb9/0x3b5 init/main.c:914 do_init_module+0xe0/0x330 kernel/module.c:3468 load_module+0x38eb/0x4270 kernel/module.c:3819 __do_sys_finit_module+0x162/0x190 kernel/module.c:3909 do_syscall_64+0x72/0x2a0 arch/x86/entry/common.c:298 entry_SYSCALL_64_after_hwframe+0x49/0xbe Fixes: baf8532a147d ("memstick: initial commit for Sony MemoryStick support") Reported-by: Hulk Robot Signed-off-by: Wang Hai Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 9ff8fb85b62e629583c5c2b9f1f2224ff70995f4 Author: Sebastian Reichel Date: Thu May 23 22:07:54 2019 +0200 drm/omap: don't check dispc timings for DSI [ Upstream commit ad9df7d91b4a6e8f4b20c2bf539ac09b3b2ad6eb ] While most display types only forward their VM to the DISPC, this is not true for DSI. DSI calculates the VM for DISPC based on its own, but it's not identical. Actually the DSI VM is not even a valid DISPC VM making this check fail. Let's restore the old behaviour and avoid checking the DISPC VM for DSI here. Fixes: 7c27fa57ef31 ("drm/omap: Call dispc timings check operation directly") Acked-by: Pavel Machek Tested-by: Tony Lindgren Tested-by: Pavel Machek Signed-off-by: Sebastian Reichel Signed-off-by: Tomi Valkeinen Signed-off-by: Sasha Levin commit 9a1713bed0c201fb433a36af465fb790469f4465 Author: Jason Gunthorpe Date: Wed May 22 16:52:52 2019 -0300 mm/hmm: fix use after free with struct hmm in the mmu notifiers [ Upstream commit 6d7c3cde93c1d9ac0b37f78ec3f2ff052159a242 ] mmu_notifier_unregister_no_release() is not a fence and the mmu_notifier system will continue to reference hmm->mn until the srcu grace period expires. Resulting in use after free races like this: CPU0 CPU1 __mmu_notifier_invalidate_range_start() srcu_read_lock hlist_for_each () // mn == hmm->mn hmm_mirror_unregister() hmm_put() hmm_free() mmu_notifier_unregister_no_release() hlist_del_init_rcu(hmm-mn->list) mn->ops->invalidate_range_start(mn, range); mm_get_hmm() mm->hmm = NULL; kfree(hmm) mutex_lock(&hmm->lock); Use SRCU to kfree the hmm memory so that the notifiers can rely on hmm existing. Get the now-safe hmm struct through container_of and directly check kref_get_unless_zero to lock it against free. Signed-off-by: Jason Gunthorpe Reviewed-by: Ira Weiny Reviewed-by: John Hubbard Reviewed-by: Ralph Campbell Reviewed-by: Christoph Hellwig Tested-by: Philip Yang Signed-off-by: Sasha Levin commit b18ed6d4e096aab3f7d2b6af241b2f03dcc8e8b8 Author: Ajay Gupta Date: Fri Jun 7 09:34:22 2019 -0700 i2c: nvidia-gpu: resume ccgx i2c client [ Upstream commit 9f2e244d0a39eb437f98324ac315e605e48636db ] Cypress USB Type-C CCGx controller firmware version 3.1.10 (which is being used in many NVIDIA GPU cards) has known issue of not triggering interrupt when a USB device is hot plugged to runtime resume the controller. If any GPU card gets latest kernel with runtime pm support but does not get latest fixed firmware then also it should continue to work and therefore a workaround is required to check for any connector change event The workaround is to request runtime resume of i2c client which is UCSI Cypress CCGx driver. CCG driver will call the ISR for any connector change event only if NVIDIA GPU has old CCG firmware with the known issue. Signed-off-by: Ajay Gupta Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit ee80886991a62c8e6f30b892c73d28252b6690fb Author: Daniel Vetter Date: Thu Jun 6 10:44:04 2019 +0200 drm/vkms: Forward timer right after drm_crtc_handle_vblank [ Upstream commit 7355965da22b8d9ebac8bce4b776399fb0bb9d32 ] In commit def35e7c592616bc09be328de8795e5e624a3cf8 Author: Shayenne Moura Date: Wed Jan 30 14:06:36 2019 -0200 drm/vkms: Bugfix extra vblank frame we fixed the vblank counter to give accurate results outside of drm_crtc_handle_vblank, which fixed bugs around vblank timestamps being off-by-one and causing the vblank counter to jump when it shouldn't. The trouble is that this completely broke crc generation. Shayenne and Rodrigo tracked this down to the vblank timestamp going backwards in time somehow. Which then resulted in an underflow in drm_vblank.c code, which resulted in all kinds of things breaking really badly. The reason for this is that once we've called drm_crtc_handle_vblank and the hrtimer isn't forwarded yet, we're returning a vblank timestamp in the past. This race is really hard to hit since it's small, except when you enable crc generation: In that case there's a call to drm_crtc_accurate_vblank right in-betwen, so we're guaranteed to hit the bug. The fix is to roll the hrtimer forward _before_ we do the vblank processing (which has a side-effect of incrementing the vblank counter), and we always subtract one frame from the hrtimer - since now it's always one frame in the future. To make sure we don't hit this again also add a WARN_ON checking for whether our timestamp is somehow moving into the past, which is never should. This also aligns more with how real hw works: 1. first all registers are updated with the new timestamp/vblank counter values. 2. then an interrupt is generated 3. kernel interrupt handler eventually fires. So doing this aligns vkms closer with what drm_vblank.c expects. Document this also in a comment. Cc: Shayenne Moura Cc: Rodrigo Siqueira Signed-off-by: Daniel Vetter Tested-by: Rodrigo Siqueira Reviewed-by: Rodrigo Siqueira Signed-off-by: Rodrigo Siqueira Link: https://patchwork.freedesktop.org/patch/msgid/20190606084404.12014-1-daniel.vetter@ffwll.ch Signed-off-by: Sasha Levin commit 8eec4901fbb1ff78f37682262a6264c6c7698180 Author: Daniel Vetter Date: Thu Jun 6 23:15:44 2019 +0200 drm/crc-debugfs: Also sprinkle irqrestore over early exits [ Upstream commit d99004d7201aa653658ff2390d6e516567c96ebc ] I. was. blind. Caught with vkms, which has some really slow crc computation function. Fixes: 1882018a70e0 ("drm/crc-debugfs: User irqsafe spinlock in drm_crtc_add_crc_entry") Cc: Rodrigo Siqueira Cc: Tomeu Vizoso Cc: Emil Velikov Cc: Benjamin Gaignard Cc: Ville Syrjälä Reviewed-by: Emil Velikov Reviewed-by: Benjamin Gaignard Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20190606211544.5389-1-daniel.vetter@ffwll.ch Signed-off-by: Sasha Levin commit 4ca20d17873e80e1f453d502112277d8cde450b5 Author: Daniel Vetter Date: Wed Jun 5 21:45:56 2019 +0200 drm/crc-debugfs: User irqsafe spinlock in drm_crtc_add_crc_entry [ Upstream commit 1882018a70e06376234133e69ede9dd743b4dbd9 ] We can be called from any context, we need to be prepared. Noticed this while hacking on vkms, which calls this function from a normal worker. Which really upsets lockdep. Cc: Rodrigo Siqueira Cc: Tomeu Vizoso Cc: Emil Velikov Cc: Benjamin Gaignard Reviewed-by: Benjamin Gaignard Reviewed-by: Ville Syrjälä Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20190605194556.16744-1-daniel.vetter@ffwll.ch Signed-off-by: Sasha Levin commit 77e4f68ccfacd723fa8ed50a8051ee0f5f8fccde Author: Thierry Reding Date: Wed Jun 5 10:46:05 2019 +0200 gpu: host1x: Increase maximum DMA segment size [ Upstream commit 1e390478cfb527e34c9ab89ba57212cb05c33c51 ] Recent versions of the DMA API debug code have started to warn about violations of the maximum DMA segment size. This is because the segment size defaults to 64 KiB, which can easily be exceeded in large buffer allocations such as used in DRM/KMS for framebuffers. Technically the Tegra SMMU and ARM SMMU don't have a maximum segment size (they map individual pages irrespective of whether they are contiguous or not), so the choice of 4 MiB is a bit arbitrary here. The maximum segment size is a 32-bit unsigned integer, though, so we can't set it to the correct maximum size, which would be the size of the aperture. Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit 26ccec2dc7780be1b9f3e329935fc13ea46a6507 Author: Daniel Rosenberg Date: Wed May 29 17:49:03 2019 -0700 f2fs: Lower threshold for disable_cp_again [ Upstream commit ae4ad7ea09d32ff1b6fb908ff12f8c1bd5241b29 ] The existing threshold for allowable holes at checkpoint=disable time is too high. The OVP space contains reserved segments, which are always in the form of free segments. These must be subtracted from the OVP value. The current threshold is meant to be the maximum value of holes of a single type we can have and still guarantee that we can fill the disk without failing to find space for a block of a given type. If the disk is full, ignoring current reserved, which only helps us, the amount of unused blocks is equal to the OVP area. Of that, there are reserved segments, which must be free segments, and the rest of the ovp area, which can come from either free segments or holes. The maximum possible amount of holes is OVP-reserved. Now, consider the disk when mounting with checkpoint=disable. We must be able to fill all available free space with either data or node blocks. When we start with checkpoint=disable, holes are locked to their current type. Say we have H of one type of hole, and H+X of the other. We can fill H of that space with arbitrary typed blocks via SSR. For the remaining H+X blocks, we may not have any of a given block type left at all. For instance, if we were to fill the disk entirely with blocks of the type with fewer holes, the H+X blocks of the opposite type would not be used. If H+X > OVP-reserved, there would be more holes than could possibly exist, and we would have failed to find a suitable block earlier on, leading to a crash in update_sit_entry. If H+X <= OVP-reserved, then the holes end up effectively masked by the OVP region in this case. Signed-off-by: Daniel Rosenberg Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 4483b9a88b953553a453282620ad8c50ffa92491 Author: Daniel Rosenberg Date: Wed May 29 17:49:05 2019 -0700 f2fs: Fix accounting for unusable blocks [ Upstream commit a4c3ecaaadac5693f555cfef1c9eecf4c39df818 ] Fixes possible underflows when dealing with unusable blocks. Signed-off-by: Daniel Rosenberg Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 5420c23f3dfebe66753daf53e3162a1016229085 Author: Eryk Brol Date: Wed May 15 15:12:41 2019 -0400 drm/amd/display: Increase Backlight Gain Step Size [ Upstream commit e25228b02e4833e5b0fdd262801a2ae6cc72b39d ] [Why] Some backlight tests fail due to backlight settling taking too long. This happens because the step size used to change backlight levels is too small. [How] 1. Change the size of the backlight gain step size 2. Change how DMCU firmware gets the step size value so that it is passed in by driver during DMCU initn Signed-off-by: Eryk Brol Reviewed-by: Jun Lei Acked-by: Leo Li Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 3b0a7154bf98fb93feff2a63bb40bad28db5f0da Author: Krunoslav Kovac Date: Thu May 16 11:14:55 2019 -0400 drm/amd/display: CS_TFM_1D only applied post EOTF [ Upstream commit 6ad34adeaec5b56a5ba90e90099cabf1c1fe9dd2 ] [Why] There's some unnecessary mem allocation for CS_TFM_ID. What's worse, it depends on LUT size and since it's 4K for CS_TFM_1D, it is 16x bigger than in regular case when it's actually needed. This leads to some crashes in stress conditions. [How] Skip ramp combining designed for RGB256 and DXGI gamma with CS_TFM_1D. Signed-off-by: Krunoslav Kovac Reviewed-by: Aric Cyr Acked-by: Leo Li Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 09a52473468241934055649f54b7a0b38291cb1b Author: Nicholas Kazlauskas Date: Wed May 1 10:26:09 2019 -0400 drm/amd/display: Reset planes for color management changes [ Upstream commit 7316c4ad299663a16ca9ce13e5e817b4ca760809 ] [Why] For commits with allow_modeset=false and CRTC degamma changes the planes aren't reset. This results in incorrect rendering. [How] Reset the planes when color management has changed on the CRTC. Technically this will include regamma changes as well, but it doesn't really after legacy userspace since those commit with allow_modeset=true. Signed-off-by: Nicholas Kazlauskas Reviewed-by: Harry Wentland Acked-by: Leo Li Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit b8041c6c3ee18f18f562c8964150b0dba5ca68c2 Author: Jyri Sarha Date: Mon May 27 16:47:54 2019 +0300 drm/bridge: sii902x: pixel clock unit is 10kHz instead of 1kHz [ Upstream commit 8dbfc5b65023b67397aca28e8adb25c819f6398c ] The pixel clock unit in the first two registers (0x00 and 0x01) of sii9022 is 10kHz, not 1kHz as in struct drm_display_mode. Division by 10 fixes the issue. Signed-off-by: Jyri Sarha Reviewed-by: Andrzej Hajda Reviewed-by: Laurent Pinchart Signed-off-by: Andrzej Hajda Link: https://patchwork.freedesktop.org/patch/msgid/1a2a8eae0b9d6333e7a5841026bf7fd65c9ccd09.1558964241.git.jsarha@ti.com Signed-off-by: Sasha Levin commit 77680b5f59495b0105247fa35d0b3089bca12554 Author: Tomi Valkeinen Date: Tue May 28 11:27:44 2019 +0300 drm/bridge: tc358767: read display_props in get_modes() [ Upstream commit 3231573065ad4f4ecc5c9147b24f29f846dc0c2f ] We need to know the link bandwidth to filter out modes we cannot support, so we need to have read the display props before doing the filtering. To ensure we have up to date display props, call tc_get_display_props() in the beginning of tc_connector_get_modes(). Signed-off-by: Tomi Valkeinen Reviewed-by: Andrzej Hajda Signed-off-by: Andrzej Hajda Link: https://patchwork.freedesktop.org/patch/msgid/20190528082747.3631-22-tomi.valkeinen@ti.com Signed-off-by: Sasha Levin commit 0481c9f74e4fea6e1b3acdb68d6a9ce1809f4369 Author: Mao Wenan Date: Tue May 28 16:02:13 2019 +0800 staging: kpc2000: report error status to spi core [ Upstream commit 9164f336311863d3e9f80840f4a1cce2aee293bd ] There is an error condition that's not reported to the spi core in kp_spi_transfer_one_message(). It should restore status value to m->status, and return it in error path. Signed-off-by: Mao Wenan Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 8299d8dd51f076ab19d8e379c255f72ad89a0a86 Author: Alex Williamson Date: Wed May 1 11:00:16 2019 -0600 PCI: Return error if cannot probe VF [ Upstream commit 76002d8b48c4b08c9bd414517dd295e132ad910b ] Commit 0e7df22401a3 ("PCI: Add sysfs sriov_drivers_autoprobe to control VF driver binding") allows the user to specify that drivers for VFs of a PF should not be probed, but it actually causes pci_device_probe() to return success back to the driver core in this case. Therefore by all sysfs appearances the device is bound to a driver, the driver link from the device exists as does the device link back from the driver, yet the driver's probe function is never called on the device. We also fail to do any sort of cleanup when we're prohibited from probing the device, the IRQ setup remains in place and we even hold a device reference. Instead, abort with errno before any setup or references are taken when pci_device_can_probe() prevents us from trying to probe the device. Link: https://lore.kernel.org/lkml/155672991496.20698.4279330795743262888.stgit@gimli.home Fixes: 0e7df22401a3 ("PCI: Add sysfs sriov_drivers_autoprobe to control VF driver binding") Signed-off-by: Alex Williamson Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin commit 153318495185028ecfaa9b6cd767b435518bd3e9 Author: Alan Mikhak Date: Thu May 23 14:18:00 2019 -0700 tools: PCI: Fix broken pcitest compilation [ Upstream commit 8a5e0af240e07dd3d4897eb8ff52aab757da7fab ] pcitest is currently broken due to the following compiler error and related warning. Fix by changing the run_test() function signature to return an integer result. pcitest.c: In function run_test: pcitest.c:143:9: warning: return with a value, in function returning void return (ret < 0) ? ret : 1 - ret; /* return 0 if test succeeded */ pcitest.c: In function main: pcitest.c:232:9: error: void value not ignored as it ought to be return run_test(test); Fixes: fef31ecaaf2c ("tools: PCI: Fix compilation warnings") Signed-off-by: Alan Mikhak Signed-off-by: Lorenzo Pieralisi Reviewed-by: Paul Walmsley Signed-off-by: Sasha Levin commit 50271c005a2f366b57d474991c9e35bb5a6b2c6e Author: Gen Zhang Date: Fri May 24 10:32:22 2019 +0800 drm/edid: Fix a missing-check bug in drm_load_edid_firmware() [ Upstream commit 9f1f1a2dab38d4ce87a13565cf4dc1b73bef3a5f ] In drm_load_edid_firmware(), fwstr is allocated by kstrdup(). And fwstr is dereferenced in the following codes. However, memory allocation functions such as kstrdup() may fail and returns NULL. Dereferencing this null pointer may cause the kernel go wrong. Thus we should check this kstrdup() operation. Further, if kstrdup() returns NULL, we should return ERR_PTR(-ENOMEM) to the caller site. Signed-off-by: Gen Zhang Reviewed-by: Jani Nikula Signed-off-by: Jani Nikula Link: https://patchwork.freedesktop.org/patch/msgid/20190524023222.GA5302@zhanggen-UX430UQ Signed-off-by: Sasha Levin commit 4664b796f9943513de3ea0b79e766e504f54f942 Author: Oak Zeng Date: Fri Feb 8 15:44:35 2019 -0600 drm/amdkfd: Fix sdma queue map issue [ Upstream commit 065e4bdfa1f3ab2884c110394d8b7e7ebe3b988c ] Previous codes assumes there are two sdma engines. This is not true e.g., Raven only has 1 SDMA engine. Fix the issue by using sdma engine number info in device_info. Signed-off-by: Oak Zeng Reviewed-by: Felix Kuehling Signed-off-by: Felix Kuehling Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit a3485498c0073e8fc94007bec6a982096796407f Author: Oak Zeng Date: Tue Nov 27 22:08:25 2018 -0600 drm/amdkfd: Fix a potential memory leak [ Upstream commit e73390d181103a19e1111ec2f25559a0570e9fe0 ] Free mqd_mem_obj it GTT buffer allocation for MQD+control stack fails. Signed-off-by: Oak Zeng Reviewed-by: Felix Kuehling Signed-off-by: Felix Kuehling Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 6817ce7fe1f1d6adb7917fa1ef724f33e818ed56 Author: Paul Hsieh Date: Fri May 3 23:50:10 2019 +0800 drm/amd/display: Disable ABM before destroy ABM struct [ Upstream commit 1090d58d4815b1fcd95a80987391006c86398b4c ] [Why] When disable driver, OS will set backlight optimization then do stop device. But this flag will cause driver to enable ABM when driver disabled. [How] Send ABM disable command before destroy ABM construct Signed-off-by: Paul Hsieh Reviewed-by: Anthony Koo Acked-by: Bhawanpreet Lakha Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 15357e565277b8def6855f844b4bb14bff8b163b Author: Tiecheng Zhou Date: Tue May 14 10:03:35 2019 +0800 drm/amdgpu/sriov: Need to initialize the HDP_NONSURFACE_BAStE [ Upstream commit fe2b5323d2c3cedaa3bf943dc7a0d233c853c914 ] it requires to initialize HDP_NONSURFACE_BASE, so as to avoid using the value left by a previous VM under sriov scenario. v2: it should not hurt baremetal, generalize it for both sriov and baremetal Signed-off-by: Emily Deng Signed-off-by: Tiecheng Zhou Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 9fc3cc6cb0cf115d20196e4ec90d00f7a335dc2c Author: Chao Yu Date: Mon May 20 17:36:59 2019 +0800 f2fs: fix to avoid deadloop if data_flush is on [ Upstream commit 040d2bb318d1aea4f28cc22504b44e446666c86e ] As Hagbard Celine reported: [ 615.697824] INFO: task kworker/u16:5:344 blocked for more than 120 seconds. [ 615.697825] Not tainted 5.0.15-gentoo-f2fslog #4 [ 615.697826] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 615.697827] kworker/u16:5 D 0 344 2 0x80000000 [ 615.697831] Workqueue: writeback wb_workfn (flush-259:0) [ 615.697832] Call Trace: [ 615.697836] ? __schedule+0x2c5/0x8b0 [ 615.697839] schedule+0x32/0x80 [ 615.697841] schedule_preempt_disabled+0x14/0x20 [ 615.697842] __mutex_lock.isra.8+0x2ba/0x4d0 [ 615.697845] ? log_store+0xf5/0x260 [ 615.697848] f2fs_write_data_pages+0x133/0x320 [ 615.697851] ? trace_hardirqs_on+0x2c/0xe0 [ 615.697854] do_writepages+0x41/0xd0 [ 615.697857] __filemap_fdatawrite_range+0x81/0xb0 [ 615.697859] f2fs_sync_dirty_inodes+0x1dd/0x200 [ 615.697861] f2fs_balance_fs_bg+0x2a7/0x2c0 [ 615.697863] ? up_read+0x5/0x20 [ 615.697865] ? f2fs_do_write_data_page+0x2cb/0x940 [ 615.697867] f2fs_balance_fs+0xe5/0x2c0 [ 615.697869] __write_data_page+0x1c8/0x6e0 [ 615.697873] f2fs_write_cache_pages+0x1e0/0x450 [ 615.697878] f2fs_write_data_pages+0x14b/0x320 [ 615.697880] ? trace_hardirqs_on+0x2c/0xe0 [ 615.697883] do_writepages+0x41/0xd0 [ 615.697885] __filemap_fdatawrite_range+0x81/0xb0 [ 615.697887] f2fs_sync_dirty_inodes+0x1dd/0x200 [ 615.697889] f2fs_balance_fs_bg+0x2a7/0x2c0 [ 615.697891] f2fs_write_node_pages+0x51/0x220 [ 615.697894] do_writepages+0x41/0xd0 [ 615.697897] __writeback_single_inode+0x3d/0x3d0 [ 615.697899] writeback_sb_inodes+0x1e8/0x410 [ 615.697902] __writeback_inodes_wb+0x5d/0xb0 [ 615.697904] wb_writeback+0x28f/0x340 [ 615.697906] ? cpumask_next+0x16/0x20 [ 615.697908] wb_workfn+0x33e/0x420 [ 615.697911] process_one_work+0x1a1/0x3d0 [ 615.697913] worker_thread+0x30/0x380 [ 615.697915] ? process_one_work+0x3d0/0x3d0 [ 615.697916] kthread+0x116/0x130 [ 615.697918] ? kthread_create_worker_on_cpu+0x70/0x70 [ 615.697921] ret_from_fork+0x3a/0x50 There is still deadloop in below condition: d A - do_writepages - f2fs_write_node_pages - f2fs_balance_fs_bg - f2fs_sync_dirty_inodes - f2fs_write_cache_pages - mutex_lock(&sbi->writepages) -- lock once - __write_data_page - f2fs_balance_fs_bg - f2fs_sync_dirty_inodes - f2fs_write_data_pages - mutex_lock(&sbi->writepages) -- lock again Thread A Thread B - do_writepages - f2fs_write_node_pages - f2fs_balance_fs_bg - f2fs_sync_dirty_inodes - .cp_task = current - f2fs_sync_dirty_inodes - .cp_task = current - filemap_fdatawrite - .cp_task = NULL - filemap_fdatawrite - f2fs_write_cache_pages - enter f2fs_balance_fs_bg since .cp_task is NULL - .cp_task = NULL Change as below to avoid this: - add condition to avoid holding .writepages mutex lock in path of data flush - introduce mutex lock sbi.flush_lock to exclude concurrent data flush in background. Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit f12bc552766d153f802809385abd73f6a580105c Author: Felix Kuehling Date: Wed May 1 17:43:10 2019 -0400 drm/amdgpu: Reserve shared fence for eviction fence [ Upstream commit dd68722c427d5b33420dce0ed0c44b4881e0a416 ] Need to reserve space for the shared eviction fence when initializing a KFD VM. Signed-off-by: Felix Kuehling Acked-by: Christian König Reviewed-by: Harish Kasiviswanathan Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit bd14be9ac21e0e5c6052a849ff510301fdbee938 Author: Roman Li Date: Thu Apr 25 11:02:30 2019 -0400 drm/amd/display: Fill plane attrs only for valid pxl format [ Upstream commit 1894478ad1f8fd7366edc5cee49ee9caea0e3d52 ] [Why] In fill_plane_buffer_attributes() we calculate chroma/luma assuming that the surface_pixel_format is always valid. If it's not the case, there's a risk of divide by zero error. [How] Check if format valid before calculating pixel format attributes Signed-off-by: Roman Li Reviewed-by: David Francis Acked-by: Bhawanpreet Lakha Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 2bd24435038e2e2ffb19364a3fbc16742382afa6 Author: Nicholas Kazlauskas Date: Thu Apr 18 12:42:32 2019 -0400 drm/amd/display: Disable cursor when offscreen in negative direction [ Upstream commit e371e19c10a264bd72c2ff1d21e2167b994710d1 ] [Why] When x or y is negative we set the x and y values to 0 and compensate with a positive cursor hotspot in DM since DC expects positive cursor values. When x or y is less than or equal to the maximum cursor width or height the cursor hotspot is clamped so the hotspot doesn't exceed the cursor size: if (x < 0) { xorigin = min(-x, amdgpu_crtc->max_cursor_width - 1); x = 0; } if (y < 0) { yorigin = min(-y, amdgpu_crtc->max_cursor_height - 1); y = 0; } This incorrectly forces the cursor to be at least 1 pixel on the screen in either direction when x or y is sufficiently negative. [How] Just disable the cursor when it goes far enough off the screen in one of these directions. This fixes kms_cursor_crc@cursor-256x256-offscreen. Signed-off-by: Nicholas Kazlauskas Reviewed-by: Sun peng Li Acked-by: Bhawanpreet Lakha Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit d7d2ce6f1b5f4580707a07b954de9a7e9b0e18d1 Author: Sean Paul Date: Thu May 23 13:16:40 2019 -0400 drm/msm/a6xx: Avoid freeing gmu resources multiple times [ Upstream commit 606ec90fc2266284f584a96ebf7f874589f56251 ] The driver checks for gmu->mmio as a sign that the device has been initialized, however there are failures in probe below the mmio init. If one of those is hit, mmio will be non-null but freed. In that case, a6xx_gmu_probe will return an error to a6xx_gpu_init which will in turn call a6xx_gmu_remove which checks gmu->mmio and tries to free resources for a second time. This causes a great boom. Fix this by adding an initialized member to gmu which is set on successful probe and cleared on removal. Changes in v2: - None Cc: Jordan Crouse Reviewed-by: Jordan Crouse Signed-off-by: Sean Paul Link: https://patchwork.freedesktop.org/patch/msgid/20190523171653.138678-1-sean@poorly.run Signed-off-by: Sasha Levin commit f197db99bbfc12c62dc8e99c3b2938effcf612b9 Author: Anthony Koo Date: Fri Apr 12 21:23:45 2019 -0400 drm/amd/display: fix multi display seamless boot case [ Upstream commit 4cd75ff096f4ef49c343093b52a952f27aba7796 ] [Why] There is a scenario that causes eDP to become blank if there are multiple displays connected, and the external display is set as the primary display such that the first flip comes to the external display. In this scenario, we call our optimize function before the eDP even has a chance to flip. [How] There is a check that prevents bandwidth optimize from occurring before first flip is complete on the seamless boot display. But actually it assumed the seamless boot display is the first one to flip. But in this scenario it is not. Modify the check to ensure the steam with the seamless boot flag set is the one that has completed the first flip. Signed-off-by: Anthony Koo Reviewed-by: Aric Cyr Acked-by: Bhawanpreet Lakha Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit ffd65f196223456a16c2755b260d7eaff201bfce Author: Nicholas Kazlauskas Date: Tue Apr 16 10:30:29 2019 -0400 drm/amd/display: Fill prescale_params->scale for RGB565 [ Upstream commit 1352c779cb74d427f4150cbe779a2f7886f70cae ] [Why] An assertion is thrown when using SURFACE_PIXEL_FORMAT_GRPH_RGB565 formats on DCE since the prescale_params->scale wasn't being filled. Found by a dmesg-fail when running the igt@kms_plane@pixel-format-pipe-a-planes test on Baffin. [How] Fill in the scale parameter. Signed-off-by: Nicholas Kazlauskas Reviewed-by: Roman Li Acked-by: Bhawanpreet Lakha Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 834f196a6eaa70a5528a6d2a10264bc52c683574 Author: Kefeng Wang Date: Fri May 24 22:37:24 2019 +0800 ipmi_ssif: fix unexpected driver unregister warning [ Upstream commit 2cd0e54489e65b8e22124a8b053aff40815487f7 ] If platform_driver_register() fails from init_ipmi_ssif(), platform_driver_unregister() called unconditionally will trigger following warning, ipmi_ssif: Unable to register driver: -12 ------------[ cut here ]------------ Unexpected driver unregister! WARNING: CPU: 1 PID: 6305 at drivers/base/driver.c:193 driver_unregister+0x60/0x70 drivers/base/driver.c:193 Fix it by adding platform_registered variable, only unregister platform driver when it is already successfully registered. Reported-by: Hulk Robot Signed-off-by: Kefeng Wang Message-Id: <20190524143724.43218-1-wangkefeng.wang@huawei.com> Signed-off-by: Corey Minyard Signed-off-by: Sasha Levin commit 81865bd492d19797b72b3824c6ec8f09f234e7fc Author: Sean Paul Date: Thu May 23 13:16:42 2019 -0400 drm/msm/a6xx: Check for ERR or NULL before iounmap [ Upstream commit 5ca4a094ba7e1369363dcbcbde8baf06ddcdc2d1 ] pdcptr and seqptr aren't necessarily valid, check them before trying to unmap them. Changes in v2: - None Cc: Jordan Crouse Reviewed-by: Jordan Crouse Signed-off-by: Sean Paul Link: https://patchwork.freedesktop.org/patch/msgid/20190523171653.138678-3-sean@poorly.run Signed-off-by: Sasha Levin commit 07fc9d96e407b8050970269ad656a8538bea6e36 Author: Chao Yu Date: Mon May 20 10:09:22 2019 +0800 f2fs: fix to check layout on last valid checkpoint park [ Upstream commit 5dae2d39074dde941cc3150dcbb7840d88179743 ] As Ju Hyung reported: " I was semi-forced today to use the new kernel and test f2fs. My Ubuntu initramfs got a bit wonky and I had to boot into live CD and fix some stuffs. The live CD was using 4.15 kernel, and just mounting the f2fs partition there corrupted f2fs and my 4.19(with 5.1-rc1-4.19 f2fs-stable merged) refused to mount with "SIT is corrupted node" message. I used the latest f2fs-tools sent by Chao including "fsck.f2fs: fix to repair cp_loads blocks at correct position" It spit out 140M worth of output, but at least I didn't have to run it twice. Everything returned "Ok" in the 2nd run. The new log is at http://arter97.com/f2fs/final After fixing the image, I used my 4.19 kernel with 5.2-rc1-4.19 f2fs-stable merged and it mounted. But, I got this: [ 1.047791] F2FS-fs (nvme0n1p3): layout of large_nat_bitmap is deprecated, run fsck to repair, chksum_offset: 4092 [ 1.081307] F2FS-fs (nvme0n1p3): Found nat_bits in checkpoint [ 1.161520] F2FS-fs (nvme0n1p3): recover fsync data on readonly fs [ 1.162418] F2FS-fs (nvme0n1p3): Mounted with checkpoint version = 761c7e00 But after doing a reboot, the message is gone: [ 1.098423] F2FS-fs (nvme0n1p3): Found nat_bits in checkpoint [ 1.177771] F2FS-fs (nvme0n1p3): recover fsync data on readonly fs [ 1.178365] F2FS-fs (nvme0n1p3): Mounted with checkpoint version = 761c7eda I'm not exactly sure why the kernel detected that I'm still using the old layout on the first boot. Maybe fsck didn't fix it properly, or the check from the kernel is improper. " Although we have rebuild the old deprecated checkpoint with new layout during repair, we only repair last checkpoint park, the other old one is remained. Once the image was mounted, we will 1) sanity check layout and 2) decide which checkpoint park to use according to cp_ver. So that we will print reported message unnecessarily at step 1), to avoid it, we simply move layout check into f2fs_sanity_check_ckpt() after step 2). Reported-by: Park Ju Hyung Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit e9ddcfa61b82dfa3cde6251cc13f4af8d6764e32 Author: Christophe Leroy Date: Wed May 22 12:17:11 2019 +0000 tty: serial: cpm_uart - fix init when SMC is relocated [ Upstream commit 06aaa3d066db87e8478522d910285141d44b1e58 ] SMC relocation can also be activated earlier by the bootloader, so the driver's behaviour cannot rely on selected kernel config. When the SMC is relocated, CPM_CR_INIT_TRX cannot be used. But the only thing CPM_CR_INIT_TRX does is to clear the rstate and tstate registers, so this can be done manually, even when SMC is not relocated. Signed-off-by: Christophe Leroy Fixes: 9ab921201444 ("cpm_uart: fix non-console port startup bug") Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 8470dffc6c73e8bcfdc3050a54d208d0191d3e75 Author: Wen Yang Date: Mon Apr 15 14:24:02 2019 +0800 pinctrl: rockchip: fix leaked of_node references [ Upstream commit 3c89c70634bb0b6f48512de873e7a45c7e1fbaa5 ] The call to of_parse_phandle returns a node pointer with refcount incremented thus it must be explicitly decremented after the last usage. Detected by coccinelle with the following warnings: ./drivers/pinctrl/pinctrl-rockchip.c:3221:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 3196, but without a corresponding object release within this function. ./drivers/pinctrl/pinctrl-rockchip.c:3223:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 3196, but without a corresponding object release within this function. Signed-off-by: Wen Yang Cc: Linus Walleij Cc: Heiko Stuebner Cc: linux-gpio@vger.kernel.org Cc: linux-rockchip@lists.infradead.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 9f9f6d50bd46785f3f21a8e01cdebb7f999d84cd Author: Serge Semin Date: Tue May 14 13:14:12 2019 +0300 tty: max310x: Fix invalid baudrate divisors calculator [ Upstream commit 35240ba26a932b279a513f66fa4cabfd7af55221 ] Current calculator doesn't do it' job quite correct. First of all the max310x baud-rates generator supports the divisor being less than 16. In this case the x2/x4 modes can be used to double or quadruple the reference frequency. But the current baud-rate setter function just filters all these modes out by the first condition and setups these modes only if there is a clocks-baud division remainder. The former doesn't seem right at all, since enabling the x2/x4 modes causes the line noise tolerance reduction and should be only used as a last resort to enable a requested too high baud-rate. Finally the fraction is supposed to be calculated from D = Fref/(c*baud) formulae, but not from D % 16, which causes the precision loss. So to speak the current baud-rate calculator code works well only if the baud perfectly fits to the uart reference input frequency. Lets fix the calculator by implementing the algo fully compliant with the fractional baud-rate generator described in the datasheet: D = Fref / (c*baud), where c={16,8,4} is the x1/x2/x4 rate mode respectively, Fref - reference input frequency. The divisor fraction is calculated from the same formulae, but making sure it is found with a resolution of 0.0625 (four bits). Signed-off-by: Serge Semin Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 2042746d87346e70e2c6c70537972616932b4207 Author: Thinh Nguyen Date: Tue May 14 14:38:38 2019 -0700 usb: core: hub: Disable hub-initiated U1/U2 [ Upstream commit 561759292774707b71ee61aecc07724905bb7ef1 ] If the device rejects the control transfer to enable device-initiated U1/U2 entry, then the device will not initiate U1/U2 transition. To improve the performance, the downstream port should not initate transition to U1/U2 to avoid the delay from the device link command response (no packet can be transmitted while waiting for a response from the device). If the device has some quirks and does not implement U1/U2, it may reject all the link state change requests, and the downstream port may resend and flood the bus with more requests. This will affect the device performance even further. This patch disables the hub-initated U1/U2 if the device-initiated U1/U2 entry fails. Reference: USB 3.2 spec 7.2.4.2.3 Signed-off-by: Thinh Nguyen Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 5bca88972a6b1945c18a5b86a6c2a19c05865e4c Author: Sam Bobroff Date: Tue May 21 15:28:39 2019 +1000 drm/bochs: Fix connector leak during driver unload [ Upstream commit 3c6b8625dde82600fd03ad1fcba223f1303ee535 ] When unloading the bochs-drm driver, a warning message is printed by drm_mode_config_cleanup() because a reference is still held to one of the drm_connector structs. Correct this by calling drm_atomic_helper_shutdown() in bochs_pci_remove(). Fixes: 6579c39594ae ("drm/bochs: atomic: switch planes to atomic, wire up helpers.") Signed-off-by: Sam Bobroff Link: http://patchwork.freedesktop.org/patch/msgid/93b363ad62f4938d9ddf3e05b2a61e3f66b2dcd3.1558416473.git.sbobroff@linux.ibm.com Signed-off-by: Gerd Hoffmann Signed-off-by: Sasha Levin commit 3f71d923758560cea2bccf226c78849614805e29 Author: Quentin Deslandes Date: Mon May 20 16:39:04 2019 +0000 staging: vt6656: use meaningful error code during buffer allocation [ Upstream commit d8c2869300ab5f7a19bf6f5a04fe473c5c9887e3 ] Check on called function's returned value for error and return 0 on success or a negative errno value on error instead of a boolean value. Signed-off-by: Quentin Deslandes Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit c5f98dd5b16a9d98b762373f4768d00e24163602 Author: Kefeng Wang Date: Fri May 17 18:12:44 2019 +0800 ipmi_si: fix unexpected driver unregister warning [ Upstream commit 2f66353963043e1d8dfacfbdf509acc5d3be7698 ] If ipmi_si_platform_init()->platform_driver_register() fails, platform_driver_unregister() called unconditionally will trigger following warning, ipmi_platform: Unable to register driver: -12 ------------[ cut here ]------------ Unexpected driver unregister! WARNING: CPU: 1 PID: 7210 at drivers/base/driver.c:193 driver_unregister+0x60/0x70 drivers/base/driver.c:193 Fix it by adding platform_registered variable, only unregister platform driver when it is already successfully registered. Reported-by: Hulk Robot Signed-off-by: Kefeng Wang Message-Id: <20190517101245.4341-1-wangkefeng.wang@huawei.com> Signed-off-by: Corey Minyard Signed-off-by: Sasha Levin commit d1ff023462bec0cc01dfd811bf94d2cd30263bad Author: Jeremy Sowden Date: Wed May 15 12:14:36 2019 +0100 staging: kpc2000: added missing clean-up to probe_core_uio. [ Upstream commit abb611d2c21c0a4fa8eab35dc936c80d9a07acd8 ] On error, probe_core_uio just returned an error without freeing resources which had previously been allocated. Added the missing clean-up code. Updated TODO. Signed-off-by: Jeremy Sowden Reviewed-by: Dan Carpenter Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit ac97f9cf3891107f95f1b6f29a779e2cd2f035cb Author: Chia-I Wu Date: Mon Apr 29 15:08:23 2019 -0700 drm/virtio: set seqno for dma-fence [ Upstream commit efe2bf965522bf0796d413b47a2abbf81d471d6f ] This is motivated by having meaningful ftrace events, but it also fixes use cases where dma_fence_is_later is called, such as in sync_file_merge. In other drivers, fence creation and cmdbuf submission normally happen atomically, mutex_lock(); fence = dma_fence_create(..., ++timeline->seqno); submit_cmdbuf(); mutex_unlock(); and have no such issue. But in our driver, because most ioctls queue commands into ctrlq, we do not want to grab a lock. Instead, we set seqno to 0 when a fence is created, and update it when the command is finally queued and the seqno is known. Signed-off-by: Chia-I Wu Reviewed-by: Emil Velikov Link: http://patchwork.freedesktop.org/patch/msgid/20190429220825.156644-1-olvaffe@gmail.com Signed-off-by: Gerd Hoffmann Signed-off-by: Sasha Levin commit 6ef0e38601df1a9125c5f6680af8c290e3177473 Author: Fabien Dessenne Date: Wed Apr 24 14:51:26 2019 +0200 iio: adc: stm32-dfsdm: missing error case during probe [ Upstream commit d2fc0156963cae8f1eec8e2dd645fbbf1e1c1c8e ] During probe, check the devm_ioremap_resource() error value. Also return the devm_clk_get() error value instead of -EINVAL. Signed-off-by: Fabien Dessenne Acked-by: Fabrice Gasnier Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 108e03242d761cb31d9ecafd359662b125aa3311 Author: Fabien Dessenne Date: Wed Apr 24 14:51:25 2019 +0200 iio: adc: stm32-dfsdm: manage the get_irq error case [ Upstream commit 3e53ef91f826957dec013c47707ffc1bb42b42d7 ] During probe, check the "get_irq" error value. Signed-off-by: Fabien Dessenne Acked-by: Fabrice Gasnier Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 68953ae09cbd1b01e88a6af8d15d2c6b42d7aafa Author: Peter Ujfalusi Date: Tue Feb 26 10:11:53 2019 +0200 drm/panel: simple: Fix panel_simple_dsi_probe [ Upstream commit 7ad9db66fafb0f0ad53fd2a66217105da5ddeffe ] In case mipi_dsi_attach() fails remove the registered panel to avoid added panel without corresponding device. Signed-off-by: Peter Ujfalusi Signed-off-by: Thierry Reding Link: https://patchwork.freedesktop.org/patch/msgid/20190226081153.31334-1-peter.ujfalusi@ti.com Signed-off-by: Sasha Levin commit 36a66cd28e40c5836e544bf3291c79908ba91ed8 Author: Peter Griffin Date: Fri Apr 19 09:33:01 2019 +0100 drm/lima: handle shared irq case for lima_pp_bcast_irq_handler [ Upstream commit 409c53f07a81f8db122c461f3255c6f43558c881 ] On Hikey board all lima ip blocks are shared with one irq. This patch avoids a NULL ptr deref crash on this platform on startup. Tested with Weston and kmscube. Signed-off-by: Peter Griffin Cc: Rob Herring Cc: Daniel Vetter Cc: Qiang Yu Signed-off-by: Qiang Yu Link: https://patchwork.freedesktop.org/patch/msgid/1555662781-22570-7-git-send-email-peter.griffin@linaro.org Signed-off-by: Sasha Levin commit bee7e7e1f5362075f3b9ff8d468e6496afc715da Author: Arnd Bergmann Date: Mon Jun 17 13:07:28 2019 +0200 btrfs: shut up bogus -Wmaybe-uninitialized warning commit 6c64460cdc8be5fa074aa8fe2ae8736d5792bdc5 upstream. gcc sometimes can't determine whether a variable has been initialized when both the initialization and the use are conditional: fs/btrfs/props.c: In function 'inherit_props': fs/btrfs/props.c:389:4: error: 'num_bytes' may be used uninitialized in this function [-Werror=maybe-uninitialized] btrfs_block_rsv_release(fs_info, trans->block_rsv, This code is fine. Unfortunately, I cannot think of a good way to rephrase it in a way that makes gcc understand this, so I add a bogus initialization the way one should not. Signed-off-by: Arnd Bergmann Reviewed-by: David Sterba [ gcc 8 and 9 don't emit the warning ] Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 15718c84f313fe4d936874844cca2b49b535bdf7 Author: Anders Roxell Date: Wed Jun 12 04:15:50 2019 -0400 media: drivers: media: coda: fix warning same module names commit 1296987d2baf7f56748359b8dd42c425b9e7ee3a upstream. When building with CONFIG_VIDEO_CODA and CONFIG_CODA_FS enabled as loadable modules, we see the following warning: fs/coda/coda.ko drivers/media/platform/coda/coda.ko Rework so media/platform/coda is named coda-vpu. Leaving CODA_FS as is since that's a well known module. Signed-off-by: Anders Roxell Reviewed-by: Philipp Zabel Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 56555c8f32b40393cd64610b79fc0228272a482b Author: Anders Roxell Date: Wed Jun 12 10:11:58 2019 +0200 regulator: 88pm800: fix warning same module names commit 6f10419187d0d5fe395e2a2f2a64370961bf02a3 upstream. When building with CONFIG_MFD_88PM800 and CONFIG_REGULATOR_88PM800 enabled as loadable modules, we see the following warning: warning: same module names found: drivers/regulator/88pm800.ko drivers/mfd/88pm800.ko Rework so that the file is named 88pm800-regulator. Signed-off-by: Anders Roxell Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman