commit d542c06f7665ee93cf6983dac472a1dd12050401 Author: Greg Kroah-Hartman Date: Mon Feb 24 08:38:51 2020 +0100 Linux 5.5.6 commit 0ff297535a5b7265bcbfba24e6a62d544c494593 Author: Alexandre Belloni Date: Mon Jan 27 23:17:24 2020 +0100 rtc: Kconfig: select REGMAP_I2C when necessary [ Upstream commit 578c2b661e2b1b474ea3571a3c3c6d57bae89e8d ] Some i2c RTC drivers are using regmap but are not selecting REGMAP_I2C which may lead to build failures. Link: https://lore.kernel.org/r/20200127221724.10160-2-alexandre.belloni@bootlin.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 1341ccf22b08be0ff9225b1d1f1adf5499982462 Author: Coly Li Date: Fri Jan 24 01:01:29 2020 +0800 bcache: properly initialize 'path' and 'err' in register_bcache() [ Upstream commit 29cda393bcaad160c4bf3676ddd99855adafc72f ] Patch "bcache: rework error unwinding in register_bcache" from Christoph Hellwig changes the local variables 'path' and 'err' in undefined initial state. If the code in register_bcache() jumps to label 'out:' or 'out_module_put:' by goto, these two variables might be reference with undefined value by the following line, out_module_put: module_put(THIS_MODULE); out: pr_info("error %s: %s", path, err); return ret; Therefore this patch initializes these two local variables properly in register_bcache() to avoid such issue. Signed-off-by: Coly Li Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 8d12e0b3912e47c9c0160a6bed23cbcb0bbf1ca0 Author: Alex Deucher Date: Tue Jan 28 14:39:45 2020 -0500 drm/amdgpu/display: handle multiple numbers of fclks in dcn_calcs.c (v2) [ Upstream commit c37243579d6c881c575dcfb54cf31c9ded88f946 ] We might get different numbers of clocks from powerplay depending on what the OEM has populated. v2: add assert for at least one level Bug: https://gitlab.freedesktop.org/drm/amd/issues/963 Reviewed-by: Nicholas Kazlauskas Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 4b3da4c88301f8739ee62068a73862ce45a70523 Author: Niklas Schnelle Date: Tue Dec 17 09:34:46 2019 +0100 s390/pci: Recover handle in clp_set_pci_fn() [ Upstream commit 17cdec960cf776b20b1fb08c622221babe591d51 ] When we try to recover a PCI function using echo 1 > /sys/bus/pci/devices//recover or manually with echo 1 > /sys/bus/pci/devices//remove echo 0 > /sys/bus/pci/slots//power echo 1 > /sys/bus/pci/slots//power clp_disable_fn() / clp_enable_fn() call clp_set_pci_fn() to first disable and then reenable the function. When the function is already in the requested state we may be left with an invalid function handle. To get a new valid handle we do a clp_list_pci() call. For this we need both the function ID and function handle in clp_set_pci_fn() so pass the zdev and get both. To simplify things also pull setting the refreshed function handle into clp_set_pci_fn() Signed-off-by: Niklas Schnelle Reviewed-by: Peter Oberparleiter Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin commit edad09107a5279862e9bc89417d9ead92e262170 Author: Ido Schimmel Date: Fri Feb 7 19:26:28 2020 +0200 mlxsw: spectrum_dpipe: Add missing error path [ Upstream commit 3a99cbb6fa7bca1995586ec2dc21b0368aad4937 ] In case devlink_dpipe_entry_ctx_prepare() failed, release RTNL that was previously taken and free the memory allocated by mlxsw_sp_erif_entry_prepare(). Fixes: 2ba5999f009d ("mlxsw: spectrum: Add Support for erif table entries access") Signed-off-by: Ido Schimmel Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit ee4ac92eac6729a5111037e0ddc26bf90911ef1a Author: Vadim Pasternak Date: Fri Feb 7 19:26:27 2020 +0200 mlxsw: core: Add validation of hardware device types for MGPIR register [ Upstream commit 36844c855b896f90bab51ccecf72940eb7e3cfe1 ] When reading the number of gearboxes from the hardware, the driver does not validate the returned 'device type' field. The driver can therefore wrongly assume that the queried devices are gearboxes. On Spectrum-3 systems that support different types of devices, this can prevent the driver from loading, as it will try to query the temperature sensors from devices which it assumes are gearboxes and in fact are not. For example: [ 218.129230] mlxsw_minimal 2-0048: Reg cmd access status failed (status=7(bad parameter)) [ 218.138282] mlxsw_minimal 2-0048: Reg cmd access failed (reg_id=900a(mtmp),type=write) [ 218.147131] mlxsw_minimal 2-0048: Failed to setup temp sensor number 256 [ 218.534480] mlxsw_minimal 2-0048: Fail to register core bus [ 218.540714] mlxsw_minimal: probe of 2-0048 failed with error -5 Fix this by validating the 'device type' field. Fixes: 2e265a8b6c094 ("mlxsw: core: Extend hwmon interface with inter-connect temperature attributes") Fixes: f14f4e621b1b4 ("mlxsw: core: Extend thermal core with per inter-connect device thermal zones") Signed-off-by: Vadim Pasternak Acked-by: Jiri Pirko Signed-off-by: Ido Schimmel Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f5654d8dba89a4e57aad5a1a018ae9df2c110281 Author: Miklos Szeredi Date: Thu Feb 6 16:39:28 2020 +0100 fuse: don't overflow LLONG_MAX with end offset [ Upstream commit 2f1398291bf35fe027914ae7a9610d8e601fbfde ] Handle the special case of fuse_readpages() wanting to read the last page of a hugest file possible and overflowing the end offset in the process. This is basically to unbreak xfstests:generic/525 and prevent filesystems from doing bad things with an overflowing offset. Reported-by: Xiao Yang Signed-off-by: Miklos Szeredi Signed-off-by: Sasha Levin commit 2e8420b46ff26b49998d32ae9b4700d9ecb4afd0 Author: Michael S. Tsirkin Date: Thu Feb 6 02:40:58 2020 -0500 virtio_balloon: prevent pfn array overflow [ Upstream commit 6e9826e77249355c09db6ba41cd3f84e89f4b614 ] Make sure, at build time, that pfn array is big enough to hold a single page. It happens to be true since the PAGE_SHIFT value at the moment is 20, which is 1M - exactly 256 4K balloon pages. Signed-off-by: Michael S. Tsirkin Reviewed-by: David Hildenbrand Signed-off-by: Sasha Levin commit 0c98725892f803990b484b4eda3ab7297e4872b6 Author: Steve French Date: Wed Feb 5 16:52:11 2020 -0600 cifs: log warning message (once) if out of disk space [ Upstream commit d6fd41905ec577851734623fb905b1763801f5ef ] We ran into a confusing problem where an application wasn't checking return code on close and so user didn't realize that the application ran out of disk space. log a warning message (once) in these cases. For example: [ 8407.391909] Out of space writing to \\oleg-server\small-share Signed-off-by: Steve French Reported-by: Oleg Kravtsov Reviewed-by: Ronnie Sahlberg Reviewed-by: Pavel Shilovsky Signed-off-by: Sasha Levin commit 9e8d4189185ae58f569ed8ac32f31960b906ed49 Author: Masahiro Yamada Date: Wed Feb 5 15:51:52 2020 +0900 kbuild: make multiple directory targets work [ Upstream commit f566e1fbadb686e28f1c307e356114b2865ef588 ] Currently, the single-target build does not work when two or more sub-directories are given: $ make fs/ kernel/ lib/ CALL scripts/checksyscalls.sh CALL scripts/atomic/check-atomics.sh DESCEND objtool make[2]: Nothing to be done for 'kernel/'. make[2]: Nothing to be done for 'fs/'. make[2]: Nothing to be done for 'lib/'. Make it work properly. Reported-by: Linus Torvalds Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin commit 8080eac08dba8aa8f892a219a9cbfef7148998f6 Author: Maciej Fijalkowski Date: Wed Feb 5 05:58:32 2020 +0100 i40e: Relax i40e_xsk_wakeup's return value when PF is busy [ Upstream commit c77e9f09143822623dd71a0fdc84331129e97c3a ] Return -EAGAIN instead of -ENETDOWN to provide a slightly milder information to user space so that an application will know to retry the syscall when __I40E_CONFIG_BUSY bit is set on pf->state. Fixes: b3873a5be757 ("net/i40e: Fix concurrency issues between config flow and XSK") Signed-off-by: Maciej Fijalkowski Signed-off-by: Daniel Borkmann Acked-by: Björn Töpel Link: https://lore.kernel.org/bpf/20200205045834.56795-2-maciej.fijalkowski@intel.com Signed-off-by: Sasha Levin commit d5fd4496b6fd81110a8ca9e24c58b7600c620b3d Author: Vasily Averin Date: Fri Jan 24 09:10:47 2020 +0300 help_next should increase position index [ Upstream commit 9f198a2ac543eaaf47be275531ad5cbd50db3edf ] if seq_file .next fuction does not change position index, read after some lseek can generate unexpected output. https://bugzilla.kernel.org/show_bug.cgi?id=206283 Signed-off-by: Vasily Averin Signed-off-by: Mike Marshall Signed-off-by: Sasha Levin commit 588f2bf818eda8ee9e4f703d8d1095aa6b16437e Author: Wenwen Wang Date: Mon Feb 3 03:47:53 2020 +0000 NFS: Fix memory leaks [ Upstream commit 123c23c6a7b7ecd2a3d6060bea1d94019f71fd66 ] In _nfs42_proc_copy(), 'res->commit_res.verf' is allocated through kzalloc() if 'args->sync' is true. In the following code, if 'res->synchronous' is false, handle_async_copy() will be invoked. If an error occurs during the invocation, the following code will not be executed and the error will be returned . However, the allocated 'res->commit_res.verf' is not deallocated, leading to a memory leak. This is also true if the invocation of process_copy_commit() returns an error. To fix the above leaks, redirect the execution to the 'out' label if an error is encountered. Signed-off-by: Wenwen Wang Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 24add5b4849b43c33d6500d25fe686d1d1e4549c Author: Alex Deucher Date: Wed Jan 29 12:42:57 2020 -0500 drm/amdgpu/smu10: fix smu10_get_clock_by_type_with_voltage [ Upstream commit 1064ad4aeef94f51ca230ac639a9e996fb7867a0 ] Cull out 0 clocks to avoid a warning in DC. Bug: https://gitlab.freedesktop.org/drm/amd/issues/963 Reviewed-by: Evan Quan Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit b6bd445a505ee42d707ef7faaf05dcc2d925c10c Author: Alex Deucher Date: Tue Jan 28 13:19:51 2020 -0500 drm/amdgpu/smu10: fix smu10_get_clock_by_type_with_latency [ Upstream commit 4d0a72b66065dd7e274bad6aa450196d42fd8f84 ] Only send non-0 clocks to DC for validation. This mirrors what the windows driver does. Bug: https://gitlab.freedesktop.org/drm/amd/issues/963 Reviewed-by: Evan Quan Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit a9e60cba99700aba5fc83322d4d0f8fd1635b24d Author: Zhiqiang Liu Date: Tue Feb 4 19:30:20 2020 +0800 brd: check and limit max_part par [ Upstream commit c8ab422553c81a0eb070329c63725df1cd1425bc ] In brd_init func, rd_nr num of brd_device are firstly allocated and add in brd_devices, then brd_devices are traversed to add each brd_device by calling add_disk func. When allocating brd_device, the disk->first_minor is set to i * max_part, if rd_nr * max_part is larger than MINORMASK, two different brd_device may have the same devt, then only one of them can be successfully added. when rmmod brd.ko, it will cause oops when calling brd_exit. Follow those steps: # modprobe brd rd_nr=3 rd_size=102400 max_part=1048576 # rmmod brd then, the oops will appear. Oops log: [ 726.613722] Call trace: [ 726.614175] kernfs_find_ns+0x24/0x130 [ 726.614852] kernfs_find_and_get_ns+0x44/0x68 [ 726.615749] sysfs_remove_group+0x38/0xb0 [ 726.616520] blk_trace_remove_sysfs+0x1c/0x28 [ 726.617320] blk_unregister_queue+0x98/0x100 [ 726.618105] del_gendisk+0x144/0x2b8 [ 726.618759] brd_exit+0x68/0x560 [brd] [ 726.619501] __arm64_sys_delete_module+0x19c/0x2a0 [ 726.620384] el0_svc_common+0x78/0x130 [ 726.621057] el0_svc_handler+0x38/0x78 [ 726.621738] el0_svc+0x8/0xc [ 726.622259] Code: aa0203f6 aa0103f7 aa1e03e0 d503201f (7940e260) Here, we add brd_check_and_reset_par func to check and limit max_part par. -- V5->V6: - remove useless code V4->V5:(suggested by Ming Lei) - make sure max_part is not larger than DISK_MAX_PARTS V3->V4:(suggested by Ming Lei) - remove useless change - add one limit of max_part V2->V3: (suggested by Ming Lei) - clear .minors when running out of consecutive minor space in brd_alloc - remove limit of rd_nr V1->V2: - add more checks in brd_check_par_valid as suggested by Ming Lei. Signed-off-by: Zhiqiang Liu Reviewed-by: Bob Liu Reviewed-by: Ming Lei Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit d302f3a53d3f1d043707083e6464cb6fb3aaab87 Author: Shubhrajyoti Datta Date: Sat Jan 11 18:44:34 2020 +0530 microblaze: Prevent the overflow of the start [ Upstream commit 061d2c1d593076424c910cb1b64ecdb5c9a6923f ] In case the start + cache size is more than the max int the start overflows. Prevent the same. Signed-off-by: Shubhrajyoti Datta Signed-off-by: Michal Simek Signed-off-by: Sasha Levin commit 18c6d681f3df07c7aa17343e322dd07dd25af9df Author: Davide Caratti Date: Mon Feb 3 16:29:30 2020 +0100 tc-testing: add missing 'nsPlugin' to basic.json [ Upstream commit e9ed4fa7b4400d7b2cf03108842a30e6c9bd0eb2 ] since tdc tests for cls_basic need $DEV1, use 'nsPlugin' so that the following command can be run without errors: [root@f31 tc-testing]# ./tdc.py -c basic Fixes: 4717b05328ba ("tc-testing: Introduced tdc tests for basic filter") Signed-off-by: Davide Caratti Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit ece3264b237561939264a7394e7f2a5fbaccb733 Author: Peter Zijlstra Date: Mon Feb 3 17:36:59 2020 -0800 asm-generic/tlb: add missing CONFIG symbol [ Upstream commit 27796d03c9c4b2b937ed4cc2b10f21559ad5a8c9 ] Without this the symbol will not actually end up in .config files. Link: http://lkml.kernel.org/r/20200116064531.483522-6-aneesh.kumar@linux.ibm.com Fixes: a30e32bd79e9 ("asm-generic/tlb: Provide generic tlb_flush() based on flush_tlb_mm()") Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Aneesh Kumar K.V Cc: Michael Ellerman Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit c6d6783988ca7f8fa98d598041c7ad39c7f4dd2c Author: Andrei Otcheretianski Date: Fri Jan 31 15:45:28 2020 +0200 iwlwifi: mvm: Check the sta is not NULL in iwl_mvm_cfg_he_sta() [ Upstream commit 12d47f0ea5e0aa63f19ba618da55a7c67850ca10 ] Fix a kernel panic by checking that the sta is not NULL. This could happen during a reconfig flow, as mac80211 moves the sta between all the states without really checking if the previous state was successfully set. So, if for some reason we failed to add back the station, subsequent calls to sta_state() callback will be done when the station is NULL. This would result in a following panic: BUG: unable to handle kernel NULL pointer dereference at 0000000000000040 IP: iwl_mvm_cfg_he_sta+0xfc/0x690 [iwlmvm] [..] Call Trace: iwl_mvm_mac_sta_state+0x629/0x6f0 [iwlmvm] drv_sta_state+0xf4/0x950 [mac80211] ieee80211_reconfig+0xa12/0x2180 [mac80211] ieee80211_restart_work+0xbb/0xe0 [mac80211] process_one_work+0x1e2/0x610 worker_thread+0x4d/0x3e0 [..] Signed-off-by: Andrei Otcheretianski Signed-off-by: Luca Coelho Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit 9108ef6bdd61af3bda67ddc8ab50143af7070004 Author: Andrei Otcheretianski Date: Fri Jan 31 15:45:24 2020 +0200 iwlwifi: mvm: Fix thermal zone registration [ Upstream commit baa6cf8450b72dcab11f37c47efce7c5b9b8ad0f ] Use a unique name when registering a thermal zone. Otherwise, with multiple NICS, we hit the following warning during the unregistration. WARNING: CPU: 2 PID: 3525 at fs/sysfs/group.c:255 RIP: 0010:sysfs_remove_group+0x80/0x90 Call Trace: dpm_sysfs_remove+0x57/0x60 device_del+0x5a/0x350 ? sscanf+0x4e/0x70 device_unregister+0x1a/0x60 hwmon_device_unregister+0x4a/0xa0 thermal_remove_hwmon_sysfs+0x175/0x1d0 thermal_zone_device_unregister+0x188/0x1e0 iwl_mvm_thermal_exit+0xe7/0x100 [iwlmvm] iwl_op_mode_mvm_stop+0x27/0x180 [iwlmvm] _iwl_op_mode_stop.isra.3+0x2b/0x50 [iwlwifi] iwl_opmode_deregister+0x90/0xa0 [iwlwifi] __exit_compat+0x10/0x2c7 [iwlmvm] __x64_sys_delete_module+0x13f/0x270 do_syscall_64+0x5a/0x110 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Signed-off-by: Andrei Otcheretianski Signed-off-by: Luca Coelho Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit cef2e37a0b01cb505e91a66710764efa69c68a90 Author: Christoph Hellwig Date: Thu Jan 30 19:40:24 2020 +0100 nvme-pci: remove nvmeq->tags [ Upstream commit cfa27356f835dc7755192e7b941d4f4851acbcc7 ] There is no real need to have a pointer to the tagset in struct nvme_queue, as we only need it in a single place, and that place can derive the used tagset from the device and qid trivially. This fixes a problem with stale pointer exposure when tagsets are reset, and also shrinks the nvme_queue structure. It also matches what most other transports have done since day 1. Reported-by: Edmund Nadolski Signed-off-by: Christoph Hellwig Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 5068f9ec5356d2c637986e3007d9bd9a22eebd04 Author: Sagi Grimberg Date: Sun Jan 26 23:23:28 2020 -0800 nvmet: fix dsm failure when payload does not match sgl descriptor [ Upstream commit b716e6889c95f64ba32af492461f6cc9341f3f05 ] The host is allowed to pass the controller an sgl describing a buffer that is larger than the dsm payload itself, allow it when executing dsm. Reported-by: Dakshaja Uppalapati Reviewed-by: Christoph Hellwig , Reviewed-by: Max Gurtovoy Signed-off-by: Sagi Grimberg Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 5c817cec3a34f0900a11a421779f37100c6e01ea Author: Amol Grover Date: Sat Jan 11 13:08:16 2020 +0530 nvmet: Pass lockdep expression to RCU lists [ Upstream commit 4ac76436a6d07dec1c3c766f234aa787a16e8f65 ] ctrl->subsys->namespaces and subsys->namespaces are traversed with list_for_each_entry_rcu outside an RCU read-side critical section but under the protection of ctrl->subsys->lock and subsys->lock respectively. Hence, add the corresponding lockdep expression to the list traversal primitive to silence false-positive lockdep warnings, and harden RCU lists. Reported-by: kbuild test robot Reviewed-by: Joel Fernandes (Google) Signed-off-by: Amol Grover Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 72c6072244e94b720611af66603f7fa2b6d62d3d Author: Zenghui Yu Date: Mon Dec 2 15:10:21 2019 +0800 irqchip/gic-v3-its: Reference to its_invall_cmd descriptor when building INVALL [ Upstream commit 107945227ac5d4c37911c7841b27c64b489ce9a9 ] It looks like an obvious mistake to use its_mapc_cmd descriptor when building the INVALL command block. It so far worked by luck because both its_mapc_cmd.col and its_invall_cmd.col sit at the same offset of the ITS command descriptor, but we should not rely on it. Fixes: cc2d3216f53c ("irqchip: GICv3: ITS command queue") Signed-off-by: Zenghui Yu Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/20191202071021.1251-1-yuzenghui@huawei.com Signed-off-by: Sasha Levin commit 46991b1804675f043a6b91567b6a23399a984c3f Author: Coly Li Date: Sat Feb 1 22:42:34 2020 +0800 bcache: fix incorrect data type usage in btree_flush_write() [ Upstream commit d1c3cc34f5a78b38d2b809b289d912c3560545df ] Dan Carpenter points out that from commit 2aa8c529387c ("bcache: avoid unnecessary btree nodes flushing in btree_flush_write()"), there is a incorrect data type usage which leads to the following static checker warning: drivers/md/bcache/journal.c:444 btree_flush_write() warn: 'ref_nr' unsigned <= 0 drivers/md/bcache/journal.c 422 static void btree_flush_write(struct cache_set *c) 423 { 424 struct btree *b, *t, *btree_nodes[BTREE_FLUSH_NR]; 425 unsigned int i, nr, ref_nr; ^^^^^^ 426 atomic_t *fifo_front_p, *now_fifo_front_p; 427 size_t mask; 428 429 if (c->journal.btree_flushing) 430 return; 431 432 spin_lock(&c->journal.flush_write_lock); 433 if (c->journal.btree_flushing) { 434 spin_unlock(&c->journal.flush_write_lock); 435 return; 436 } 437 c->journal.btree_flushing = true; 438 spin_unlock(&c->journal.flush_write_lock); 439 440 /* get the oldest journal entry and check its refcount */ 441 spin_lock(&c->journal.lock); 442 fifo_front_p = &fifo_front(&c->journal.pin); 443 ref_nr = atomic_read(fifo_front_p); 444 if (ref_nr <= 0) { ^^^^^^^^^^^ Unsigned can't be less than zero. 445 /* 446 * do nothing if no btree node references 447 * the oldest journal entry 448 */ 449 spin_unlock(&c->journal.lock); 450 goto out; 451 } 452 spin_unlock(&c->journal.lock); As the warning information indicates, local varaible ref_nr in unsigned int type is wrong, which does not matche atomic_read() and the "<= 0" checking. This patch fixes the above error by defining local variable ref_nr as int type. Fixes: 2aa8c529387c ("bcache: avoid unnecessary btree nodes flushing in btree_flush_write()") Reported-by: Dan Carpenter Signed-off-by: Coly Li Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 328c1eab194a218e36fe0abdcfff898fe7e6d306 Author: Coly Li Date: Sat Feb 1 22:42:32 2020 +0800 bcache: explicity type cast in bset_bkey_last() [ Upstream commit 7c02b0055f774ed9afb6e1c7724f33bf148ffdc0 ] In bset.h, macro bset_bkey_last() is defined as, bkey_idx((struct bkey *) (i)->d, (i)->keys) Parameter i can be variable type of data structure, the macro always works once the type of struct i has member 'd' and 'keys'. bset_bkey_last() is also used in macro csum_set() to calculate the checksum of a on-disk data structure. When csum_set() is used to calculate checksum of on-disk bcache super block, the parameter 'i' data type is struct cache_sb_disk. Inside struct cache_sb_disk (also in struct cache_sb) the member keys is __u16 type. But bkey_idx() expects unsigned int (a 32bit width), so there is problem when sending parameters via stack to call bkey_idx(). Sparse tool from Intel 0day kbuild system reports this incompatible problem. bkey_idx() is part of user space API, so the simplest fix is to cast the (i)->keys to unsigned int type in macro bset_bkey_last(). Reported-by: kbuild test robot Signed-off-by: Coly Li Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 1c6bfe895c94d27e78b565cece046d3d75208600 Author: Coly Li Date: Sat Feb 1 22:42:31 2020 +0800 bcache: fix memory corruption in bch_cache_accounting_clear() [ Upstream commit 5bebf7486d4f4940b2a8e4009beb1dff5041853d ] Commit 83ff9318c44ba ("bcache: not use hard coded memset size in bch_cache_accounting_clear()") tries to make the code more easy to understand by removing the hard coded number with following change, void bch_cache_accounting_clear(...) { memset(&acc->total.cache_hits, 0, - sizeof(unsigned long) * 7); + sizeof(struct cache_stats)); } Unfortunately the change was wrong (it also tells us the original code was not easy to correctly understand). The hard coded number 7 is used because in struct cache_stats, 15 struct cache_stats { 16 struct kobject kobj; 17 18 unsigned long cache_hits; 19 unsigned long cache_misses; 20 unsigned long cache_bypass_hits; 21 unsigned long cache_bypass_misses; 22 unsigned long cache_readaheads; 23 unsigned long cache_miss_collisions; 24 unsigned long sectors_bypassed; 25 26 unsigned int rescale; 27 }; only members in LINE 18-24 want to be set to 0. It is wrong to use 'sizeof(struct cache_stats)' to replace 'sizeof(unsigned long) * 7), the memory objects behind acc->total is staled by this change. Сорокин Артем Сергеевич reports that by the following steps, kernel panic will be triggered, 1. Create new set: make-bcache -B /dev/nvme1n1 -C /dev/sda --wipe-bcache 2. Run in /sys/fs/bcache/: echo 1 > clear_stats && cat stats_five_minute/cache_bypass_hits I can reproduce the panic and get following dmesg with KASAN enabled, [22613.172742] ================================================================== [22613.172862] BUG: KASAN: null-ptr-deref in sysfs_kf_seq_show+0x117/0x230 [22613.172864] Read of size 8 at addr 0000000000000000 by task cat/6753 [22613.172870] CPU: 1 PID: 6753 Comm: cat Not tainted 5.5.0-rc7-lp151.28.16-default+ #11 [22613.172872] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/29/2019 [22613.172873] Call Trace: [22613.172964] dump_stack+0x8b/0xbb [22613.172968] ? sysfs_kf_seq_show+0x117/0x230 [22613.172970] ? sysfs_kf_seq_show+0x117/0x230 [22613.173031] __kasan_report+0x176/0x192 [22613.173064] ? pr_cont_kernfs_name+0x40/0x60 [22613.173067] ? sysfs_kf_seq_show+0x117/0x230 [22613.173070] kasan_report+0xe/0x20 [22613.173072] sysfs_kf_seq_show+0x117/0x230 [22613.173105] seq_read+0x199/0x6d0 [22613.173110] vfs_read+0xa5/0x1a0 [22613.173113] ksys_read+0x110/0x160 [22613.173115] ? kernel_write+0xb0/0xb0 [22613.173177] do_syscall_64+0x77/0x290 [22613.173238] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [22613.173241] RIP: 0033:0x7fc2c886ac61 [22613.173244] Code: fe ff ff 48 8d 3d c7 a0 09 00 48 83 ec 08 e8 46 03 02 00 66 0f 1f 44 00 00 8b 05 ca fb 2c 00 48 63 ff 85 c0 75 13 31 c0 0f 05 <48> 3d 00 f0 ff ff 77 57 f3 c3 0f 1f 44 00 00 55 53 48 89 d5 48 89 [22613.173245] RSP: 002b:00007ffebe776d68 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 [22613.173248] RAX: ffffffffffffffda RBX: 0000000000020000 RCX: 00007fc2c886ac61 [22613.173249] RDX: 0000000000020000 RSI: 00007fc2c8cca000 RDI: 0000000000000003 [22613.173250] RBP: 0000000000020000 R08: ffffffffffffffff R09: 0000000000000000 [22613.173251] R10: 000000000000038c R11: 0000000000000246 R12: 00007fc2c8cca000 [22613.173253] R13: 0000000000000003 R14: 00007fc2c8cca00f R15: 0000000000020000 [22613.173255] ================================================================== [22613.173256] Disabling lock debugging due to kernel taint [22613.173350] BUG: kernel NULL pointer dereference, address: 0000000000000000 [22613.178380] #PF: supervisor read access in kernel mode [22613.180959] #PF: error_code(0x0000) - not-present page [22613.183444] PGD 0 P4D 0 [22613.184867] Oops: 0000 [#1] SMP KASAN PTI [22613.186797] CPU: 1 PID: 6753 Comm: cat Tainted: G B 5.5.0-rc7-lp151.28.16-default+ #11 [22613.191253] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/29/2019 [22613.196706] RIP: 0010:sysfs_kf_seq_show+0x117/0x230 [22613.199097] Code: ff 48 8b 0b 48 8b 44 24 08 48 01 e9 eb a6 31 f6 48 89 cf ba 00 10 00 00 48 89 4c 24 10 e8 b1 e6 e9 ff 4c 89 ff e8 19 07 ea ff <49> 8b 07 48 85 c0 48 89 44 24 08 0f 84 91 00 00 00 49 8b 6d 00 48 [22613.208016] RSP: 0018:ffff8881d4f8fd78 EFLAGS: 00010246 [22613.210448] RAX: 0000000000000000 RBX: ffff8881eb99b180 RCX: ffffffff810d9ef6 [22613.213691] RDX: 0000000000000001 RSI: 0000000000000246 RDI: 0000000000000246 [22613.216893] RBP: 0000000000001000 R08: fffffbfff072ddcd R09: fffffbfff072ddcd [22613.220075] R10: 0000000000000001 R11: fffffbfff072ddcc R12: ffff8881de5c0200 [22613.223256] R13: ffff8881ed175500 R14: ffff8881eb99b198 R15: 0000000000000000 [22613.226290] FS: 00007fc2c8d3d500(0000) GS:ffff8881f2a80000(0000) knlGS:0000000000000000 [22613.229637] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [22613.231993] CR2: 0000000000000000 CR3: 00000001ec89a004 CR4: 00000000003606e0 [22613.234909] Call Trace: [22613.235931] seq_read+0x199/0x6d0 [22613.237259] vfs_read+0xa5/0x1a0 [22613.239229] ksys_read+0x110/0x160 [22613.240590] ? kernel_write+0xb0/0xb0 [22613.242040] do_syscall_64+0x77/0x290 [22613.243625] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [22613.245450] RIP: 0033:0x7fc2c886ac61 [22613.246706] Code: fe ff ff 48 8d 3d c7 a0 09 00 48 83 ec 08 e8 46 03 02 00 66 0f 1f 44 00 00 8b 05 ca fb 2c 00 48 63 ff 85 c0 75 13 31 c0 0f 05 <48> 3d 00 f0 ff ff 77 57 f3 c3 0f 1f 44 00 00 55 53 48 89 d5 48 89 [22613.253296] RSP: 002b:00007ffebe776d68 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 [22613.255835] RAX: ffffffffffffffda RBX: 0000000000020000 RCX: 00007fc2c886ac61 [22613.258472] RDX: 0000000000020000 RSI: 00007fc2c8cca000 RDI: 0000000000000003 [22613.260807] RBP: 0000000000020000 R08: ffffffffffffffff R09: 0000000000000000 [22613.263188] R10: 000000000000038c R11: 0000000000000246 R12: 00007fc2c8cca000 [22613.265598] R13: 0000000000000003 R14: 00007fc2c8cca00f R15: 0000000000020000 [22613.268729] Modules linked in: scsi_transport_iscsi af_packet iscsi_ibft iscsi_boot_sysfs vmw_vsock_vmci_transport vsock fuse bnep kvm_intel kvm irqbypass crc32_pclmul crc32c_intel ghash_clmulni_intel snd_ens1371 snd_ac97_codec ac97_bus bcache snd_pcm btusb btrtl btbcm btintel crc64 aesni_intel glue_helper crypto_simd vmw_balloon cryptd bluetooth snd_timer snd_rawmidi snd joydev pcspkr e1000 rfkill vmw_vmci soundcore ecdh_generic ecc gameport i2c_piix4 mptctl ac button hid_generic usbhid sr_mod cdrom ata_generic ehci_pci vmwgfx uhci_hcd drm_kms_helper syscopyarea serio_raw sysfillrect sysimgblt fb_sys_fops ttm ehci_hcd mptspi scsi_transport_spi mptscsih ata_piix mptbase ahci usbcore libahci drm sg dm_multipath dm_mod scsi_dh_rdac scsi_dh_emc scsi_dh_alua [22613.292429] CR2: 0000000000000000 [22613.293563] ---[ end trace a074b26a8508f378 ]--- [22613.295138] RIP: 0010:sysfs_kf_seq_show+0x117/0x230 [22613.296769] Code: ff 48 8b 0b 48 8b 44 24 08 48 01 e9 eb a6 31 f6 48 89 cf ba 00 10 00 00 48 89 4c 24 10 e8 b1 e6 e9 ff 4c 89 ff e8 19 07 ea ff <49> 8b 07 48 85 c0 48 89 44 24 08 0f 84 91 00 00 00 49 8b 6d 00 48 [22613.303553] RSP: 0018:ffff8881d4f8fd78 EFLAGS: 00010246 [22613.305280] RAX: 0000000000000000 RBX: ffff8881eb99b180 RCX: ffffffff810d9ef6 [22613.307924] RDX: 0000000000000001 RSI: 0000000000000246 RDI: 0000000000000246 [22613.310272] RBP: 0000000000001000 R08: fffffbfff072ddcd R09: fffffbfff072ddcd [22613.312685] R10: 0000000000000001 R11: fffffbfff072ddcc R12: ffff8881de5c0200 [22613.315076] R13: ffff8881ed175500 R14: ffff8881eb99b198 R15: 0000000000000000 [22613.318116] FS: 00007fc2c8d3d500(0000) GS:ffff8881f2a80000(0000) knlGS:0000000000000000 [22613.320743] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [22613.322628] CR2: 0000000000000000 CR3: 00000001ec89a004 CR4: 00000000003606e0 Here this patch fixes the following problem by explicity set all the 7 members to 0 in bch_cache_accounting_clear(). Reported-by: Сорокин Артем Сергеевич Signed-off-by: Coly Li Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit a56f1f45694f61d7df7de26a78aae368cea38952 Author: Yunfeng Ye Date: Thu Jan 30 22:17:26 2020 -0800 reiserfs: prevent NULL pointer dereference in reiserfs_insert_item() [ Upstream commit aacee5446a2a1aa35d0a49dab289552578657fb4 ] The variable inode may be NULL in reiserfs_insert_item(), but there is no check before accessing the member of inode. Fix this by adding NULL pointer check before calling reiserfs_debug(). Link: http://lkml.kernel.org/r/79c5135d-ff25-1cc9-4e99-9f572b88cc00@huawei.com Signed-off-by: Yunfeng Ye Cc: zhengbin Cc: Hu Shiyuan Cc: Feilong Lin Cc: Jan Kara Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit d11dbc093e48296118abc311f1e3020572afbb9d Author: Nathan Chancellor Date: Thu Jan 30 22:16:37 2020 -0800 lib/scatterlist.c: adjust indentation in __sg_alloc_table [ Upstream commit 4e456fee215677584cafa7f67298a76917e89c64 ] Clang warns: ../lib/scatterlist.c:314:5: warning: misleading indentation; statement is not part of the previous 'if' [-Wmisleading-indentation] return -ENOMEM; ^ ../lib/scatterlist.c:311:4: note: previous statement is here if (prv) ^ 1 warning generated. This warning occurs because there is a space before the tab on this line. Remove it so that the indentation is consistent with the Linux kernel coding style and clang no longer warns. Link: http://lkml.kernel.org/r/20191218033606.11942-1-natechancellor@gmail.com Link: https://github.com/ClangBuiltLinux/linux/issues/830 Fixes: edce6820a9fd ("scatterlist: prevent invalid free when alloc fails") Signed-off-by: Nathan Chancellor Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit f08694f0c9d6c45699022ebb39f54a256e3533df Author: wangyan Date: Thu Jan 30 22:11:50 2020 -0800 ocfs2: fix a NULL pointer dereference when call ocfs2_update_inode_fsync_trans() [ Upstream commit 9f16ca48fc818a17de8be1f75d08e7f4addc4497 ] I found a NULL pointer dereference in ocfs2_update_inode_fsync_trans(), handle->h_transaction may be NULL in this situation: ocfs2_file_write_iter ->__generic_file_write_iter ->generic_perform_write ->ocfs2_write_begin ->ocfs2_write_begin_nolock ->ocfs2_write_cluster_by_desc ->ocfs2_write_cluster ->ocfs2_mark_extent_written ->ocfs2_change_extent_flag ->ocfs2_split_extent ->ocfs2_try_to_merge_extent ->ocfs2_extend_rotate_transaction ->ocfs2_extend_trans ->jbd2_journal_restart ->jbd2__journal_restart // handle->h_transaction is NULL here ->handle->h_transaction = NULL; ->start_this_handle /* journal aborted due to storage network disconnection, return error */ ->return -EROFS; /* line 3806 in ocfs2_try_to_merge_extent (), it will ignore ret error. */ ->ret = 0; ->... ->ocfs2_write_end ->ocfs2_write_end_nolock ->ocfs2_update_inode_fsync_trans // NULL pointer dereference ->oi->i_sync_tid = handle->h_transaction->t_tid; The information of NULL pointer dereference as follows: JBD2: Detected IO errors while flushing file data on dm-11-45 Aborting journal on device dm-11-45. JBD2: Error -5 detected when updating journal superblock for dm-11-45. (dd,22081,3):ocfs2_extend_trans:474 ERROR: status = -30 (dd,22081,3):ocfs2_try_to_merge_extent:3877 ERROR: status = -30 Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 Mem abort info: ESR = 0x96000004 Exception class = DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 Data abort info: ISV = 0, ISS = 0x00000004 CM = 0, WnR = 0 user pgtable: 4k pages, 48-bit VAs, pgdp = 00000000e74e1338 [0000000000000008] pgd=0000000000000000 Internal error: Oops: 96000004 [#1] SMP Process dd (pid: 22081, stack limit = 0x00000000584f35a9) CPU: 3 PID: 22081 Comm: dd Kdump: loaded Hardware name: Huawei TaiShan 2280 V2/BC82AMDD, BIOS 0.98 08/25/2019 pstate: 60400009 (nZCv daif +PAN -UAO) pc : ocfs2_write_end_nolock+0x2b8/0x550 [ocfs2] lr : ocfs2_write_end_nolock+0x2a0/0x550 [ocfs2] sp : ffff0000459fba70 x29: ffff0000459fba70 x28: 0000000000000000 x27: ffff807ccf7f1000 x26: 0000000000000001 x25: ffff807bdff57970 x24: ffff807caf1d4000 x23: ffff807cc79e9000 x22: 0000000000001000 x21: 000000006c6cd000 x20: ffff0000091d9000 x19: ffff807ccb239db0 x18: ffffffffffffffff x17: 000000000000000e x16: 0000000000000007 x15: ffff807c5e15bd78 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000001 x9 : 0000000000000228 x8 : 000000000000000c x7 : 0000000000000fff x6 : ffff807a308ed6b0 x5 : ffff7e01f10967c0 x4 : 0000000000000018 x3 : d0bc661572445600 x2 : 0000000000000000 x1 : 000000001b2e0200 x0 : 0000000000000000 Call trace: ocfs2_write_end_nolock+0x2b8/0x550 [ocfs2] ocfs2_write_end+0x4c/0x80 [ocfs2] generic_perform_write+0x108/0x1a8 __generic_file_write_iter+0x158/0x1c8 ocfs2_file_write_iter+0x668/0x950 [ocfs2] __vfs_write+0x11c/0x190 vfs_write+0xac/0x1c0 ksys_write+0x6c/0xd8 __arm64_sys_write+0x24/0x30 el0_svc_common+0x78/0x130 el0_svc_handler+0x38/0x78 el0_svc+0x8/0xc To prevent NULL pointer dereference in this situation, we use is_handle_aborted() before using handle->h_transaction->t_tid. Link: http://lkml.kernel.org/r/03e750ab-9ade-83aa-b000-b9e81e34e539@huawei.com Signed-off-by: Yan Wang Reviewed-by: Jun Piao Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Joseph Qi Cc: Changwei Ge Cc: Gang He Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit c37a800b727906aafc07027df31610a62df111f2 Author: Masahiro Yamada Date: Thu Jan 30 22:11:40 2020 -0800 ocfs2: make local header paths relative to C files [ Upstream commit ca322fb6030956c2337fbf1c1beeb08c5dd5c943 ] Gang He reports the failure of building fs/ocfs2/ as an external module of the kernel installed on the system: $ cd fs/ocfs2 $ make -C /lib/modules/`uname -r`/build M=`pwd` modules If you want to make it work reliably, I'd recommend to remove ccflags-y from the Makefiles, and to make header paths relative to the C files. I think this is the correct usage of the #include "..." directive. Link: http://lkml.kernel.org/r/20191227022950.14804-1-ghe@suse.com Signed-off-by: Masahiro Yamada Signed-off-by: Gang He Reported-by: Gang He Reviewed-by: Gang He Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Joseph Qi Cc: Changwei Ge Cc: Jun Piao Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit c78a2baf5e1fe1b38121d6b54bab77ccb81a1a86 Author: Tom Zanussi Date: Wed Jan 29 21:18:18 2020 -0500 tracing: Fix now invalid var_ref_vals assumption in trace action [ Upstream commit d380dcde9a07ca5de4805dee11f58a98ec0ad6ff ] The patch 'tracing: Fix histogram code when expression has same var as value' added code to return an existing variable reference when creating a new variable reference, which resulted in var_ref_vals slots being reused instead of being duplicated. The implementation of the trace action assumes that the end of the var_ref_vals array starting at action_data.var_ref_idx corresponds to the values that will be assigned to the trace params. The patch mentioned above invalidates that assumption, which means that each param needs to explicitly specify its index into var_ref_vals. This fix changes action_data.var_ref_idx to an array of var ref indexes to account for that. Link: https://lore.kernel.org/r/1580335695.6220.8.camel@kernel.org Fixes: 8bcebc77e85f ("tracing: Fix histogram code when expression has same var as value") Signed-off-by: Tom Zanussi Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Sasha Levin commit 6026fd9da213daab95469356fe7fdcf29ae1a296 Author: Josef Bacik Date: Tue Jan 21 14:34:52 2020 -0500 btrfs: do not do delalloc reservation under page lock [ Upstream commit f4b1363cae43fef7c86c993b7ca7fe7d546b3c68 ] We ran into a deadlock in production with the fixup worker. The stack traces were as follows: Thread responsible for the writeout, waiting on the page lock [<0>] io_schedule+0x12/0x40 [<0>] __lock_page+0x109/0x1e0 [<0>] extent_write_cache_pages+0x206/0x360 [<0>] extent_writepages+0x40/0x60 [<0>] do_writepages+0x31/0xb0 [<0>] __writeback_single_inode+0x3d/0x350 [<0>] writeback_sb_inodes+0x19d/0x3c0 [<0>] __writeback_inodes_wb+0x5d/0xb0 [<0>] wb_writeback+0x231/0x2c0 [<0>] wb_workfn+0x308/0x3c0 [<0>] process_one_work+0x1e0/0x390 [<0>] worker_thread+0x2b/0x3c0 [<0>] kthread+0x113/0x130 [<0>] ret_from_fork+0x35/0x40 [<0>] 0xffffffffffffffff Thread of the fixup worker who is holding the page lock [<0>] start_delalloc_inodes+0x241/0x2d0 [<0>] btrfs_start_delalloc_roots+0x179/0x230 [<0>] btrfs_alloc_data_chunk_ondemand+0x11b/0x2e0 [<0>] btrfs_check_data_free_space+0x53/0xa0 [<0>] btrfs_delalloc_reserve_space+0x20/0x70 [<0>] btrfs_writepage_fixup_worker+0x1fc/0x2a0 [<0>] normal_work_helper+0x11c/0x360 [<0>] process_one_work+0x1e0/0x390 [<0>] worker_thread+0x2b/0x3c0 [<0>] kthread+0x113/0x130 [<0>] ret_from_fork+0x35/0x40 [<0>] 0xffffffffffffffff Thankfully the stars have to align just right to hit this. First you have to end up in the fixup worker, which is tricky by itself (my reproducer does DIO reads into a MMAP'ed region, so not a common operation). Then you have to have less than a page size of free data space and 0 unallocated space so you go down the "commit the transaction to free up pinned space" path. This was accomplished by a random balance that was running on the host. Then you get this deadlock. I'm still in the process of trying to force the deadlock to happen on demand, but I've hit other issues. I can still trigger the fixup worker path itself so this patch has been tested in that regard, so the normal case is fine. Fixes: 87826df0ec36 ("btrfs: delalloc for page dirtied out-of-band in fixup worker") Signed-off-by: Josef Bacik Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 89a2281b1a5094bc05263cc0e3090e146cf57b21 Author: Alexandre Ghiti Date: Sat Jan 18 12:03:35 2020 -0500 powerpc: Do not consider weak unresolved symbol relocations as bad [ Upstream commit 43e76cd368fbb67e767da5363ffeaa3989993c8c ] Commit 8580ac9404f6 ("bpf: Process in-kernel BTF") introduced two weak symbols that may be unresolved at link time which result in an absolute relocation to 0. relocs_check.sh emits the following warning: "WARNING: 2 bad relocations c000000001a41478 R_PPC64_ADDR64 _binary__btf_vmlinux_bin_start c000000001a41480 R_PPC64_ADDR64 _binary__btf_vmlinux_bin_end" whereas those relocations are legitimate even for a relocatable kernel compiled with -pie option. relocs_check.sh already excluded some weak unresolved symbols explicitly: remove those hardcoded symbols and add some logic that parses the symbols using nm, retrieves all the weak unresolved symbols and excludes those from the list of the potential bad relocations. Reported-by: Stephen Rothwell Signed-off-by: Alexandre Ghiti Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20200118170335.21440-1-alex@ghiti.fr Signed-off-by: Sasha Levin commit 9d7222c9f95c7c3852f4af9df809404e85ee605c Author: Daniel Vetter Date: Tue Jan 28 17:09:52 2020 +0100 radeon: insert 10ms sleep in dce5_crtc_load_lut [ Upstream commit ec3d65082d7dabad6fa8f66a8ef166f2d522d6b2 ] Per at least one tester this is enough magic to recover the regression introduced for some people (but not all) in commit b8e2b0199cc377617dc238f5106352c06dcd3fa2 Author: Peter Rosin Date: Tue Jul 4 12:36:57 2017 +0200 drm/fb-helper: factor out pseudo-palette which for radeon had the side-effect of refactoring out a seemingly redudant writing of the color palette. 10ms in a fairly slow modeset path feels like an acceptable form of duct-tape, so maybe worth a shot and see what sticks. Cc: Alex Deucher Cc: Michel Dänzer References: https://bugzilla.kernel.org/show_bug.cgi?id=198123 Signed-off-by: Daniel Vetter Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 1432928883b700cdcf9574c2979a4ef789617c03 Author: Vasily Averin Date: Fri Jan 24 10:03:06 2020 +0300 trigger_next should increase position index [ Upstream commit 6722b23e7a2ace078344064a9735fb73e554e9ef ] if seq_file .next fuction does not change position index, read after some lseek can generate unexpected output. Without patch: # dd bs=30 skip=1 if=/sys/kernel/tracing/events/sched/sched_switch/trigger dd: /sys/kernel/tracing/events/sched/sched_switch/trigger: cannot skip to specified offset n traceoff snapshot stacktrace enable_event disable_event enable_hist disable_hist hist # Available triggers: # traceon traceoff snapshot stacktrace enable_event disable_event enable_hist disable_hist hist 6+1 records in 6+1 records out 206 bytes copied, 0.00027916 s, 738 kB/s Notice the printing of "# Available triggers:..." after the line. With the patch: # dd bs=30 skip=1 if=/sys/kernel/tracing/events/sched/sched_switch/trigger dd: /sys/kernel/tracing/events/sched/sched_switch/trigger: cannot skip to specified offset n traceoff snapshot stacktrace enable_event disable_event enable_hist disable_hist hist 2+1 records in 2+1 records out 88 bytes copied, 0.000526867 s, 167 kB/s It only prints the end of the file, and does not restart. Link: http://lkml.kernel.org/r/3c35ee24-dd3a-8119-9c19-552ed253388a@virtuozzo.com https://bugzilla.kernel.org/show_bug.cgi?id=206283 Signed-off-by: Vasily Averin Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Sasha Levin commit 8306f5c7d7e5c5c0cd03a4e69ff069868ae1e300 Author: Vasily Averin Date: Fri Jan 24 10:02:56 2020 +0300 ftrace: fpid_next() should increase position index [ Upstream commit e4075e8bdffd93a9b6d6e1d52fabedceeca5a91b ] if seq_file .next fuction does not change position index, read after some lseek can generate unexpected output. Without patch: # dd bs=4 skip=1 if=/sys/kernel/tracing/set_ftrace_pid dd: /sys/kernel/tracing/set_ftrace_pid: cannot skip to specified offset id no pid 2+1 records in 2+1 records out 10 bytes copied, 0.000213285 s, 46.9 kB/s Notice the "id" followed by "no pid". With the patch: # dd bs=4 skip=1 if=/sys/kernel/tracing/set_ftrace_pid dd: /sys/kernel/tracing/set_ftrace_pid: cannot skip to specified offset id 0+1 records in 0+1 records out 3 bytes copied, 0.000202112 s, 14.8 kB/s Notice that it only prints "id" and not the "no pid" afterward. Link: http://lkml.kernel.org/r/4f87c6ad-f114-30bb-8506-c32274ce2992@virtuozzo.com https://bugzilla.kernel.org/show_bug.cgi?id=206283 Signed-off-by: Vasily Averin Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Sasha Levin commit b694a3efe713b538ed14d737021dd3fec61e2c73 Author: Gustavo A. R. Silva Date: Tue Jan 28 20:26:13 2020 -0600 char: hpet: Fix out-of-bounds read bug [ Upstream commit 98c49f1746ac44ccc164e914b9a44183fad09f51 ] Currently, there is an out-of-bounds read on array hpetp->hp_dev in the following for loop: 870 for (i = 0; i < hdp->hd_nirqs; i++) 871 hpetp->hp_dev[i].hd_hdwirq = hdp->hd_irq[i]; This is due to the recent change from one-element array to flexible-array member in struct hpets: 104 struct hpets { ... 113 struct hpet_dev hp_dev[]; 114 }; This change affected the total size of the dynamic memory allocation, decreasing it by one time the size of struct hpet_dev. Fix this by adjusting the allocation size when calling struct_size(). Fixes: 987f028b8637c ("char: hpet: Use flexible-array member") Signed-off-by: Gustavo A. R. Silva Signed-off-by: Tetsuo Handa Acked-by: Eric Biggers Link: https://lore.kernel.org/r/20200129022613.GA24281@embeddedor.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit bbff9cd26170b98fa296df79bd2aec0f98e4f071 Author: Ben Skeggs Date: Tue Jan 28 14:39:26 2020 +1000 drm/nouveau/disp/nv50-: prevent oops when no channel method map provided [ Upstream commit 0e6176c6d286316e9431b4f695940cfac4ffe6c2 ] The implementations for most channel types contains a map of methods to priv registers in order to provide debugging info when a disp exception has been raised. This info is missing from the implementation of PIO channels as they're rather simplistic already, however, if an exception is raised by one of them, we'd end up triggering a NULL-pointer deref. Not ideal... Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=206299 Signed-off-by: Ben Skeggs Signed-off-by: Sasha Levin commit e12c1aab2fcc5c306609434b3eb12751469554f6 Author: Bharata B Rao Date: Wed Jan 22 10:25:42 2020 +0530 KVM: PPC: Book3S HV: Release lock on page-out failure path [ Upstream commit e032e3b55b6f487e48c163c5dca74086f147a169 ] When migrate_vma_setup() fails in kvmppc_svm_page_out(), release kvm->arch.uvmem_lock before returning. Fixes: ca9f4942670 ("KVM: PPC: Book3S HV: Support for running secure guests") Signed-off-by: Bharata B Rao Reviewed-by: Kamalesh Babulal Signed-off-by: Paul Mackerras Signed-off-by: Sasha Levin commit 28fb656e752822b44c5642dce3659192cb235dcb Author: Marc Zyngier Date: Mon Dec 16 11:24:57 2019 +0000 irqchip/gic-v3: Only provision redistributors that are enabled in ACPI [ Upstream commit 926b5dfa6b8dc666ff398044af6906b156e1d949 ] We currently allocate redistributor region structures for individual redistributors when ACPI doesn't present us with compact MMIO regions covering multiple redistributors. It turns out that we allocate these structures even when the redistributor is flagged as disabled by ACPI. It works fine until someone actually tries to tarse one of these structures, and access the corresponding MMIO region. Instead, track the number of enabled redistributors, and only allocate what is required. This makes sure that there is no invalid data to misuse. Signed-off-by: Marc Zyngier Reported-by: Heyi Guo Tested-by: Heyi Guo Link: https://lore.kernel.org/r/20191216062745.63397-1-guoheyi@huawei.com Signed-off-by: Sasha Levin commit c7ef30f0a5bc6aa266a3d6c8a698f05df8fff647 Author: Dor Askayo Date: Sat Jan 4 14:22:15 2020 +0200 drm/amd/display: do not allocate display_mode_lib unnecessarily [ Upstream commit bb67bfd2e7101bf2ac5327b0b7a847cd9fb9723f ] This allocation isn't required and can fail when resuming from suspend. Bug: https://gitlab.freedesktop.org/drm/amd/issues/1009 Signed-off-by: Dor Askayo Reviewed-by: Leo Li Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 478c9a91859614189baffe1401a877ab3b12bf73 Author: Guennadi Liakhovetski Date: Fri Jan 24 15:36:25 2020 -0600 ASoC: Intel: consistent HDMI codec probing code [ Upstream commit 98ff5c262f27aafee077a4c096f71a8566e9e948 ] Multiple Intel ASoC machine drivers repeat the same pattern in their .late_probe() methods: they first check whether the common HDMI codec driver is used, if not, they proceed by linking the legacy HDMI driver to each HDMI port. While doing that they use some inconsistent code: 1. after the loop they check, whether the list contained at least one element and if not, they return an error. However, the earlier code to use the common HDMI driver uses the first element of the same list without checking. To fix this we move the check to the top of the function. 2. some of those .late_probe() implementations execute code, only needed for the common HDMI driver, before checking, whether the driver is used. Move the code to after the check. 3. Some of those functions also perform a redundant initialisation of the "err" variable. This patch fixes those issues. Signed-off-by: Guennadi Liakhovetski Signed-off-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20200124213625.30186-8-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 1b1bdb67479a3536a4de74a192130d83c4fa83ce Author: Arnd Bergmann Date: Tue Jan 7 22:01:04 2020 +0100 rbd: work around -Wuninitialized warning [ Upstream commit a55e601b2f02df5db7070e9a37bd655c9c576a52 ] gcc -O3 warns about a dummy variable that is passed down into rbd_img_fill_nodata without being initialized: drivers/block/rbd.c: In function 'rbd_img_fill_nodata': drivers/block/rbd.c:2573:13: error: 'dummy' is used uninitialized in this function [-Werror=uninitialized] fctx->iter = *fctx->pos; Since this is a dummy, I assume the warning is harmless, but it's better to initialize it anyway and avoid the warning. Fixes: mmtom ("init/Kconfig: enable -O3 for all arches") Signed-off-by: Arnd Bergmann Reviewed-by: Ilya Dryomov Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit 4a6a5c393a264a71a6bfff0e30f07d36a22932f0 Author: Xiubo Li Date: Tue Dec 10 20:29:40 2019 -0500 ceph: check availability of mds cluster on mount after wait timeout [ Upstream commit 97820058fb2831a4b203981fa2566ceaaa396103 ] If all the MDS daemons are down for some reason, then the first mount attempt will fail with EIO after the mount request times out. A mount attempt will also fail with EIO if all of the MDS's are laggy. This patch changes the code to return -EHOSTUNREACH in these situations and adds a pr_info error message to help the admin determine the cause. URL: https://tracker.ceph.com/issues/4386 Signed-off-by: Xiubo Li Reviewed-by: Jeff Layton Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit cae5e66dde1d04274c867cb6a5cf3da25563c373 Author: Christophe Leroy Date: Mon Dec 23 07:54:22 2019 +0000 powerpc/mm: Don't log user reads to 0xffffffff [ Upstream commit 0f9aee0cb9da7db7d96f63cfa2dc5e4f1bffeb87 ] Running vdsotest leaves many times the following log: [ 79.629901] vdsotest[396]: User access of kernel address (ffffffff) - exploit attempt? (uid: 0) A pointer set to (-1) is likely a programming error similar to a NULL pointer and is not worth logging as an exploit attempt. Don't log user accesses to 0xffffffff. Signed-off-by: Christophe Leroy Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/0728849e826ba16f1fbd6fa7f5c6cc87bd64e097.1577087627.git.christophe.leroy@c-s.fr Signed-off-by: Sasha Levin commit 1bdfa5900ff670a0fa13b3bcd50dc6f6aa2a63f4 Author: Vasily Averin Date: Sat Jan 25 12:10:02 2020 +0300 bpf: map_seq_next should always increase position index [ Upstream commit 90435a7891a2259b0f74c5a1bc5600d0d64cba8f ] If seq_file .next fuction does not change position index, read after some lseek can generate an unexpected output. See also: https://bugzilla.kernel.org/show_bug.cgi?id=206283 v1 -> v2: removed missed increment in end of function Signed-off-by: Vasily Averin Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/eca84fdd-c374-a154-d874-6c7b55fc3bc4@virtuozzo.com Signed-off-by: Sasha Levin commit e37764ca261d2bc86a512a62d670b7fbce8894a1 Author: Wei Hu Date: Mon Dec 9 15:57:49 2019 +0800 video: hyperv: hyperv_fb: Use physical memory for fb on HyperV Gen 1 VMs. [ Upstream commit 3a6fb6c4255c3893ab61e2bd4e9ae01ca6bbcd94 ] On Hyper-V, Generation 1 VMs can directly use VM's physical memory for their framebuffers. This can improve the efficiency of framebuffer and overall performence for VM. The physical memory assigned to framebuffer must be contiguous. We use CMA allocator to get contiguouse physicial memory when the framebuffer size is greater than 4MB. For size under 4MB, we use alloc_pages to achieve this. To enable framebuffer memory allocation from CMA, supply a kernel parameter to give enough space to CMA allocator at boot time. For example: cma=130m This gives 130MB memory to CAM allocator that can be allocated to framebuffer. If this fails, we fall back to the old way of using mmio for framebuffer. Reported-by: kbuild test robot Signed-off-by: Wei Hu Acked-by: Bartlomiej Zolnierkiewicz Signed-off-by: Sasha Levin commit b3f6d5d65ec28ea0ec264a0d112fd71cdc613c77 Author: Ronnie Sahlberg Date: Wed Jan 22 11:07:56 2020 +1000 cifs: fix NULL dereference in match_prepath [ Upstream commit fe1292686333d1dadaf84091f585ee903b9ddb84 ] RHBZ: 1760879 Fix an oops in match_prepath() by making sure that the prepath string is not NULL before we pass it into strcmp(). This is similar to other checks we make for example in cifs_root_iget() Signed-off-by: Ronnie Sahlberg Signed-off-by: Steve French Signed-off-by: Sasha Levin commit a1977f2d8b146c41270d88a37f42bbda3a5c0924 Author: Paulo Alcantara (SUSE) Date: Thu Jan 9 10:03:19 2020 -0300 cifs: Fix mount options set in automount [ Upstream commit 5739375ee4230980166807d347cc21c305532bbc ] Starting from 4a367dc04435, we must set the mount options based on the DFS full path rather than the resolved target, that is, cifs_mount() will be responsible for resolving the DFS link (cached) as well as performing failover to any other targets in the referral. Signed-off-by: Paulo Alcantara (SUSE) Reported-by: Martijn de Gouw Fixes: 4a367dc04435 ("cifs: Add support for failover in cifs_mount()") Link: https://lore.kernel.org/linux-cifs/39643d7d-2abb-14d3-ced6-c394fab9a777@prodrive-technologies.com Tested-by: Martijn de Gouw Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 79f596ace09cb7ccffc1e6341970462b06d183b7 Author: Steve French Date: Thu Jan 16 15:58:00 2020 -0600 cifs: fix unitialized variable poential problem with network I/O cache lock patch [ Upstream commit 463a7b457c02250a84faa1d23c52da9e3364aed2 ] static analysis with Coverity detected an issue with the following commit: Author: Paulo Alcantara (SUSE) Date: Wed Dec 4 17:38:03 2019 -0300 cifs: Avoid doing network I/O while holding cache lock Addresses-Coverity: ("Uninitialized pointer read") Reported-by: Colin Ian King Signed-off-by: Paulo Alcantara (SUSE) Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 3babf6abb494e5e62f0200e3dfc0c5babb89106d Author: Colin Ian King Date: Sun Jan 26 00:09:54 2020 +0000 iwlegacy: ensure loop counter addr does not wrap and cause an infinite loop [ Upstream commit c2f9a4e4a5abfc84c01b738496b3fd2d471e0b18 ] The loop counter addr is a u16 where as the upper limit of the loop is an int. In the unlikely event that the il->cfg->eeprom_size is greater than 64K then we end up with an infinite loop since addr will wrap around an never reach upper loop limit. Fix this by making addr an int. Addresses-Coverity: ("Infinite loop") Fixes: be663ab67077 ("iwlwifi: split the drivers for agn and legacy devices 3945/4965") Signed-off-by: Colin Ian King Acked-by: Stanislaw Gruszka Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit 6e4af087c8e050d72f9aad8fd342260f9b277298 Author: Yan-Hsuan Chuang Date: Tue Jan 7 16:08:07 2020 +0800 rtw88: fix potential NULL skb access in TX ISR [ Upstream commit f4f84ff8377d4cedf18317747bc407b2cf657d0f ] Sometimes the TX queue may be empty and we could possible dequeue a NULL pointer, crash the kernel. If the skb is NULL then there is nothing to do, just leave the ISR. And the TX queue should not be empty here, so print an error to see if there is anything wrong for DMA ring. Fixes: e3037485c68e ("rtw88: new Realtek 802.11ac driver") Signed-off-by: Yan-Hsuan Chuang Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit 6b9c88af6fc868d0f5a2a4c393abdfbc0e137433 Author: Nathan Chancellor Date: Tue Dec 17 18:15:46 2019 -0700 hostap: Adjust indentation in prism2_hostapd_add_sta [ Upstream commit b61156fba74f659d0bc2de8f2dbf5bad9f4b8faf ] Clang warns: ../drivers/net/wireless/intersil/hostap/hostap_ap.c:2511:3: warning: misleading indentation; statement is not part of the previous 'if' [-Wmisleading-indentation] if (sta->tx_supp_rates & WLAN_RATE_5M5) ^ ../drivers/net/wireless/intersil/hostap/hostap_ap.c:2509:2: note: previous statement is here if (sta->tx_supp_rates & WLAN_RATE_2M) ^ 1 warning generated. This warning occurs because there is a space before the tab on this line. Remove it so that the indentation is consistent with the Linux kernel coding style and clang no longer warns. Fixes: ff1d2767d5a4 ("Add HostAP wireless driver.") Link: https://github.com/ClangBuiltLinux/linux/issues/813 Signed-off-by: Nathan Chancellor Reviewed-by: Nick Desaulniers Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit 2264e85ec867ffe0281ffe9be0292473ad4ecbe1 Author: Nicola Lunghi Date: Sat Jan 25 15:09:17 2020 +0000 ALSA: usb-audio: add quirks for Line6 Helix devices fw>=2.82 [ Upstream commit b81cbf7abfc94878a3c6f0789f2185ee55b1cc21 ] With firmware 2.82 Line6 changed the usb id of some of the Helix devices but the quirks is still needed. Add it to the quirk list for line6 helix family of devices. Thanks to Jens for pointing out the missing ids. Signed-off-by: Nicola Lunghi Link: https://lore.kernel.org/r/20200125150917.5040-1-nick83ola@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 2ec80a7c14941d792cf19548906174fe9f4214a6 Author: Vincenzo Frascino Date: Fri Jan 10 13:37:59 2020 +0100 ARM: 8951/1: Fix Kexec compilation issue. [ Upstream commit 76950f7162cad51d2200ebd22c620c14af38f718 ] To perform the reserve_crashkernel() operation kexec uses SECTION_SIZE to find a memblock in a range. SECTION_SIZE is not defined for nommu systems. Trying to compile kexec in these conditions results in a build error: linux/arch/arm/kernel/setup.c: In function ‘reserve_crashkernel’: linux/arch/arm/kernel/setup.c:1016:25: error: ‘SECTION_SIZE’ undeclared (first use in this function); did you mean ‘SECTIONS_WIDTH’? crash_size, SECTION_SIZE); ^~~~~~~~~~~~ SECTIONS_WIDTH linux/arch/arm/kernel/setup.c:1016:25: note: each undeclared identifier is reported only once for each function it appears in linux/scripts/Makefile.build:265: recipe for target 'arch/arm/kernel/setup.o' failed Make KEXEC depend on MMU to fix the compilation issue. Signed-off-by: Vincenzo Frascino Signed-off-by: Russell King Signed-off-by: Sasha Levin commit ba8d6588a11221d9648ffa154b55b7f9ad0bb631 Author: Ard Biesheuvel Date: Fri Nov 22 12:59:00 2019 +0100 ARM: 8941/1: decompressor: enable CP15 barrier instructions in v7 cache setup code [ Upstream commit 8239fc7755fd3d410920006615abd0c7d653560f ] Commit e17b1af96b2afc38e684aa2f1033387e2ed10029 "ARM: 8857/1: efi: enable CP15 DMB instructions before cleaning the cache" added some explicit handling of the CP15BEN bit in the SCTLR system register, to ensure that CP15 barrier instructions are enabled, even if we enter the decompressor via the EFI stub. However, as it turns out, there are other ways in which we may end up using CP15 barrier instructions without them being enabled. I.e., when the decompressor startup code skips the cache_on() initially, we end up calling cache_clean_flush() with the caches and MMU off, in which case the CP15BEN bit in SCTLR may not be programmed either. And in fact, cache_on() itself issues CP15 barrier instructions before actually enabling them by programming the new SCTLR value (and issuing an ISB) Since these routines are shared between v7 CPUs and older ones that implement the CPUID extension as well, using the ordinary v7 barrier instructions in this code is not possible, and so we should enable the CP15 ones explicitly before issuing them. Note that a v7 ISB is still required between programming the SCTLR register and using the CP15 barrier instructions, and we should take care to branch over it if the CP15BEN bit is already set, given that in that case, the CPU may not support it. Signed-off-by: Ard Biesheuvel Signed-off-by: Russell King Signed-off-by: Sasha Levin commit 2096e0fb2bd08a4c0f885849adb1db5b2e985d75 Author: Oliver O'Halloran Date: Wed Jan 22 14:11:25 2020 +1100 selftests/eeh: Bump EEH wait time to 60s [ Upstream commit 414f50434aa2463202a5b35e844f4125dd1a7101 ] Some newer cards supported by aacraid can take up to 40s to recover after an EEH event. This causes spurious failures in the basic EEH self-test since the current maximim timeout is only 30s. Fix the immediate issue by bumping the timeout to a default of 60s, and allow the wait time to be specified via an environmental variable (EEH_MAX_WAIT). Reported-by: Steve Best Suggested-by: Douglas Miller Signed-off-by: Oliver O'Halloran Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20200122031125.25991-1-oohall@gmail.com Signed-off-by: Sasha Levin commit fafe7c1f076f24223ab76437d20b09aaba706b45 Author: Michael Bringmann Date: Wed Jan 15 08:53:59 2020 -0600 powerpc/pseries/lparcfg: Fix display of Maximum Memory [ Upstream commit f1dbc1c5c70d0d4c60b5d467ba941fba167c12f6 ] Correct overflow problem in calculation and display of Maximum Memory value to syscfg. Signed-off-by: Michael Bringmann [mpe: Only n_lmbs needs casting to unsigned long] Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/5577aef8-1d5a-ca95-ff0a-9c7b5977e5bf@linux.ibm.com Signed-off-by: Sasha Levin commit 3aa3e4130ba5d854e2e563cab18d7fa44b5be0d5 Author: zhangyi (F) Date: Wed Dec 4 20:46:13 2019 +0800 jbd2: make sure ESHUTDOWN to be recorded in the journal superblock [ Upstream commit 0e98c084a21177ef136149c6a293b3d1eb33ff92 ] Commit fb7c02445c49 ("ext4: pass -ESHUTDOWN code to jbd2 layer") want to allow jbd2 layer to distinguish shutdown journal abort from other error cases. So the ESHUTDOWN should be taken precedence over any other errno which has already been recoded after EXT4_FLAGS_SHUTDOWN is set, but it only update errno in the journal suoerblock now if the old errno is 0. Fixes: fb7c02445c49 ("ext4: pass -ESHUTDOWN code to jbd2 layer") Signed-off-by: zhangyi (F) Reviewed-by: Jan Kara Link: https://lore.kernel.org/r/20191204124614.45424-4-yi.zhang@huawei.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 6c17450df89894e6c41988b5f97af31ea5863e49 Author: zhangyi (F) Date: Wed Dec 4 20:46:11 2019 +0800 jbd2: switch to use jbd2_journal_abort() when failed to submit the commit record [ Upstream commit d0a186e0d3e7ac05cc77da7c157dae5aa59f95d9 ] We invoke jbd2_journal_abort() to abort the journal and record errno in the jbd2 superblock when committing journal transaction besides the failure on submitting the commit record. But there is no need for the case and we can also invoke jbd2_journal_abort() instead of __jbd2_journal_abort_hard(). Fixes: 818d276ceb83a ("ext4: Add the journal checksum feature") Signed-off-by: zhangyi (F) Reviewed-by: Jan Kara Link: https://lore.kernel.org/r/20191204124614.45424-2-yi.zhang@huawei.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 94ea0d0f6bf42e34d1a5b5a976867b2ef986c9de Author: Lorenz Bauer Date: Fri Jan 24 11:27:54 2020 +0000 selftests: bpf: Reset global state between reuseport test runs [ Upstream commit 51bad0f05616c43d6d34b0a19bcc9bdab8e8fb39 ] Currently, there is a lot of false positives if a single reuseport test fails. This is because expected_results and the result map are not cleared. Zero both after individual test runs, which fixes the mentioned false positives. Fixes: 91134d849a0e ("bpf: Test BPF_PROG_TYPE_SK_REUSEPORT") Signed-off-by: Lorenz Bauer Signed-off-by: Daniel Borkmann Reviewed-by: Jakub Sitnicki Acked-by: Martin KaFai Lau Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20200124112754.19664-5-lmb@cloudflare.com Signed-off-by: Sasha Levin commit d4a02c29c70735b7e5799e8c69e3114dbfde8536 Author: Stephen Boyd Date: Thu Jan 23 21:58:46 2020 -0800 alarmtimer: Make alarmtimer platform device child of RTC device [ Upstream commit c79108bd19a8490315847e0c95ac6526fcd8e770 ] The alarmtimer_suspend() function will fail if an RTC device is on a bus such as SPI or i2c and that RTC device registers and probes after alarmtimer_init() registers and probes the 'alarmtimer' platform device. This is because system wide suspend suspends devices in the reverse order of their probe. When alarmtimer_suspend() attempts to program the RTC for a wakeup it will try to program an RTC device on a bus that has already been suspended. Move the alarmtimer device registration to happen when the RTC which is used for wakeup is registered. Register the 'alarmtimer' platform device as a child of the RTC device too, so that it can be guaranteed that the RTC device won't be suspended when alarmtimer_suspend() is called. Reported-by: Douglas Anderson Signed-off-by: Stephen Boyd Signed-off-by: Thomas Gleixner Reviewed-by: Douglas Anderson Link: https://lore.kernel.org/r/20200124055849.154411-2-swboyd@chromium.org Signed-off-by: Sasha Levin commit 91ede09930525a183b33107ba330b8d4060cf08b Author: Lu Baolu Date: Thu Jan 16 09:52:36 2020 +0800 iommu/vt-d: Remove unnecessary WARN_ON_ONCE() [ Upstream commit 857f081426e5aa38313426c13373730f1345fe95 ] Address field in device TLB invalidation descriptor is qualified by the S field. If S field is zero, a single page at page address specified by address [63:12] is requested to be invalidated. If S field is set, the least significant bit in the address field with value 0b (say bit N) indicates the invalidation address range. The spec doesn't require the address [N - 1, 0] to be cleared, hence remove the unnecessary WARN_ON_ONCE(). Otherwise, the caller might set "mask = MAX_AGAW_PFN_WIDTH" in order to invalidating all the cached mappings on an endpoint, and below overflow error will be triggered. [...] UBSAN: Undefined behaviour in drivers/iommu/dmar.c:1354:3 shift exponent 64 is too large for 64-bit type 'long long unsigned int' [...] Reported-and-tested-by: Frank Signed-off-by: Lu Baolu Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 81e9d9e3aba4aac6cbacf138b6d47a620961d9e5 Author: Barret Rhoden Date: Wed Jan 15 11:03:56 2020 +0800 iommu/vt-d: Mark firmware tainted if RMRR fails sanity check [ Upstream commit f5a68bb0752e0cf77c06f53f72258e7beb41381b ] RMRR entries describe memory regions that are DMA targets for devices outside the kernel's control. RMRR entries that fail the sanity check are pointing to regions of memory that the firmware did not tell the kernel are reserved or otherwise should not be used. Instead of aborting DMAR processing, this commit marks the firmware as tainted. These RMRRs will still be identity mapped, otherwise, some devices, e.x. graphic devices, will not work during boot. Signed-off-by: Barret Rhoden Signed-off-by: Lu Baolu Fixes: f036c7fa0ab60 ("iommu/vt-d: Check VT-d RMRR region in BIOS is reported as reserved") Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 2d5ff654d9c2e82adcd576b6cd5dd0f6d7c3bdc5 Author: Coly Li Date: Fri Jan 24 01:01:30 2020 +0800 bcache: fix use-after-free in register_bcache() [ Upstream commit ae3cd299919af6eb670d5af0bc9d7ba14086bd8e ] The patch "bcache: rework error unwinding in register_bcache" introduces a use-after-free regression in register_bcache(). Here are current code, 2510 out_free_path: 2511 kfree(path); 2512 out_module_put: 2513 module_put(THIS_MODULE); 2514 out: 2515 pr_info("error %s: %s", path, err); 2516 return ret; If some error happens and the above code path is executed, at line 2511 path is released, but referenced at line 2515. Then KASAN reports a use- after-free error message. This patch changes line 2515 in the following way to fix the problem, 2515 pr_info("error %s: %s", path?path:"", err); Signed-off-by: Coly Li Cc: Christoph Hellwig Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit a81d1c887b5c9f37200578e3d7bbb9134b6ef0a1 Author: Christoph Hellwig Date: Fri Jan 24 01:01:28 2020 +0800 bcache: rework error unwinding in register_bcache [ Upstream commit 50246693f81fe887f4db78bf7089051d7f1894cc ] Split the successful and error return path, and use one goto label for each resource to unwind. This also fixes some small errors like leaking the module reference count in the reboot case (which seems entirely harmless) or printing the wrong warning messages for early failures. Signed-off-by: Christoph Hellwig Signed-off-by: Coly Li Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 7f087d4603b939e16c97757c646beb4ed6d4bed9 Author: Liang Chen Date: Fri Jan 24 01:01:26 2020 +0800 bcache: cached_dev_free needs to put the sb page [ Upstream commit e8547d42095e58bee658f00fef8e33d2a185c927 ] Same as cache device, the buffer page needs to be put while freeing cached_dev. Otherwise a page would be leaked every time a cached_dev is stopped. Signed-off-by: Liang Chen Signed-off-by: Christoph Hellwig Signed-off-by: Coly Li Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 09ec7c185e3f8752527de935c2a2c9a88e5e521d Author: Nikolay Borisov Date: Fri Jan 10 14:11:35 2020 +0200 btrfs: Fix split-brain handling when changing FSID to metadata uuid [ Upstream commit 1362089d2ad7e20d16371b39d3c11990d4ec23e4 ] Current code doesn't correctly handle the situation which arises when a file system that has METADATA_UUID_INCOMPAT flag set and has its FSID changed to the one in metadata uuid. This causes the incompat flag to disappear. In case of a power failure we could end up in a situation where part of the disks in a multi-disk filesystem are correctly reverted to METADATA_UUID_INCOMPAT flag unset state, while others have METADATA_UUID_INCOMPAT set and CHANGING_FSID_V2_IN_PROGRESS. This patch corrects the behavior required to handle the case where a disk of the second type is scanned first, creating the necessary btrfs_fs_devices. Subsequently, when a disk which has already completed the transition is scanned it should overwrite the data in btrfs_fs_devices. Reported-by: Su Yue Reviewed-by: Josef Bacik Signed-off-by: Nikolay Borisov Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit da966d880004f26adce8ee16210abf61c868952c Author: David Sterba Date: Mon Dec 16 20:00:48 2019 +0100 btrfs: separate definition of assertion failure handlers [ Upstream commit 68c467cbb2f389b6c933e235bce0d1756fc8cc34 ] There's a report where objtool detects unreachable instructions, eg.: fs/btrfs/ctree.o: warning: objtool: btrfs_search_slot()+0x2d4: unreachable instruction This seems to be a false positive due to compiler version. The cause is in the ASSERT macro implementation that does the conditional check as IS_DEFINED(CONFIG_BTRFS_ASSERT) and not an #ifdef. To avoid that, use the ifdefs directly. There are still 2 reports that aren't fixed: fs/btrfs/extent_io.o: warning: objtool: __set_extent_bit()+0x71f: unreachable instruction fs/btrfs/relocation.o: warning: objtool: find_data_references()+0x4e0: unreachable instruction Co-developed-by: Josh Poimboeuf Signed-off-by: Josh Poimboeuf Reported-by: Randy Dunlap Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 5685aaf4b1de8db823a53567194625d7af200a2b Author: Sergey Zakharchenko Date: Thu Oct 3 11:31:23 2019 +0200 media: uvcvideo: Add a quirk to force GEO GC6500 Camera bits-per-pixel value [ Upstream commit 1dd2e8f942574e2be18374ebb81751082d8d467c ] This device does not function correctly in raw mode in kernel versions validating buffer sizes in bulk mode. It erroneously announces 16 bits per pixel instead of 12 for NV12 format, so it needs this quirk to fix computed frame size and avoid legitimate frames getting discarded. [Move info and div variables to local scope] Signed-off-by: Sergey Zakharchenko Signed-off-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 36cc39461cc5d3cf0ad87ce0213a7473ce0d21ab Author: Oliver O'Halloran Date: Wed Aug 21 16:26:53 2019 +1000 powerpc/sriov: Remove VF eeh_dev state when disabling SR-IOV [ Upstream commit 1fb4124ca9d456656a324f1ee29b7bf942f59ac8 ] When disabling virtual functions on an SR-IOV adapter we currently do not correctly remove the EEH state for the now-dead virtual functions. When removing the pci_dn that was created for the VF when SR-IOV was enabled we free the corresponding eeh_dev without removing it from the child device list of the eeh_pe that contained it. This can result in crashes due to the use-after-free. Signed-off-by: Oliver O'Halloran Reviewed-by: Sam Bobroff Tested-by: Sam Bobroff Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20190821062655.19735-1-oohall@gmail.com Signed-off-by: Sasha Levin commit 9624ccd15100a7408e8ea3e5e107839f055cfd60 Author: Olof Johansson Date: Thu Dec 19 16:15:17 2019 -0800 net/mlx5e: Fix printk format warning [ Upstream commit ca9c74ae9be5e78541c2058db9a754947a7d4a9b ] Use "%zu" for size_t. Seen on ARM allmodconfig: drivers/net/ethernet/mellanox/mlx5/core/wq.c: In function 'mlx5_wq_cyc_wqe_dump': include/linux/kern_levels.h:5:18: warning: format '%ld' expects argument of type 'long int', but argument 5 has type 'size_t' {aka 'unsigned int'} [-Wformat=] Fixes: 130c7b46c93d ("net/mlx5e: TX, Dump WQs wqe descriptors on CQE with error events") Signed-off-by: Olof Johansson Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit 28f29294a104786ad4a3c5e17a5c34ac338a3a52 Author: Ben Skeggs Date: Thu Jan 23 08:23:06 2020 +1000 drm/nouveau/mmu: fix comptag memory leak [ Upstream commit 35e4909b6a2b4005ced3c4238da60d926b78fdea ] Signed-off-by: Ben Skeggs Signed-off-by: Sasha Levin commit 6affad9aded3dd6879ad852be8bf993f6071f106 Author: Trond Myklebust Date: Mon Jan 6 13:40:34 2020 -0500 sunrpc: Fix potential leaks in sunrpc_cache_unhash() [ Upstream commit 1d82163714c16ebe09c7a8c9cd3cef7abcc16208 ] When we unhash the cache entry, we need to handle any pending upcalls by calling cache_fresh_unlocked(). Signed-off-by: Trond Myklebust Signed-off-by: J. Bruce Fields Signed-off-by: Sasha Levin commit 2dd9cca2d9dbf6e638b228a6bbd4924913e39374 Author: Peter Große Date: Wed Jan 22 19:01:06 2020 +0100 ALSA: hda - Add docking station support for Lenovo Thinkpad T420s [ Upstream commit ef7d84caa5928b40b1c93a26dbe5a3f12737c6ab ] Lenovo Thinkpad T420s uses the same codec as T420, so apply the same quirk to enable audio output on a docking station. Signed-off-by: Peter Große Link: https://lore.kernel.org/r/20200122180106.9351-1-pegro@friiks.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit c8f9325fa1108fbf4bb12f9b6ff158572f0185af Author: Chris Down Date: Wed Jan 22 00:01:10 2020 +0000 bpf, btf: Always output invariant hit in pahole DWARF to BTF transform [ Upstream commit 2a67a6ccb01f21b854715d86ff6432a18b97adb3 ] When trying to compile with CONFIG_DEBUG_INFO_BTF enabled, I got this error: % make -s Failed to generate BTF for vmlinux Try to disable CONFIG_DEBUG_INFO_BTF make[3]: *** [vmlinux] Error 1 Compiling again without -s shows the true error (that pahole is missing), but since this is fatal, we should show the error unconditionally on stderr as well, not silence it using the `info` function. With this patch: % make -s BTF: .tmp_vmlinux.btf: pahole (pahole) is not available Failed to generate BTF for vmlinux Try to disable CONFIG_DEBUG_INFO_BTF make[3]: *** [vmlinux] Error 1 Signed-off-by: Chris Down Signed-off-by: Daniel Borkmann Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20200122000110.GA310073@chrisdown.name Signed-off-by: Sasha Levin commit 4f35a1170454ac9e2a22f2826ef2cba91d1e932c Author: Colin Ian King Date: Thu Jan 16 17:57:58 2020 +0000 driver core: platform: fix u32 greater or equal to zero comparison [ Upstream commit 0707cfa5c3ef58effb143db9db6d6e20503f9dec ] Currently the check that a u32 variable i is >= 0 is always true because the unsigned variable will never be negative, causing the loop to run forever. Fix this by changing the pre-decrement check to a zero check on i followed by a decrement of i. Addresses-Coverity: ("Unsigned compared against 0") Fixes: 39cc539f90d0 ("driver core: platform: Prevent resouce overflow from causing infinite loops") Signed-off-by: Colin Ian King Reviewed-by: Rafael J. Wysocki Link: https://lore.kernel.org/r/20200116175758.88396-1-colin.king@canonical.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 6929b2608048dbe6640406e9161a351b2151d380 Author: Sven Schnelle Date: Wed Jan 15 13:42:27 2020 +0100 s390: fix __EMIT_BUG() macro [ Upstream commit 17248ea0367465f4aaef728f6af661ed38e38cf1 ] Setting a kprobe on getname_flags() failed: $ echo 'p:tmr1 getname_flags +0(%r2):ustring' > kprobe_events -bash: echo: write error: Invalid argument Debugging the kprobes code showed that the address of getname_flags() is contained in the __bug_table. Kprobes doesn't allow to set probes at BUG() locations. $ objdump -j __bug_table -x build/fs/namei.o [..] 0000000000000108 R_390_PC32 .text+0x00000000000075a8 000000000000010c R_390_PC32 .L223+0x0000000000000004 I was expecting getname_flags() to start with a BUG(), but: 7598: e3 20 10 00 00 04 lg %r2,0(%r1) 759e: c0 f4 00 00 00 00 jg 759e 75a0: R_390_PLT32DBL kmem_cache_free+0x2 75a4: a7 f4 00 01 j 75a6 00000000000075a8 : 75a8: c0 04 00 00 00 00 brcl 0,75a8 75ae: eb 6f f0 48 00 24 stmg %r6,%r15,72(%r15) 75b4: b9 04 00 ef lgr %r14,%r15 75b8: e3 f0 ff a8 ff 71 lay %r15,-88(%r15) So the BUG() is actually the last opcode of the previous function. Fix this by switching to using the MONITOR CALL (MC) instruction, and set the entry in __bug_table to the beginning of that MC. Reviewed-by: Heiko Carstens Signed-off-by: Sven Schnelle Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin commit 748274065b03cea855b33f72355c8e6714811415 Author: Vasily Gorbik Date: Tue Dec 10 14:33:39 2019 +0100 s390/ftrace: generate traced function stack frame [ Upstream commit 45f7a0da600d3c409b5ad8d5ddddacd98ddc8840 ] Currently backtrace from ftraced function does not contain ftraced function itself. e.g. for "path_openat": arch_stack_walk+0x15c/0x2d8 stack_trace_save+0x50/0x68 stack_trace_call+0x15e/0x3d8 ftrace_graph_caller+0x0/0x1c <-- ftrace code do_filp_open+0x7c/0xe8 <-- ftraced function caller do_open_execat+0x76/0x1b8 open_exec+0x52/0x78 load_elf_binary+0x180/0x1160 search_binary_handler+0x8e/0x288 load_script+0x2a8/0x2b8 search_binary_handler+0x8e/0x288 __do_execve_file.isra.39+0x6fa/0xb40 __s390x_sys_execve+0x56/0x68 system_call+0xdc/0x2d8 Ftraced function is expected in the backtrace by ftrace kselftests, which are now failing. It would also be nice to have it for clarity reasons. "ftrace_caller" itself is called without stack frame allocated for it and does not store its caller (ftraced function). Instead it simply allocates a stack frame for "ftrace_trace_function" and sets backchain to point to ftraced function stack frame (which contains ftraced function caller in saved r14). To fix this issue make "ftrace_caller" allocate a stack frame for itself just to store ftraced function for the stack unwinder. As a result backtrace looks like the following: arch_stack_walk+0x15c/0x2d8 stack_trace_save+0x50/0x68 stack_trace_call+0x15e/0x3d8 ftrace_graph_caller+0x0/0x1c <-- ftrace code path_openat+0x6/0xd60 <-- ftraced function do_filp_open+0x7c/0xe8 <-- ftraced function caller do_open_execat+0x76/0x1b8 open_exec+0x52/0x78 load_elf_binary+0x180/0x1160 search_binary_handler+0x8e/0x288 load_script+0x2a8/0x2b8 search_binary_handler+0x8e/0x288 __do_execve_file.isra.39+0x6fa/0xb40 __s390x_sys_execve+0x56/0x68 system_call+0xdc/0x2d8 Reported-by: Sven Schnelle Tested-by: Sven Schnelle Reviewed-by: Heiko Carstens Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin commit 581d7f9223715b05feabefd2141424a8ff233fc0 Author: Vasily Gorbik Date: Wed Jan 8 14:46:00 2020 +0100 s390: adjust -mpacked-stack support check for clang 10 [ Upstream commit 253b3c4b2920e07ce9e2b18800b9b65245e2fafa ] clang 10 introduces -mpacked-stack compiler option implementation. At the same time currently it does not support a combination of -mpacked-stack and -mbackchain. This leads to the following build error: clang: error: unsupported option '-mpacked-stack with -mbackchain' for target 's390x-ibm-linux' If/when clang adds support for a combination of -mpacked-stack and -mbackchain it would also require -msoft-float (like gcc does). According to Ulrich Weigand "stack slot assigned to the kernel backchain overlaps the stack slot assigned to the FPR varargs (both are required to be placed immediately after the saved r15 slot if present)." Extend -mpacked-stack compiler option support check to include all 3 options -mpacked-stack -mbackchain -msoft-float which must present to support -mpacked-stack with -mbackchain. Acked-by: Heiko Carstens Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin commit 0cb4e84d6e5cdc0107e0624fdd22eb25595174cc Author: Masami Hiramatsu Date: Wed Jan 22 13:11:54 2020 +0900 x86/decoder: Add TEST opcode to Group3-2 [ Upstream commit 8b7e20a7ba54836076ff35a28349dabea4cec48f ] Add TEST opcode to Group3-2 reg=001b as same as Group3-1 does. Commit 12a78d43de76 ("x86/decoder: Add new TEST instruction pattern") added a TEST opcode assignment to f6 XX/001/XXX (Group 3-1), but did not add f7 XX/001/XXX (Group 3-2). Actually, this TEST opcode variant (ModRM.reg /1) is not described in the Intel SDM Vol2 but in AMD64 Architecture Programmer's Manual Vol.3, Appendix A.2 Table A-6. ModRM.reg Extensions for the Primary Opcode Map. Without this fix, Randy found a warning by insn_decoder_test related to this issue as below. HOSTCC arch/x86/tools/insn_decoder_test HOSTCC arch/x86/tools/insn_sanity TEST posttest arch/x86/tools/insn_decoder_test: warning: Found an x86 instruction decoder bug, please report this. arch/x86/tools/insn_decoder_test: warning: ffffffff81000bf1: f7 0b 00 01 08 00 testl $0x80100,(%rbx) arch/x86/tools/insn_decoder_test: warning: objdump says 6 bytes, but insn_get_length() says 2 arch/x86/tools/insn_decoder_test: warning: Decoded and checked 11913894 instructions with 1 failures TEST posttest arch/x86/tools/insn_sanity: Success: decoded and checked 1000000 random instructions with 0 errors (seed:0x871ce29c) To fix this error, add the TEST opcode according to AMD64 APM Vol.3. [ bp: Massage commit message. ] Reported-by: Randy Dunlap Signed-off-by: Masami Hiramatsu Signed-off-by: Borislav Petkov Acked-by: Randy Dunlap Tested-by: Randy Dunlap Link: https://lkml.kernel.org/r/157966631413.9580.10311036595431878351.stgit@devnote2 Signed-off-by: Sasha Levin commit a4e7349aa7adb92ebf9112342482c5048eed287a Author: Shile Zhang Date: Mon Jan 20 12:14:08 2020 -0600 objtool: Fix ARCH=x86_64 build error [ Upstream commit 8580bed7e751e6d4f17881e059daf3cb37ba4717 ] Building objtool with ARCH=x86_64 fails with: $make ARCH=x86_64 -C tools/objtool ... CC arch/x86/decode.o arch/x86/decode.c:10:22: fatal error: asm/insn.h: No such file or directory #include ^ compilation terminated. mv: cannot stat ‘arch/x86/.decode.o.tmp’: No such file or directory make[2]: *** [arch/x86/decode.o] Error 1 ... The root cause is that the command-line variable 'ARCH' cannot be overridden. It can be replaced by 'SRCARCH', which is defined in 'tools/scripts/Makefile.arch'. Signed-off-by: Shile Zhang Signed-off-by: Josh Poimboeuf Signed-off-by: Ingo Molnar Reviewed-by: Kamalesh Babulal Link: https://lore.kernel.org/r/d5d11370ae116df6c653493acd300ec3d7f5e925.1579543924.git.jpoimboe@redhat.com Signed-off-by: Sasha Levin commit ca64aa3e41cb967e3e39a627c6d91f893e38369b Author: Masahiro Yamada Date: Sat Jan 18 02:14:35 2020 +0900 kbuild: use -S instead of -E for precise cc-option test in Kconfig [ Upstream commit 3bed1b7b9d79ca40e41e3af130931a3225e951a3 ] Currently, -E (stop after the preprocessing stage) is used to check whether the given compiler flag is supported. While it is faster than -S (or -c), it can be false-positive. You need to run the compilation proper to check the flag more precisely. For example, -E and -S disagree about the support of "--param asan-instrument-allocas=1". $ gcc -Werror --param asan-instrument-allocas=1 -E -x c /dev/null -o /dev/null $ echo $? 0 $ gcc -Werror --param asan-instrument-allocas=1 -S -x c /dev/null -o /dev/null cc1: error: invalid --param name ‘asan-instrument-allocas’; did you mean ‘asan-instrument-writes’? $ echo $? 1 Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin commit ee33c38937ebdcbb3e3c34b987a9cd50aa6af600 Author: Michael Walle Date: Tue Jan 14 16:46:13 2020 +0100 spi: spi-fsl-qspi: Ensure width is respected in spi-mem operations [ Upstream commit b0177aca7aea7e8917d4e463334b51facb293d02 ] Make use of a core helper to ensure the desired width is respected when calling spi-mem operators. Otherwise only the SPI controller will be matched with the flash chip, which might lead to wrong widths. Also consider the width specified by the user in the device tree. Fixes: 84d043185dbe ("spi: Add a driver for the Freescale/NXP QuadSPI controller") Signed-off-by: Michael Walle Link: https://lore.kernel.org/r/20200114154613.8195-1-michael@walle.cc Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 7dabba5b77f461071cc6ddf7187a575f29a64195 Author: Kai Vehmanen Date: Mon Jan 20 18:01:17 2020 +0200 ALSA: hda/hdmi - add retry logic to parse_intel_hdmi() [ Upstream commit 2928fa0a97ebb9549cb877fdc99aed9b95438c3a ] The initial snd_hda_get_sub_node() can fail on certain devices (e.g. some Chromebook models using Intel GLK). The failure rate is very low, but as this is is part of the probe process, end-user impact is high. In observed cases, related hardware status registers have expected values, but the node query still fails. Retrying the node query does seem to help, so fix the problem by adding retry logic to the query. This does not impact non-Intel platforms. BugLink: https://github.com/thesofproject/linux/issues/1642 Signed-off-by: Kai Vehmanen Reviewed-by: Takashi Iwai Link: https://lore.kernel.org/r/20200120160117.29130-4-kai.vehmanen@linux.intel.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 93d1648ab3110ea460efbb0595ffc3b2ad383690 Author: John Garry Date: Fri Jan 17 01:38:43 2020 +0800 irqchip/mbigen: Set driver .suppress_bind_attrs to avoid remove problems [ Upstream commit d6152e6ec9e2171280436f7b31a571509b9287e1 ] The following crash can be seen for setting CONFIG_DEBUG_TEST_DRIVER_REMOVE=y for DT FW (which some people still use): Hisilicon MBIGEN-V2 60080000.interrupt-controller: Failed to create mbi-gen irqdomain Hisilicon MBIGEN-V2: probe of 60080000.interrupt-controller failed with error -12 [...] Unable to handle kernel paging request at virtual address 0000000000005008 Mem abort info: ESR = 0x96000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 Data abort info: ISV = 0, ISS = 0x00000004 CM = 0, WnR = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=0000041fb9990000 [0000000000005008] pgd=0000000000000000 Internal error: Oops: 96000004 [#1] PREEMPT SMP Modules linked in: CPU: 7 PID: 1 Comm: swapper/0 Not tainted 5.5.0-rc6-00002-g3fc42638a506-dirty #1622 Hardware name: Huawei Taishan 2280 /D05, BIOS Hisilicon D05 IT21 Nemo 2.0 RC0 04/18/2018 pstate: 40000085 (nZcv daIf -PAN -UAO) pc : mbigen_set_type+0x38/0x60 lr : __irq_set_trigger+0x6c/0x188 sp : ffff800014b4b400 x29: ffff800014b4b400 x28: 0000000000000007 x27: 0000000000000000 x26: 0000000000000000 x25: ffff041fd83bd0d4 x24: ffff041fd83bd188 x23: 0000000000000000 x22: ffff80001193ce00 x21: 0000000000000004 x20: 0000000000000000 x19: ffff041fd83bd000 x18: ffffffffffffffff x17: 0000000000000000 x16: 0000000000000000 x15: ffff8000119098c8 x14: ffff041fb94ec91c x13: ffff041fb94ec1a1 x12: 0000000000000030 x11: 0101010101010101 x10: 0000000000000040 x9 : 0000000000000000 x8 : ffff041fb98c6680 x7 : ffff800014b4b380 x6 : ffff041fd81636c8 x5 : 0000000000000000 x4 : 000000000000025f x3 : 0000000000005000 x2 : 0000000000005008 x1 : 0000000000000004 x0 : 0000000080000000 Call trace: mbigen_set_type+0x38/0x60 __setup_irq+0x744/0x900 request_threaded_irq+0xe0/0x198 pcie_pme_probe+0x98/0x118 pcie_port_probe_service+0x38/0x78 really_probe+0xa0/0x3e0 driver_probe_device+0x58/0x100 __device_attach_driver+0x90/0xb0 bus_for_each_drv+0x64/0xc8 __device_attach+0xd8/0x138 device_initial_probe+0x10/0x18 bus_probe_device+0x90/0x98 device_add+0x4c4/0x770 device_register+0x1c/0x28 pcie_port_device_register+0x1e4/0x4f0 pcie_portdrv_probe+0x34/0xd8 local_pci_probe+0x3c/0xa0 pci_device_probe+0x128/0x1c0 really_probe+0xa0/0x3e0 driver_probe_device+0x58/0x100 __device_attach_driver+0x90/0xb0 bus_for_each_drv+0x64/0xc8 __device_attach+0xd8/0x138 device_attach+0x10/0x18 pci_bus_add_device+0x4c/0xb8 pci_bus_add_devices+0x38/0x88 pci_host_probe+0x3c/0xc0 pci_host_common_probe+0xf0/0x208 hisi_pcie_almost_ecam_probe+0x24/0x30 platform_drv_probe+0x50/0xa0 really_probe+0xa0/0x3e0 driver_probe_device+0x58/0x100 device_driver_attach+0x6c/0x90 __driver_attach+0x84/0xc8 bus_for_each_dev+0x74/0xc8 driver_attach+0x20/0x28 bus_add_driver+0x148/0x1f0 driver_register+0x60/0x110 __platform_driver_register+0x40/0x48 hisi_pcie_almost_ecam_driver_init+0x1c/0x24 The specific problem here is that the mbigen driver real probe has failed as the mbigen_of_create_domain()->of_platform_device_create() call fails, the reason for that being that we never destroyed the platform device created during the remove test dry run and there is some conflict. Since we generally would never want to unbind this driver, and to save adding a driver tear down path for that, just set the driver .suppress_bind_attrs member to avoid this possibility. Signed-off-by: John Garry Signed-off-by: Marc Zyngier Reviewed-by: Hanjun Guo Link: https://lore.kernel.org/r/1579196323-180137-1-git-send-email-john.garry@huawei.com Signed-off-by: Sasha Levin commit 3721868c1fe733f39c1b12832a606842ff163c02 Author: Enric Balletbo i Serra Date: Mon Jan 20 13:39:21 2020 +0100 regulator: core: Fix exported symbols to the exported GPL version [ Upstream commit 3d7610e8da993539346dce6f7c909fd3d56bf4d5 ] Change the exported symbols introduced by commit e9153311491da ("regulator: vctrl-regulator: Avoid deadlock getting and setting the voltage") from EXPORT_SYMBOL() to EXPORT_SYMBOL_GPL(), like is used for all the core parts. Fixes: e9153311491da ("regulator: vctrl-regulator: Avoid deadlock getting and setting the voltage") Reported-by: Dmitry Osipenko Signed-off-by: Enric Balletbo i Serra Link: https://lore.kernel.org/r/20200120123921.1204339-1-enric.balletbo@collabora.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit d7b7990b0909cb64ee43ca219d7d6fa2e76c33c3 Author: Brandon Maier Date: Thu May 30 17:52:23 2019 -0500 remoteproc: Initialize rproc_class before use [ Upstream commit a8f40111d184098cd2b3dc0c7170c42250a5fa09 ] The remoteproc_core and remoteproc drivers all initialize with module_init(). However remoteproc drivers need the rproc_class during their probe. If one of the remoteproc drivers runs init and gets through probe before remoteproc_init() runs, a NULL pointer access of rproc_class's `glue_dirs` spinlock occurs. > Unable to handle kernel NULL pointer dereference at virtual address 000000dc > pgd = c0004000 > [000000dc] *pgd=00000000 > Internal error: Oops: 5 [#1] PREEMPT ARM > Modules linked in: > CPU: 0 PID: 1 Comm: swapper Tainted: G W 4.14.106-rt56 #1 > Hardware name: Generic OMAP36xx (Flattened Device Tree) > task: c6050000 task.stack: c604a000 > PC is at rt_spin_lock+0x40/0x6c > LR is at rt_spin_lock+0x28/0x6c > pc : [] lr : [] psr: 60000013 > sp : c604bdc0 ip : 00000000 fp : 00000000 > r10: 00000000 r9 : c61c7c10 r8 : c6269c20 > r7 : c0905888 r6 : c6269c20 r5 : 00000000 r4 : 000000d4 > r3 : 000000dc r2 : c6050000 r1 : 00000002 r0 : 000000d4 > Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none ... > [] (rt_spin_lock) from [] (get_device_parent+0x54/0x17c) > [] (get_device_parent) from [] (device_add+0xe0/0x5b4) > [] (device_add) from [] (rproc_add+0x18/0xd8) > [] (rproc_add) from [] (my_rproc_probe+0x158/0x204) > [] (my_rproc_probe) from [] (platform_drv_probe+0x34/0x70) > [] (platform_drv_probe) from [] (driver_probe_device+0x2c8/0x420) > [] (driver_probe_device) from [] (__driver_attach+0x100/0x11c) > [] (__driver_attach) from [] (bus_for_each_dev+0x7c/0xc0) > [] (bus_for_each_dev) from [] (bus_add_driver+0x1cc/0x264) > [] (bus_add_driver) from [] (driver_register+0x78/0xf8) > [] (driver_register) from [] (do_one_initcall+0x100/0x190) > [] (do_one_initcall) from [] (kernel_init_freeable+0x130/0x1d0) > [] (kernel_init_freeable) from [] (kernel_init+0x8/0x114) > [] (kernel_init) from [] (ret_from_fork+0x14/0x24) > Code: e2843008 e3c2203f f5d3f000 e5922010 (e193cf9f) > ---[ end trace 0000000000000002 ]--- Signed-off-by: Brandon Maier Link: https://lore.kernel.org/r/20190530225223.136420-1-brandon.maier@rockwellcollins.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 0637cb8526e842fe7caf6323eed48a9020617b84 Author: Jessica Yu Date: Fri Jan 17 13:32:21 2020 +0100 module: avoid setting info->name early in case we can fall back to info->mod->name [ Upstream commit 708e0ada1916be765b7faa58854062f2bc620bbf ] In setup_load_info(), info->name (which contains the name of the module, mostly used for early logging purposes before the module gets set up) gets unconditionally assigned if .modinfo is missing despite the fact that there is an if (!info->name) check near the end of the function. Avoid assigning a placeholder string to info->name if .modinfo doesn't exist, so that we can fall back to info->mod->name later on. Fixes: 5fdc7db6448a ("module: setup load info before module_sig_check()") Reviewed-by: Miroslav Benes Signed-off-by: Jessica Yu Signed-off-by: Sasha Levin commit 399596d8c337b5914997ad53764a486ec8ebbdb2 Author: Anand Jain Date: Fri Jan 10 12:26:34 2020 +0800 btrfs: device stats, log when stats are zeroed [ Upstream commit a69976bc69308aa475d0ba3b8b3efd1d013c0460 ] We had a report indicating that some read errors aren't reported by the device stats in the userland. It is important to have the errors reported in the device stat as user land scripts might depend on it to take the reasonable corrective actions. But to debug these issue we need to be really sure that request to reset the device stat did not come from the userland itself. So log an info message when device error reset happens. For example: BTRFS info (device sdc): device stats zeroed by btrfs(9223) Reported-by: philip@philip-seeger.de Link: https://www.spinics.net/lists/linux-btrfs/msg96528.html Reviewed-by: Josef Bacik Signed-off-by: Anand Jain Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 44b63fb0a00876281279a55283595e93590b21ee Author: David Sterba Date: Wed Jan 8 15:29:53 2020 +0100 btrfs: safely advance counter when looking up bio csums [ Upstream commit 4babad10198fa73fe73239d02c2e99e3333f5f5c ] Dan's smatch tool reports fs/btrfs/file-item.c:295 btrfs_lookup_bio_sums() warn: should this be 'count == -1' which points to the while (count--) loop. With count == 0 the check itself could decrement it to -1. There's a WARN_ON a few lines below that has never been seen in practice though. It turns out that the value of page_bytes_left matches the count (by sectorsize multiples). The loop never reaches the state where count would go to -1, because page_bytes_left == 0 is found first and this breaks out. For clarity, use only plain check on count (and only for positive value), decrement safely inside the loop. Any other discrepancy after the whole bio list processing should be reported by the exising WARN_ON_ONCE as well. Reported-by: Dan Carpenter Reviewed-by: Josef Bacik Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit aa58ccfc5cee436fa19032f761a104c13a5f1081 Author: Johannes Thumshirn Date: Thu Dec 5 14:19:57 2019 +0100 btrfs: fix possible NULL-pointer dereference in integrity checks [ Upstream commit 3dbd351df42109902fbcebf27104149226a4fcd9 ] A user reports a possible NULL-pointer dereference in btrfsic_process_superblock(). We are assigning state->fs_info to a local fs_info variable and afterwards checking for the presence of state. While we would BUG_ON() a NULL state anyways, we can also just remove the local fs_info copy, as fs_info is only used once as the first argument for btrfs_num_copies(). There we can just pass in state->fs_info as well. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=205003 Signed-off-by: Johannes Thumshirn Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 8ff099e8f5d17862af623f49a02b662b89033ffe Author: yu kuai Date: Mon Jan 20 19:51:43 2020 +0800 pwm: Remove set but not set variable 'pwm' [ Upstream commit 9871abffc81048e20f02e15d6aa4558a44ad53ea ] Fixes gcc '-Wunused-but-set-variable' warning: drivers/pwm/pwm-pca9685.c: In function ‘pca9685_pwm_gpio_free’: drivers/pwm/pwm-pca9685.c:162:21: warning: variable ‘pwm’ set but not used [-Wunused-but-set-variable] It is never used, and so can be removed. In that case, hold and release the lock 'pca->lock' can be removed since nothing will be done between them. Fixes: e926b12c611c ("pwm: Clear chip_data in pwm_put()") Signed-off-by: yu kuai Acked-by: Uwe Kleine-König Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit e4fa208e242a46d2a05a590c5973e18a356eb335 Author: Dan Carpenter Date: Tue Jan 7 16:06:07 2020 +0300 ide: serverworks: potential overflow in svwks_set_pio_mode() [ Upstream commit ce1f31b4c0b9551dd51874dd5364654ed4ca13ae ] The "drive->dn" variable is a u8 controlled by root. Signed-off-by: Dan Carpenter Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit fec984eeb40ec27a6a0792f136483336c2d3a0ff Author: Dan Carpenter Date: Tue Jan 7 16:04:41 2020 +0300 cmd64x: potential buffer overflow in cmd64x_program_timings() [ Upstream commit 117fcc3053606d8db5cef8821dca15022ae578bb ] The "drive->dn" value is a u8 and it is controlled by root only, but it could be out of bounds here so let's check. Signed-off-by: Dan Carpenter Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit bf5266754e55648e2f7ea397bdc9532bab7f33da Author: Uwe Kleine-König Date: Mon Nov 11 10:03:54 2019 +0100 pwm: omap-dmtimer: Remove PWM chip in .remove before making it unfunctional [ Upstream commit 43efdc8f0e6d7088ec61bd55a73bf853f002d043 ] In the old code (e.g.) mutex_destroy() was called before pwmchip_remove(). Between these two calls it is possible that a PWM callback is used which tries to grab the mutex. Fixes: 6604c6556db9 ("pwm: Add PWM driver for OMAP using dual-mode timers") Signed-off-by: Uwe Kleine-König Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit 5a89821e0b0f844947ec7b03dee940817d009a0e Author: Ard Biesheuvel Date: Sat Jan 18 17:57:04 2020 +0100 x86/boot/compressed: Relax sed symbol type regex for LLVM ld.lld [ Upstream commit bc310baf2ba381c648983c7f4748327f17324562 ] The final build stage of the x86 kernel captures some symbol addresses from the decompressor binary and copies them into zoffset.h. It uses sed with a regular expression that matches the address, symbol type and symbol name, and mangles the captured addresses and the names of symbols of interest into #define directives that are added to zoffset.h The symbol type is indicated by a single letter, which we match strictly: only letters in the set 'ABCDGRSTVW' are matched, even though the actual symbol type is relevant and therefore ignored. Commit bc7c9d620 ("efi/libstub/x86: Force 'hidden' visibility for extern declarations") made a change to the way external symbol references are classified, resulting in 'startup_32' now being emitted as a hidden symbol. This prevents the use of GOT entries to refer to this symbol via its absolute address, which recent toolchains (including Clang based ones) already avoid by default, making this change a no-op in the majority of cases. However, as it turns out, the LLVM linker classifies such hidden symbols as symbols with static linkage in fully linked ELF binaries, causing tools such as NM to output a lowercase 't' rather than an upper case 'T' for the type of such symbols. Since our sed expression only matches upper case letters for the symbol type, the line describing startup_32 is disregarded, resulting in a build error like the following arch/x86/boot/header.S:568:18: error: symbol 'ZO_startup_32' can not be undefined in a subtraction expression init_size: .long (0x00000000008fd000 - ZO_startup_32 + (((0x0000000001f6361c + ((0x0000000001f6361c >> 8) + 65536) - 0x00000000008c32e5) + 4095) & ~4095)) # kernel initialization size Given that we are only interested in the value of the symbol, let's match any character in the set 'a-zA-Z' instead. Signed-off-by: Ard Biesheuvel Signed-off-by: Ingo Molnar Tested-by: Nathan Chancellor Signed-off-by: Sasha Levin commit 0c938379e4d4478490116fca19b8e8d7040164ef Author: Ard Biesheuvel Date: Mon Jan 13 18:22:40 2020 +0100 efi/arm: Defer probe of PCIe backed efifb on DT systems [ Upstream commit 64c8a0cd0a535891d5905c3a1651150f0f141439 ] The new of_devlink support breaks PCIe probing on ARM platforms booting via UEFI if the firmware exposes a EFI framebuffer that is backed by a PCI device. The reason is that the probing order gets reversed, resulting in a resource conflict on the framebuffer memory window when the PCIe probes last, causing it to give up entirely. Given that we rely on PCI quirks to deal with EFI framebuffers that get moved around in memory, we cannot simply drop the memory reservation, so instead, let's use the device link infrastructure to register this dependency, and force the probing to occur in the expected order. Co-developed-by: Saravana Kannan Signed-off-by: Ard Biesheuvel Signed-off-by: Saravana Kannan Signed-off-by: Ard Biesheuvel Signed-off-by: Ingo Molnar Link: https://lore.kernel.org/r/20200113172245.27925-9-ardb@kernel.org Signed-off-by: Sasha Levin commit e95882b368e231e3742364295ff8e49a616eb6a9 Author: Ard Biesheuvel Date: Mon Jan 13 18:22:36 2020 +0100 x86/mm: Fix NX bit clearing issue in kernel_map_pages_in_pgd [ Upstream commit 75fbef0a8b6b4bb19b9a91b5214f846c2dc5139e ] The following commit: 15f003d20782 ("x86/mm/pat: Don't implicitly allow _PAGE_RW in kernel_map_pages_in_pgd()") modified kernel_map_pages_in_pgd() to manage writable permissions of memory mappings in the EFI page table in a different way, but in the process, it removed the ability to clear NX attributes from read-only mappings, by clobbering the clear mask if _PAGE_RW is not being requested. Failure to remove the NX attribute from read-only mappings is unlikely to be a security issue, but it does prevent us from tightening the permissions in the EFI page tables going forward, so let's fix it now. Fixes: 15f003d20782 ("x86/mm/pat: Don't implicitly allow _PAGE_RW in kernel_map_pages_in_pgd() Signed-off-by: Ard Biesheuvel Signed-off-by: Ingo Molnar Link: https://lore.kernel.org/r/20200113172245.27925-5-ardb@kernel.org Signed-off-by: Sasha Levin commit d5431ba5649d3b340049b62a3734185915befc4d Author: Chao Yu Date: Mon Dec 30 17:41:41 2019 +0800 f2fs: fix memleak of kobject [ Upstream commit fe396ad8e7526f059f7b8c7290d33a1b84adacab ] If kobject_init_and_add() failed, caller needs to invoke kobject_put() to release kobject explicitly. Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 38e4f02b35720a12f13f76fea5c99230879b096c Author: Enric Balletbo i Serra Date: Thu Jan 16 10:45:43 2020 +0100 regulator: vctrl-regulator: Avoid deadlock getting and setting the voltage [ Upstream commit e9153311491da9d9863ead9888a1613531cb4a1b ] `cat /sys/kernel/debug/regulator/regulator_summary` ends on a deadlock when you have a voltage controlled regulator (vctrl). The problem is that the vctrl_get_voltage() and vctrl_set_voltage() calls the regulator_get_voltage() and regulator_set_voltage() and that will try to lock again the dependent regulators (the regulator supplying the control voltage). Fix the issue by exporting the unlocked version of the regulator_get_voltage() and regulator_set_voltage() API so drivers that need it, like the voltage controlled regulator driver can use it. Fixes: f8702f9e4aa7 ("regulator: core: Use ww_mutex for regulators locking") Reported-by: Douglas Anderson Signed-off-by: Enric Balletbo i Serra Link: https://lore.kernel.org/r/20200116094543.2847321-1-enric.balletbo@collabora.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 24c259557c45e817941d3843f82331a477c86a7e Author: Cezary Rojewski Date: Mon Jan 13 12:40:54 2020 +0100 ASoC: SOF: Intel: hda: Fix SKL dai count [ Upstream commit a6947c9d86bcfd61b758b5693eba58defe7fd2ae ] With fourth pin added for iDisp for skl_dai, update SOF_SKL_DAI_NUM to account for the change. Without this, dais from the bottom of the list are skipped. In current state that's the case for 'Alt Analog CPU DAI'. Fixes: ac42b142cd76 ("ASoC: SOF: Intel: hda: Add iDisp4 DAI") Signed-off-by: Cezary Rojewski Reviewed-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20200113114054.9716-1-cezary.rojewski@intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 72cd0385276c060aec44815bdb1eb9a2cbf81ef3 Author: Charles Keepax Date: Tue Jan 14 16:18:38 2020 +0000 ASoC: wm_adsp: Correct cache handling of new kernel control API [ Upstream commit 73ecf1a673d3502dff1445f06675aba65ff20ce7 ] The recently added API that exposes firmware mixer controls to the kernel is missing cache handling and all writes bypass the cache, this obviously causes the cache to get out of sync with the hardware. Factor out the cache handling into two new helper functions and call those from both the normal ALSA control handlers and the new kernel API. Fixes: eb65ccdb0836 ("ASoC: wm_adsp: Expose mixer control API") Signed-off-by: Charles Keepax Link: https://lore.kernel.org/r/20200114161841.451-1-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit fb4a80e5450a86dbc51d1b9ac5b508429573224f Author: Marco Elver Date: Thu Jan 16 19:55:29 2020 +0100 debugobjects: Fix various data races [ Upstream commit 35fd7a637c42bb54ba4608f4d40ae6e55fc88781 ] The counters obj_pool_free, and obj_nr_tofree, and the flag obj_freeing are read locklessly outside the pool_lock critical sections. If read with plain accesses, this would result in data races. This is addressed as follows: * reads outside critical sections become READ_ONCE()s (pairing with WRITE_ONCE()s added); * writes become WRITE_ONCE()s (pairing with READ_ONCE()s added); since writes happen inside critical sections, only the write and not the read of RMWs needs to be atomic, thus WRITE_ONCE(var, var +/- X) is sufficient. The data races were reported by KCSAN: BUG: KCSAN: data-race in __free_object / fill_pool write to 0xffffffff8beb04f8 of 4 bytes by interrupt on cpu 1: __free_object+0x1ee/0x8e0 lib/debugobjects.c:404 __debug_check_no_obj_freed+0x199/0x330 lib/debugobjects.c:969 debug_check_no_obj_freed+0x3c/0x44 lib/debugobjects.c:994 slab_free_hook mm/slub.c:1422 [inline] read to 0xffffffff8beb04f8 of 4 bytes by task 1 on cpu 2: fill_pool+0x3d/0x520 lib/debugobjects.c:135 __debug_object_init+0x3c/0x810 lib/debugobjects.c:536 debug_object_init lib/debugobjects.c:591 [inline] debug_object_activate+0x228/0x320 lib/debugobjects.c:677 debug_rcu_head_queue kernel/rcu/rcu.h:176 [inline] BUG: KCSAN: data-race in __debug_object_init / fill_pool read to 0xffffffff8beb04f8 of 4 bytes by task 10 on cpu 6: fill_pool+0x3d/0x520 lib/debugobjects.c:135 __debug_object_init+0x3c/0x810 lib/debugobjects.c:536 debug_object_init_on_stack+0x39/0x50 lib/debugobjects.c:606 init_timer_on_stack_key kernel/time/timer.c:742 [inline] write to 0xffffffff8beb04f8 of 4 bytes by task 1 on cpu 3: alloc_object lib/debugobjects.c:258 [inline] __debug_object_init+0x717/0x810 lib/debugobjects.c:544 debug_object_init lib/debugobjects.c:591 [inline] debug_object_activate+0x228/0x320 lib/debugobjects.c:677 debug_rcu_head_queue kernel/rcu/rcu.h:176 [inline] BUG: KCSAN: data-race in free_obj_work / free_object read to 0xffffffff9140c190 of 4 bytes by task 10 on cpu 6: free_object+0x4b/0xd0 lib/debugobjects.c:426 debug_object_free+0x190/0x210 lib/debugobjects.c:824 destroy_timer_on_stack kernel/time/timer.c:749 [inline] write to 0xffffffff9140c190 of 4 bytes by task 93 on cpu 1: free_obj_work+0x24f/0x480 lib/debugobjects.c:313 process_one_work+0x454/0x8d0 kernel/workqueue.c:2264 worker_thread+0x9a/0x780 kernel/workqueue.c:2410 Reported-by: Qian Cai Signed-off-by: Marco Elver Signed-off-by: Thomas Gleixner Link: https://lore.kernel.org/r/20200116185529.11026-1-elver@google.com Signed-off-by: Sasha Levin commit 01fb47aafe3539b5d3c398c0dcc776d6513412af Author: Arnd Bergmann Date: Thu Dec 12 15:03:57 2019 +0100 x86/apic/uv: Avoid unused variable warning [ Upstream commit d0b7788804482b2689946cd8d910ac3e03126c8d ] When CONFIG_PROC_FS is disabled, the compiler warns about an unused variable: arch/x86/kernel/apic/x2apic_uv_x.c: In function 'uv_setup_proc_files': arch/x86/kernel/apic/x2apic_uv_x.c:1546:8: error: unused variable 'name' [-Werror=unused-variable] char *name = hubless ? "hubless" : "hubbed"; Simplify the code so this variable is no longer needed. Fixes: 8785968bce1c ("x86/platform/uv: Add UV Hubbed/Hubless Proc FS Files") Signed-off-by: Arnd Bergmann Signed-off-by: Thomas Gleixner Link: https://lore.kernel.org/r/20191212140419.315264-1-arnd@arndb.de Signed-off-by: Sasha Levin commit b5c1f6eafa558bd109479608d1ac2e98d75c210b Author: Vladimir Oltean Date: Thu Jan 16 19:18:28 2020 +0200 enetc: Don't print from enetc_sched_speed_set when link goes down [ Upstream commit 90f29f0eada4d60e1f6ae537502ddb2202b9540d ] It is not an error to unplug a cable from the ENETC port even with TSN offloads, so don't spam the log with link-related messages from the tc-taprio offload subsystem, a single notification is sufficient: [10972.351859] fsl_enetc 0000:00:00.0 eno0: Qbv PSPEED set speed link down. [10972.360241] fsl_enetc 0000:00:00.0 eno0: Link is Down Fixes: 2e47cb415f0a ("enetc: update TSN Qbv PSPEED set according to adjust link speed") Signed-off-by: Vladimir Oltean Reviewed-by: Andrew Lunn Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 172f47b7fbd6119dd9005e9faa5af04bd71501db Author: Thomas Gleixner Date: Thu Jan 16 19:17:02 2020 +0100 watchdog/softlockup: Enforce that timestamp is valid on boot [ Upstream commit 11e31f608b499f044f24b20be73f1dcab3e43f8a ] Robert reported that during boot the watchdog timestamp is set to 0 for one second which is the indicator for a watchdog reset. The reason for this is that the timestamp is in seconds and the time is taken from sched clock and divided by ~1e9. sched clock starts at 0 which means that for the first second during boot the watchdog timestamp is 0, i.e. reset. Use ULONG_MAX as the reset indicator value so the watchdog works correctly right from the start. ULONG_MAX would only conflict with a real timestamp if the system reaches an uptime of 136 years on 32bit and almost eternity on 64bit. Reported-by: Robert Richter Signed-off-by: Thomas Gleixner Link: https://lore.kernel.org/r/87o8v3uuzl.fsf@nanos.tec.linutronix.de Signed-off-by: Sasha Levin commit 3512462036dbe44d88e93e75ee8a993781183ddb Author: Kim Phillips Date: Thu Nov 14 12:37:19 2019 -0600 perf/x86/amd: Constrain Large Increment per Cycle events [ Upstream commit 471af006a747f1c535c8a8c6c0973c320fe01b22 ] AMD Family 17h processors and above gain support for Large Increment per Cycle events. Unfortunately there is no CPUID or equivalent bit that indicates whether the feature exists or not, so we continue to determine eligibility based on a CPU family number comparison. For Large Increment per Cycle events, we add a f17h-and-compatibles get_event_constraints_f17h() that returns an even counter bitmask: Large Increment per Cycle events can only be placed on PMCs 0, 2, and 4 out of the currently available 0-5. The only currently public event that requires this feature to report valid counts is PMCx003 "Retired SSE/AVX Operations". Note that the CPU family logic in amd_core_pmu_init() is changed so as to be able to selectively add initialization for features available in ranges of backward-compatible CPU families. This Large Increment per Cycle feature is expected to be retained in future families. A side-effect of assigning a new get_constraints function for f17h disables calling the old (prior to f15h) amd_get_event_constraints implementation left enabled by commit e40ed1542dd7 ("perf/x86: Add perf support for AMD family-17h processors"), which is no longer necessary since those North Bridge event codes are obsoleted. Also fix a spelling mistake whilst in the area (calulating -> calculating). Fixes: e40ed1542dd7 ("perf/x86: Add perf support for AMD family-17h processors") Signed-off-by: Kim Phillips Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20191114183720.19887-2-kim.phillips@amd.com Signed-off-by: Sasha Levin commit 330a4a7e2b36ef4fd7b95b5f8aaedb8bc1adb9d6 Author: Valentin Schneider Date: Wed Jan 15 16:09:15 2020 +0000 sched/topology: Assert non-NUMA topology masks don't (partially) overlap [ Upstream commit ccf74128d66ce937876184ad55db2e0276af08d3 ] topology.c::get_group() relies on the assumption that non-NUMA domains do not partially overlap. Zeng Tao pointed out in [1] that such topology descriptions, while completely bogus, can end up being exposed to the scheduler. In his example (8 CPUs, 2-node system), we end up with: MC span for CPU3 == 3-7 MC span for CPU4 == 4-7 The first pass through get_group(3, sdd@MC) will result in the following sched_group list: 3 -> 4 -> 5 -> 6 -> 7 ^ / `----------------' And a later pass through get_group(4, sdd@MC) will "corrupt" that to: 3 -> 4 -> 5 -> 6 -> 7 ^ / `-----------' which will completely break things like 'while (sg != sd->groups)' when using CPU3's base sched_domain. There already are some architecture-specific checks in place such as x86/kernel/smpboot.c::topology.sane(), but this is something we can detect in the core scheduler, so it seems worthwhile to do so. Warn and abort the construction of the sched domains if such a broken topology description is detected. Note that this is somewhat expensive (O(t.c²), 't' non-NUMA topology levels and 'c' CPUs) and could be gated under SCHED_DEBUG if deemed necessary. Testing ======= Dietmar managed to reproduce this using the following qemu incantation: $ qemu-system-aarch64 -kernel ./Image -hda ./qemu-image-aarch64.img \ -append 'root=/dev/vda console=ttyAMA0 loglevel=8 sched_debug' -smp \ cores=8 --nographic -m 512 -cpu cortex-a53 -machine virt -numa \ node,cpus=0-2,nodeid=0 -numa node,cpus=3-7,nodeid=1 alongside the following drivers/base/arch_topology.c hack (AIUI wouldn't be needed if '-smp cores=X, sockets=Y' would work with qemu): 8<--- @@ -465,6 +465,9 @@ void update_siblings_masks(unsigned int cpuid) if (cpuid_topo->package_id != cpu_topo->package_id) continue; + if ((cpu < 4 && cpuid > 3) || (cpu > 3 && cpuid < 4)) + continue; + cpumask_set_cpu(cpuid, &cpu_topo->core_sibling); cpumask_set_cpu(cpu, &cpuid_topo->core_sibling); 8<--- [1]: https://lkml.kernel.org/r/1577088979-8545-1-git-send-email-prime.zeng@hisilicon.com Reported-by: Zeng Tao Signed-off-by: Valentin Schneider Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20200115160915.22575-1-valentin.schneider@arm.com Signed-off-by: Sasha Levin commit 74a05bdf3170b6011809e4b6b31212b22463e450 Author: Li Guanglei Date: Wed Dec 25 15:44:04 2019 +0800 sched/core: Fix size of rq::uclamp initialization [ Upstream commit dcd6dffb0a75741471297724640733fa4e958d72 ] rq::uclamp is an array of struct uclamp_rq, make sure we clear the whole thing. Fixes: 69842cba9ace ("sched/uclamp: Add CPU's clamp buckets refcountinga") Signed-off-by: Li Guanglei Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Qais Yousef Link: https://lkml.kernel.org/r/1577259844-12677-1-git-send-email-guangleix.li@gmail.com Signed-off-by: Sasha Levin commit 4d0fbc1220dee7635a934764abbe4f1b17a68788 Author: Lokesh Vutla Date: Fri Nov 22 15:33:56 2019 +0530 arm64: dts: ti: k3-j721e-main: Add missing power-domains for smmu [ Upstream commit 3f03a58b25753843ce9e4511e9e246c51bd11011 ] Add power-domains entry for smmu, so that the it is accessible as long as the driver is active. Without this device shutdown is throwing the below warning: "[ 44.736348] arm-smmu-v3 36600000.smmu: failed to clear cr0" Reported-by: Suman Anna Signed-off-by: Lokesh Vutla Signed-off-by: Tero Kristo Signed-off-by: Sasha Levin commit ed88413ebb1af21eab4f4eba8694d91e3bd90cf8 Author: zhengbin Date: Tue Nov 19 14:27:40 2019 +0800 KVM: PPC: Remove set but not used variable 'ra', 'rs', 'rt' [ Upstream commit 4de0a8355463e068e443b48eb5ae32370155368b ] Fixes gcc '-Wunused-but-set-variable' warning: arch/powerpc/kvm/emulate_loadstore.c: In function kvmppc_emulate_loadstore: arch/powerpc/kvm/emulate_loadstore.c:87:6: warning: variable ra set but not used [-Wunused-but-set-variable] arch/powerpc/kvm/emulate_loadstore.c: In function kvmppc_emulate_loadstore: arch/powerpc/kvm/emulate_loadstore.c:87:10: warning: variable rs set but not used [-Wunused-but-set-variable] arch/powerpc/kvm/emulate_loadstore.c: In function kvmppc_emulate_loadstore: arch/powerpc/kvm/emulate_loadstore.c:87:14: warning: variable rt set but not used [-Wunused-but-set-variable] They are not used since commit 2b33cb585f94 ("KVM: PPC: Reimplement LOAD_FP/STORE_FP instruction mmio emulation with analyse_instr() input") Reported-by: Hulk Robot Signed-off-by: zhengbin Signed-off-by: Paul Mackerras Signed-off-by: Sasha Levin commit f5cc1e2faca6fdba6597cf260e2409451aded179 Author: Wei Yongjun Date: Wed Jan 15 15:03:03 2020 +0000 EDAC/sifive: Fix return value check in ecc_register() [ Upstream commit 6cd18453b68942913fd3b1913b707646e544c2ac ] In case of error, the function edac_device_alloc_ctl_info() returns a NULL pointer, not ERR_PTR(). Replace the IS_ERR() test in the return value check with a NULL test. Fixes: 91abaeaaff35 ("EDAC/sifive: Add EDAC platform driver for SiFive SoCs") Signed-off-by: Wei Yongjun Signed-off-by: Borislav Petkov Link: https://lkml.kernel.org/r/20200115150303.112627-1-weiyongjun1@huawei.com Signed-off-by: Sasha Levin commit 59bcdde1df7f57fc64a01842577f7864de5f4927 Author: Jérôme Pouiller Date: Wed Jan 15 13:55:06 2020 +0000 staging: wfx: fix possible overflow on jiffies comparaison [ Upstream commit def39be019b6494acd3570ce6f3f11ba1c3203a3 ] MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit It is recommended to use function time_*() to compare jiffies. Signed-off-by: Jérôme Pouiller Link: https://lore.kernel.org/r/20200115135338.14374-45-Jerome.Pouiller@silabs.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit e3e70f500d08c1ec58f85e7c725be80863ec624b Author: Jun Lei Date: Wed Dec 18 14:40:56 2019 -0500 drm/amd/display: fixup DML dependencies [ Upstream commit 34ad0230062c39cdcba564d16d122c0fb467a7d6 ] [why] Need to fix DML portability issues to enable SW unit testing around DML [how] Move calcs into dc include folder since multiple components reference it Remove relative paths to external dependencies Signed-off-by: Jun Lei Reviewed-by: Anthony Koo Acked-by: Harry Wentland Acked-by: Rodrigo Siqueira Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 10aa618efcbd7973f026e1d90f094da6d8a1f33b Author: Sami Tolvanen Date: Thu Oct 31 12:46:52 2019 -0700 arm64: fix alternatives with LLVM's integrated assembler [ Upstream commit c54f90c2627cc316d365e3073614731e17dbc631 ] LLVM's integrated assembler fails with the following error when building KVM: :12:6: error: expected absolute expression .if kvm_update_va_mask == 0 ^ :21:6: error: expected absolute expression .if kvm_update_va_mask == 0 ^ :24:2: error: unrecognized instruction mnemonic NOT_AN_INSTRUCTION ^ LLVM ERROR: Error parsing inline asm These errors come from ALTERNATIVE_CB and __ALTERNATIVE_CFG, which test for the existence of the callback parameter in inline assembly using the following expression: " .if " __stringify(cb) " == 0\n" This works with GNU as, but isn't supported by LLVM. This change splits __ALTERNATIVE_CFG and ALTINSTR_ENTRY into separate macros to fix the LLVM build. Link: https://github.com/ClangBuiltLinux/linux/issues/472 Signed-off-by: Sami Tolvanen Tested-by: Nick Desaulniers Reviewed-by: Kees Cook Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 259f029d88e1f42c41918b1c0131864615e12ffe Author: Sami Tolvanen Date: Thu Oct 31 12:57:05 2019 -0700 arm64: lse: fix LSE atomics with LLVM's integrated assembler [ Upstream commit e0d5896bd356cd577f9710a02d7a474cdf58426b ] Unlike gcc, clang considers each inline assembly block to be independent and therefore, when using the integrated assembler for inline assembly, any preambles that enable features must be repeated in each block. This change defines __LSE_PREAMBLE and adds it to each inline assembly block that has LSE instructions, which allows them to be compiled also with clang's assembler. Link: https://github.com/ClangBuiltLinux/linux/issues/671 Signed-off-by: Sami Tolvanen Tested-by: Andrew Murray Tested-by: Kees Cook Reviewed-by: Andrew Murray Reviewed-by: Kees Cook Reviewed-by: Nick Desaulniers Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 7a73872f90632e761cdb38039a647f23975b547b Author: Leon Romanovsky Date: Wed Jan 15 14:43:35 2020 +0200 RDMA/mlx5: Don't fake udata for kernel path [ Upstream commit 4835709176e8ccf6561abc9f5c405293e008095f ] Kernel paths must not set udata and provide NULL pointer, instead of faking zeroed udata struct. Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 5c5af6685909243a3ec619085d756eca015231af Author: Mika Westerberg Date: Thu Jan 16 14:09:02 2020 +0300 pinctrl: tigerlake: Tiger Lake uses _HID enumeration [ Upstream commit cd0a32371db73d0b50536a7ca4f036abddff0d1d ] Turns out that Tiger Lake GPIO will be enumerated using _HID method where there is only a single ACPI device and multiple BARs so rework the driver to support that scheme instead. Fixes: c9ccf71fc807 ("pinctrl: intel: Add Intel Tiger Lake pin controller support") Signed-off-by: Mika Westerberg Signed-off-by: Andy Shevchenko Signed-off-by: Sasha Levin commit bbe2af2bc1edf0a46c8d71540a2f202e27f15352 Author: Chanwoo Choi Date: Thu Dec 26 14:23:49 2019 +0900 PM / devfreq: Add debugfs support with devfreq_summary file [ Upstream commit 490a421bc575d1bf391a6ad5b582dcfbd0037724 ] Add debugfs interface to provide debugging information of devfreq device. It contains 'devfreq_summary' entry to show the summary of registered devfreq devices as following and the additional debugfs file will be added. - /sys/kernel/debug/devfreq/devfreq_summary [Detailed description of each field of 'devfreq_summary' debugfs file] - dev_name : Device name of h/w - dev : Device name made by devfreq core - parent_dev : If devfreq device uses the passive governor, show parent devfreq device name. Otherwise, show 'null'. - governor : Devfreq governor name - polling_ms : If devfreq device uses the simple_ondemand governor, polling_ms is necessary for the period. (unit: millisecond) - cur_freq_Hz : Current frequency (unit: Hz) - min_freq_Hz : Minimum frequency (unit: Hz) - max_freq_Hz : Maximum frequency (unit: Hz) [For example on Exynos5422-based Odroid-XU3 board] $ cat /sys/kernel/debug/devfreq/devfreq_summary dev_name dev parent_dev governor polling_ms cur_freq_Hz min_freq_Hz max_freq_Hz ------------------------------ ---------- ---------- --------------- ---------- ------------ ------------ ------------ 10c20000.memory-controller devfreq0 null simple_ondemand 0 165000000 165000000 825000000 soc:bus_wcore devfreq1 null simple_ondemand 50 532000000 88700000 532000000 soc:bus_noc devfreq2 devfreq1 passive 0 111000000 66600000 111000000 soc:bus_fsys_apb devfreq3 devfreq1 passive 0 222000000 111000000 222000000 soc:bus_fsys devfreq4 devfreq1 passive 0 200000000 75000000 200000000 soc:bus_fsys2 devfreq5 devfreq1 passive 0 200000000 75000000 200000000 soc:bus_mfc devfreq6 devfreq1 passive 0 333000000 83250000 333000000 soc:bus_gen devfreq7 devfreq1 passive 0 266000000 88700000 266000000 soc:bus_peri devfreq8 devfreq1 passive 0 66600000 66600000 66600000 soc:bus_g2d devfreq9 devfreq1 passive 0 333000000 83250000 333000000 soc:bus_g2d_acp devfreq10 devfreq1 passive 0 266000000 66500000 266000000 soc:bus_jpeg devfreq11 devfreq1 passive 0 300000000 75000000 300000000 soc:bus_jpeg_apb devfreq12 devfreq1 passive 0 166500000 83250000 166500000 soc:bus_disp1_fimd devfreq13 devfreq1 passive 0 200000000 120000000 200000000 soc:bus_disp1 devfreq14 devfreq1 passive 0 300000000 120000000 300000000 soc:bus_gscl_scaler devfreq15 devfreq1 passive 0 300000000 150000000 300000000 soc:bus_mscl devfreq16 devfreq1 passive 0 666000000 84000000 666000000 [lkp: Reported the build error] Reported-by: kbuild test robot Signed-off-by: Chanwoo Choi Signed-off-by: Sasha Levin commit 41160b7bdbc3577e75656a15a62fceee4f400dda Author: Alexander Tsoy Date: Wed Jan 15 18:13:58 2020 +0300 ALSA: usb-audio: add implicit fb quirk for MOTU M Series [ Upstream commit c249177944b650816069f6c49b769baaa94339dc ] This fixes crackling sound during playback. Further note: MOTU is known for reusing Product IDs for different devices or different generations of the device (e.g. MicroBook I/II/IIc shares a single Product ID). This patch was only tested with M4 audio interface, but the same Product ID is also used by M2. Hope it will work for M2 as well. Signed-off-by: Alexander Tsoy Link: https://lore.kernel.org/r/20200115151358.56672-1-alexander@tsoy.me Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 38794beebe1b3014311443082b1010b46561d7b8 Author: Geert Uytterhoeven Date: Sun Jan 12 17:58:58 2020 +0100 crypto: essiv - fix AEAD capitalization and preposition use in help text [ Upstream commit ab3d436bf3e9d05f58ceaa85ff7475bfcd6e45af ] "AEAD" is capitalized everywhere else. Use "an" when followed by a written or spoken vowel. Fixes: be1eb7f78aa8fbe3 ("crypto: essiv - create wrapper template for ESSIV generation") Signed-off-by: Geert Uytterhoeven Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit f69e904eba8915fa5c9e61e1c0108b704e606ef8 Author: Zaibo Xu Date: Sat Jan 11 16:58:15 2020 +0800 crypto: hisilicon - Bugfixed tfm leak [ Upstream commit dfee9955abc7ec9364413d16316181322cf44f2f ] 1.Fixed the bug of software tfm leakage. 2.Update HW error log message. Signed-off-by: Zaibo Xu Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 087e5955210e1cb1d869dce3ba218caee3fc4dc0 Author: Zaibo Xu Date: Sat Jan 11 10:41:48 2020 +0800 crypto: hisilicon - Update debugfs usage of SEC V2 [ Upstream commit ca0d158dc9e5dc0902c1d507d82178d97f6f5709 ] Applied some advices of Marco Elver on atomic usage of Debugfs, which is carried out by basing on Arnd Bergmann's fixing patch. Reported-by: Arnd Bergmann Reported-by: Marco Elver Signed-off-by: Zaibo Xu Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 09a1795214950e5ea54531906820594abc78078f Author: Nick Black Date: Thu Dec 26 15:31:48 2019 -0500 scsi: iscsi: Don't destroy session if there are outstanding connections [ Upstream commit 54155ed4199c7aa3fd20866648024ab63c96d579 ] A faulty userspace that calls destroy_session() before destroying the connections can trigger the failure. This patch prevents the issue by refusing to destroy the session if there are outstanding connections. ------------[ cut here ]------------ kernel BUG at mm/slub.c:306! invalid opcode: 0000 [#1] SMP PTI CPU: 1 PID: 1224 Comm: iscsid Not tainted 5.4.0-rc2.iscsi+ #7 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:__slab_free+0x181/0x350 [...] [ 1209.686056] RSP: 0018:ffffa93d4074fae0 EFLAGS: 00010246 [ 1209.686694] RAX: ffff934efa5ad800 RBX: 000000008010000a RCX: ffff934efa5ad800 [ 1209.687651] RDX: ffff934efa5ad800 RSI: ffffeb4041e96b00 RDI: ffff934efd402c40 [ 1209.688582] RBP: ffffa93d4074fb80 R08: 0000000000000001 R09: ffffffffbb5dfa26 [ 1209.689425] R10: ffff934efa5ad800 R11: 0000000000000001 R12: ffffeb4041e96b00 [ 1209.690285] R13: ffff934efa5ad800 R14: ffff934efd402c40 R15: 0000000000000000 [ 1209.691213] FS: 00007f7945dfb540(0000) GS:ffff934efda80000(0000) knlGS:0000000000000000 [ 1209.692316] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1209.693013] CR2: 000055877fd3da80 CR3: 0000000077384000 CR4: 00000000000006e0 [ 1209.693897] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1209.694773] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 1209.695631] Call Trace: [ 1209.695957] ? __wake_up_common_lock+0x8a/0xc0 [ 1209.696712] iscsi_pool_free+0x26/0x40 [ 1209.697263] iscsi_session_teardown+0x2f/0xf0 [ 1209.698117] iscsi_sw_tcp_session_destroy+0x45/0x60 [ 1209.698831] iscsi_if_rx+0xd88/0x14e0 [ 1209.699370] netlink_unicast+0x16f/0x200 [ 1209.699932] netlink_sendmsg+0x21a/0x3e0 [ 1209.700446] sock_sendmsg+0x4f/0x60 [ 1209.700902] ___sys_sendmsg+0x2ae/0x320 [ 1209.701451] ? cp_new_stat+0x150/0x180 [ 1209.701922] __sys_sendmsg+0x59/0xa0 [ 1209.702357] do_syscall_64+0x52/0x160 [ 1209.702812] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 1209.703419] RIP: 0033:0x7f7946433914 [...] [ 1209.706084] RSP: 002b:00007fffb99f2378 EFLAGS: 00000246 ORIG_RAX: 000000000000002e [ 1209.706994] RAX: ffffffffffffffda RBX: 000055bc869eac20 RCX: 00007f7946433914 [ 1209.708082] RDX: 0000000000000000 RSI: 00007fffb99f2390 RDI: 0000000000000005 [ 1209.709120] RBP: 00007fffb99f2390 R08: 000055bc84fe9320 R09: 00007fffb99f1f07 [ 1209.710110] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000038 [ 1209.711085] R13: 000055bc8502306e R14: 0000000000000000 R15: 0000000000000000 Modules linked in: ---[ end trace a2d933ede7f730d8 ]--- Link: https://lore.kernel.org/r/20191226203148.2172200-1-krisman@collabora.com Signed-off-by: Nick Black Co-developed-by: Salman Qazi Signed-off-by: Salman Qazi Co-developed-by: Junho Ryu Signed-off-by: Junho Ryu Co-developed-by: Khazhismel Kumykov Signed-off-by: Khazhismel Kumykov Co-developed-by: Gabriel Krisman Bertazi Signed-off-by: Gabriel Krisman Bertazi Reviewed-by: Lee Duncan Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit a37c28f55c0c1fd1592b9c17f79304c07f68b98f Author: Stanley Chu Date: Sat Jan 11 15:11:47 2020 +0800 scsi: ufs-mediatek: add apply_dev_quirks variant operation [ Upstream commit ea92c32bd336efba89c5b09cf609e6e26e963796 ] Add vendor-specific variant callback "apply_dev_quirks" to MediaTek UFS driver. Cc: Alim Akhtar Cc: Asutosh Das Cc: Avri Altman Cc: Bart Van Assche Cc: Bean Huo Cc: Can Guo Cc: Matthias Brugger Link: https://lore.kernel.org/r/1578726707-6596-3-git-send-email-stanley.chu@mediatek.com Reviewed-by: Avri Altman Reviewed-by: Bean Huo Signed-off-by: Stanley Chu Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 86cb870500bac3dab8da7725bf2571c3012901d3 Author: Stanley Chu Date: Sat Jan 11 15:11:46 2020 +0800 scsi: ufs: pass device information to apply_dev_quirks [ Upstream commit c40ad6b7fcd35bc4d36db820c7737e1aa18d5d41 ] Pass UFS device information to vendor-specific variant callback "apply_dev_quirks" because some platform vendors need to know such information to apply special handling or quirks in specific devices. At the same time, modify existing vendor implementations according to the new interface for those vendor drivers which will be built-in or built as a module alone with UFS core driver. [mkp: clarified commit desc] Cc: Alim Akhtar Cc: Asutosh Das Cc: Avri Altman Cc: Bart Van Assche Cc: Bean Huo Cc: Can Guo Cc: Matthias Brugger Link: https://lore.kernel.org/r/1578726707-6596-2-git-send-email-stanley.chu@mediatek.com Reviewed-by: Avri Altman Reviewed-by: Bean Huo Signed-off-by: Stanley Chu Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit a6c92a0cd904c887bf91a248653ba2afe08aeb7a Author: Jaegeuk Kim Date: Fri Dec 13 18:32:16 2019 -0800 f2fs: free sysfs kobject [ Upstream commit 820d366736c949ffe698d3b3fe1266a91da1766d ] Detected kmemleak. Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit f5875bce82e6bd618620f990793a43e4f8a7e077 Author: Jaegeuk Kim Date: Fri Dec 6 16:59:58 2019 -0800 f2fs: set I_LINKABLE early to avoid wrong access by vfs [ Upstream commit 5b1dbb082f196278f82b6a15a13848efacb9ff11 ] This patch moves setting I_LINKABLE early in rename2(whiteout) to avoid the below warning. [ 3189.163385] WARNING: CPU: 3 PID: 59523 at fs/inode.c:358 inc_nlink+0x32/0x40 [ 3189.246979] Call Trace: [ 3189.248707] f2fs_init_inode_metadata+0x2d6/0x440 [f2fs] [ 3189.251399] f2fs_add_inline_entry+0x162/0x8c0 [f2fs] [ 3189.254010] f2fs_add_dentry+0x69/0xe0 [f2fs] [ 3189.256353] f2fs_do_add_link+0xc5/0x100 [f2fs] [ 3189.258774] f2fs_rename2+0xabf/0x1010 [f2fs] [ 3189.261079] vfs_rename+0x3f8/0xaa0 [ 3189.263056] ? tomoyo_path_rename+0x44/0x60 [ 3189.265283] ? do_renameat2+0x49b/0x550 [ 3189.267324] do_renameat2+0x49b/0x550 [ 3189.269316] __x64_sys_renameat2+0x20/0x30 [ 3189.271441] do_syscall_64+0x5a/0x230 [ 3189.273410] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 3189.275848] RIP: 0033:0x7f270b4d9a49 Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 10dc28b1cdc7e65eb9f652662d7e9dd58470cecc Author: Dan Carpenter Date: Wed Jan 15 20:46:04 2020 +0300 ALSA: usb-audio: unlock on error in probe [ Upstream commit a3afa29942b84b4e2548beacccc3a68b8d77e3dc ] We need to unlock before we returning on this error path. Fixes: 73ac9f5e5b43 ("ALSA: usb-audio: Add boot quirk for MOTU M Series") Signed-off-by: Dan Carpenter Link: https://lore.kernel.org/r/20200115174604.rhanfgy4j3uc65cx@kili.mountain Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 67571f43da67610591ac36e30e4f873ba7903717 Author: Will Deacon Date: Wed Jan 15 15:21:47 2020 +0000 iommu/arm-smmu-v3: Use WRITE_ONCE() when changing validity of an STE [ Upstream commit d71e01716b3606a6648df7e5646ae12c75babde4 ] If, for some bizarre reason, the compiler decided to split up the write of STE DWORD 0, we could end up making a partial structure valid. Although this probably won't happen, follow the example of the context-descriptor code and use WRITE_ONCE() to ensure atomicity of the write. Reported-by: Jean-Philippe Brucker Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit e48b3b04d58801829f0d778dbeef1a393a67d2e1 Author: Masahiro Yamada Date: Fri Jan 10 14:02:24 2020 +0900 kbuild: remove *.tmp file when filechk fails [ Upstream commit 88fe89a47153facd8cb2d06d5c8727f7224c43c2 ] Bartosz Golaszewski reports that when "make {menu,n,g,x}config" fails due to missing packages, a temporary file is left over, which is not ignored by git. For example, if GTK+ is not installed: $ make gconfig * * Unable to find the GTK+ installation. Please make sure that * the GTK+ 2.0 development package is correctly installed. * You need gtk+-2.0 gmodule-2.0 libglade-2.0 * scripts/kconfig/Makefile:208: recipe for target 'scripts/kconfig/gconf-cfg' failed make[1]: *** [scripts/kconfig/gconf-cfg] Error 1 Makefile:567: recipe for target 'gconfig' failed make: *** [gconfig] Error 2 $ git status HEAD detached at v5.4 Untracked files: (use "git add ..." to include in what will be committed) scripts/kconfig/gconf-cfg.tmp nothing added to commit but untracked files present (use "git add" to track) This is because the check scripts are run with filechk, which misses to clean up the temporary file on failure. When the line { $(filechk_$(1)); } > $@.tmp; ... fails, it exits immediately due to the 'set -e'. Use trap to make sure to delete the temporary file on exit. For extra safety, I replaced $@.tmp with $(dot-target).tmp to make it a hidden file. Reported-by: Bartosz Golaszewski Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin commit 8a3f5b1a952e473e0d1111a936a6939fd6202ea9 Author: Tony Lindgren Date: Wed Jan 15 07:25:26 2020 -0600 usb: musb: omap2430: Get rid of musb .set_vbus for omap2430 glue [ Upstream commit 91b6dec32e5c25fbdbb564d1e5af23764ec17ef1 ] We currently have musb_set_vbus() called from two different paths. Mostly it gets called from the USB PHY via omap_musb_set_mailbox(), but in some cases it can get also called from musb_stage0_irq() rather via .set_vbus: (musb_set_host [musb_hdrc]) (omap2430_musb_set_vbus [omap2430]) (musb_stage0_irq [musb_hdrc]) (musb_interrupt [musb_hdrc]) (omap2430_musb_interrupt [omap2430]) This is racy and will not work with introducing generic helper functions for musb_set_host() and musb_set_peripheral(). We want to get rid of the busy loops in favor of usleep_range(). Let's just get rid of .set_vbus for omap2430 glue layer and let the PHY code handle VBUS with musb_set_vbus(). Note that in the follow-up patch we can completely remove omap2430_musb_set_vbus(), but let's do it in a separate patch as this change may actually turn out to be needed as a fix. Reported-by: Pavel Machek Acked-by: Pavel Machek Signed-off-by: Tony Lindgren Signed-off-by: Bin Liu Link: https://lore.kernel.org/r/20200115132547.364-5-b-liu@ti.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 4c6a908ed7d55074aa334abe235ddee383c3a7f9 Author: Leonard Crestez Date: Tue Jan 14 22:25:46 2020 +0200 perf/imx_ddr: Fix cpu hotplug state cleanup [ Upstream commit 9ee68b314e9aa63ed11b98beb8a68810b8234dcf ] This driver allocates a dynamic cpu hotplug state but never releases it. If reloaded in a loop it will quickly trigger a WARN message: "No more dynamic states available for CPU hotplug" Fix by calling cpuhp_remove_multi_state on remove like several other perf pmu drivers. Also fix the cleanup logic on probe error paths: add the missing cpuhp_remove_multi_state call and properly check the return value from cpuhp_state_add_instant_nocalls. Fixes: 9a66d36cc7ac ("drivers/perf: imx_ddr: Add DDR performance counter support to perf") Acked-by: Joakim Zhang Signed-off-by: Leonard Crestez Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 4f8d534fb4eb64c5dea74863b007d9b51345070a Author: Navid Emamdoost Date: Tue Sep 24 23:37:58 2019 -0500 drm/vmwgfx: prevent memory leak in vmw_cmdbuf_res_add [ Upstream commit 40efb09a7f53125719e49864da008495e39aaa1e ] In vmw_cmdbuf_res_add if drm_ht_insert_item fails the allocated memory for cres should be released. Fixes: 18e4a4669c50 ("drm/vmwgfx: Fix compat shader namespace") Signed-off-by: Navid Emamdoost Reviewed-by: Thomas Hellstrom Signed-off-by: Thomas Hellstrom Signed-off-by: Sasha Levin commit 3edd9f0b3c000ace984dc90bb05d8dc196871337 Author: Stephen Boyd Date: Tue Jan 14 15:11:03 2020 -0800 gpiolib: Set lockdep class for hierarchical irq domains [ Upstream commit c34f6dc8c9e6bbe9fba1d53acd6d9a3889599da3 ] I see the following lockdep splat in the qcom pinctrl driver when attempting to suspend the device. ============================================ WARNING: possible recursive locking detected 5.4.2 #2 Tainted: G S -------------------------------------------- cat/6536 is trying to acquire lock: ffffff814787ccc0 (&irq_desc_lock_class){-.-.}, at: __irq_get_desc_lock+0x64/0x94 but task is already holding lock: ffffff81436740c0 (&irq_desc_lock_class){-.-.}, at: __irq_get_desc_lock+0x64/0x94 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&irq_desc_lock_class); lock(&irq_desc_lock_class); *** DEADLOCK *** May be due to missing lock nesting notation 7 locks held by cat/6536: #0: ffffff8140e0c420 (sb_writers#7){.+.+}, at: vfs_write+0xc8/0x19c #1: ffffff8121eec480 (&of->mutex){+.+.}, at: kernfs_fop_write+0x128/0x1f4 #2: ffffff8147cad668 (kn->count#263){.+.+}, at: kernfs_fop_write+0x130/0x1f4 #3: ffffffd011446000 (system_transition_mutex){+.+.}, at: pm_suspend+0x108/0x354 #4: ffffff814302b970 (&dev->mutex){....}, at: __device_suspend+0x16c/0x420 #5: ffffff81436740c0 (&irq_desc_lock_class){-.-.}, at: __irq_get_desc_lock+0x64/0x94 #6: ffffff81479b8c10 (&pctrl->lock){....}, at: msm_gpio_irq_set_wake+0x48/0x7c stack backtrace: CPU: 4 PID: 6536 Comm: cat Tainted: G S 5.4.2 #2 Call trace: dump_backtrace+0x0/0x174 show_stack+0x20/0x2c dump_stack+0xdc/0x144 __lock_acquire+0x52c/0x2268 lock_acquire+0x1dc/0x220 _raw_spin_lock_irqsave+0x64/0x80 __irq_get_desc_lock+0x64/0x94 irq_set_irq_wake+0x40/0x144 msm_gpio_irq_set_wake+0x5c/0x7c set_irq_wake_real+0x40/0x5c irq_set_irq_wake+0x70/0x144 cros_ec_rtc_suspend+0x38/0x4c platform_pm_suspend+0x34/0x60 dpm_run_callback+0x64/0xcc __device_suspend+0x314/0x420 dpm_suspend+0xf8/0x298 dpm_suspend_start+0x84/0xb4 suspend_devices_and_enter+0xbc/0x628 pm_suspend+0x214/0x354 state_store+0xb0/0x108 kobj_attr_store+0x14/0x24 sysfs_kf_write+0x4c/0x64 kernfs_fop_write+0x158/0x1f4 __vfs_write+0x54/0x18c vfs_write+0xdc/0x19c ksys_write+0x7c/0xe4 __arm64_sys_write+0x20/0x2c el0_svc_common+0xa8/0x160 el0_svc_compat_handler+0x2c/0x38 el0_svc_compat+0x8/0x10 This is because the msm_gpio_irq_set_wake() function calls irq_set_irq_wake() as a backup in case the irq comes in during the path to idle. Given that we're calling irqchip functions from within an irqchip we need to set the lockdep class to be different for this child controller vs. the default one that the parent irqchip gets. This used to be done before this driver was converted to hierarchical irq domains in commit e35a6ae0eb3a ("pinctrl/msm: Setup GPIO chip in hierarchy") via the gpiochip_irq_map() function. With hierarchical irq domains this function has been replaced by gpiochip_hierarchy_irq_domain_alloc(). Therefore, set the lockdep class like was done previously in the irq domain path so we can avoid this lockdep warning. Fixes: fdd61a013a24 ("gpio: Add support for hierarchical IRQ domains") Cc: Thierry Reding Cc: Brian Masney Cc: Lina Iyer Cc: Marc Zyngier Cc: Maulik Shah Signed-off-by: Stephen Boyd Link: https://lore.kernel.org/r/20200114231103.85641-1-swboyd@chromium.org Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 12ed1d16d15ad6b7cd4d50a6ac94ac120825068c Author: Mikulas Patocka Date: Mon Jan 13 15:04:37 2020 -0500 dm thin: don't allow changing data device during thin-pool reload [ Upstream commit 873937e75f9a8ea231a502c3d29d9cb6ad91b3ef ] The existing code allows changing the data device when the thin-pool target is reloaded. This capability is not required and only complicates device lifetime guarantees. This can cause crashes like the one reported here: https://bugzilla.redhat.com/show_bug.cgi?id=1788596 where the kernel tries to issue a flush bio located in a structure that was already freed. Take the first step to simplifying the thin-pool's data device lifetime by disallowing changing it. Like the thin-pool's metadata device, the data device is now set in pool_create() and it cannot be changed for a given thin-pool. Signed-off-by: Mikulas Patocka Signed-off-by: Mike Snitzer Signed-off-by: Sasha Levin commit ca257c597c1d60a0e34d06f16eb4b33f510af82f Author: Ben Skeggs Date: Wed Jan 15 06:34:21 2020 +1000 drm/nouveau/fault/gv100-: fix memory leak on module unload [ Upstream commit 633cc9beeb6f9b5fa2f17a2a9d0e2790cb6c3de7 ] Signed-off-by: Ben Skeggs Signed-off-by: Sasha Levin commit 937ebc27f0cc5731f85d35fa41fc6efee908a58d Author: YueHaibing Date: Fri Jan 10 15:28:37 2020 +0800 drm/nouveau/drm/ttm: Remove set but not used variable 'mem' [ Upstream commit 2e4534a22794746b11a794b2229b8d58797eccce ] drivers/gpu/drm/nouveau/nouveau_ttm.c: In function nouveau_vram_manager_new: drivers/gpu/drm/nouveau/nouveau_ttm.c:66:22: warning: variable mem set but not used [-Wunused-but-set-variable] drivers/gpu/drm/nouveau/nouveau_ttm.c: In function nouveau_gart_manager_new: drivers/gpu/drm/nouveau/nouveau_ttm.c:106:22: warning: variable mem set but not used [-Wunused-but-set-variable] They are not used any more, so remove it. Reported-by: Hulk Robot Signed-off-by: YueHaibing Signed-off-by: Ben Skeggs Signed-off-by: Sasha Levin commit 564803b5fc19d8025df886b576e851a1cbc7edcf Author: YueHaibing Date: Fri Jan 10 14:32:01 2020 +0800 drm/nouveau: Fix copy-paste error in nouveau_fence_wait_uevent_handler [ Upstream commit 1eb013473bff5f95b6fe1ca4dd7deda47257b9c2 ] Like other cases, it should use rcu protected 'chan' rather than 'fence->channel' in nouveau_fence_wait_uevent_handler. Fixes: 0ec5f02f0e2c ("drm/nouveau: prevent stale fence->channel pointers, and protect with rcu") Signed-off-by: YueHaibing Signed-off-by: Ben Skeggs Signed-off-by: Sasha Levin commit f349d45fae05094fe49dcb795ea850b254924020 Author: Ben Skeggs Date: Thu Jan 9 11:46:15 2020 +1000 drm/nouveau/gr/gk20a,gm200-: add terminators to method lists read from fw [ Upstream commit 7adc77aa0e11f25b0e762859219c70852cd8d56f ] Method init is typically ordered by class in the FW image as ThreeD, TwoD, Compute. Due to a bug in parsing the FW into our internal format, we've been accidentally sending Twod + Compute methods to the ThreeD class, as well as Compute methods to the TwoD class - oops. Signed-off-by: Ben Skeggs Signed-off-by: Sasha Levin commit 28514c00c884fcc75f6843440696c7da271c6163 Author: Dan Carpenter Date: Wed Jan 8 08:46:01 2020 +0300 drm/nouveau/secboot/gm20b: initialize pointer in gm20b_secboot_new() [ Upstream commit 3613a9bea95a1470dd42e4ed1cc7d86ebe0a2dc0 ] We accidentally set "psb" which is a no-op instead of "*psb" so it generates a static checker warning. We should probably set it before the first error return so that it's always initialized. Fixes: 923f1bd27bf1 ("drm/nouveau/secboot/gm20b: add secure boot support") Signed-off-by: Dan Carpenter Signed-off-by: Ben Skeggs Signed-off-by: Sasha Levin commit e43272ca596790fa9dc168915db8f51fdb269749 Author: Reto Schneider Date: Tue Jan 14 09:48:06 2020 +0100 MIPS: ralink: dts: gardena_smart_gateway_mt7688: Limit UART1 [ Upstream commit e8c192011c920517e5578d51c7aff0ecadd25de3 ] The radio module asserts CTS when its RX buffer has 10 bytes left. Putting just 8 instead of 16 bytes into the UART1 TX buffer on the Linux side ensures to not overflow the RX buffer on the radio module side. Signed-off-by: Reto Schneider Signed-off-by: Stefan Roese Cc: Paul Burton Signed-off-by: Paul Burton Cc: linux-mips@vger.kernel.org Signed-off-by: Sasha Levin commit e99c0bd7fedfc30cdc334fc4917cfe7bdf7164d0 Author: Arnd Bergmann Date: Tue Jan 7 21:05:43 2020 +0100 vme: bridges: reduce stack usage [ Upstream commit 7483e7a939c074d887450ef1c4d9ccc5909405f8 ] With CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE_O3, the stack usage in vme_fake grows above the warning limit: drivers/vme/bridges/vme_fake.c: In function 'fake_master_read': drivers/vme/bridges/vme_fake.c:610:1: error: the frame size of 1160 bytes is larger than 1024 bytes [-Werror=frame-larger-than=] drivers/vme/bridges/vme_fake.c: In function 'fake_master_write': drivers/vme/bridges/vme_fake.c:797:1: error: the frame size of 1160 bytes is larger than 1024 bytes [-Werror=frame-larger-than=] The problem is that in some configurations, each call to fake_vmereadX() puts another variable on the stack. Reduce the amount of inlining to get back to the previous state, with no function using more than 200 bytes each. Signed-off-by: Arnd Bergmann Link: https://lore.kernel.org/r/20200107200610.3482901-1-arnd@arndb.de Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 6e1a97ea211dd2891fca4e253a9e146c66453990 Author: Li RongQing Date: Fri Jan 10 09:04:37 2020 +0800 bpf: Return -EBADRQC for invalid map type in __bpf_tx_xdp_map [ Upstream commit 0a29275b6300f39f78a87f2038bbfe5bdbaeca47 ] A negative value should be returned if map->map_type is invalid although that is impossible now, but if we run into such situation in future, then xdpbuff could be leaked. Daniel Borkmann suggested: -EBADRQC should be returned to stay consistent with generic XDP for the tracepoint output and not to be confused with -EOPNOTSUPP from other locations like dev_map_enqueue() when ndo_xdp_xmit is missing and such. Suggested-by: Daniel Borkmann Signed-off-by: Li RongQing Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/1578618277-18085-1-git-send-email-lirongqing@baidu.com Signed-off-by: Sasha Levin commit 9664fb1a66861887bd0067becbdd0179e0e38007 Author: Pierre-Louis Bossart Date: Mon Jan 13 14:56:20 2020 -0600 ASoC: SOF: Intel: hda-dai: fix compilation warning in pcm_prepare [ Upstream commit d873997192ddcacb5333575502be2f91ea4b47b8 ] Fix GCC warning with W=1, previous cleanup did not remove unnecessary variable. sound/soc/sof/intel/hda-dai.c: In function ‘hda_link_pcm_prepare’: sound/soc/sof/intel/hda-dai.c:265:31: warning: variable ‘hda_stream’ set but not used [-Wunused-but-set-variable] 265 | struct sof_intel_hda_stream *hda_stream; | ^~~~~~~~~~ Fixes: a3ebccb52efdf ("ASoC: SOF: Intel: hda: reset link DMA state in prepare") Cc: Kai Vehmanen Signed-off-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20200113205620.27285-1-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 90be63abf0eae6b114abb213a7d45cb440787147 Author: Geert Uytterhoeven Date: Fri Dec 6 14:22:19 2019 +0100 driver core: Print device when resources present in really_probe() [ Upstream commit 7c35e699c88bd60734277b26962783c60e04b494 ] If a device already has devres items attached before probing, a warning backtrace is printed. However, this backtrace does not reveal the offending device, leaving the user uninformed. Furthermore, using WARN_ON() causes systems with panic-on-warn to reboot. Fix this by replacing the WARN_ON() by a dev_crit() message. Abort probing the device, to prevent doing more damage to the device's resources. Signed-off-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/20191206132219.28908-1-geert+renesas@glider.be Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit ddd1fd7f064b0961ceb4dc595b1d676911131247 Author: Simon Schwartz Date: Tue Dec 10 17:41:37 2019 -0500 driver core: platform: Prevent resouce overflow from causing infinite loops [ Upstream commit 39cc539f90d035a293240c9443af50be55ee81b8 ] num_resources in the platform_device struct is declared as a u32. The for loops that iterate over num_resources use an int as the counter, which can cause infinite loops on architectures with smaller ints. Change the loop counters to u32. Signed-off-by: Simon Schwartz Link: https://lore.kernel.org/r/2201ce63a2a171ffd2ed14e867875316efcf71db.camel@theschwartz.xyz Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 589472a28901c5fdd6d452dd5ce8b7567298823f Author: Arnd Bergmann Date: Tue Jan 7 21:29:40 2020 +0100 visorbus: fix uninitialized variable access [ Upstream commit caf82f727e69b647f09d57a1fc56e69d22a5f483 ] The setup_crash_devices_work_queue function only partially initializes the message it sends to chipset_init, leading to undefined behavior: drivers/visorbus/visorchipset.c: In function 'setup_crash_devices_work_queue': drivers/visorbus/visorchipset.c:333:6: error: '((unsigned char*)&msg.hdr.flags)[0]' is used uninitialized in this function [-Werror=uninitialized] if (inmsg->hdr.flags.response_expected) Set up the entire structure, zero-initializing the 'response_expected' flag. This was apparently found by the patch that added the -O3 build option in Kconfig. Fixes: 12e364b9f08a ("staging: visorchipset driver to provide registration and other services") Signed-off-by: Arnd Bergmann Link: https://lore.kernel.org/r/20200107202950.782951-1-arnd@arndb.de Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 46fafff9c8ef83f5dd2aa8d90b969fbcaa5725b2 Author: Luc Van Oostenryck Date: Mon Dec 9 22:36:55 2019 +0100 misc: xilinx_sdfec: fix xsdfec_poll()'s return type [ Upstream commit fa4e7fc1386078edcfddd8848cb0374f4af74fe7 ] xsdfec_poll() is defined as returning 'unsigned int' but the .poll method is declared as returning '__poll_t', a bitwise type. Fix this by using the proper return type and using the EPOLL constants instead of the POLL ones, as required for __poll_t. CC: Derek Kiernan CC: Dragan Cvetic Signed-off-by: Luc Van Oostenryck Acked-by: Dragan Cvetic Link: https://lore.kernel.org/r/20191209213655.57985-1-luc.vanoostenryck@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit db54c15b01e0dc9e311f3988d2ad5df639c00f6c Author: Ioana Ciornei Date: Wed Dec 4 16:29:50 2019 +0200 bus: fsl-mc: properly empty-initialize structure [ Upstream commit cff081ea9d0962defd733daf6778f62b1dac3daa ] Use the proper form of the empty initializer when working with structures that contain an array. Otherwise, older gcc versions (eg gcc 4.9) will complain about this. Fixes: 1ac210d128ef ("bus: fsl-mc: add the fsl_mc_get_endpoint function") Reported-by: kbuild test robot Signed-off-by: Ioana Ciornei Acked-by: Laurentiu Tudor Link: https://lore.kernel.org/r/20191204142950.30206-1-ioana.ciornei@nxp.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 133f8852187cd21e001b35f1f36bb73fb96cbd26 Author: Nathan Chancellor Date: Tue Dec 17 19:39:13 2019 -0700 tty: synclink_gt: Adjust indentation in several functions [ Upstream commit 446e76873b5e4e70bdee5db2f2a894d5b4a7d081 ] Clang warns: ../drivers/tty/synclink_gt.c:1337:3: warning: misleading indentation; statement is not part of the previous 'if' [-Wmisleading-indentation] if (C_CRTSCTS(tty)) { ^ ../drivers/tty/synclink_gt.c:1335:2: note: previous statement is here if (I_IXOFF(tty)) ^ ../drivers/tty/synclink_gt.c:2563:3: warning: misleading indentation; statement is not part of the previous 'if' [-Wmisleading-indentation] if (I_BRKINT(info->port.tty) || I_PARMRK(info->port.tty)) ^ ../drivers/tty/synclink_gt.c:2561:2: note: previous statement is here if (I_INPCK(info->port.tty)) ^ ../drivers/tty/synclink_gt.c:3221:3: warning: misleading indentation; statement is not part of the previous 'else' [-Wmisleading-indentation] set_signals(info); ^ ../drivers/tty/synclink_gt.c:3219:2: note: previous statement is here else ^ 3 warnings generated. The indentation on these lines is not at all consistent, tabs and spaces are mixed together. Convert to just using tabs to be consistent with the Linux kernel coding style and eliminate these warnings from clang. Link: https://github.com/ClangBuiltLinux/linux/issues/822 Signed-off-by: Nathan Chancellor Link: https://lore.kernel.org/r/20191218023912.13827-1-natechancellor@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit aaf3a0f8421614573490ed1cd04dec09c05dc40c Author: Nathan Chancellor Date: Tue Dec 17 19:47:20 2019 -0700 tty: synclinkmp: Adjust indentation in several functions [ Upstream commit 1feedf61e7265128244f6993f23421f33dd93dbc ] Clang warns: ../drivers/tty/synclinkmp.c:1456:3: warning: misleading indentation; statement is not part of the previous 'if' [-Wmisleading-indentation] if (C_CRTSCTS(tty)) { ^ ../drivers/tty/synclinkmp.c:1453:2: note: previous statement is here if (I_IXOFF(tty)) ^ ../drivers/tty/synclinkmp.c:2473:8: warning: misleading indentation; statement is not part of the previous 'if' [-Wmisleading-indentation] info->port.tty->hw_stopped = 0; ^ ../drivers/tty/synclinkmp.c:2471:7: note: previous statement is here if ( debug_level >= DEBUG_LEVEL_ISR ) ^ ../drivers/tty/synclinkmp.c:2482:8: warning: misleading indentation; statement is not part of the previous 'if' [-Wmisleading-indentation] info->port.tty->hw_stopped = 1; ^ ../drivers/tty/synclinkmp.c:2480:7: note: previous statement is here if ( debug_level >= DEBUG_LEVEL_ISR ) ^ ../drivers/tty/synclinkmp.c:2809:3: warning: misleading indentation; statement is not part of the previous 'if' [-Wmisleading-indentation] if (I_BRKINT(info->port.tty) || I_PARMRK(info->port.tty)) ^ ../drivers/tty/synclinkmp.c:2807:2: note: previous statement is here if (I_INPCK(info->port.tty)) ^ ../drivers/tty/synclinkmp.c:3246:3: warning: misleading indentation; statement is not part of the previous 'else' [-Wmisleading-indentation] set_signals(info); ^ ../drivers/tty/synclinkmp.c:3244:2: note: previous statement is here else ^ 5 warnings generated. The indentation on these lines is not at all consistent, tabs and spaces are mixed together. Convert to just using tabs to be consistent with the Linux kernel coding style and eliminate these warnings from clang. Link: https://github.com/ClangBuiltLinux/linux/issues/823 Signed-off-by: Nathan Chancellor Link: https://lore.kernel.org/r/20191218024720.3528-1-natechancellor@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 4156ba7d2941c825ae7db829555113cdab76bd44 Author: Zhengyuan Liu Date: Fri Dec 20 10:21:27 2019 +0800 raid6/test: fix a compilation warning [ Upstream commit 5e5ac01c2b8802921fee680518a986011cb59820 ] The compilation warning is redefination showed as following: In file included from tables.c:2: ../../../include/linux/export.h:180: warning: "EXPORT_SYMBOL" redefined #define EXPORT_SYMBOL(sym) __EXPORT_SYMBOL(sym, "") In file included from tables.c:1: ../../../include/linux/raid/pq.h:61: note: this is the location of the previous definition #define EXPORT_SYMBOL(sym) Fixes: 69a94abb82ee ("export.h, genksyms: do not make genksyms calculate CRC of trimmed symbols") Signed-off-by: Zhengyuan Liu Signed-off-by: Song Liu Signed-off-by: Sasha Levin commit 76fccd309761847f43901930916decd60c550fe8 Author: Chen Zhou Date: Mon Jan 13 21:32:42 2020 +0800 ASoC: atmel: fix build error with CONFIG_SND_ATMEL_SOC_DMA=m [ Upstream commit 8fea78029f5e6ed734ae1957bef23cfda1af4354 ] If CONFIG_SND_ATMEL_SOC_DMA=m, build error: sound/soc/atmel/atmel_ssc_dai.o: In function `atmel_ssc_set_audio': (.text+0x7cd): undefined reference to `atmel_pcm_dma_platform_register' Function atmel_pcm_dma_platform_register is defined under CONFIG SND_ATMEL_SOC_DMA, so select SND_ATMEL_SOC_DMA in CONFIG SND_ATMEL_SOC_SSC, same to CONFIG_SND_ATMEL_SOC_PDC. Reported-by: Hulk Robot Signed-off-by: Chen Zhou Link: https://lore.kernel.org/r/20200113133242.144550-1-chenzhou10@huawei.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 148e2930ba8252afbbade85b528a23d7c27086e4 Author: Paul Burton Date: Thu Jan 9 11:14:22 2020 -0800 ASoC: txx9: Remove unused rtd variable [ Upstream commit ec0f6a4c4a987aa20b2e77e0db2ae555276e45e6 ] Commit a857e073ffc6 ("ASoC: txx9: txx9aclc: remove snd_pcm_ops") removed the last use of the rtd variable but didn't remove its definition, leading to the following warning/error for MIPS rbtx49xx_defconfig builds: sound/soc/txx9/txx9aclc.c: In function 'txx9aclc_pcm_hw_params': sound/soc/txx9/txx9aclc.c:54:30: error: unused variable 'rtd' [-Werror=unused-variable] struct snd_soc_pcm_runtime *rtd = snd_pcm_substream_chip(substream); ^~~ Resolve this by removing the unused variable. Signed-off-by: Paul Burton Fixes: a857e073ffc6 ("ASoC: txx9: txx9aclc: remove snd_pcm_ops") Cc: Kuninori Morimoto Cc: Mark Brown Cc: Liam Girdwood Cc: Jaroslav Kysela Cc: Takashi Iwai Cc: alsa-devel@alsa-project.org Link: https://lore.kernel.org/r/20200109191422.334516-1-paulburton@kernel.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 2cfa8f60b79c00ebd224afc212ed264842ceff0f Author: Alexander Tsoy Date: Sun Jan 12 13:23:58 2020 +0300 ALSA: usb-audio: Add boot quirk for MOTU M Series [ Upstream commit 73ac9f5e5b43a5dbadb61f27dae7a971f7ec0d22 ] Add delay to make sure that audio urbs are not sent too early. Otherwise the device hangs. Windows driver makes ~2s delay, so use about the same time delay value. snd_usb_apply_boot_quirk() is called 3 times for my MOTU M4, which is an overkill. Thus a quirk that is called only once is implemented. Also send two vendor-specific control messages before and after the delay. This behaviour is blindly copied from the Windows driver. Signed-off-by: Alexander Tsoy Link: https://lore.kernel.org/r/20200112102358.18085-1-alexander@tsoy.me Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 2a9e46cddf71caad730c2ff4e97ef808df111055 Author: Johan Jonker Date: Fri Jan 10 14:44:20 2020 +0100 ARM: dts: rockchip: add reg property to brcmf sub node for rk3188-bqedison2qc [ Upstream commit cf206bca178cd5b5a436494b2e0cea75295944f4 ] An experimental test with the command below gives this error: rk3188-bqedison2qc.dt.yaml: dwmmc@10218000: wifi@1: 'reg' is a required property So fix this by adding a reg property to the brcmf sub node. Also add #address-cells and #size-cells to prevent more warnings. make ARCH=arm dtbs_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml Signed-off-by: Johan Jonker Link: https://lore.kernel.org/r/20200110134420.11280-1-jbx6244@gmail.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 8195cdaaef2f7f70435061d88dffaa09a96f7655 Author: Johan Jonker Date: Fri Jan 10 15:21:28 2020 +0100 arm64: dts: rockchip: add reg property to brcmf sub-nodes [ Upstream commit 96ff264bccb22175bbe2185a1eb5204ca3c5f03f ] An experimental test with the command below gives this error: rk3399-firefly.dt.yaml: dwmmc@fe310000: wifi@1: 'reg' is a required property rk3399-orangepi.dt.yaml: dwmmc@fe310000: wifi@1: 'reg' is a required property rk3399-khadas-edge.dt.yaml: dwmmc@fe310000: wifi@1: 'reg' is a required property rk3399-khadas-edge-captain.dt.yaml: dwmmc@fe310000: wifi@1: 'reg' is a required property rk3399-khadas-edge-v.dt.yaml: dwmmc@fe310000: wifi@1: 'reg' is a required property So fix this by adding a reg property to the brcmf sub node. Also add #address-cells and #size-cells to prevent more warnings. make ARCH=arm64 dtbs_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml Signed-off-by: Johan Jonker Link: https://lore.kernel.org/r/20200110142128.13522-1-jbx6244@gmail.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 7e995c7b323144602c32cefdedc0ccd7905f9b40 Author: Johan Jonker Date: Fri Jan 10 17:12:00 2020 +0100 arm64: dts: rockchip: fix dwmmc clock name for rk3308 [ Upstream commit 2be6a280144e521248a4bdefb691a0a97e604294 ] An experimental test with the command below gives this error: rk3308-evb.dt.yaml: dwmmc@ff480000: clock-names:2: 'ciu-drive' was expected 'ciu-drv' is not a valid dwmmc clock name, so fix this by changing it to 'ciu-drive'. make ARCH=arm64 dtbs_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml Signed-off-by: Johan Jonker Link: https://lore.kernel.org/r/20200110161200.22755-1-jbx6244@gmail.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 2d42ec796e5795e7c9d85f6a7ba938234e720d94 Author: Johan Jonker Date: Fri Jan 10 17:12:00 2020 +0100 arm64: dts: rockchip: fix dwmmc clock name for px30 [ Upstream commit 7f2147350291569acd1df5a26dcdfc573916016f ] An experimental test with the command below gives this error: px30-evb.dt.yaml: dwmmc@ff390000: clock-names:2: 'ciu-drive' was expected 'ciu-drv' is not a valid dwmmc clock name, so fix this by changing it to 'ciu-drive'. make ARCH=arm64 dtbs_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml Signed-off-by: Johan Jonker Link: https://lore.kernel.org/r/20200110161200.22755-1-jbx6244@gmail.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 6adf50d0371ac22ecc424ee879fa3aed3b3de32e Author: Bartosz Golaszewski Date: Fri Jan 10 18:16:41 2020 +0100 clocksource: davinci: only enable clockevents once tim34 is initialized [ Upstream commit cea931c25104e6bddc42eb067f58193f355dbdd7 ] The DM365 platform has a strange quirk (only present when using ancient u-boot - mainline u-boot v2013.01 and later works fine) where if we enable the second half of the timer in periodic mode before we do its initialization - the time won't start flowing and we can't boot. When using more recent u-boot, we can enable the timer, then reinitialize it and all works fine. To work around this issue only enable clockevents once tim34 is initialized i.e. move clockevents_config_and_register() below tim34 initialization. Signed-off-by: Bartosz Golaszewski Signed-off-by: Sekhar Nori Signed-off-by: Sasha Levin commit 7f6c65489cdaed85be41de15498ef63a63cae402 Author: Arnd Bergmann Date: Sun Jan 12 13:04:42 2020 +0100 wan: ixp4xx_hss: fix compile-testing on 64-bit [ Upstream commit 504c28c853ec5c626900b914b5833daf0581a344 ] Change the driver to use portable integer types to avoid warnings during compile testing: drivers/net/wan/ixp4xx_hss.c:863:21: error: cast to 'u32 *' (aka 'unsigned int *') from smaller integer type 'int' [-Werror,-Wint-to-pointer-cast] memcpy_swab32(mem, (u32 *)((int)skb->data & ~3), bytes / 4); ^ drivers/net/wan/ixp4xx_hss.c:979:12: error: incompatible pointer types passing 'u32 *' (aka 'unsigned int *') to parameter of type 'dma_addr_t *' (aka 'unsigned long long *') [-Werror,-Wincompatible-pointer-types] &port->desc_tab_phys))) ^~~~~~~~~~~~~~~~~~~~ include/linux/dmapool.h:27:20: note: passing argument to parameter 'handle' here dma_addr_t *handle); ^ Signed-off-by: Arnd Bergmann Signed-off-by: Linus Walleij Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a87392f7c4e58cebf966dad82430c79e598659f3 Author: Changbin Du Date: Sat Jan 11 20:54:27 2020 +0800 x86/nmi: Remove irq_work from the long duration NMI handler [ Upstream commit 248ed51048c40d36728e70914e38bffd7821da57 ] First, printk() is NMI-context safe now since the safe printk() has been implemented and it already has an irq_work to make NMI-context safe. Second, this NMI irq_work actually does not work if a NMI handler causes panic by watchdog timeout. It has no chance to run in such case, while the safe printk() will flush its per-cpu buffers before panicking. While at it, repurpose the irq_work callback into a function which concentrates the NMI duration checking and makes the code easier to follow. [ bp: Massage. ] Signed-off-by: Changbin Du Signed-off-by: Borislav Petkov Acked-by: Thomas Gleixner Link: https://lkml.kernel.org/r/20200111125427.15662-1-changbin.du@gmail.com Signed-off-by: Sasha Levin commit efa7868394b04b5d1fd5f8d798f8f43066379c22 Author: Jonathan Lemon Date: Thu Jan 9 11:35:42 2020 -0800 bnxt: Detach page from page pool before sending up the stack [ Upstream commit 3071c51783b39d6a676d02a9256c3b3f87804285 ] When running in XDP mode, pages come from the page pool, and should be freed back to the same pool or specifically detached. Currently, when the driver re-initializes, the page pool destruction is delayed forever since it thinks there are oustanding pages. Fixes: 322b87ca55f2 ("bnxt_en: add page_pool support") Signed-off-by: Jonathan Lemon Reviewed-by: Andy Gospodarek Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit a762cfd791ae2ce047fc83b610f8c56743e3e87f Author: Philipp Zabel Date: Thu Jan 9 17:03:21 2020 -0800 Input: edt-ft5x06 - work around first register access error [ Upstream commit e112324cc0422c046f1cf54c56f333d34fa20885 ] The EP0700MLP1 returns bogus data on the first register read access (reading the threshold parameter from register 0x00): edt_ft5x06 2-0038: crc error: 0xfc expected, got 0x40 It ignores writes until then. This patch adds a dummy read after which the number of sensors and parameter read/writes work correctly. Signed-off-by: Philipp Zabel Signed-off-by: Marco Felsch Tested-by: Andy Shevchenko Reviewed-by: Andy Shevchenko Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit 13285b66d04904004216045f6140baf80ecfffc2 Author: Paul E. McKenney Date: Sat Nov 9 09:42:13 2019 -0800 rcu: Use WRITE_ONCE() for assignments to ->pprev for hlist_nulls [ Upstream commit 860c8802ace14c646864795e057349c9fb2d60ad ] Eric Dumazet supplied a KCSAN report of a bug that forces use of hlist_unhashed_lockless() from sk_unhashed(): ------------------------------------------------------------------------ BUG: KCSAN: data-race in inet_unhash / inet_unhash write to 0xffff8880a69a0170 of 8 bytes by interrupt on cpu 1: __hlist_nulls_del include/linux/list_nulls.h:88 [inline] hlist_nulls_del_init_rcu include/linux/rculist_nulls.h:36 [inline] __sk_nulls_del_node_init_rcu include/net/sock.h:676 [inline] inet_unhash+0x38f/0x4a0 net/ipv4/inet_hashtables.c:612 tcp_set_state+0xfa/0x3e0 net/ipv4/tcp.c:2249 tcp_done+0x93/0x1e0 net/ipv4/tcp.c:3854 tcp_write_err+0x7e/0xc0 net/ipv4/tcp_timer.c:56 tcp_retransmit_timer+0x9b8/0x16d0 net/ipv4/tcp_timer.c:479 tcp_write_timer_handler+0x42d/0x510 net/ipv4/tcp_timer.c:599 tcp_write_timer+0xd1/0xf0 net/ipv4/tcp_timer.c:619 call_timer_fn+0x5f/0x2f0 kernel/time/timer.c:1404 expire_timers kernel/time/timer.c:1449 [inline] __run_timers kernel/time/timer.c:1773 [inline] __run_timers kernel/time/timer.c:1740 [inline] run_timer_softirq+0xc0c/0xcd0 kernel/time/timer.c:1786 __do_softirq+0x115/0x33f kernel/softirq.c:292 invoke_softirq kernel/softirq.c:373 [inline] irq_exit+0xbb/0xe0 kernel/softirq.c:413 exiting_irq arch/x86/include/asm/apic.h:536 [inline] smp_apic_timer_interrupt+0xe6/0x280 arch/x86/kernel/apic/apic.c:1137 apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:830 native_safe_halt+0xe/0x10 arch/x86/kernel/paravirt.c:71 arch_cpu_idle+0x1f/0x30 arch/x86/kernel/process.c:571 default_idle_call+0x1e/0x40 kernel/sched/idle.c:94 cpuidle_idle_call kernel/sched/idle.c:154 [inline] do_idle+0x1af/0x280 kernel/sched/idle.c:263 cpu_startup_entry+0x1b/0x20 kernel/sched/idle.c:355 start_secondary+0x208/0x260 arch/x86/kernel/smpboot.c:264 secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:241 read to 0xffff8880a69a0170 of 8 bytes by interrupt on cpu 0: sk_unhashed include/net/sock.h:607 [inline] inet_unhash+0x3d/0x4a0 net/ipv4/inet_hashtables.c:592 tcp_set_state+0xfa/0x3e0 net/ipv4/tcp.c:2249 tcp_done+0x93/0x1e0 net/ipv4/tcp.c:3854 tcp_write_err+0x7e/0xc0 net/ipv4/tcp_timer.c:56 tcp_retransmit_timer+0x9b8/0x16d0 net/ipv4/tcp_timer.c:479 tcp_write_timer_handler+0x42d/0x510 net/ipv4/tcp_timer.c:599 tcp_write_timer+0xd1/0xf0 net/ipv4/tcp_timer.c:619 call_timer_fn+0x5f/0x2f0 kernel/time/timer.c:1404 expire_timers kernel/time/timer.c:1449 [inline] __run_timers kernel/time/timer.c:1773 [inline] __run_timers kernel/time/timer.c:1740 [inline] run_timer_softirq+0xc0c/0xcd0 kernel/time/timer.c:1786 __do_softirq+0x115/0x33f kernel/softirq.c:292 invoke_softirq kernel/softirq.c:373 [inline] irq_exit+0xbb/0xe0 kernel/softirq.c:413 exiting_irq arch/x86/include/asm/apic.h:536 [inline] smp_apic_timer_interrupt+0xe6/0x280 arch/x86/kernel/apic/apic.c:1137 apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:830 native_safe_halt+0xe/0x10 arch/x86/kernel/paravirt.c:71 arch_cpu_idle+0x1f/0x30 arch/x86/kernel/process.c:571 default_idle_call+0x1e/0x40 kernel/sched/idle.c:94 cpuidle_idle_call kernel/sched/idle.c:154 [inline] do_idle+0x1af/0x280 kernel/sched/idle.c:263 cpu_startup_entry+0x1b/0x20 kernel/sched/idle.c:355 rest_init+0xec/0xf6 init/main.c:452 arch_call_rest_init+0x17/0x37 start_kernel+0x838/0x85e init/main.c:786 x86_64_start_reservations+0x29/0x2b arch/x86/kernel/head64.c:490 x86_64_start_kernel+0x72/0x76 arch/x86/kernel/head64.c:471 secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:241 Reported by Kernel Concurrency Sanitizer on: CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.4.0-rc6+ #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 ------------------------------------------------------------------------ This commit therefore replaces C-language assignments with WRITE_ONCE() in include/linux/list_nulls.h and include/linux/rculist_nulls.h. Reported-by: Eric Dumazet # For KCSAN Signed-off-by: Paul E. McKenney Signed-off-by: Sasha Levin commit 5650aaa1c72b8bf0f26d251d724b624ebdbb5ea7 Author: Ard Biesheuvel Date: Fri Jan 3 12:39:46 2020 +0100 efi/x86: Don't panic or BUG() on non-critical error conditions [ Upstream commit e2d68a955e49d61fd0384f23e92058dc9b79be5e ] The logic in __efi_enter_virtual_mode() does a number of steps in sequence, all of which may fail in one way or the other. In most cases, we simply print an error and disable EFI runtime services support, but in some cases, we BUG() or panic() and bring down the system when encountering conditions that we could easily handle in the same way. While at it, replace a pointless page-to-virt-phys conversion with one that goes straight from struct page to physical. Signed-off-by: Ard Biesheuvel Cc: Andy Lutomirski Cc: Ard Biesheuvel Cc: Arvind Sankar Cc: Matthew Garrett Cc: linux-efi@vger.kernel.org Link: https://lkml.kernel.org/r/20200103113953.9571-14-ardb@kernel.org Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit 2a0a4875ca2734ee60b2b8020028b63d728da312 Author: Dmitry Osipenko Date: Wed Dec 18 21:23:03 2019 +0300 soc/tegra: fuse: Correct straps' address for older Tegra124 device trees [ Upstream commit 2d9ea1934f8ef0dfb862d103389562cc28b4fc03 ] Trying to read out Chip ID before APBMISC registers are mapped won't succeed, in a result Tegra124 gets a wrong address for the HW straps register if machine uses an old outdated device tree. Fixes: 297c4f3dcbff ("soc/tegra: fuse: Restrict legacy code to 32-bit ARM") Signed-off-by: Dmitry Osipenko Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit 6f2ab530f9388664aeb59f2b73095dc41e195656 Author: Mike Marciniszyn Date: Mon Jan 6 08:42:35 2020 -0500 IB/hfi1: Add RcvShortLengthErrCnt to hfi1stats [ Upstream commit 2c9d4e26d1ab27ceae2ded2ffe930f8e5f5b2a89 ] This counter, RxShrErr, is required for error analysis and debug. Fixes: 7724105686e7 ("IB/hfi1: add driver files") Link: https://lore.kernel.org/r/20200106134235.119356.29123.stgit@awfm-01.aw.intel.com Reviewed-by: Kaike Wan Signed-off-by: Mike Marciniszyn Signed-off-by: Dennis Dalessandro Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit a6d80a20989c25376eafc0cbd4d0e88d19c8f411 Author: Mike Marciniszyn Date: Mon Jan 6 08:42:28 2020 -0500 IB/hfi1: Add software counter for ctxt0 seq drop [ Upstream commit 5ffd048698ea5139743acd45e8ab388a683642b8 ] All other code paths increment some form of drop counter. This was missed in the original implementation. Fixes: 82c2611daaf0 ("staging/rdma/hfi1: Handle packets with invalid RHF on context 0") Link: https://lore.kernel.org/r/20200106134228.119356.96828.stgit@awfm-01.aw.intel.com Reviewed-by: Kaike Wan Signed-off-by: Mike Marciniszyn Signed-off-by: Dennis Dalessandro Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit bc71f3684b6cd535c86586738394c8ca60af8cc4 Author: Arnd Bergmann Date: Sat Jan 4 22:48:21 2020 +0100 staging: rtl8188: avoid excessive stack usage [ Upstream commit c497ae2077c055b85c1bf04f3d182a84bd8f365b ] The rtl8188 copy of the os_dep support code causes a warning about a very significant stack usage in the translate_scan() function: drivers/staging/rtl8188eu/os_dep/ioctl_linux.c: In function 'translate_scan': drivers/staging/rtl8188eu/os_dep/ioctl_linux.c:306:1: error: the frame size of 1560 bytes is larger than 1400 bytes [-Werror=frame-larger-than=] Use the same trick as in the rtl8723bs copy of the same function, and allocate it dynamically. Signed-off-by: Arnd Bergmann Link: https://lore.kernel.org/r/20200104214832.558198-1-arnd@arndb.de Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 2776d3ad4d1ca662ae8ee0a61cf946076196fb55 Author: Yongqiang Niu Date: Fri Dec 13 15:28:51 2019 +0800 drm/mediatek: Add gamma property according to hardware capability [ Upstream commit 4cebc1de506fa753301266a5a23bb21bca52ad3a ] If there is no gamma function in the crtc display path, don't add gamma property for crtc Fixes: 2f3f4dda747c ("drm/mediatek: Add gamma correction.") Signed-off-by: Yongqiang Niu Signed-off-by: Hsin-Yi Wang Signed-off-by: CK Hu Signed-off-by: Sasha Levin commit 629cdd64db08966b430d254aaf9b7f7abd05c7ee Author: Alan Maguire Date: Mon Jan 6 22:28:21 2020 +0000 kunit: remove timeout dependence on sysctl_hung_task_timeout_seconds [ Upstream commit 1c024d45151b51c8f8d4749e65958b0bcf3e7c52 ] In discussion of how to handle timeouts, it was noted that if sysctl_hung_task_timeout_seconds is exceeded for a kunit test, the test task will be killed and an oops generated. This should suffice as a means of debugging such timeout issues for now. Hence remove use of sysctl_hung_task_timeout_secs, which has the added benefit of avoiding the need to export that symbol from the core kernel. Co-developed-by: Knut Omang Signed-off-by: Knut Omang Signed-off-by: Alan Maguire Reviewed-by: Stephen Boyd Acked-by: Brendan Higgins Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit 183a9d1c534fcb82f1e645f23a721d10e70d4b0a Author: Dan Carpenter Date: Wed Jan 8 08:46:29 2020 +0300 selftests: Uninitialized variable in test_cgcore_proc_migration() [ Upstream commit 192c197cbca599321de95a4cf15c2fa0681140d3 ] The "c_threads" variable is used in the error handling code before it has been initialized Fixes: 11318989c381 ("selftests: cgroup: Add task migration tests") Signed-off-by: Dan Carpenter Acked-by: Michal Koutný Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit 72472893c1aa8fa602da20846f9b4d8c950f03ea Author: Jan Kara Date: Tue Jan 7 16:36:49 2020 +0100 udf: Fix free space reporting for metadata and virtual partitions [ Upstream commit a4a8b99ec819ca60b49dc582a4287ef03411f117 ] Free space on filesystems with metadata or virtual partition maps currently gets misreported. This is because these partitions are just remapped onto underlying real partitions from which keep track of free blocks. Take this remapping into account when counting free blocks as well. Reviewed-by: Pali Rohár Reported-by: Pali Rohár Signed-off-by: Jan Kara Signed-off-by: Sasha Levin commit 8e1775196465dfe3b1d952fa4287b1932b57eb22 Author: Shuah Khan Date: Wed Jan 8 18:24:16 2020 -0700 usbip: Fix unsafe unaligned pointer usage [ Upstream commit 585c91f40d201bc564d4e76b83c05b3b5363fe7e ] Fix unsafe unaligned pointer usage in usbip network interfaces. usbip tool build fails with new gcc -Werror=address-of-packed-member checks. usbip_network.c: In function ‘usbip_net_pack_usb_device’: usbip_network.c:79:32: error: taking address of packed member of ‘struct usbip_usb_device’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 79 | usbip_net_pack_uint32_t(pack, &udev->busnum); Fix with minor changes to pass by value instead of by address. Signed-off-by: Shuah Khan Link: https://lore.kernel.org/r/20200109012416.2875-1-skhan@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 0ee39ed5546bfc2c46ac3d88a813f6f83e969104 Author: Benjamin Gaignard Date: Wed Jan 8 14:26:47 2020 +0100 ARM: dts: stm32: Add power-supply for DSI panel on stm32f469-disco [ Upstream commit 0ff15a86d0c5a3f004fee2e92d65b88e56a3bc58 ] Add a fixed regulator and use it as power supply for DSI panel. Fixes: 18c8866266 ("ARM: dts: stm32: Add display support on stm32f469-disco") Signed-off-by: Benjamin Gaignard Signed-off-by: Alexandre Torgue Signed-off-by: Sasha Levin commit 03f5b44df5b1615c6a108c08149a0edf763fa1e4 Author: Dmitry Torokhov Date: Fri Dec 13 09:46:23 2019 -0800 usb: dwc3: use proper initializers for property entries [ Upstream commit 5eb5afb07853d6e90d3a2b230c825e028e948f79 ] We should not be reaching into property entries and initialize them by hand, but rather use proper initializer macros. This way we can alter internal representation of property entries with no visible changes to their users. Reported-by: Marek Szyprowski Tested-by: Marek Szyprowski Signed-off-by: Dmitry Torokhov Acked-by: Hans de Goede Acked-by: Felipe Balbi Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 25847b41f2808fe7158e2ecd30c30596fd99a940 Author: Dingchen Zhang Date: Mon Jun 10 09:47:51 2019 -0400 drm: remove the newline for CRC source name. [ Upstream commit 72a848f5c46bab4c921edc9cbffd1ab273b2be17 ] userspace may transfer a newline, and this terminating newline is replaced by a '\0' to avoid followup issues. 'len-1' is the index to replace the newline of CRC source name. v3: typo fix (Sam) v2: update patch subject, body and format. (Sam) Cc: Leo Li Cc: Harry Wentland Cc: Sam Ravnborg Signed-off-by: Dingchen Zhang Reviewed-by: Sam Ravnborg Signed-off-by: Alex Deucher Link: https://patchwork.freedesktop.org/patch/msgid/20190610134751.14356-1-dingchen.zhang@amd.com Signed-off-by: Sasha Levin commit 55076034e9ae43b9fbe9414e0d30fa2623fa4afa Author: Wenpeng Liang Date: Mon Jan 6 20:21:10 2020 +0800 RDMA/hns: Avoid printing address of mtt page [ Upstream commit eca44507c3e908b7362696a4d6a11d90371334c6 ] Address of a page shouldn't be printed in case of security issues. Link: https://lore.kernel.org/r/1578313276-29080-2-git-send-email-liweihang@huawei.com Signed-off-by: Wenpeng Liang Signed-off-by: Weihang Li Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 33492740a6127eba287dc24a4f793fc0ffc5f71c Author: Arnd Bergmann Date: Sat Jan 4 22:51:44 2020 +0100 mlx5: work around high stack usage with gcc [ Upstream commit 42ae1a5c76691928ed217c7e40269db27f5225e9 ] In some configurations, gcc tries too hard to optimize this code: drivers/net/ethernet/mellanox/mlx5/core/en_stats.c: In function 'mlx5e_grp_sw_update_stats': drivers/net/ethernet/mellanox/mlx5/core/en_stats.c:302:1: error: the frame size of 1336 bytes is larger than 1024 bytes [-Werror=frame-larger-than=] As was stated in the bug report, the reason is that gcc runs into a corner case in the register allocator that is rather hard to fix in a good way. As there is an easy way to work around it, just add a comment and the barrier that stops gcc from trying to overoptimize the function. Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92657 Cc: Adhemerval Zanella Signed-off-by: Arnd Bergmann Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit 3845a7caa20a4075bf6088b3b275971f94fad1f9 Author: Felix Kuehling Date: Thu Dec 19 22:36:55 2019 -0500 drm/amdkfd: Fix permissions of hang_hws [ Upstream commit 2bdac179e217a0c0b548a8c60524977586621b19 ] Reading from /sys/kernel/debug/kfd/hang_hws would cause a kernel oops because we didn't implement a read callback. Set the permission to write-only to prevent that. Signed-off-by: Felix Kuehling Reviewed-by: shaoyunl Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit dd99c14ecd91f47cfc0b3188e4f2e76b01cc4443 Author: Jacob Pan Date: Thu Jan 2 08:18:09 2020 +0800 iommu/vt-d: Avoid sending invalid page response [ Upstream commit 5f75585e19cc7018bf2016aa771632081ee2f313 ] Page responses should only be sent when last page in group (LPIG) or private data is present in the page request. This patch avoids sending invalid descriptors. Fixes: 5d308fc1ecf53 ("iommu/vt-d: Add 256-bit invalidation descriptor support") Signed-off-by: Jacob Pan Reviewed-by: Eric Auger Signed-off-by: Lu Baolu Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 9b5b3ee264f942fd1934e788fc7cb822e1f35bca Author: Jacob Pan Date: Thu Jan 2 08:18:04 2020 +0800 iommu/vt-d: Match CPU and IOMMU paging mode [ Upstream commit 79db7e1b4cf2a006f556099c13de3b12970fc6e3 ] When setting up first level page tables for sharing with CPU, we need to ensure IOMMU can support no less than the levels supported by the CPU. It is not adequate, as in the current code, to set up 5-level paging in PASID entry First Level Paging Mode(FLPM) solely based on CPU. Currently, intel_pasid_setup_first_level() is only used by native SVM code which already checks paging mode matches. However, future use of this helper function may not be limited to native SVM. https://lkml.org/lkml/2019/11/18/1037 Fixes: 437f35e1cd4c8 ("iommu/vt-d: Add first level page table interface") Signed-off-by: Jacob Pan Reviewed-by: Eric Auger Signed-off-by: Lu Baolu Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 3b6916c11004d1ca9398aecb245f2aa31229ba91 Author: Jason Ekstrand Date: Thu Jan 2 14:27:54 2020 -0600 ACPI: button: Add DMI quirk for Razer Blade Stealth 13 late 2019 lid switch [ Upstream commit 0528904926aab19bffb2068879aa44db166c6d5f ] Running evemu-record on the lid switch event shows that the lid reports the first "close" but then never reports an "open". This causes systemd to continuously re-suspend the laptop every 30s. Resetting the _LID to "open" fixes the issue. Signed-off-by: Jason Ekstrand Reviewed-by: Hans de Goede Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit b8f775d0eed8e19bfea386c83e4517c963ce7157 Author: Sam McNally Date: Fri Jan 3 12:50:19 2020 +1100 ASoC: Intel: sof_rt5682: Ignore the speaker amp when there isn't one. [ Upstream commit d4b74e218a8d0d6cf58e546627ab9d4d4f2645ab ] Some members of the Google_Hatch family include a rt5682 jack codec, but no speaker amplifier. This uses the same driver (sof_rt5682) as a combination of rt5682 jack codec and max98357a speaker amplifier. Within the sof_rt5682 driver, these cases are not currently distinguishable, relying on a DMI quirk to decide the configuration. This causes an incorrect configuration when only the rt5682 is present on a Google_Hatch device. For CML, the jack codec is used as the primary key when matching, with a possible speaker amplifier described in quirk_data. The two cases of interest are the second and third 10EC5682 entries in snd_soc_acpi_intel_cml_machines[]. The second entry matches the combination of rt5682 and max98357a, resulting in the quirk_data field in the snd_soc_acpi_mach being non-null, pointing at max98357a_spk_codecs, the snd_soc_acpi_codecs for the matched speaker amplifier. The third entry matches just the rt5682, resulting in a null quirk_data. The sof_rt5682 driver's DMI data matching identifies that a speaker amplifier is present for all Google_Hatch family devices. Detect cases where there is no speaker amplifier by checking for a null quirk_data in the snd_soc_acpi_mach and remove the speaker amplifier bit in that case. Signed-off-by: Sam McNally Acked-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20200103124921.v3.1.Ib87c4a7fbb3fc818ea12198e291b87dc2d5bc8c2@changeid Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit f9df37019ed3b1ca5903813dd3a9687af5967ea8 Author: Alexey Kardashevskiy Date: Mon Dec 23 12:09:27 2019 +1100 vfio/spapr/nvlink2: Skip unpinning pages on error exit [ Upstream commit 338b4e10f939a71194d8ecef7ece205a942cec05 ] The nvlink2 subdriver for IBM Witherspoon machines preregisters GPU memory in the IOMMI API so KVM TCE code can map this memory for DMA as well. This is done by mm_iommu_newdev() called from vfio_pci_nvgpu_regops::mmap. In an unlikely event of failure the data->mem remains NULL and since mm_iommu_put() (which unregisters the region and unpins memory if that was regular memory) does not expect mem=NULL, it should not be called. This adds a check to only call mm_iommu_put() for a valid data->mem. Fixes: 7f92891778df ("vfio_pci: Add NVIDIA GV100GL [Tesla V100 SXM2] subdriver") Signed-off-by: Alexey Kardashevskiy Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit 42dbab0ca8efcc30859b2ec15b12c8bf85a00de2 Author: Andrey Zhizhikin Date: Wed Dec 11 08:01:09 2019 +0000 tools lib api fs: Fix gcc9 stringop-truncation compilation error [ Upstream commit 6794200fa3c9c3e6759dae099145f23e4310f4f7 ] GCC9 introduced string hardening mechanisms, which exhibits the error during fs api compilation: error: '__builtin_strncpy' specified bound 4096 equals destination size [-Werror=stringop-truncation] This comes when the length of copy passed to strncpy is is equal to destination size, which could potentially lead to buffer overflow. There is a need to mitigate this potential issue by limiting the size of destination by 1 and explicitly terminate the destination with NULL. Signed-off-by: Andrey Zhizhikin Reviewed-by: Petr Mladek Acked-by: Jiri Olsa Cc: Alexei Starovoitov Cc: Andrii Nakryiko Cc: Daniel Borkmann Cc: Kefeng Wang Cc: Martin KaFai Lau Cc: Petr Mladek Cc: Sergey Senozhatsky Cc: Song Liu Cc: Yonghong Song Cc: bpf@vger.kernel.org Cc: netdev@vger.kernel.org Link: http://lore.kernel.org/lkml/20191211080109.18765-1-andrey.zhizhikin@leica-geosystems.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 43aadaf6eff9b1555ba26d2545a8842c1204b034 Author: Dmitry Torokhov Date: Thu Jan 2 17:03:19 2020 -0800 net: phy: fixed_phy: fix use-after-free when checking link GPIO [ Upstream commit d266f19f3ae7fbcaf92229639b78d2110ae44f33 ] If we fail to locate GPIO for any reason other than deferral or not-found-GPIO, we try to print device tree node info, however if might be freed already as we called of_node_put() on it. Acked-by: David S. Miller Signed-off-by: Dmitry Torokhov Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 79861be01c5b11361bd86e00b09a4633b31fd7b2 Author: Takashi Iwai Date: Sun Jan 5 15:48:23 2020 +0100 ALSA: sh: Fix compile warning wrt const [ Upstream commit f1dd4795b1523fbca7ab4344dd5a8bb439cc770d ] A long-standing compile warning was seen during build test: sound/sh/aica.c: In function 'load_aica_firmware': sound/sh/aica.c:521:25: warning: passing argument 2 of 'spu_memload' discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers] Fixes: 198de43d758c ("[ALSA] Add ALSA support for the SEGA Dreamcast PCM device") Link: https://lore.kernel.org/r/20200105144823.29547-69-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 5e329c90de80634306b88055c7c6cc7bddc6109e Author: Takashi Iwai Date: Sun Jan 5 09:11:19 2020 +0100 ALSA: hda/realtek - Apply mic mute LED quirk for Dell E7xx laptops, too [ Upstream commit 5fab5829674c279839a7408ab30c71c6dfe726b9 ] Dell E7xx laptops have also mic mute LED that is driven by the dell-laptop platform driver. Bind it with the capture control as already done for other models. A caveat is that the fixup hook for the mic mute LED has to be applied at last, otherwise it results in the invalid override of the callback. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=205529 Link: https://lore.kernel.org/r/20200105081119.21396-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 5b72bb01bccf7439f9d69a3094b99f431220b95f Author: Kunihiko Hayashi Date: Fri Dec 27 10:42:05 2019 +0900 clk: uniphier: Add SCSSI clock gate for each channel [ Upstream commit 1ec09a2ec67a0baa46a3ccac041dbcdbc6db2cb9 ] SCSSI has clock gates for each channel in the SoCs newer than Pro4, so this adds missing clock gates for channel 1, 2 and 3. And more, this moves MCSSI clock ID after SCSSI. Fixes: ff388ee36516 ("clk: uniphier: add clock frequency support for SPI") Signed-off-by: Kunihiko Hayashi Acked-by: Masahiro Yamada Link: https://lkml.kernel.org/r/1577410925-22021-1-git-send-email-hayashi.kunihiko@socionext.com Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 76cc8bb46b96485d2e10547797600fda498e8d86 Author: Stephen Boyd Date: Mon Dec 30 10:29:35 2019 -0800 clk: Use parent node pointer during registration if necessary [ Upstream commit 9011f92622e5ef2d075f45e5fa818776d4feb8c0 ] Sometimes clk drivers are attached to devices which are children of a parent device that is connected to a node in DT. This happens when devices are MFD-ish and the parent device driver mostly registers child devices to match against drivers placed in their respective subsystem directories like drivers/clk, drivers/regulator, etc. When the clk driver calls clk_register() with a device pointer, that struct device pointer won't have a device_node associated with it because it was created purely in software as a way to partition logic to a subsystem. This causes problems for the way we find parent clks for the clks registered by these child devices because we look at the registering device's device_node pointer to lookup 'clocks' and 'clock-names' properties. Let's use the parent device's device_node pointer if the registering device doesn't have a device_node but the parent does. This simplifies clk registration code by avoiding the need to assign some device_node to the device registering the clk. Cc: Bjorn Andersson Reported-by: Niklas Cassel Signed-off-by: Stephen Boyd Link: https://lkml.kernel.org/r/20191230190455.141339-1-sboyd@kernel.org [sboyd@kernel.org: Fixup kernel-doc notation] Reviewed-by: Niklas Cassel Reviewed-by: Bjorn Andersson Tested-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 1f85ea289449d84b5411ea55a8325b5ae3dc7ec1 Author: Takashi Iwai Date: Sat Jan 4 12:00:57 2020 +0100 ALSA: sh: Fix unused variable warnings [ Upstream commit 5da116f164ce265e397b8f59af5c39e4a61d61a5 ] Remove unused variables that are left over after the conversion of new PCM ops: sound/sh/sh_dac_audio.c:166:26: warning: unused variable 'runtime' sound/sh/sh_dac_audio.c:186:26: warning: unused variable 'runtime' sound/sh/sh_dac_audio.c:205:26: warning: unused variable 'runtime' Fixes: 1cc2f8ba0b3e ("ALSA: sh: Convert to the new PCM ops") Link: https://lore.kernel.org/r/20200104110057.13875-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit bd70f02310783a797043b13ff8cf2578d6ef01d0 Author: Icenowy Zheng Date: Fri Jan 3 22:35:03 2020 -0800 clk: sunxi-ng: add mux and pll notifiers for A64 CPU clock [ Upstream commit ec97faff743b398e21f74a54c81333f3390093aa ] The A64 PLL_CPU clock has the same instability if some factor changed without the PLL gated like other SoCs with sun6i-style CCU, e.g. A33, H3. Add the mux and pll notifiers for A64 CPU clock to workaround the problem. Fixes: c6a0637460c2 ("clk: sunxi-ng: Add A64 clocks") Signed-off-by: Icenowy Zheng Signed-off-by: Vasily Khoruzhick Signed-off-by: Maxime Ripard Signed-off-by: Sasha Levin commit 38a7658375a102143ec3bde759d48df97813c009 Author: Mitch Williams Date: Thu Dec 12 03:13:05 2019 -0800 ice: add extra check for null Rx descriptor [ Upstream commit 1f45ebe0d8fbe6178670b663005f38ef8535db5d ] In the case where the hardware gives us a null Rx descriptor, it is theoretically possible that we could call one of our skb-construction functions with no data pointer, which would cause a panic. In real life, this will never happen - we only get null RX descriptors as the final descriptor in a chain of otherwise-valid descriptors. When this happens, the skb will be extant and we'll just call ice_add_rx_frag(), which can deal with empty data buffers. Unfortunately, Coverity does not have intimate knowledge of our hardware, so we must add a check here. Signed-off-by: Mitch Williams Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin commit b73dcb6cfae78a24388d1ecdb8848e2c2a21c574 Author: Jiewei Ke Date: Fri Dec 27 19:36:13 2019 +0800 RDMA/rxe: Fix error type of mmap_offset [ Upstream commit 6ca18d8927d468c763571f78c9a7387a69ffa020 ] The type of mmap_offset should be u64 instead of int to match the type of mminfo.offset. If otherwise, after we create several thousands of CQs, it will run into overflow issues. Link: https://lore.kernel.org/r/20191227113613.5020-1-kejiewei.cn@gmail.com Signed-off-by: Jiewei Ke Reviewed-by: Jason Gunthorpe Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 375918c0ea8137a8aacae5a1703334ae7cb62c26 Author: Peter Rosin Date: Tue Aug 27 11:09:16 2019 +0000 fbdev: fix numbering of fbcon options [ Upstream commit fd933c00ebe220060e66fb136a7050a242456566 ] Three shall be the number thou shalt count, and the number of the counting shall be three. Four shalt thou not count... One! Two! Five! Fixes: efb985f6b265 ("[PATCH] fbcon: Console Rotation - Add framebuffer console documentation") Signed-off-by: Peter Rosin Reviewed-by: Geert Uytterhoeven Cc: Jonathan Corbet Cc: Matthew Wilcox Signed-off-by: Bartlomiej Zolnierkiewicz Link: https://patchwork.freedesktop.org/patch/msgid/20190827110854.12574-2-peda@axentia.se Signed-off-by: Sasha Levin commit 92f2b0478613d2fdffce04f7747be8d8dd5df88e Author: Pierre-Louis Bossart Date: Thu Jan 2 13:59:52 2020 -0600 ASoC: soc-topology: fix endianness issues [ Upstream commit 72bbeda0222bcd382ee33b3aff71346074410c21 ] Sparse complains about a series of easy warnings, fix. Signed-off-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20200102195952.9465-3-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit a1436eb19c88e98eefcdc485480971270314f753 Author: Kunihiko Hayashi Date: Fri Nov 29 13:19:19 2019 +0900 reset: uniphier: Add SCSSI reset control for each channel [ Upstream commit f4aec227e985e31d2fdc5608daf48e3de19157b7 ] SCSSI has reset controls for each channel in the SoCs newer than Pro4, so this adds missing reset controls for channel 1, 2 and 3. And more, this moves MCSSI reset ID after SCSSI. Fixes: 6b39fd590aeb ("reset: uniphier: add reset control support for SPI") Signed-off-by: Kunihiko Hayashi Acked-by: Masahiro Yamada Signed-off-by: Philipp Zabel Signed-off-by: Sasha Levin commit 764bc83b8b8221d0b6589cfa814e3a2a603b2aca Author: Geert Uytterhoeven Date: Wed Dec 18 20:48:10 2019 +0100 pinctrl: sh-pfc: sh7269: Fix CAN function GPIOs [ Upstream commit 02aeb2f21530c98fc3ca51028eda742a3fafbd9f ] pinmux_func_gpios[] contains a hole due to the missing function GPIO definition for the "CTX0&CTX1" signal, which is the logical "AND" of the first two CAN outputs. A closer look reveals other issues: - Some functionality is available on alternative pins, but the PINMUX_DATA() entries is using the wrong marks, - Several configurations are missing. Fix this by: - Renaming CTX0CTX1CTX2_MARK, CRX0CRX1_PJ22_MARK, and CRX0CRX1CRX2_PJ20_MARK to CTX0_CTX1_CTX2_MARK, CRX0_CRX1_PJ22_MARK, resp. CRX0_CRX1_CRX2_PJ20_MARK for consistency with the corresponding enum IDs, - Adding all missing enum IDs and marks, - Use the right (*_PJ2x) variants for alternative pins, - Adding all missing configurations to pinmux_data[], - Adding all missing function GPIO definitions to pinmux_func_gpios[]. See SH7268 Group, SH7269 Group User’s Manual: Hardware, Rev. 2.00: [1] Table 1.4 List of Pins [2] Figure 23.29 Connection Example when Using Channels 0 and 1 as One Channel (64 Mailboxes × 1 Channel) and Channel 2 as One Channel (32 Mailboxes × 1 Channel), [3] Figure 23.30 Connection Example when Using Channels 0, 1, and 2 as One Channel (96 Mailboxes × 1 Channel), [4] Table 48.3 Multiplexed Pins (Port B), [5] Table 48.4 Multiplexed Pins (Port C), [6] Table 48.10 Multiplexed Pins (Port J), [7] Section 48.2.4 Port B Control Registers 0 to 5 (PBCR0 to PBCR5). Signed-off-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/20191218194812.12741-5-geert+renesas@glider.be Signed-off-by: Sasha Levin commit 6c74fcb485744b28a524b15e55235aaaa5f9b478 Author: Manasi Navare Date: Wed Dec 11 13:24:33 2019 -0800 drm/fbdev: Fallback to non tiled mode if all tiles not present [ Upstream commit f25c7a006cd1c07254780e3406e45cee4842b933 ] In case of tiled displays, if we hotplug just one connector, fbcon currently just selects the preferred mode and if it is tiled mode then that becomes a problem if rest of the tiles are not present. So in the fbdev driver on hotplug when we probe the client modeset, if we dont find all the connectors for all tiles, then on a connector with one tile, just fallback to the first available non tiled mode to display over a single connector. On the hotplug of the consecutive tiled connectors, if the tiled mode no longer exists because of fbcon size limitation, then return no modes for consecutive tiles but retain the non tiled mode on the 0th tile. Use the same logic in case of connected boot case as well. This has been tested with Dell UP328K tiled monitor. v2: * Set the modes on consecutive hotplugged tiles to no mode if tiled mode is pruned (Dave) v1: * Just handle the 1st connector hotplug case * v1 Reviewed-by: Dave Airlie Suggested-by: Ville Syrjälä Suggested-by: Dave Airlie Cc: Ville Syrjälä Cc: Dave Airlie Signed-off-by: Manasi Navare Reviewed-by: Dave Airlie Link: https://patchwork.freedesktop.org/patch/msgid/20191113222952.9231-1-manasi.d.navare@intel.com Signed-off-by: Sasha Levin commit 5b4ab0153929ccdcb1b1072139d562aabf090a0b Author: Chanwoo Choi Date: Thu Dec 12 11:20:30 2019 +0900 PM / devfreq: rk3399_dmc: Add COMPILE_TEST and HAVE_ARM_SMCCC dependency [ Upstream commit eff5d31f7407fa9d31fb840106f1593399457298 ] To build test, add COMPILE_TEST depedency to both ARM_RK3399_DMC_DEVFREQ and DEVFREQ_EVENT_ROCKCHIP_DFI configuration. And ARM_RK3399_DMC_DEVFREQ used the SMCCC interface so that add HAVE_ARM_SMCCC dependency to prevent the build break. Reported-by: kbuild test robot Signed-off-by: Chanwoo Choi Signed-off-by: Sasha Levin commit dec6ed3d5a8a2e3a17563fc471ff320b1068814d Author: Kamil Konieczny Date: Thu Dec 5 15:55:25 2019 +0100 PM / devfreq: Change time stats to 64-bit [ Upstream commit b76b3479dab948bea0a98b6d263eb56d8f358528 ] Change time stats counting to bigger type by using 64-bit jiffies. This will make devfreq stats code look similar to cpufreq stats and prevents overflow (for HZ = 1000 after 49.7 days). Signed-off-by: Kamil Konieczny Acked-by: Chanwoo Choi Signed-off-by: Chanwoo Choi Signed-off-by: Sasha Levin commit a1651f8355a611d0877a5fe5fd057d6813bf5e67 Author: Arnd Bergmann Date: Tue Oct 22 16:26:48 2019 +0200 PM / devfreq: exynos-ppmu: Fix excessive stack usage [ Upstream commit d4556f5e99d5f603913bac01adaff8670cb2d08b ] Putting a 'struct devfreq_event_dev' object on the stack is generally a bad idea and here it leads to a warnig about potential stack overflow: drivers/devfreq/event/exynos-ppmu.c:643:12: error: stack frame size of 1040 bytes in function 'exynos_ppmu_probe' [-Werror,-Wframe-larger-than=] There is no real need for the device structure, only the string inside it, so add an internal helper function that simply takes the string as its argument and remove the device structure. Fixes: 1dd62c66d345 ("PM / devfreq: events: extend events by type of counted data") Signed-off-by: Arnd Bergmann [cw00.choi: Fix the issue from 'desc->name' to 'desc[j].name'] Signed-off-by: Chanwoo Choi Signed-off-by: Sasha Levin commit 07a579e07d6d69ff5de51bfb375e58fef1ac7f8b Author: Valdis Kletnieks Date: Thu Dec 5 21:36:07 2019 -0500 x86/vdso: Provide missing include file [ Upstream commit bff47c2302cc249bcd550b17067f8dddbd4b6f77 ] When building with C=1, sparse issues a warning: CHECK arch/x86/entry/vdso/vdso32-setup.c arch/x86/entry/vdso/vdso32-setup.c:28:28: warning: symbol 'vdso32_enabled' was not declared. Should it be static? Provide the missing header file. Signed-off-by: Valdis Kletnieks Signed-off-by: Borislav Petkov Cc: "H. Peter Anvin" Cc: Andy Lutomirski Cc: Ingo Molnar Cc: Thomas Gleixner Cc: x86-ml Link: https://lkml.kernel.org/r/36224.1575599767@turing-police Signed-off-by: Sasha Levin commit dd80257220f636f683f3356bdd79a5a3f210a36e Author: Vinay Kumar Yadav Date: Thu Dec 19 16:21:48 2019 +0530 crypto: chtls - Fixed memory leak [ Upstream commit 93e23eb2ed6c11b4f483c8111ac155ec2b1f3042 ] Freed work request skbs when connection terminates. enqueue_wr()/ dequeue_wr() is shared between softirq and application contexts, should be protected by socket lock. Moved dequeue_wr() to appropriate file. Signed-off-by: Vinay Kumar Yadav Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 85e9e5220d1bcfbaa2b8452a9014786947731237 Author: Martin Blumenstingl Date: Thu Dec 26 19:51:47 2019 +0100 net: phy: realtek: add logging for the RGMII TX delay configuration [ Upstream commit 3aec743d69822d22d4a5b60deb9518ed8be6fa67 ] RGMII requires a delay of 2ns between the data and the clock signal. There are at least three ways this can happen. One possibility is by having the PHY generate this delay. This is a common source for problems (for example with slow TX speeds or packet loss when sending data). The TX delay configuration of the RTL8211F PHY can be set either by pin-strappping the RXD1 pin (HIGH means enabled, LOW means disabled) or through configuring a paged register. The setting from the RXD1 pin is also reflected in the register. Add debug logging to the TX delay configuration on RTL8211F so it's easier to spot these issues (for example if the TX delay is enabled for both, the RTL8211F PHY and the MAC). This is especially helpful because there is no public datasheet for the RTL8211F PHY available with all the RX/TX delay specifics. Signed-off-by: Martin Blumenstingl Reviewed-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 07001f08a9957abb3ab5848ff5bfa4198a8d6341 Author: Hechao Li Date: Mon Dec 23 17:17:42 2019 -0800 bpf: Print error message for bpftool cgroup show [ Upstream commit 1162f844030ac1ac7321b5e8f6c9badc7a11428f ] Currently, when bpftool cgroup show has an error, no error message is printed. This is confusing because the user may think the result is empty. Before the change: $ bpftool cgroup show /sys/fs/cgroup ID AttachType AttachFlags Name $ echo $? 255 After the change: $ ./bpftool cgroup show /sys/fs/cgroup Error: can't query bpf programs attached to /sys/fs/cgroup: Operation not permitted v2: Rename check_query_cgroup_progs to cgroup_has_attached_progs Signed-off-by: Hechao Li Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20191224011742.3714301-1-hechaol@fb.com Signed-off-by: Sasha Levin commit 7ac78dd1e0992fd6d2ae375cc0dd6456c632f605 Author: Sascha Hauer Date: Mon Dec 16 11:53:28 2019 +0100 dmaengine: imx-sdma: Fix memory leak [ Upstream commit 02939cd167095f16328a1bd5cab5a90b550606df ] The current descriptor is not on any list of the virtual DMA channel. Once sdma_terminate_all() is called when a descriptor is currently in flight then this one is forgotten to be freed. We have to call vchan_terminate_vdesc() on this descriptor to re-add it to the lists. Now that we also free the currently running descriptor we can (and actually have to) remove the current descriptor from its list also for the cyclic case. Signed-off-by: Sascha Hauer Reviewed-by: Robin Gong Tested-by: Robin Gong Link: https://lore.kernel.org/r/20191216105328.15198-10-s.hauer@pengutronix.de Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit dfce2b70f599ecbbf5b597928085d4d86038aa31 Author: YueHaibing Date: Fri Nov 29 03:35:34 2019 +0000 clk: bm1800: Remove set but not used variable 'fref' [ Upstream commit 59ef4da4e4084d323dd4c3aa4b2fc64ce9e25625 ] Fixes gcc '-Wunused-but-set-variable' warning: drivers/clk/clk-bm1880.c: In function 'bm1880_pll_rate_calc': drivers/clk/clk-bm1880.c:477:13: warning: variable 'fref' set but not used [-Wunused-but-set-variable] It is never used, so remove it. Reported-by: Hulk Robot Signed-off-by: YueHaibing Link: https://lkml.kernel.org/r/20191129033534.188257-1-yuehaibing@huawei.com Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 19ada40db8d60945303e1c43e85f60d076942e0f Author: Logan Gunthorpe Date: Mon Dec 16 12:01:16 2019 -0700 dmaengine: Store module owner in dma_device struct [ Upstream commit dae7a589c18a4d979d5f14b09374e871b995ceb1 ] dma_chan_to_owner() dereferences the driver from the struct device to obtain the owner and call module_[get|put](). However, if the backing device is unbound before the dma_device is unregistered, the driver will be cleared and this will cause a NULL pointer dereference. Instead, store a pointer to the owner module in the dma_device struct so the module reference can be properly put when the channel is put, even if the backing device was destroyed first. This change helps to support a safer unbind of DMA engines. If the dma_device is unregistered in the driver's remove function, there's no guarantee that there are no existing clients and a users action may trigger the WARN_ONCE in dma_async_device_unregister() which is unlikely to leave the system in a consistent state. Instead, a better approach is to allow the backing driver to go away and fail any subsequent requests to it. Signed-off-by: Logan Gunthorpe Link: https://lore.kernel.org/r/20191216190120.21374-2-logang@deltatee.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit ee86150aceb2a848003a8d173a79a258bc64577d Author: Jerome Brunet Date: Tue Sep 24 14:39:52 2019 +0200 clk: actually call the clock init before any other callback of the clock [ Upstream commit f6fa75ca912be6021335de63a32aa4d295f3c524 ] __clk_init_parent() will call the .get_parent() callback of the clock so .init() must run before. Fixes: 541debae0adf ("clk: call the clock init() callback before any other ops callback") Signed-off-by: Jerome Brunet Link: https://lkml.kernel.org/r/20190924123954.31561-2-jbrunet@baylibre.com Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit c150545ba725f3ac0847e89bc2b5f7bc5c1053cf Author: Jeffrey Hugo Date: Tue Dec 17 08:49:13 2019 -0800 clk: qcom: Add missing msm8998 gcc_bimc_gfx_clk [ Upstream commit db2c7c0a04b11753f5741d00b784b5380ddeee72 ] gcc_bimc_gfx_clk is a required clock for booting the GPU and GPU SMMU. Fixes: 4807c71cc688 (arm64: dts: Add msm8998 SoC and MTP board support) Signed-off-by: Jeffrey Hugo Link: https://lkml.kernel.org/r/20191217164913.4783-1-jeffrey.l.hugo@gmail.com Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 96eb0740a31d280b503ae2b0f8b67be019cb68f1 Author: Qian Cai Date: Fri Nov 22 14:16:54 2019 -0500 iommu/iova: Silence warnings under memory pressure [ Upstream commit 944c9175397476199d4dd1028d87ddc582c35ee8 ] When running heavy memory pressure workloads, this 5+ old system is throwing endless warnings below because disk IO is too slow to recover from swapping. Since the volume from alloc_iova_fast() could be large, once it calls printk(), it will trigger disk IO (writing to the log files) and pending softirqs which could cause an infinite loop and make no progress for days by the ongoimng memory reclaim. This is the counter part for Intel where the AMD part has already been merged. See the commit 3d708895325b ("iommu/amd: Silence warnings under memory pressure"). Since the allocation failure will be reported in intel_alloc_iova(), so just call dev_err_once() there because even the "ratelimited" is too much, and silence the one in alloc_iova_mem() to avoid the expensive warn_alloc(). hpsa 0000:03:00.0: DMAR: Allocating 1-page iova failed hpsa 0000:03:00.0: DMAR: Allocating 1-page iova failed hpsa 0000:03:00.0: DMAR: Allocating 1-page iova failed hpsa 0000:03:00.0: DMAR: Allocating 1-page iova failed hpsa 0000:03:00.0: DMAR: Allocating 1-page iova failed hpsa 0000:03:00.0: DMAR: Allocating 1-page iova failed hpsa 0000:03:00.0: DMAR: Allocating 1-page iova failed hpsa 0000:03:00.0: DMAR: Allocating 1-page iova failed slab_out_of_memory: 66 callbacks suppressed SLUB: Unable to allocate memory on node -1, gfp=0xa20(GFP_ATOMIC) cache: iommu_iova, object size: 40, buffer size: 448, default order: 0, min order: 0 node 0: slabs: 1822, objs: 16398, free: 0 node 1: slabs: 2051, objs: 18459, free: 31 SLUB: Unable to allocate memory on node -1, gfp=0xa20(GFP_ATOMIC) cache: iommu_iova, object size: 40, buffer size: 448, default order: 0, min order: 0 node 0: slabs: 1822, objs: 16398, free: 0 node 1: slabs: 2051, objs: 18459, free: 31 SLUB: Unable to allocate memory on node -1, gfp=0xa20(GFP_ATOMIC) cache: iommu_iova, object size: 40, buffer size: 448, default order: 0, min order: 0 SLUB: Unable to allocate memory on node -1, gfp=0xa20(GFP_ATOMIC) SLUB: Unable to allocate memory on node -1, gfp=0xa20(GFP_ATOMIC) SLUB: Unable to allocate memory on node -1, gfp=0xa20(GFP_ATOMIC) SLUB: Unable to allocate memory on node -1, gfp=0xa20(GFP_ATOMIC) SLUB: Unable to allocate memory on node -1, gfp=0xa20(GFP_ATOMIC) cache: skbuff_head_cache, object size: 208, buffer size: 640, default order: 0, min order: 0 cache: skbuff_head_cache, object size: 208, buffer size: 640, default order: 0, min order: 0 cache: skbuff_head_cache, object size: 208, buffer size: 640, default order: 0, min order: 0 cache: skbuff_head_cache, object size: 208, buffer size: 640, default order: 0, min order: 0 node 0: slabs: 697, objs: 4182, free: 0 node 0: slabs: 697, objs: 4182, free: 0 node 0: slabs: 697, objs: 4182, free: 0 node 0: slabs: 697, objs: 4182, free: 0 node 1: slabs: 381, objs: 2286, free: 27 node 1: slabs: 381, objs: 2286, free: 27 node 1: slabs: 381, objs: 2286, free: 27 node 1: slabs: 381, objs: 2286, free: 27 node 0: slabs: 1822, objs: 16398, free: 0 cache: skbuff_head_cache, object size: 208, buffer size: 640, default order: 0, min order: 0 node 1: slabs: 2051, objs: 18459, free: 31 node 0: slabs: 697, objs: 4182, free: 0 SLUB: Unable to allocate memory on node -1, gfp=0xa20(GFP_ATOMIC) node 1: slabs: 381, objs: 2286, free: 27 cache: skbuff_head_cache, object size: 208, buffer size: 640, default order: 0, min order: 0 node 0: slabs: 697, objs: 4182, free: 0 node 1: slabs: 381, objs: 2286, free: 27 hpsa 0000:03:00.0: DMAR: Allocating 1-page iova failed warn_alloc: 96 callbacks suppressed kworker/11:1H: page allocation failure: order:0, mode:0xa20(GFP_ATOMIC), nodemask=(null),cpuset=/,mems_allowed=0-1 CPU: 11 PID: 1642 Comm: kworker/11:1H Tainted: G B Hardware name: HP ProLiant XL420 Gen9/ProLiant XL420 Gen9, BIOS U19 12/27/2015 Workqueue: kblockd blk_mq_run_work_fn Call Trace: dump_stack+0xa0/0xea warn_alloc.cold.94+0x8a/0x12d __alloc_pages_slowpath+0x1750/0x1870 __alloc_pages_nodemask+0x58a/0x710 alloc_pages_current+0x9c/0x110 alloc_slab_page+0xc9/0x760 allocate_slab+0x48f/0x5d0 new_slab+0x46/0x70 ___slab_alloc+0x4ab/0x7b0 __slab_alloc+0x43/0x70 kmem_cache_alloc+0x2dd/0x450 SLUB: Unable to allocate memory on node -1, gfp=0xa20(GFP_ATOMIC) alloc_iova+0x33/0x210 cache: skbuff_head_cache, object size: 208, buffer size: 640, default order: 0, min order: 0 node 0: slabs: 697, objs: 4182, free: 0 alloc_iova_fast+0x62/0x3d1 node 1: slabs: 381, objs: 2286, free: 27 intel_alloc_iova+0xce/0xe0 intel_map_sg+0xed/0x410 scsi_dma_map+0xd7/0x160 scsi_queue_rq+0xbf7/0x1310 blk_mq_dispatch_rq_list+0x4d9/0xbc0 blk_mq_sched_dispatch_requests+0x24a/0x300 __blk_mq_run_hw_queue+0x156/0x230 blk_mq_run_work_fn+0x3b/0x40 process_one_work+0x579/0xb90 worker_thread+0x63/0x5b0 kthread+0x1e6/0x210 ret_from_fork+0x3a/0x50 Mem-Info: active_anon:2422723 inactive_anon:361971 isolated_anon:34403 active_file:2285 inactive_file:1838 isolated_file:0 unevictable:0 dirty:1 writeback:5 unstable:0 slab_reclaimable:13972 slab_unreclaimable:453879 mapped:2380 shmem:154 pagetables:6948 bounce:0 free:19133 free_pcp:7363 free_cma:0 Signed-off-by: Qian Cai Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 2156666568e91289068dbf037598bb40d830ba0b Author: Suravee Suthikulpanit Date: Wed Nov 20 07:55:49 2019 -0600 iommu/amd: Only support x2APIC with IVHD type 11h/40h [ Upstream commit 966b753cf3969553ca50bacd2b8c4ddade5ecc9e ] Current implementation for IOMMU x2APIC support makes use of the MMIO access to MSI capability block registers, which requires checking EFR[MsiCapMmioSup]. However, only IVHD type 11h/40h contain the information, and not in the IVHD type 10h IOMMU feature reporting field. Since the BIOS in newer systems, which supports x2APIC, would normally contain IVHD type 11h/40h, remove the IOMMU_FEAT_XTSUP_SHIFT check for IVHD type 10h, and only support x2APIC with IVHD type 11h/40h. Fixes: 66929812955b ('iommu/amd: Add support for X2APIC IOMMU interrupts') Signed-off-by: Suravee Suthikulpanit Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 1f1d48331ac0989ea082eec148693e4c9d834feb Author: Suravee Suthikulpanit Date: Wed Nov 20 07:55:48 2019 -0600 iommu/amd: Check feature support bit before accessing MSI capability registers [ Upstream commit 813071438e83d338ba5cfe98b3b26c890dc0a6c0 ] The IOMMU MMIO access to MSI capability registers is available only if the EFR[MsiCapMmioSup] is set. Current implementation assumes this bit is set if the EFR[XtSup] is set, which might not be the case. Fix by checking the EFR[MsiCapMmioSup] before accessing the MSI address low/high and MSI data registers via the MMIO. Fixes: 66929812955b ('iommu/amd: Add support for X2APIC IOMMU interrupts') Signed-off-by: Suravee Suthikulpanit Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 08bd511fe94577d962eb48dca90a2ebc3dcd3a15 Author: Greg Kroah-Hartman Date: Thu Dec 19 12:03:39 2019 +0000 PCI/ATS: Restore EXPORT_SYMBOL_GPL() for pci_{enable,disable}_ats() [ Upstream commit bb950bca5d522119f8b9ce3f6cbac4841c6d6517 ] Commit d355bb209783 ("PCI/ATS: Remove unnecessary EXPORT_SYMBOL_GPL()") unexported a bunch of symbols from the PCI core since the only external users were non-modular IOMMU drivers. Although most of those symbols can remain private for now, 'pci_{enable,disable_ats()' is required for the ARM SMMUv3 driver to build as a module, otherwise we get a build failure as follows: | ERROR: "pci_enable_ats" [drivers/iommu/arm-smmu-v3.ko] undefined! | ERROR: "pci_disable_ats" [drivers/iommu/arm-smmu-v3.ko] undefined! Re-export these two functions so that the ARM SMMUv3 driver can be build as a module. Cc: Bjorn Helgaas Cc: Joerg Roedel Signed-off-by: Greg Kroah-Hartman [will: rewrote commit message] Signed-off-by: Will Deacon Tested-by: John Garry # smmu v3 Reviewed-by: Greg Kroah-Hartman Acked-by: Bjorn Helgaas Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 2dd3bdfb84225e352c7568ae7b45c44904870094 Author: Bjorn Andersson Date: Wed Nov 13 15:22:45 2019 -0800 arm64: dts: qcom: db845c: Enable ath10k 8bit host-cap quirk [ Upstream commit 2e198c395a084ff3015d71896e35de049c40e3a4 ] The WiFi firmware used on db845c implements the 8bit host-capability message, so enable the quirk for this. Reviewed-by: Jeffrey Hugo Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20191113232245.4039932-1-bjorn.andersson@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit eab841df2c5fe61df47c3baa4a53f935b63f5d58 Author: James Smart Date: Wed Dec 18 15:58:00 2019 -0800 scsi: lpfc: Fix: Rework setting of fdmi symbolic node name registration [ Upstream commit df9166bfa7750bade5737ffc91fbd432e0354442 ] This patch reworks the fdmi symbolic node name data for the following two issues: - Correcting extraneous periods following the DV and HN fdmi data fields. - Avoiding buffer overflow issues when formatting the data. The fix to the fist issue is to just remove the characters. The fix to the second issue has all data being staged in temporary storage before being moved to the real buffer. Link: https://lore.kernel.org/r/20191218235808.31922-3-jsmart2021@gmail.com Signed-off-by: Dick Kennedy Signed-off-by: James Smart Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 8e77bca3232e85f1cdb6dfd40680c6f7001f5719 Author: Jaihind Yadav Date: Tue Dec 17 17:25:47 2019 +0530 selinux: ensure we cleanup the internal AVC counters on error in avc_update() [ Upstream commit 030b995ad9ece9fa2d218af4429c1c78c2342096 ] In AVC update we don't call avc_node_kill() when avc_xperms_populate() fails, resulting in the avc->avc_cache.active_nodes counter having a false value. In last patch this changes was missed , so correcting it. Fixes: fa1aa143ac4a ("selinux: extended permissions for ioctls") Signed-off-by: Jaihind Yadav Signed-off-by: Ravi Kumar Siddojigari [PM: merge fuzz, minor description cleanup] Signed-off-by: Paul Moore Signed-off-by: Sasha Levin commit 3efbcdca59a1d78406a7022698b91be31de95af8 Author: Sibi Sankar Date: Wed Dec 18 18:52:13 2019 +0530 remoteproc: q6v5-mss: Remove mem clk from the active pool [ Upstream commit 6ba519aa13758dd55248f3a6f939536656df2661 ] Currently the mem clk is voted upon from both the active and proxy pool on MSM8998 SoCs where only a proxy vote should suffice. Fix this by removing mem clk from the active pool. Fixes: 1665cbd5731fa ("remoteproc: qcom_q6v5_mss: Add support for MSM8998") Signed-off-by: Sibi Sankar Link: https://lore.kernel.org/r/20191218132217.28141-2-sibis@codeaurora.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit e57a55261ddce5d1339b0c9633f4693ce89d91fa Author: Geert Uytterhoeven Date: Wed Dec 11 14:52:21 2019 +0100 ARM: dts: r8a7779: Add device node for ARM global timer [ Upstream commit 8443ffd1bbd5be74e9b12db234746d12e8ea93e2 ] Add a device node for the global timer, which is part of the Cortex-A9 MPCore. The global timer can serve as an accurate (4 ns) clock source for scheduling and delay loops. Signed-off-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/20191211135222.26770-4-geert+renesas@glider.be Signed-off-by: Sasha Levin commit 1442712069e4a793ac6fb7eb12b5d6aa5e8142b9 Author: Sergei Shtylyov Date: Fri Sep 27 21:09:21 2019 +0300 clk: renesas: rcar-gen3: Allow changing the RPC[D2] clocks [ Upstream commit 0d67c0340a60829c5c1b7d09629d23bbd67696f3 ] I was unable to get clk_set_rate() setting a lower RPC-IF clock frequency and that issue boiled down to me not passing CLK_SET_RATE_PARENT flag to clk_register_composite() when registering the RPC[D2] clocks... Fixes: db4a0073cc82 ("clk: renesas: rcar-gen3: Add RPC clocks") Signed-off-by: Sergei Shtylyov Link: https://lore.kernel.org/r/be27a344-d8bf-9e0c-8950-2d1b48498496@cogentembedded.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit a5d1f407b8b80f66d969136ed84994c9a8c3bb42 Author: Bibby Hsieh Date: Tue Dec 10 13:05:21 2019 +0800 drm/mediatek: handle events when enabling/disabling crtc [ Upstream commit 411f5c1eacfebb1f6e40b653d29447cdfe7282aa ] The driver currently handles vblank events only when updating planes on an already enabled CRTC. The atomic update API however allows requesting an event when enabling or disabling a CRTC. This currently leads to event objects being leaked in the kernel and to events not being sent out. Fix it. Signed-off-by: Bibby Hsieh Signed-off-by: CK Hu Signed-off-by: Sasha Levin commit b1ddaae4052fec9d9d0858482138981df8a55724 Author: Brendan Higgins Date: Wed Dec 11 11:27:40 2019 -0800 crypto: amlogic - add unspecified HAS_IOMEM dependency [ Upstream commit 7d07de2c18abd95f72efb28f78a4825e0fc1aa6a ] Currently CONFIG_CRYPTO_DEV_AMLOGIC_GXL=y implicitly depends on CONFIG_HAS_IOMEM=y; consequently, on architectures without IOMEM we get the following build error: ld: drivers/crypto/amlogic/amlogic-gxl-core.o: in function `meson_crypto_probe': drivers/crypto/amlogic/amlogic-gxl-core.c:240: undefined reference to `devm_platform_ioremap_resource' Fix the build error by adding the unspecified dependency. Reported-by: Brendan Higgins Signed-off-by: Brendan Higgins Acked-by: Corentin Labbe Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit f00153e7cf292eb16fc2ea498c117863035733b8 Author: Brendan Higgins Date: Wed Dec 11 11:27:39 2019 -0800 crypto: inside-secure - add unspecified HAS_IOMEM dependency [ Upstream commit 6dc0e310623fdcb27a1486eb436f0118c45e95a5 ] Currently CONFIG_CRYPTO_DEV_SAFEXCEL=y implicitly depends on CONFIG_HAS_IOMEM=y; consequently, on architectures without IOMEM we get the following build error: ld: drivers/crypto/inside-secure/safexcel.o: in function `safexcel_probe': drivers/crypto/inside-secure/safexcel.c:1692: undefined reference to `devm_platform_ioremap_resource' Fix the build error by adding the unspecified dependency. Reported-by: Brendan Higgins Signed-off-by: Brendan Higgins Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit d896da6fab47b3a526f86e8be040ebf6b8b172b9 Author: Nathan Chancellor Date: Tue Dec 17 18:42:20 2019 -0700 scsi: aic7xxx: Adjust indentation in ahc_find_syncrate [ Upstream commit 4dbc96ad65c45cdd4e895ed7ae4c151b780790c5 ] Clang warns: ../drivers/scsi/aic7xxx/aic7xxx_core.c:2317:5: warning: misleading indentation; statement is not part of the previous 'if' [-Wmisleading-indentation] if ((syncrate->sxfr_u2 & ST_SXFR) != 0) ^ ../drivers/scsi/aic7xxx/aic7xxx_core.c:2310:4: note: previous statement is here if (syncrate == &ahc_syncrates[maxsync]) ^ 1 warning generated. This warning occurs because there is a space amongst the tabs on this line. Remove it so that the indentation is consistent with the Linux kernel coding style and clang no longer warns. This has been a problem since the beginning of git history hence no fixes tag. Link: https://github.com/ClangBuiltLinux/linux/issues/817 Link: https://lore.kernel.org/r/20191218014220.52746-1-natechancellor@gmail.com Signed-off-by: Nathan Chancellor Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit ca07ebc5557e0e2d8dd53b3ba362fac17b955ebc Author: Can Guo Date: Mon Nov 25 22:53:33 2019 -0800 scsi: ufs: Complete pending requests in host reset and restore path [ Upstream commit 2df74b6985b51e77756e2e8faa16c45ca3ba53c5 ] In UFS host reset and restore path, before probe, we stop and start the host controller once. After host controller is stopped, the pending requests, if any, are cleared from the doorbell, but no completion IRQ would be raised due to the hba is stopped. These pending requests shall be completed along with the first NOP_OUT command (as it is the first command which can raise a transfer completion IRQ) sent during probe. Since the OCSs of these pending requests are not SUCCESS (because they are not yet literally finished), their UPIUs shall be dumped. When there are multiple pending requests, the UPIU dump can be overwhelming and may lead to stability issues because it is in atomic context. Therefore, before probe, complete these pending requests right after host controller is stopped and silence the UPIU dump from them. Link: https://lore.kernel.org/r/1574751214-8321-5-git-send-email-cang@qti.qualcomm.com Reviewed-by: Alim Akhtar Reviewed-by: Bean Huo Tested-by: Bean Huo Signed-off-by: Can Guo Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 13867ddd80ea314230527f05d1a4a628a8ed2eaa Author: Trond Myklebust Date: Wed Dec 18 14:57:23 2019 -0500 nfsd: Clone should commit src file metadata too [ Upstream commit 57f64034966fb945fc958f95f0c51e47af590344 ] vfs_clone_file_range() can modify the metadata on the source file too, so we need to commit that to stable storage as well. Reported-by: Dave Chinner Signed-off-by: Trond Myklebust Acked-by: Dave Chinner Signed-off-by: J. Bruce Fields Signed-off-by: Sasha Levin commit 51c1d030fffb7e1fbfcf4f8c16e6d600e7534237 Author: Erik Kaneda Date: Tue Dec 17 11:35:20 2019 -0800 ACPICA: Disassembler: create buffer fields in ACPI_PARSE_LOAD_PASS1 [ Upstream commit 5ddbd77181dfca61b16d2e2222382ea65637f1b9 ] ACPICA commit 29cc8dbc5463a93625bed87d7550a8bed8913bf4 create_buffer_field is a deferred op that is typically processed in load pass 2. However, disassembly of control method contents walk the parse tree with ACPI_PARSE_LOAD_PASS1 and AML_CREATE operators are processed in a later walk. This is a problem when there is a control method that has the same name as the AML_CREATE object. In this case, any use of the name segment will be detected as a method call rather than a reference to a buffer field. If this is detected as a method call, it can result in a mal-formed parse tree if the control methods have parameters. This change in processing AML_CREATE ops earlier solves this issue by inserting the named object in the ACPI namespace so that references to this name would be detected as a name string rather than a method call. Link: https://github.com/acpica/acpica/commit/29cc8dbc Reported-by: Elia Geretto Tested-by: Elia Geretto Signed-off-by: Bob Moore Signed-off-by: Erik Kaneda Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 29ed00f49f59f352c8ee75406d0da666a4ebf433 Author: Jeffrey Hugo Date: Tue Dec 17 08:54:09 2019 -0800 clk: qcom: smd: Add missing bimc clock [ Upstream commit 87ec9adcca71801a44ddb311185b17df09839ab5 ] It turns out booting the modem is dependent on a bimc vote from Linux on msm8998. To make the modem happy, add the bimc clock to rely on the default vote from rpmcc. Once we have interconnect support, bimc should be controlled properly. Fixes: 6131dc81211c ("clk: qcom: smd: Add support for MSM8998 rpm clocks") Signed-off-by: Jeffrey Hugo Link: https://lkml.kernel.org/r/20191217165409.4919-1-jeffrey.l.hugo@gmail.com Reviewed-by: Bjorn Andersson Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 7429e7ff873c77044f4d714633e9bd8578063c06 Author: Monk Liu Date: Tue Dec 17 18:16:44 2019 +0800 drm/amdgpu: fix KIQ ring test fail in TDR of SRIOV [ Upstream commit 5a7489a7e189ee2be889485f90c8cf24ea4b9a40 ] issues: MEC is ruined by the amdkfd_pre_reset after VF FLR done fix: amdkfd_pre_reset() would ruin MEC after hypervisor finished the VF FLR, the correct sequence is do amdkfd_pre_reset before VF FLR but there is a limitation to block this sequence: if we do pre_reset() before VF FLR, it would go KIQ way to do register access and stuck there, because KIQ probably won't work by that time (e.g. you already made GFX hang) so the best way right now is to simply remove it. Signed-off-by: Monk Liu Reviewed-by: Emily Deng Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 02dbc003c9661ad05059aad49bf9bd29f4fb9ef9 Author: Monk Liu Date: Tue Dec 17 18:18:31 2019 +0800 drm/amdgpu: fix double gpu_recovery for NV of SRIOV [ Upstream commit 1512d064f55bace6a8e32d65009c7ea112e76a31 ] issues: gpu_recover() is re-entered by the mailbox interrupt handler mxgpu_nv.c fix: we need to bypass the gpu_recover() invoke in mailbox interrupt as long as the timeout is not infinite (thus the TDR will be triggered automatically after time out, no need to invoke gpu_recover() through mailbox interrupt. Signed-off-by: Monk Liu Reviewed-by: Emily Deng Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 36a36d16067e3c6b863e68837ef4046ed43bcdb5 Author: Sung Lee Date: Wed Dec 4 18:36:07 2019 -0500 drm/amd/display: Lower DPP DTO only when safe [ Upstream commit 5479034576ec8b7166a66efe5de1d911feb43d4a ] [Why] A corner case currently exists where DPP DTO is lowered before pipes are updated to a higher viewport. This causes underflow as the DPPCLK is too low for the current viewport. [How] Only lower DPP DTO when it is safe to lower, or if the newer clocks are higher than the current ones. Signed-off-by: Sung Lee Reviewed-by: Dmytro Laktyushkin Reviewed-by: Tony Cheng Acked-by: Rodrigo Siqueira Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 5ede16d673b71aaaaa4629de2ffea8d3747df4ea Author: Sung Lee Date: Mon Dec 2 16:45:16 2019 -0500 drm/amd/display: Fix update_bw_bounding_box Calcs [ Upstream commit 615b9b585eb57c1d49382d16a62de768f2c6a340 ] [Why] Previously update_bw_bounding_box for RN was commented out due to incorrect values causing BSOD on Hybrid Graphics. However, commenting out this function also may cause issues such as underflow in certain cases such as 2x4K displays. [How] Fix dram_speed_mts calculations. Update from proper index of clock_limits[] Signed-off-by: Sung Lee Reviewed-by: Yongqiang Sun Acked-by: Rodrigo Siqueira Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 596f43ce68ff7b84c48a6f55b5b415f2ce901666 Author: Aditya Pakki Date: Sun Dec 15 13:58:58 2019 -0600 orinoco: avoid assertion in case of NULL pointer [ Upstream commit c705f9fc6a1736dcf6ec01f8206707c108dca824 ] In ezusb_init, if upriv is NULL, the code crashes. However, the caller in ezusb_probe can handle the error and print the failure message. The patch replaces the BUG_ON call to error return. Signed-off-by: Aditya Pakki Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit efcb9ffdf88572bbbf79bc942595a68a244ff48a Author: Phong Tran Date: Wed Nov 27 00:55:29 2019 +0700 rtlwifi: rtl_pci: Fix -Wcast-function-type [ Upstream commit cb775c88da5d48a85d99d95219f637b6fad2e0e9 ] correct usage prototype of callback in tasklet_init(). Report by https://github.com/KSPP/linux/issues/20 Signed-off-by: Phong Tran Reviewed-by: Kees Cook Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit 4a08c34ff9b937daff2c44c072e5c840f5108665 Author: Phong Tran Date: Wed Nov 27 00:55:28 2019 +0700 iwlegacy: Fix -Wcast-function-type [ Upstream commit da5e57e8a6a3e69dac2937ba63fa86355628fbb2 ] correct usage prototype of callback in tasklet_init(). Report by https://github.com/KSPP/linux/issues/20 Signed-off-by: Phong Tran Reviewed-by: Kees Cook Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit 7b2b1581aa1d682e34b12f8e10ba81fc883e4a57 Author: Phong Tran Date: Wed Nov 27 00:55:27 2019 +0700 ipw2x00: Fix -Wcast-function-type [ Upstream commit ebd77feb27e91bb5fe35a7818b7c13ea7435fb98 ] correct usage prototype of callback in tasklet_init(). Report by https://github.com/KSPP/linux/issues/20 Signed-off-by: Phong Tran Reviewed-by: Kees Cook Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit 60155e4aeb6fbe331625247118be181ef46d7c80 Author: Phong Tran Date: Wed Nov 27 00:55:26 2019 +0700 b43legacy: Fix -Wcast-function-type [ Upstream commit 475eec112e4267232d10f4afe2f939a241692b6c ] correct usage prototype of callback in tasklet_init(). Report by https://github.com/KSPP/linux/issues/20 Tested-by: Larry Finger Signed-off-by: Phong Tran Reviewed-by: Kees Cook Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit bc68d3530d5879dd367ef689d573cfbd9cb56a55 Author: James Sewart Date: Tue Dec 10 16:25:40 2019 -0600 PCI: Add DMA alias quirk for PLX PEX NTB [ Upstream commit 7b90dfc4873b87c468cc6046538f46a531c1d785 ] The PLX PEX NTB forwards DMA transactions using Requester IDs that don't exist as PCI devices. The devfn for a transaction is used as an index into a lookup table storing the origin of a transaction on the other side of the bridge. Alias all possible devfns to the NTB device so that any transaction coming in is governed by the mappings for the NTB. Signed-off-by: James Sewart Signed-off-by: Bjorn Helgaas Reviewed-by: Logan Gunthorpe Signed-off-by: Sasha Levin commit b66b480e7fdbc3dbf21ae0fd27076a2b8d26c2bc Author: James Sewart Date: Tue Dec 10 16:07:30 2019 -0600 PCI: Add nr_devfns parameter to pci_add_dma_alias() [ Upstream commit 09298542cd891b43778db1f65aa3613aa5a562eb ] Add a "nr_devfns" parameter to pci_add_dma_alias() so it can be used to create DMA aliases for a range of devfns. [bhelgaas: incorporate nr_devfns fix from James, update quirk_pex_vca_alias() and setup_aliases()] Signed-off-by: James Sewart Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin commit 5df6f3531533a10b149af5f8acf9f454d0080eae Author: Arnd Bergmann Date: Mon Oct 28 10:13:16 2019 +0100 nfs: fix timstamp debug prints [ Upstream commit 057f184b1245150b88e59997fc6f1af0e138d42e ] Starting in v5.5, the timestamps are correctly passed down as 64-bit seconds with NFSv4 on 32-bit machines, but some debug statements still truncate them to 'long'. Fixes: e86d5a02874c ("NFS: Convert struct nfs_fattr to use struct timespec64") Signed-off-by: Arnd Bergmann Signed-off-by: Sasha Levin commit 961034d5787da4bac97f4f31d78e05c592768eee Author: Nathan Chancellor Date: Tue Dec 17 20:42:57 2019 -0700 ALSA: usx2y: Adjust indentation in snd_usX2Y_hwdep_dsp_status [ Upstream commit df4654bd6e42125d9b85ce3a26eaca2935290b98 ] Clang warns: ../sound/usb/usx2y/usX2Yhwdep.c:122:3: warning: misleading indentation; statement is not part of the previous 'if' [-Wmisleading-indentation] info->version = USX2Y_DRIVER_VERSION; ^ ../sound/usb/usx2y/usX2Yhwdep.c:120:2: note: previous statement is here if (us428->chip_status & USX2Y_STAT_CHIP_INIT) ^ 1 warning generated. This warning occurs because there is a space before the tab on this line. Remove it so that the indentation is consistent with the Linux kernel coding style and clang no longer warns. This was introduced before the beginning of git history so no fixes tag. Link: https://github.com/ClangBuiltLinux/linux/issues/831 Signed-off-by: Nathan Chancellor Link: https://lore.kernel.org/r/20191218034257.54535-1-natechancellor@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 5a9b1bab8d6c5475b1eceb64d914901719bdb27a Author: Xin Long Date: Fri Dec 13 16:53:06 2019 +0800 netfilter: nft_tunnel: add the missing ERSPAN_VERSION nla_policy [ Upstream commit 0705f95c332081036d85f26691e9d3cd7d901c31 ] ERSPAN_VERSION is an attribute parsed in kernel side, nla_policy type should be added for it, like other attributes. Fixes: af308b94a2a4 ("netfilter: nf_tables: add tunnel support") Signed-off-by: Xin Long Reviewed-by: Simon Horman Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 13d92b69dfb1033c3451dfc9641f8415c065ce1d Author: Arnd Bergmann Date: Tue Dec 10 21:39:13 2019 +0100 x86/mce/therm_throt: Mark throttle_active_work() as __maybe_unused [ Upstream commit db1ae0314f47e88ae06679270adf17ffa245afd4 ] throttle_active_work() is only called if CONFIG_SYSFS is set, otherwise we get a harmless warning: arch/x86/kernel/cpu/mce/therm_throt.c:238:13: error: 'throttle_active_work' \ defined but not used [-Werror=unused-function] Mark the function as __maybe_unused to avoid the warning. Fixes: f6656208f04e ("x86/mce/therm_throt: Optimize notifications of thermal throttle") Signed-off-by: Arnd Bergmann Signed-off-by: Borislav Petkov Reviewed-by: Srinivas Pandruvada Cc: bberg@redhat.com Cc: ckellner@redhat.com Cc: Greg Kroah-Hartman Cc: hdegoede@redhat.com Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: linux-edac Cc: Thomas Gleixner Cc: Tony Luck Cc: x86-ml Link: https://lkml.kernel.org/r/20191210203925.3119091-1-arnd@arndb.de Signed-off-by: Sasha Levin commit 812b844299ddc53bc88da75d9f8f8347e5a7c0ab Author: Aditya Pakki Date: Sun Dec 15 10:14:51 2019 -0600 fore200e: Fix incorrect checks of NULL pointer dereference [ Upstream commit bbd20c939c8aa3f27fa30e86691af250bf92973a ] In fore200e_send and fore200e_close, the pointers from the arguments are dereferenced in the variable declaration block and then checked for NULL. The patch fixes these issues by avoiding NULL pointer dereferences. Signed-off-by: Aditya Pakki Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 6e2900369a3711d167255355758f984fd3cc2e6d Author: Heiner Kallweit Date: Fri Dec 13 16:53:37 2019 +0100 r8169: check that Realtek PHY driver module is loaded [ Upstream commit f325937735498afb054a0195291bbf68d0b60be5 ] Some users complained about problems with r8169 and it turned out that the generic PHY driver was used instead instead of the dedicated one. In all cases reason was that r8169.ko was in initramfs, but realtek.ko not. Manually adding realtek.ko to initramfs fixed the issues. Root cause seems to be that tools like dracut and genkernel don't consider softdeps. Add a check for loaded Realtek PHY driver module and provide the user with a hint if it's not loaded. Signed-off-by: Heiner Kallweit Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit d0f320b013efb52cee2ba1b7da85658d58f56dc5 Author: Toke Høiland-Jørgensen Date: Mon Dec 16 11:38:19 2019 +0100 samples/bpf: Set -fno-stack-protector when building BPF programs [ Upstream commit 450278977acbf494a20367c22fbb38729772d1fc ] It seems Clang can in some cases turn on stack protection by default, which doesn't work with BPF. This was reported once before[0], but it seems the flag to explicitly turn off the stack protector wasn't added to the Makefile, so do that now. The symptom of this is compile errors like the following: error: :0:0: in function bpf_prog1 i32 (%struct.__sk_buff*): A call to built-in function '__stack_chk_fail' is not supported. [0] https://www.spinics.net/lists/netdev/msg556400.html Signed-off-by: Toke Høiland-Jørgensen Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191216103819.359535-1-toke@redhat.com Signed-off-by: Sasha Levin commit b86a985b7960808b46c8f1b90e94925dadb56af6 Author: Jan Kara Date: Thu Dec 12 11:35:58 2019 +0100 reiserfs: Fix spurious unlock in reiserfs_fill_super() error handling [ Upstream commit 4d5c1adaf893b8aa52525d2b81995e949bcb3239 ] When we fail to allocate string for journal device name we jump to 'error' label which tries to unlock reiserfs write lock which is not held. Jump to 'error_unlocked' instead. Fixes: f32485be8397 ("reiserfs: delay reiserfs lock until journal initialization") Signed-off-by: Jan Kara Signed-off-by: Sasha Levin commit d157c377a8343d80627af84bf0ebb054cfb240df Author: Nathan Chancellor Date: Sun Dec 8 22:11:40 2019 +0100 media: v4l2-device.h: Explicitly compare grp{id,mask} to zero in v4l2_device macros [ Upstream commit afb34781620274236bd9fc9246e22f6963ef5262 ] When building with Clang + -Wtautological-constant-compare, several of the ivtv and cx18 drivers warn along the lines of: drivers/media/pci/cx18/cx18-driver.c:1005:21: warning: converting the result of '<<' to a boolean always evaluates to true [-Wtautological-constant-compare] cx18_call_hw(cx, CX18_HW_GPIO_RESET_CTRL, ^ drivers/media/pci/cx18/cx18-cards.h:18:37: note: expanded from macro 'CX18_HW_GPIO_RESET_CTRL' #define CX18_HW_GPIO_RESET_CTRL (1 << 6) ^ 1 warning generated. This warning happens because the shift operation is implicitly converted to a boolean in v4l2_device_mask_call_all before being negated. This can be solved by just comparing the mask result to 0 explicitly so that there is no boolean conversion. The ultimate goal is to enable -Wtautological-compare globally because there are several subwarnings that would be helpful to have. For visual consistency and avoidance of these warnings in the future, all of the implicitly boolean conversions in the v4l2_device macros are converted to explicit ones as well. Link: https://github.com/ClangBuiltLinux/linux/issues/752 Reviewed-by: Ezequiel Garcia Reviewed-by: Nick Desaulniers Signed-off-by: Nathan Chancellor Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 45657fe7e50196f673507c4d22fe2365d3fd73bf Author: Willem de Bruijn Date: Thu Dec 12 11:36:46 2019 -0500 selftests/net: make so_txtime more robust to timer variance [ Upstream commit ea6a547669b37453f2b1a5d85188d75b3613dfaa ] The SO_TXTIME test depends on accurate timers. In some virtualized environments the test has been reported to be flaky. This is easily reproduced by disabling kvm acceleration in Qemu. Allow greater variance in a run and retry to further reduce flakiness. Observed errors are one of two kinds: either the packet arrives too early or late at recv(), or it was dropped in the qdisc itself and the recv() call times out. In the latter case, the qdisc queues a notification to the error queue of the send socket. Also explicitly report this cause. Link: https://lore.kernel.org/netdev/CA+FuTSdYOnJCsGuj43xwV1jxvYsaoa_LzHQF9qMyhrkLrivxKw@mail.gmail.com Reported-by: Naresh Kamboju Signed-off-by: Willem de Bruijn Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 14382d1f5b43809c6ad32e9710a1f38bd708a0ac Author: Paul Cercueil Date: Tue Dec 10 15:41:38 2019 +0100 gpu/drm: ingenic: Avoid null pointer deference in plane atomic update [ Upstream commit 354b051c5dcbeb35bbfd5d54161364fc7a75a58a ] It is possible that there is no drm_framebuffer associated with a given plane state. v2: Handle drm_plane->state which can be NULL too Signed-off-by: Paul Cercueil Link: https://patchwork.freedesktop.org/patch/msgid/20191210144142.33143-2-paul@crapouillou.net # *** extracted tags *** Acked-by: Sam Ravnborg Signed-off-by: Sasha Levin commit 0a27a2afbb24e073198041a09b2716e9540a7e1a Author: Jakub Kicinski Date: Tue Dec 10 10:20:32 2019 -0800 Revert "nfp: abm: fix memory leak in nfp_abm_u32_knode_replace" [ Upstream commit 1d1997db870f4058676439ef7014390ba9e24eb2 ] This reverts commit 78beef629fd9 ("nfp: abm: fix memory leak in nfp_abm_u32_knode_replace"). The quoted commit does not fix anything and resulted in a bogus CVE-2019-19076. If match is NULL then it is known there is no matching entry in list, hence, calling nfp_abm_u32_knode_delete() is pointless. Signed-off-by: Jakub Kicinski Reviewed-by: John Hurley Signed-off-by: Sasha Levin commit 5913185024a8be28bc4c249cf5b07bfaa6db486e Author: Daniel Drake Date: Wed Nov 27 13:38:36 2019 +0800 PCI: Increase D3 delay for AMD Ryzen5/7 XHCI controllers [ Upstream commit 3030df209aa8cf831b9963829bd9f94900ee8032 ] On Asus UX434DA (AMD Ryzen7 3700U) and Asus X512DK (AMD Ryzen5 3500U), the XHCI controller fails to resume from runtime suspend or s2idle, and USB becomes unusable from that point. xhci_hcd 0000:03:00.4: Refused to change power state, currently in D3 xhci_hcd 0000:03:00.4: enabling device (0000 -> 0002) xhci_hcd 0000:03:00.4: WARN: xHC restore state timeout xhci_hcd 0000:03:00.4: PCI post-resume error -110! xhci_hcd 0000:03:00.4: HC died; cleaning up During suspend, a transition to D3cold is attempted, however the affected platforms do not seem to cut the power to the PCI device when in this state, so the device stays in D3hot. Upon resume, the D3hot-to-D0 transition is successful only if the D3 delay is increased to 20ms. The transition failure does not appear to be detectable as a CRS condition. Add a PCI quirk to increase the delay on the affected hardware. Link: https://bugzilla.kernel.org/show_bug.cgi?id=205587 Link: http://lkml.kernel.org/r/CAD8Lp47Vh69gQjROYG69=waJgL7hs1PwnLonL9+27S_TcRhixA@mail.gmail.com Link: https://lore.kernel.org/r/20191127053836.31624-2-drake@endlessm.com Signed-off-by: Daniel Drake Signed-off-by: Bjorn Helgaas Reviewed-by: Mika Westerberg Signed-off-by: Sasha Levin commit 72f213d5e928451ce8bfb93995235cdb5849115d Author: Daniel Drake Date: Wed Nov 27 13:38:35 2019 +0800 PCI: Add generic quirk for increasing D3hot delay [ Upstream commit 62fe23df067715a21c4aef44068efe7ceaa8f627 ] Separate the D3 delay increase functionality out of quirk_radeon_pm() into its own function so that it can be shared with other quirks, including the AMD Ryzen XHCI quirk that will be introduced in a followup commit. Tweak the function name and message to indicate more clearly that the delay relates to a D3hot-to-D0 transition. Link: https://lore.kernel.org/r/20191127053836.31624-1-drake@endlessm.com Signed-off-by: Daniel Drake Signed-off-by: Bjorn Helgaas Reviewed-by: Mika Westerberg Signed-off-by: Sasha Levin commit c300e43e8bfd1912d3eb619a5c623b17c286aa07 Author: Forest Crossman Date: Sat Nov 16 23:38:40 2019 +0100 media: cx23885: Add support for AVerMedia CE310B [ Upstream commit dc4cac67e13515835ed8081d510aa507aacb013b ] The AVerMedia CE310B is a simple composite + S-Video + stereo audio capture card, and uses only the CX23888 to perform all of these functions. I've tested both video inputs and the audio interface and confirmed that they're all working. However, there are some issues: * Sometimes when I switch inputs the video signal turns black and can't be recovered until the system is rebooted. I haven't been able to determine the cause of this behavior, nor have I found a solution to fix it or any workarounds other than rebooting. * The card sometimes seems to have trouble syncing to the video signal, and some of the VBI data appears as noise at the top of the frame, but I assume that to be a result of my very noisy RF environment and the card's unshielded input traces rather than a configuration issue. Signed-off-by: Forest Crossman Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 196f61f09f698227e1bef12f66c8b17c1746201d Author: Wei Liu Date: Wed Dec 11 17:45:11 2019 +0000 PCI: iproc: Apply quirk_paxc_bridge() for module as well as built-in [ Upstream commit 574f29036fce385e28617547955dd6911d375025 ] Previously quirk_paxc_bridge() was applied when the iproc driver was built-in, but not when it was compiled as a module. This happened because it was under #ifdef CONFIG_PCIE_IPROC_PLATFORM: PCIE_IPROC_PLATFORM=y causes CONFIG_PCIE_IPROC_PLATFORM to be defined, but PCIE_IPROC_PLATFORM=m causes CONFIG_PCIE_IPROC_PLATFORM_MODULE to be defined. Move quirk_paxc_bridge() to pcie-iproc.c and drop the #ifdef so the quirk is always applied, whether iproc is built-in or a module. [bhelgaas: commit log, move to pcie-iproc.c, not pcie-iproc-platform.c] Link: https://lore.kernel.org/r/20191211174511.89713-1-wei.liu@kernel.org Signed-off-by: Wei Liu Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin commit 20062ea22130c959a7954a86e0839022c36d9284 Author: Tony Lindgren Date: Thu Dec 12 08:57:58 2019 -0800 bus: ti-sysc: Implement quirk handling for CLKDM_NOAUTO [ Upstream commit 94f6345712b37e4bb23cb265ce4c65b9d177e75a ] For dra7 dcan and dwc3 instances we need to block clockdomain autoidle. Let's do this with CLKDM_NOAUTO quirk flag and enable it for dcan and dwc3. Cc: Keerthy Cc: Roger Quadros Cc: Tero Kristo Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin commit 487c47c6ddeb82b345b03cb11b83e62ae36573e6 Author: Lakshmi Ramasubramanian Date: Wed Dec 11 08:47:02 2019 -0800 IMA: Check IMA policy flag [ Upstream commit c5563bad88e07017e08cce1142903e501598c80c ] process_buffer_measurement() may be called prior to IMA being initialized (for instance, when the IMA hook is called when a key is added to the .builtin_trusted_keys keyring), which would result in a kernel panic. This patch adds the check in process_buffer_measurement() to return immediately if IMA is not initialized yet. Signed-off-by: Lakshmi Ramasubramanian Signed-off-by: Mimi Zohar Signed-off-by: Sasha Levin commit 3f3cc843b265e246e190c03638b5654b4e299338 Author: Andrey Smirnov Date: Mon Dec 9 08:50:18 2019 -0800 ARM: dts: imx6: rdu2: Limit USBH1 to Full Speed [ Upstream commit 6bb1e09c4c375db29770444f689f35f5cbe696bc ] Cabling used to connect devices to USBH1 on RDU2 does not meet USB spec cable quality and cable length requirements to operate at High Speed, so limit the port to Full Speed only. Reported-by: Chris Healy Reviewed-by: Chris Healy Reviewed-by: Lucas Stach Signed-off-by: Andrey Smirnov Cc: Shawn Guo Cc: Fabio Estevam Cc: Lucas Stach Cc: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 0de9b73e2cc5f57eac713cb8047d65348578998c Author: Andrey Smirnov Date: Mon Dec 9 08:50:17 2019 -0800 ARM: dts: imx6: rdu2: Disable WP for USDHC2 and USDHC3 [ Upstream commit cd58a174e58649426fb43d7456e5f7d7eab58af1 ] RDU2 production units come with resistor connecting WP pin to correpsonding GPIO DNPed for both SD card slots. Drop any WP related configuration and mark both slots with "disable-wp". Reported-by: Chris Healy Reviewed-by: Chris Healy Reviewed-by: Lucas Stach Signed-off-by: Andrey Smirnov Cc: Shawn Guo Cc: Fabio Estevam Cc: Lucas Stach Cc: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 65255322b983a41fd2f4aeaddb0c65b2a08ee18e Author: Krzysztof Kozlowski Date: Thu Dec 5 21:00:06 2019 +0100 ARM: exynos_defconfig: Bring back explicitly wanted options [ Upstream commit 9f9e2df2e64df197ff6548ef494f76be5b35d08a ] Few options KALLSYMS_ALL, SCSI, PM_DEVFREQ and mutex/spinlock debugging were removed with savedefconfig because they were selected by other options. However these are user-visible options and they might not be selected in the future. Exactly this happened with commit 0e4a459f56c3 ("tracing: Remove unnecessary DEBUG_FS dependency") removing the dependency between DEBUG_FS and TRACING. To avoid losing these options in the future, explicitly mention them in defconfig. Reported-by: Marek Szyprowski Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin commit 4949a57988ef6e654846913f40a0571014d1ba9c Author: Abel Vesa Date: Wed Dec 11 11:25:40 2019 +0200 clk: imx: Add correct failure handling for clk based helpers [ Upstream commit f60f1c62c3188fcca945581e35e3440ee3fdcc95 ] If the clk_hw based API returns an error, trying to return the clk from hw will end up in a NULL pointer dereference. So adding the to_clk checker and using it inside every clk based macro helper we handle that case correctly. This to_clk is also temporary and will go away along with the clk based macro helpers once there is no user that need them anymore. Signed-off-by: Abel Vesa Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 3f4d3d010477365ee1aefedc3ad52563740b777e Author: Daniel Jordan Date: Tue Dec 3 14:31:10 2019 -0500 padata: validate cpumask without removed CPU during offline [ Upstream commit 894c9ef9780c5cf2f143415e867ee39a33ecb75d ] Configuring an instance's parallel mask without any online CPUs... echo 2 > /sys/kernel/pcrypt/pencrypt/parallel_cpumask echo 0 > /sys/devices/system/cpu/cpu1/online ...makes tcrypt mode=215 crash like this: divide error: 0000 [#1] SMP PTI CPU: 4 PID: 283 Comm: modprobe Not tainted 5.4.0-rc8-padata-doc-v2+ #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20191013_105130-anatol 04/01/2014 RIP: 0010:padata_do_parallel+0x114/0x300 Call Trace: pcrypt_aead_encrypt+0xc0/0xd0 [pcrypt] crypto_aead_encrypt+0x1f/0x30 do_mult_aead_op+0x4e/0xdf [tcrypt] test_mb_aead_speed.constprop.0.cold+0x226/0x564 [tcrypt] do_test+0x28c2/0x4d49 [tcrypt] tcrypt_mod_init+0x55/0x1000 [tcrypt] ... cpumask_weight() in padata_cpu_hash() returns 0 because the mask has no CPUs. The problem is __padata_remove_cpu() checks for valid masks too early and so doesn't mark the instance PADATA_INVALID as expected, which would have made padata_do_parallel() return error before doing the division. Fix by introducing a second padata CPU hotplug state before CPUHP_BRINGUP_CPU so that __padata_remove_cpu() sees the online mask without @cpu. No need for the second argument to padata_replace() since @cpu is now already missing from the online mask. Fixes: 33e54450683c ("padata: Handle empty padata cpumasks") Signed-off-by: Daniel Jordan Cc: Eric Biggers Cc: Herbert Xu Cc: Sebastian Andrzej Siewior Cc: Steffen Klassert Cc: Thomas Gleixner Cc: linux-crypto@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 468615891566af22de448a5f6c94bfe895397001 Author: Manu Gautam Date: Mon Dec 9 16:15:01 2019 +0100 arm64: dts: qcom: msm8996: Disable USB2 PHY suspend by core [ Upstream commit d026c96b25b7ce5df89526aad2df988d553edb4d ] QUSB2 PHY on msm8996 doesn't work well when autosuspend by dwc3 core using USB2PHYCFG register is enabled. One of the issue seen is that PHY driver reports PLL lock failure and fails phy_init() if dwc3 core has USB2 PHY suspend enabled. Fix this by using quirks to disable USB2 PHY LPM/suspend and dwc3 core already takes care of explicitly suspending PHY during suspend if quirks are specified. Signed-off-by: Manu Gautam Signed-off-by: Paolo Pisati Link: https://lore.kernel.org/r/20191209151501.26993-1-p.pisati@gmail.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit ef27169ce0fc96dbd9e332d699bea8b686a4e587 Author: Chen Wandun Date: Tue Dec 10 18:24:50 2019 +0800 enetc: remove variable 'tc_max_sized_frame' set but not used [ Upstream commit 6525b5ef65fdaf8a782449fb5d585195b573c2c1 ] Fixes gcc '-Wunused-but-set-variable' warning: drivers/net/ethernet/freescale/enetc/enetc_qos.c: In function enetc_setup_tc_cbs: drivers/net/ethernet/freescale/enetc/enetc_qos.c:195:6: warning: variable tc_max_sized_frame set but not used [-Wunused-but-set-variable] Fixes: c431047c4efe ("enetc: add support Credit Based Shaper(CBS) for hardware offload") Signed-off-by: Chen Wandun Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 7b94c9965ca06e1944fddc1326273e4882846fbb Author: Paul Moore Date: Mon Dec 9 20:39:46 2019 -0500 selinux: ensure we cleanup the internal AVC counters on error in avc_insert() [ Upstream commit d8db60cb23e49a92cf8cada3297395c7fa50fdf8 ] Fix avc_insert() to call avc_node_kill() if we've already allocated an AVC node and the code fails to insert the node in the cache. Fixes: fa1aa143ac4a ("selinux: extended permissions for ioctls") Reported-by: rsiddoji@codeaurora.org Suggested-by: Stephen Smalley Acked-by: Stephen Smalley Signed-off-by: Paul Moore Signed-off-by: Sasha Levin commit 06389f62ef05ace90a0140966b6b4ed27848ddb3 Author: Viresh Kumar Date: Mon Nov 18 14:41:07 2019 +0530 opp: Free static OPPs on errors while adding them [ Upstream commit ba0033192145cbd4e70ef64552958b13d597eb9e ] The static OPPs aren't getting freed properly, if errors occur while adding them. Fix that by calling _put_opp_list_kref() and putting their reference on failures. Fixes: 11e1a1648298 ("opp: Don't decrement uninitialized list_kref") Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit 49d88337ac1466ea0266146c6fd75448d85b5701 Author: Andre Przywara Date: Thu Nov 21 01:18:35 2019 +0000 arm: dts: allwinner: H3: Add PMU node [ Upstream commit 0388a110747bec0c9d9de995842bb2a03a26aae1 ] Add the Performance Monitoring Unit (PMU) device tree node to the H3 .dtsi, which tells DT users which interrupts are triggered by PMU overflow events on each core. The numbers come from the manual and have been checked in U-Boot and with perf in Linux. Tested with perf record and taskset on an OrangePi Zero. Signed-off-by: Andre Przywara Signed-off-by: Maxime Ripard Signed-off-by: Sasha Levin commit 88ed7e6d5ca91511a165d93301614d7482778501 Author: Andre Przywara Date: Thu Nov 21 01:18:34 2019 +0000 arm64: dts: allwinner: H5: Add PMU node [ Upstream commit c35a516a46187c8eeb7a56c64505ec6f7e22a0c7 ] Add the Performance Monitoring Unit (PMU) device tree node to the H5 .dtsi, which tells DT users which interrupts are triggered by PMU overflow events on each core. As with the A64, the interrupt numbers from the manual were wrong (off by 4), the actual SPI IDs have been gathered in U-Boot, and were verified with perf in Linux. Tested with perf record and taskset on an OrangePi PC2. Signed-off-by: Andre Przywara Signed-off-by: Maxime Ripard Signed-off-by: Sasha Levin commit 053c6f33b390f859edd5093480bd9fc42bbed9d2 Author: Andre Przywara Date: Thu Nov 21 01:18:33 2019 +0000 arm64: dts: allwinner: H6: Add PMU mode [ Upstream commit 7aa9b9eb7d6a8fde7acbe0446444f7e3fae1fe3b ] Add the Performance Monitoring Unit (PMU) device tree node to the H6 .dtsi, which tells DT users which interrupts are triggered by PMU overflow events on each core. The numbers come from the manual and have been checked in U-Boot and with perf in Linux. Tested with perf record and taskset on a Pine H64. Signed-off-by: Andre Przywara Signed-off-by: Maxime Ripard Signed-off-by: Sasha Levin commit c2fc8c0f616fa03f5b91529fe27be5b933585e47 Author: Mao Wenan Date: Mon Dec 9 21:08:45 2019 +0800 NFC: port100: Convert cpu_to_le16(le16_to_cpu(E1) + E2) to use le16_add_cpu(). [ Upstream commit 718eae277e62a26e5862eb72a830b5e0fe37b04a ] Convert cpu_to_le16(le16_to_cpu(frame->datalen) + len) to use le16_add_cpu(), which is more concise and does the same thing. Reported-by: Hulk Robot Signed-off-by: Mao Wenan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 467c674cfa9bacdcd4ee097e093edd928f8f8003 Author: Thong Thai Date: Fri Dec 6 09:19:20 2019 -0500 Revert "drm/amdgpu: enable VCN DPG on Raven and Raven2" [ Upstream commit d515959125f24767d02e82587a11e444eeba0e7b ] This reverts commit a4840d91c984f93b2acdcd44441d624bbc1af0d2. Reverting due to power efficiency issues seen on Raven 1 and 2 when DPG mode is enabled. Signed-off-by: Thong Thai Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 76cb528725dbfbf0fc1ffb606abd74b9fcffac48 Author: Rasmus Villemoes Date: Thu Nov 28 15:55:51 2019 +0100 net/wan/fsl_ucc_hdlc: reject muram offsets above 64K [ Upstream commit 148587a59f6b85831695e0497d9dd1af5f0495af ] Qiang Zhao points out that these offsets get written to 16-bit registers, and there are some QE platforms with more than 64K muram. So it is possible that qe_muram_alloc() gives us an allocation that can't actually be used by the hardware, so detect and reject that. Reported-by: Qiang Zhao Reviewed-by: Timur Tabi Signed-off-by: Rasmus Villemoes Acked-by: David S. Miller Signed-off-by: Li Yang Signed-off-by: Sasha Levin commit c0317d74194fa96697f6c4bde0201e7300e0eaf5 Author: Miquel Raynal Date: Tue Dec 3 17:47:09 2019 +0100 regulator: rk808: Lower log level on optional GPIOs being not available [ Upstream commit b8a039d37792067c1a380dc710361905724b9b2f ] RK808 can leverage a couple of GPIOs to tweak the ramp rate during DVS (Dynamic Voltage Scaling). These GPIOs are entirely optional but a dev_warn() appeared when cleaning this driver to use a more up-to-date gpiod API. At least reduce the log level to 'info' as it is totally fine to not populate these GPIO on a hardware design. This change is trivial but it is worth not polluting the logs during bringup phase by having real warnings and errors sorted out correctly. Fixes: a13eaf02e2d6 ("regulator: rk808: make better use of the gpiod API") Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/r/20191203164709.11127-1-miquel.raynal@bootlin.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 2f6e40d606c6d5cefc0d3055ada93b42187207b0 Author: Bard Liao Date: Wed Dec 4 15:28:59 2019 -0600 ASoC: SOF: Intel: hda: solve MSI issues by merging ipc and stream irq handlers [ Upstream commit 7c11af9fcdc425b80f140a218d4fef9f17734bfc ] The existing code uses two handlers for a shared edge-based MSI interrupts. In corner cases, interrupts are lost, leading to IPC timeouts. Those timeouts do not appear in legacy mode. This patch merges the two handlers and threads into a single one, and simplifies the mask/unmask operations by using a single top-level mask (Global Interrupt Enable). The handler only checks for interrupt sources using the Global Interrupt Status (GIS) field, and all the actual work happens in the thread. This also enables us to remove the use of spin locks. Stream events are prioritized over IPC ones. This patch was tested with HDaudio and SoundWire platforms, and all known IPC timeout issues are solved in MSI mode. The SoundWire-specific patches will be provided in follow-up patches, where the SoundWire interrupts are handled in the same thread as IPC and stream interrupts. Signed-off-by: Bard Liao Signed-off-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20191204212859.13239-1-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 3a33c6004143ad0e9945ec993f50c1d87ec1a9ae Author: Sathyanarayana Nujella Date: Tue Nov 26 08:32:04 2019 -0600 ASoC: intel: sof_rt5682: Add support for tgl-max98357a-rt5682 [ Upstream commit 6605f0ca3af3b964635287ec7c9dadc812b78eb0 ] This patch adds the driver data and updates quirk info for tgl with max98357a speaker amp and ALC5682 headset codec. Signed-off-by: Sathyanarayana Nujella Signed-off-by: Jairaj Arava Signed-off-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20191126143205.21987-3-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit c27bcb3d09e7174e5709b3c7a2aef92a2a631a63 Author: Sathyanarayana Nujella Date: Tue Nov 26 08:32:03 2019 -0600 ASoC: intel: sof_rt5682: Add quirk for number of HDMI DAI's [ Upstream commit c68e07970eca79106b0c35b88a12298569590081 ] TGL supports one more HDMI DAI than previous models. So add quirk support for number of HDMI DAI's. Signed-off-by: Sathyanarayana Nujella Signed-off-by: Jairaj Arava Signed-off-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20191126143205.21987-2-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 0c6f18cecdcccc97c15259d0b72018e47721e5c5 Author: Masami Hiramatsu Date: Tue Dec 3 15:14:04 2019 +0900 modules: lockdep: Suppress suspicious RCU usage warning [ Upstream commit bf08949cc8b98b7d1e20cfbba169a5938d42dae8 ] While running kprobe module test, find_module_all() caused a suspicious RCU usage warning. ----- ============================= WARNING: suspicious RCU usage 5.4.0-next-20191202+ #63 Not tainted ----------------------------- kernel/module.c:619 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by rmmod/642: #0: ffffffff8227da80 (module_mutex){+.+.}, at: __x64_sys_delete_module+0x9a/0x230 stack backtrace: CPU: 0 PID: 642 Comm: rmmod Not tainted 5.4.0-next-20191202+ #63 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack+0x71/0xa0 find_module_all+0xc1/0xd0 __x64_sys_delete_module+0xac/0x230 ? do_syscall_64+0x12/0x1f0 do_syscall_64+0x50/0x1f0 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x4b6d49 ----- This is because list_for_each_entry_rcu(modules) is called without rcu_read_lock(). This is safe because the module_mutex is locked. Pass lockdep_is_held(&module_mutex) to the list_for_each_entry_rcu() to suppress this warning, This also fixes similar issue in mod_find() and each_symbol_section(). Signed-off-by: Masami Hiramatsu Signed-off-by: Jessica Yu Signed-off-by: Sasha Levin commit 358bd73d13a61cb7c5ff8c6de7c78e29fd096a58 Author: Robin Murphy Date: Sat Nov 16 12:47:19 2019 +0000 arm64: dts: rockchip: Fix NanoPC-T4 cooling maps [ Upstream commit a793e19c15f25a126138ac4ae9facf9204754af3 ] Although it appeared to follow logically from the bindings, apparently the thermal framework can't properly cope with a single cooling device being shared between multiple maps. The CPU zone is probably easier to overheat, so remove the references to the (optional) fan from the GPU cooling zone to avoid things getting confused. Hopefully GPU-intensive tasks will leak enough heat across to the CPU zone to still hit the fan trips before reaching critical GPU temperatures. Signed-off-by: Robin Murphy Link: https://lore.kernel.org/r/5bb39f3115df1a487d717d3ae87e523b03749379.1573908197.git.robin.murphy@arm.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit b0d2ada02c3c5196a94a8b7d2cd3b7982df49fc9 Author: Adam Ford Date: Wed Oct 16 08:51:45 2019 -0500 drm/panel: simple: Add Logic PD Type 28 display support [ Upstream commit 0d35408afbeb603bc9972ae91e4dd2638bcffe52 ] Previously, there was an omap panel-dpi driver that would read generic timings from the device tree and set the display timing accordingly. This driver was removed so the screen no longer functions. This patch modifies the panel-simple file to setup the timings to the same values previously used. Fixes: 8bf4b1621178 ("drm/omap: Remove panel-dpi driver") Signed-off-by: Adam Ford Reviewed-by: Sam Ravnborg Signed-off-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/20191016135147.7743-1-aford173@gmail.com Signed-off-by: Sasha Levin commit 5823855257e5257c88c3c5ad437e3b101837d163 Author: Nathan Chancellor Date: Sat Nov 23 12:23:36 2019 -0700 drm/amdgpu: Ensure ret is always initialized when using SOC15_WAIT_ON_RREG [ Upstream commit a63141e31764f8daf3f29e8e2d450dcf9199d1c8 ] Commit b0f3cd3191cd ("drm/amdgpu: remove unnecessary JPEG2.0 code from VCN2.0") introduced a new clang warning in the vcn_v2_0_stop function: ../drivers/gpu/drm/amd/amdgpu/vcn_v2_0.c:1082:2: warning: variable 'r' is used uninitialized whenever 'while' loop exits because its condition is false [-Wsometimes-uninitialized] SOC15_WAIT_ON_RREG(VCN, 0, mmUVD_STATUS, UVD_STATUS__IDLE, 0x7, r); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ../drivers/gpu/drm/amd/amdgpu/../amdgpu/soc15_common.h:55:10: note: expanded from macro 'SOC15_WAIT_ON_RREG' while ((tmp_ & (mask)) != (expected_value)) { \ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ../drivers/gpu/drm/amd/amdgpu/vcn_v2_0.c:1083:6: note: uninitialized use occurs here if (r) ^ ../drivers/gpu/drm/amd/amdgpu/vcn_v2_0.c:1082:2: note: remove the condition if it is always true SOC15_WAIT_ON_RREG(VCN, 0, mmUVD_STATUS, UVD_STATUS__IDLE, 0x7, r); ^ ../drivers/gpu/drm/amd/amdgpu/../amdgpu/soc15_common.h:55:10: note: expanded from macro 'SOC15_WAIT_ON_RREG' while ((tmp_ & (mask)) != (expected_value)) { \ ^ ../drivers/gpu/drm/amd/amdgpu/vcn_v2_0.c:1072:7: note: initialize the variable 'r' to silence this warning int r; ^ = 0 1 warning generated. To prevent warnings like this from happening in the future, make the SOC15_WAIT_ON_RREG macro initialize its ret variable before the while loop that can time out. This macro's return value is always checked so it should set ret in both the success and fail path. Link: https://github.com/ClangBuiltLinux/linux/issues/776 Signed-off-by: Nathan Chancellor Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 83f89f04b550d0f435899703fa7d2a959e75df89 Author: Wen Gong Date: Fri Nov 15 09:21:32 2019 +0200 ath10k: correct the tlv len of ath10k_wmi_tlv_op_gen_config_pno_start [ Upstream commit e01cc82c4d1ec3bddcbb7cd991cf5dc0131ed9a1 ] the tlv len is set to the total len of the wmi cmd, it will trigger firmware crash, correct the tlv len. Tested with QCA6174 SDIO with firmware WLAN.RMH.4.4.1-00017-QCARMSWP-1 and QCA6174 PCIE with firmware WLAN.RM.4.4.1-00110-QCARMSWPZ-1. Fixes: ce834e280f2f875 ("ath10k: support NET_DETECT WoWLAN feature") Signed-off-by: Wen Gong Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit 7255b9422cc266c23df73b35c2d6e58b4d592fc5 Author: Chris Wilson Date: Thu Nov 14 20:44:13 2019 +0000 drm/amdgpu/dm: Do not throw an error for a display with no audio [ Upstream commit 852a91d627e9ce849d68df9d3f5336689003bdc7 ] An old display with no audio may not have an EDID with a CEA block, or it may simply be too old to support audio. This is not a driver error, so don't flag it as such. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112140 References: ae2a3495973e ("drm/amd: be quiet when no SAD block is found") Signed-off-by: Chris Wilson Cc: Harry Wentland Cc: Jean Delvare Cc: Alex Deucher Reviewed-by: Harry Wentland Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 308751b53dd82fd0e12ea3b2ffd0d85d5bf60c00 Author: yu kuai Date: Mon Nov 4 21:27:20 2019 +0800 drm/amdgpu: remove 4 set but not used variable in amdgpu_atombios_get_connector_info_from_object_table [ Upstream commit bae028e3e521e8cb8caf2cc16a455ce4c55f2332 ] Fixes gcc '-Wunused-but-set-variable' warning: drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c: In function 'amdgpu_atombios_get_connector_info_from_object_table': drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:376:26: warning: variable 'grph_obj_num' set but not used [-Wunused-but-set-variable] drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:376:13: warning: variable 'grph_obj_id' set but not used [-Wunused-but-set-variable] drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:341:37: warning: variable 'con_obj_type' set but not used [-Wunused-but-set-variable] drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:341:24: warning: variable 'con_obj_num' set but not used [-Wunused-but-set-variable] They are never used, so can be removed. Fixes: d38ceaf99ed0 ("drm/amdgpu: add core driver (v4)") Signed-off-by: yu kuai Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit aee053bd0d397b43b32f5a0f4b7fd9b7d8228590 Author: Eric Yang Date: Fri Oct 11 15:34:20 2019 -0400 drm/amd/display: Renoir chroma viewport WA [ Upstream commit 1cad8ff7ecc6b70a062b8e8b74a0cd08c928341d ] [Why] For unknown reason, immediate flip with host VM translation on NV12 surface will underflow on last row of PTE. [How] Hack chroma viewport height to make fetch one more row of PTE. Note that this will cause hubp underflow on all video underlay cases, but the underflow is not user visible since it is in blank region. Signed-off-by: Eric Yang Reviewed-by: Tony Cheng Acked-by: Bhawanpreet Lakha Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit e028271bb28a433b5ee3b48b424fbe033d88163e Author: Jakub Sitnicki Date: Thu Feb 6 12:16:51 2020 +0100 bpf, sockhash: Synchronize_rcu before free'ing map [ Upstream commit 0b2dc83906cf1e694e48003eae5df8fa63f76fd9 ] We need to have a synchronize_rcu before free'ing the sockhash because any outstanding psock references will have a pointer to the map and when they use it, this could trigger a use after free. This is a sister fix for sockhash, following commit 2bb90e5cc90e ("bpf: sockmap, synchronize_rcu before free'ing map") which addressed sockmap, which comes from a manual audit. Fixes: 604326b41a6fb ("bpf, sockmap: convert to generic sk_msg interface") Signed-off-by: Jakub Sitnicki Signed-off-by: Daniel Borkmann Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20200206111652.694507-3-jakub@cloudflare.com Signed-off-by: Sasha Levin commit 4daa2141cf5514f7ee6d8cad41465a76e5ae42c0 Author: Yong Zhao Date: Wed Jan 29 19:55:47 2020 -0500 drm/amdkfd: Fix a bug in SDMA RLC queue counting under HWS mode [ Upstream commit f38abc15d157b7b31fa7f651dc8bf92858c963f8 ] The sdma_queue_count increment should be done before execute_queues_cpsch(), which calls pm_calc_rlib_size() where sdma_queue_count is used to calculate whether over_subscription is triggered. With the previous code, when a SDMA queue is created, compute_queue_count in pm_calc_rlib_size() is one more than the actual compute queue number, because the queue_count has been incremented while sdma_queue_count has not. This patch fixes that. Signed-off-by: Yong Zhao Reviewed-by: Felix Kuehling Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit be1a6b1a07e6b82d31a74f0263b6435a3d89cea3 Author: Douglas Anderson Date: Mon Feb 3 10:31:34 2020 -0800 clk: qcom: rcg2: Don't crash if our parent can't be found; return an error [ Upstream commit 908b050114d8fefdddc57ec9fbc213c3690e7f5f ] When I got my clock parenting slightly wrong I ended up with a crash that looked like this: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 ... pc : clk_hw_get_rate+0x14/0x44 ... Call trace: clk_hw_get_rate+0x14/0x44 _freq_tbl_determine_rate+0x94/0xfc clk_rcg2_determine_rate+0x2c/0x38 clk_core_determine_round_nolock+0x4c/0x88 clk_core_round_rate_nolock+0x6c/0xa8 clk_core_round_rate_nolock+0x9c/0xa8 clk_core_set_rate_nolock+0x70/0x180 clk_set_rate+0x3c/0x6c of_clk_set_defaults+0x254/0x360 platform_drv_probe+0x28/0xb0 really_probe+0x120/0x2dc driver_probe_device+0x64/0xfc device_driver_attach+0x4c/0x6c __driver_attach+0xac/0xc0 bus_for_each_dev+0x84/0xcc driver_attach+0x2c/0x38 bus_add_driver+0xfc/0x1d0 driver_register+0x64/0xf8 __platform_driver_register+0x4c/0x58 msm_drm_register+0x5c/0x60 ... It turned out that clk_hw_get_parent_by_index() was returning NULL and we weren't checking. Let's check it so that we don't crash. Fixes: ac269395cdd8 ("clk: qcom: Convert to clk_hw based provider APIs") Signed-off-by: Douglas Anderson Reviewed-by: Matthias Kaehlcke Link: https://lkml.kernel.org/r/20200203103049.v4.1.I7487325fe8e701a68a07d3be8a6a4b571eca9cfa@changeid Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 67f7a2e43fa3126d405ff61ea4457d5e01c79533 Author: Stephen Boyd Date: Tue Jan 28 11:33:29 2020 -0800 clk: qcom: Don't overwrite 'cfg' in clk_rcg2_dfs_populate_freq() [ Upstream commit 21e157c62eeded8b1558a991b4820b761d48a730 ] The DFS frequency table logic overwrites 'cfg' while detecting the parent clk and then later on in clk_rcg2_dfs_populate_freq() we use that same variable to figure out the mode of the clk, either MND or not. Add a new variable to hold the parent clk bit so that 'cfg' is left untouched for use later. This fixes problems in detecting the supported frequencies for any clks in DFS mode. Fixes: cc4f6944d0e3 ("clk: qcom: Add support for RCG to register for DFS") Reported-by: Rajendra Nayak Signed-off-by: Stephen Boyd Link: https://lkml.kernel.org/r/20200128193329.45635-1-sboyd@kernel.org Tested-by: Rajendra Nayak Signed-off-by: Sasha Levin commit 20f1c3dbe493648cb3aa0a945fa8a304523192c3 Author: Masahiro Yamada Date: Sat Feb 1 14:03:11 2020 +0900 kconfig: fix broken dependency in randconfig-generated .config [ Upstream commit c8fb7d7e48d11520ad24808cfce7afb7b9c9f798 ] Running randconfig on arm64 using KCONFIG_SEED=0x40C5E904 (e.g. on v5.5) produces the .config with CONFIG_EFI=y and CONFIG_CPU_BIG_ENDIAN=y, which does not meet the !CONFIG_CPU_BIG_ENDIAN dependency. This is because the user choice for CONFIG_CPU_LITTLE_ENDIAN vs CONFIG_CPU_BIG_ENDIAN is set by randomize_choice_values() after the value of CONFIG_EFI is calculated. When this happens, the has_changed flag should be set. Currently, it takes the result from the last iteration. It should accumulate all the results of the loop. Fixes: 3b9a19e08960 ("kconfig: loop as long as we changed some symbols in randconfig") Reported-by: Vincenzo Frascino Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin commit a6a8b27650de77d3b179b3057df2880b7bbec62d Author: Paolo Valente Date: Mon Feb 3 11:40:54 2020 +0100 block, bfq: do not plug I/O for bfq_queues with no proc refs [ Upstream commit f718b093277df582fbf8775548a4f163e664d282 ] Commit 478de3380c1c ("block, bfq: deschedule empty bfq_queues not referred by any process") fixed commit 3726112ec731 ("block, bfq: re-schedule empty queues if they deserve I/O plugging") by descheduling an empty bfq_queue when it remains with not process reference. Yet, this still left a case uncovered: an empty bfq_queue with not process reference that remains in service. This happens for an in-service sync bfq_queue that is deemed to deserve I/O-dispatch plugging when it remains empty. Yet no new requests will arrive for such a bfq_queue if no process sends requests to it any longer. Even worse, the bfq_queue may happen to be prematurely freed while still in service (because there may remain no reference to it any longer). This commit solves this problem by preventing I/O dispatch from being plugged for the in-service bfq_queue, if the latter has no process reference (the bfq_queue is then prevented from remaining in service). Fixes: 3726112ec731 ("block, bfq: re-schedule empty queues if they deserve I/O plugging") Tested-by: Oleksandr Natalenko Reported-by: Patrick Dung Tested-by: Patrick Dung Signed-off-by: Paolo Valente Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 8317d9aaf7b0cf61739d2d6cdca4d1d4b2b74cd1 Author: Colin Ian King Date: Thu Jan 30 22:15:25 2020 -0800 drivers/block/zram/zram_drv.c: fix error return codes not being returned in writeback_store [ Upstream commit 3b82a051c10143639a378dcd12019f2353cc9054 ] Currently when an error code -EIO or -ENOSPC in the for-loop of writeback_store the error code is being overwritten by a ret = len assignment at the end of the function and the error codes are being lost. Fix this by assigning ret = len at the start of the function and remove the assignment from the end, hence allowing ret to be preserved when error codes are assigned to it. Addresses Coverity ("Unused value") Link: http://lkml.kernel.org/r/20191128122958.178290-1-colin.king@canonical.com Fixes: a939888ec38b ("zram: support idle/huge page writeback") Signed-off-by: Colin Ian King Acked-by: Minchan Kim Cc: Sergey Senozhatsky Cc: Jens Axboe Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 3ec693053be4b84a6596afc52aac803c6bd20d52 Author: Chris Mason Date: Tue Jan 21 11:51:42 2020 -0500 Btrfs: keep pages dirty when using btrfs_writepage_fixup_worker [ Upstream commit 25f3c5021985e885292980d04a1423fd83c967bb ] For COW, btrfs expects pages dirty pages to have been through a few setup steps. This includes reserving space for the new block allocations and marking the range in the state tree for delayed allocation. A few places outside btrfs will dirty pages directly, especially when unmapping mmap'd pages. In order for these to properly go through COW, we run them through a fixup worker to wait for stable pages, and do the delalloc prep. 87826df0ec36 added a window where the dirty pages were cleaned, but pending more action from the fixup worker. We clear_page_dirty_for_io() before we call into writepage, so the page is no longer dirty. The commit changed it so now we leave the page clean between unlocking it here and the fixup worker starting at some point in the future. During this window, page migration can jump in and relocate the page. Once our fixup work actually starts, it finds page->mapping is NULL and we end up freeing the page without ever writing it. This leads to crc errors and other exciting problems, since it screws up the whole statemachine for waiting for ordered extents. The fix here is to keep the page dirty while we're waiting for the fixup worker to get to work. This is accomplished by returning -EAGAIN from btrfs_writepage_cow_fixup if we queued the page up for fixup, which will cause the writepage function to redirty the page. Because we now expect the page to be dirty once it gets to the fixup worker we must adjust the error cases to call clear_page_dirty_for_io() on the page. That is the bulk of the patch, but it is not the fix, the fix is the -EAGAIN from btrfs_writepage_cow_fixup. We cannot separate these two changes out because the error conditions change with the new expectations. Signed-off-by: Chris Mason Signed-off-by: Josef Bacik Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 048d1357b8a99f15c8b2b588fcde2b2ca84e51bd Author: Christian Borntraeger Date: Thu Dec 5 07:40:43 2019 -0500 KVM: s390: ENOTSUPP -> EOPNOTSUPP fixups [ Upstream commit c611990844c28c61ca4b35ff69d3a2ae95ccd486 ] There is no ENOTSUPP for userspace. Reported-by: Julian Wiedmann Fixes: 519783935451 ("KVM: s390: introduce ais mode modify function") Fixes: 2c1a48f2e5ed ("KVM: S390: add new group for flic") Reviewed-by: Cornelia Huck Reviewed-by: Thomas Huth Signed-off-by: Christian Borntraeger Signed-off-by: Sasha Levin commit 6d9a246e9b70a4a293b619560ebafd16eec66ffa Author: Sun Ke Date: Wed Jan 22 11:18:57 2020 +0800 nbd: add a flush_workqueue in nbd_start_device [ Upstream commit 5c0dd228b5fc30a3b732c7ae2657e0161ec7ed80 ] When kzalloc fail, may cause trying to destroy the workqueue from inside the workqueue. If num_connections is m (2 < m), and NO.1 ~ NO.n (1 < n < m) kzalloc are successful. The NO.(n + 1) failed. Then, nbd_start_device will return ENOMEM to nbd_start_device_ioctl, and nbd_start_device_ioctl will return immediately without running flush_workqueue. However, we still have n recv threads. If nbd_release run first, recv threads may have to drop the last config_refs and try to destroy the workqueue from inside the workqueue. To fix it, add a flush_workqueue in nbd_start_device. Fixes: e9e006f5fcf2 ("nbd: fix max number of supported devs") Signed-off-by: Sun Ke Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 0d0a95537fdb66a589109458d1385c0ac5308e9b Author: Tom Zanussi Date: Fri Jun 28 12:40:20 2019 -0500 tracing: Simplify assignment parsing for hist triggers [ Upstream commit b527b638fd63ba791dc90a0a6e9a3035b10df52b ] In the process of adding better error messages for sorting, I realized that strsep was being used incorrectly and some of the error paths I was expecting to be hit weren't and just fell through to the common invalid key error case. It also became obvious that for keyword assignments, it wasn't necessary to save the full assignment and reparse it later, and having a common empty-assignment check would also make more sense in terms of error processing. Change the code to fix these problems and simplify it for new error message changes in a subsequent patch. Link: http://lkml.kernel.org/r/1c3ef0b6655deaf345f6faee2584a0298ac2d743.1561743018.git.zanussi@kernel.org Fixes: e62347d24534 ("tracing: Add hist trigger support for user-defined sorting ('sort=' param)") Fixes: 7ef224d1d0e3 ("tracing: Add 'hist' event trigger command") Fixes: a4072fe85ba3 ("tracing: Add a clock attribute for hist triggers") Reported-by: Masami Hiramatsu Reviewed-by: Masami Hiramatsu Signed-off-by: Tom Zanussi Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Sasha Levin commit fc1be5273e93dc951d9e0e6590101a8f15a8f963 Author: Harry Wentland Date: Tue Jan 21 16:12:45 2020 -0500 drm/amd/display: Retrain dongles when SINK_COUNT becomes non-zero [ Upstream commit 3eb6d7aca53d81ce888624f09cd44dc0302161e8 ] [WHY] Two years ago the patch referenced by the Fixes tag stopped running dp_verify_link_cap_with_retries during DP detection when the reason for the detection was a short-pulse interrupt. This effectively meant that we were no longer doing the verify_link_cap training on active dongles when their SINK_COUNT changed from 0 to 1. A year ago this was partly remedied with: commit 80adaebd2d41 ("drm/amd/display: Don't skip link training for empty dongle") This made sure that we trained the dongle on initial hotplug (without connected downstream devices). This is all fine and dandy if it weren't for the fact that there are some dongles on the market that don't like link training when SINK_COUNT is 0 These dongles will in fact indicate a SINK_COUNT of 0 immediately after hotplug, even when a downstream device is connected, and then trigger a shortpulse interrupt indicating a SINK_COUNT change to 1. In order to play nicely we will need our policy to not link train an active DP dongle when SINK_COUNT is 0 but ensure we train it when the SINK_COUNT changes to 1. [HOW] Call dp_verify_link_cap_with_retries on detection even when the detection is triggered from a short pulse interrupt. With this change we can also revert this commit which we'll do in a separate follow-up change: commit 80adaebd2d41 ("drm/amd/display: Don't skip link training for empty dongle") Fixes: 0301ccbaf67d ("drm/amd/display: DP Compliance 400.1.1 failure") Suggested-by: Louis Li Tested-by: Louis Li Cc: Wenjing Liu Cc: Hersen Wu Cc: Eric Yang Reviewed-by: Wenjing Liu Signed-off-by: Harry Wentland Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit fe0ed403e082358eea51ad2a2a56f92896f4a1cf Author: Geert Uytterhoeven Date: Sun Jan 12 18:13:49 2020 +0100 rtc: i2c/spi: Avoid inclusion of REGMAP support when not needed [ Upstream commit 34719de919af07682861cb0fa2bcf64da33ecf44 ] Merely enabling I2C and RTC selects REGMAP_I2C and REGMAP_SPI, even when no driver needs it. While the former can be moduler, the latter cannot, and thus becomes built-in. Fix this by moving the select statements for REGMAP_I2C and REGMAP_SPI from the RTC_I2C_AND_SPI helper to the individual drivers that depend on it. Note that the comment for RTC_I2C_AND_SPI refers to SND_SOC_I2C_AND_SPI for more information, but the latter does not select REGMAP_{I2C,SPI} itself, and defers that to the individual drivers, too. Fixes: 080481f54ef62121 ("rtc: merge ds3232 and ds3234") Signed-off-by: Geert Uytterhoeven Reported-by: kbuild test robot Reported-by: kbuild test robot Link: https://lore.kernel.org/r/20200112171349.22268-1-geert@linux-m68k.org Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 3c52259634a101c24146ed0c0d9473d0ebb859ef Author: Matthieu Baerts Date: Tue Oct 22 19:12:20 2019 +0200 selftests: settings: tests can be in subsubdirs [ Upstream commit ac87813d4372f4c005264acbe3b7f00c1dee37c4 ] Commit 852c8cbf34d3 ("selftests/kselftest/runner.sh: Add 45 second timeout per test") adds support for a new per-test-directory "settings" file. But this only works for tests not in a sub-subdirectories, e.g. - tools/testing/selftests/rtc (rtc) is OK, - tools/testing/selftests/net/mptcp (net/mptcp) is not. We have to increase the timeout for net/mptcp tests which are not upstreamed yet but this fix is valid for other tests if they need to add a "settings" file, see the full list with: tools/testing/selftests/*/*/**/Makefile Note that this patch changes the text header message printed at the end of the execution but this text is modified only for the tests that are in sub-subdirectories, e.g. ok 1 selftests: net/mptcp: mptcp_connect.sh Before we had: ok 1 selftests: mptcp: mptcp_connect.sh But showing the full target name is probably better, just in case a subsubdir has the same name as another one in another subdirectory. Fixes: 852c8cbf34d3 (selftests/kselftest/runner.sh: Add 45 second timeout per test) Signed-off-by: Matthieu Baerts Reviewed-by: Kees Cook Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit b3025b83fffa59ab00f38641235e04ac79c55ce2 Author: Jean-Philippe Brucker Date: Thu Dec 26 10:20:33 2019 +0100 brcmfmac: sdio: Fix OOB interrupt initialization on brcm43362 [ Upstream commit 8c8e60fb86a90a30721bbd797f58f96b3980dcc1 ] Commit 262f2b53f679 ("brcmfmac: call brcmf_attach() just before calling brcmf_bus_started()") changed the initialization order of the brcmfmac SDIO driver. Unfortunately since brcmf_sdiod_intr_register() is now called before the sdiodev->bus_if initialization, it reads the wrong chip ID and fails to initialize the GPIO on brcm43362. Thus the chip cannot send interrupts and fails to probe: [ 12.517023] brcmfmac: brcmf_sdio_bus_rxctl: resumed on timeout [ 12.531214] ieee80211 phy0: brcmf_bus_started: failed: -110 [ 12.536976] ieee80211 phy0: brcmf_attach: dongle is not responding: err=-110 [ 12.566467] brcmfmac: brcmf_sdio_firmware_callback: brcmf_attach failed Initialize the bus interface earlier to ensure that brcmf_sdiod_intr_register() properly sets up the OOB interrupt. BugLink: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908438 Fixes: 262f2b53f679 ("brcmfmac: call brcmf_attach() just before calling brcmf_bus_started()") Signed-off-by: Jean-Philippe Brucker Reviewed-by: Arend van Spriel Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit 2c26d64b853a0d194aaa1c1c63344630b9acb17a Author: Ping-Ke Shih Date: Fri Dec 20 17:21:46 2019 +0800 rtw88: fix rate mask for 1SS chip [ Upstream commit 35a68fa5f96a80797e11b6952a47c5a84939a7bf ] The rate mask is used to tell firmware the supported rate depends on negotiation. We loop 2 times for all VHT/HT 2SS rate mask first, and then only keep the part according to chip's NSS. This commit fixes the logic error of '&' operations for VHT/HT rate, and we should run this logic before adding legacy rate. To access HT MCS map, index 0/1 represent MCS 0-7/8-15 respectively. Use NL80211_BAND_xxx is incorrect, so fix it as well. Signed-off-by: Ping-Ke Shih Signed-off-by: Yan-Hsuan Chuang Reviewed-by: Chris Chiu Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit 75d10af05874e153575246681bc9e400f60e7be5 Author: Rakesh Pillai Date: Tue Jan 21 12:42:28 2020 +0530 ath10k: Correct the DMA direction for management tx buffers [ Upstream commit 6ba8b3b6bd772f575f7736c8fd893c6981fcce16 ] The management packets, send to firmware via WMI, are mapped using the direction DMA_TO_DEVICE. Currently in case of wmi cleanup, these buffers are being unmapped using an incorrect DMA direction. This can cause unwanted behavior when the host driver is handling a restart of the wlan firmware. We might see a trace like below [] __dma_inv_area+0x28/0x58 [] ath10k_wmi_mgmt_tx_clean_up_pending+0x60/0xb0 [ath10k_core] [] idr_for_each+0x78/0xe4 [] ath10k_wmi_detach+0x4c/0x7c [ath10k_core] [] ath10k_core_stop+0x58/0x68 [ath10k_core] [] ath10k_halt+0xec/0x13c [ath10k_core] [] ath10k_core_restart+0x11c/0x1a8 [ath10k_core] [] process_one_work+0x16c/0x31c Fix the incorrect DMA direction during the wmi management tx buffer cleanup. Tested HW: WCN3990 Tested FW: WLAN.HL.3.1-00784-QCAHLSWMTPLZ-1 Fixes: dc405152bb6 ("ath10k: handle mgmt tx completion event") Signed-off-by: Rakesh Pillai Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit e70f20ff3cf88133012b8d311cf8c048aaac9efb Author: zhangyi (F) Date: Wed Dec 4 20:46:12 2019 +0800 ext4, jbd2: ensure panic when aborting with zero errno [ Upstream commit 51f57b01e4a3c7d7bdceffd84de35144e8c538e7 ] JBD2_REC_ERR flag used to indicate the errno has been updated when jbd2 aborted, and then __ext4_abort() and ext4_handle_error() can invoke panic if ERRORS_PANIC is specified. But if the journal has been aborted with zero errno, jbd2_journal_abort() didn't set this flag so we can no longer panic. Fix this by always record the proper errno in the journal superblock. Fixes: 4327ba52afd03 ("ext4, jbd2: ensure entering into panic after recording an error in superblock") Signed-off-by: zhangyi (F) Reviewed-by: Jan Kara Link: https://lore.kernel.org/r/20191204124614.45424-3-yi.zhang@huawei.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 3c0e3e92b9644600534655f7d304be986b5196d3 Author: Vincenzo Frascino Date: Fri Jan 10 13:39:26 2020 +0100 ARM: 8952/1: Disable kmemleak on XIP kernels [ Upstream commit bc420c6ceefbb86cbbc8c00061bd779c17fa6997 ] Kmemleak relies on specific symbols to register the read only data during init (e.g. __start_ro_after_init). Trying to build an XIP kernel on arm results in the linking error reported below because when this option is selected read only data after init are not allowed since .data is read only (.rodata). arm-linux-gnueabihf-ld: mm/kmemleak.o: in function `kmemleak_init': kmemleak.c:(.init.text+0x148): undefined reference to `__end_ro_after_init' arm-linux-gnueabihf-ld: kmemleak.c:(.init.text+0x14c): undefined reference to `__end_ro_after_init' arm-linux-gnueabihf-ld: kmemleak.c:(.init.text+0x150): undefined reference to `__start_ro_after_init' arm-linux-gnueabihf-ld: kmemleak.c:(.init.text+0x156): undefined reference to `__start_ro_after_init' arm-linux-gnueabihf-ld: kmemleak.c:(.init.text+0x162): undefined reference to `__start_ro_after_init' arm-linux-gnueabihf-ld: kmemleak.c:(.init.text+0x16a): undefined reference to `__start_ro_after_init' linux/Makefile:1078: recipe for target 'vmlinux' failed Fix the issue enabling kmemleak only on non XIP kernels. Signed-off-by: Vincenzo Frascino Signed-off-by: Russell King Signed-off-by: Sasha Levin commit aab58ab5d723f658a127d2f4384cce4fde93ae5d Author: Steven Rostedt (VMware) Date: Fri Jan 24 17:47:49 2020 -0500 tracing: Fix very unlikely race of registering two stat tracers [ Upstream commit dfb6cd1e654315168e36d947471bd2a0ccd834ae ] Looking through old emails in my INBOX, I came across a patch from Luis Henriques that attempted to fix a race of two stat tracers registering the same stat trace (extremely unlikely, as this is done in the kernel, and probably doesn't even exist). The submitted patch wasn't quite right as it needed to deal with clean up a bit better (if two stat tracers were the same, it would have the same files). But to make the code cleaner, all we needed to do is to keep the all_stat_sessions_mutex held for most of the registering function. Link: http://lkml.kernel.org/r/1410299375-20068-1-git-send-email-luis.henriques@canonical.com Fixes: 002bb86d8d42f ("tracing/ftrace: separate events tracing and stats tracing engine") Reported-by: Luis Henriques Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Sasha Levin commit 853aaba5a941b2ba566e766dc30ead24eaf9c0b2 Author: Luis Henriques Date: Tue Sep 9 22:49:41 2014 +0100 tracing: Fix tracing_stat return values in error handling paths [ Upstream commit afccc00f75bbbee4e4ae833a96c2d29a7259c693 ] tracing_stat_init() was always returning '0', even on the error paths. It now returns -ENODEV if tracing_init_dentry() fails or -ENOMEM if it fails to created the 'trace_stat' debugfs directory. Link: http://lkml.kernel.org/r/1410299381-20108-1-git-send-email-luis.henriques@canonical.com Fixes: ed6f1c996bfe4 ("tracing: Check return value of tracing_init_dentry()") Signed-off-by: Luis Henriques [ Pulled from the archeological digging of my INBOX ] Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Sasha Levin commit 4ee55e53ae3474cf69435772c61e4c28bf571c6a Author: Oliver O'Halloran Date: Fri Jan 10 18:02:05 2020 +1100 powerpc/iov: Move VF pdev fixup into pcibios_fixup_iov() [ Upstream commit 965c94f309be58fbcc6c8d3e4f123376c5970d79 ] An ioda_pe for each VF is allocated in pnv_pci_sriov_enable() before the pci_dev for the VF is created. We need to set the pe->pdev pointer at some point after the pci_dev is created. Currently we do that in: pcibios_bus_add_device() pnv_pci_dma_dev_setup() (via phb->ops.dma_dev_setup) /* fixup is done here */ pnv_pci_ioda_dma_dev_setup() (via pnv_phb->dma_dev_setup) The fixup needs to be done before setting up DMA for for the VF's PE, but there's no real reason to delay it until this point. Move the fixup into pnv_pci_ioda_fixup_iov() so the ordering is: pcibios_add_device() pnv_pci_ioda_fixup_iov() (via ppc_md.pcibios_fixup_sriov) pcibios_bus_add_device() ... This isn't strictly required, but it's a slightly more logical place to do the fixup and it simplifies pnv_pci_dma_dev_setup(). Signed-off-by: Oliver O'Halloran Reviewed-by: Alexey Kardashevskiy Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20200110070207.439-4-oohall@gmail.com Signed-off-by: Sasha Levin commit 007fb6fbaf54a3a169db607c8af1eedff5de805d Author: Chen Zhou Date: Wed Jan 22 09:32:40 2020 +0800 backlight: qcom-wled: Fix unsigned comparison to zero [ Upstream commit 7af43a76695db71a57203793fb9dd3c81a5783b1 ] Fixes coccicheck warning: ./drivers/video/backlight/qcom-wled.c:1104:5-15: WARNING: Unsigned expression compared with zero: string_len > 0 The unsigned variable string_len is assigned a return value from the call to of_property_count_elems_of_size(), which may return negative error code. Fixes: 775d2ffb4af6 ("backlight: qcom-wled: Restructure the driver for WLED3") Signed-off-by: Chen Zhou Reviewed-by: Bjorn Andersson Reviewed-by: Daniel Thompson Reviewed-by: Kiran Gunda Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 7aebd2d83375490642d5975e8ea85af050dcf170 Author: Niklas Schnelle Date: Thu Dec 19 09:16:59 2019 +0100 s390/pci: Fix possible deadlock in recover_store() [ Upstream commit 576c75e36c689bec6a940e807bae27291ab0c0de ] With zpci_disable() working, lockdep detected a potential deadlock (lockdep output at the end). The deadlock is between recovering a PCI function via the /sys/bus/pci/devices//recover attribute vs powering it off via /sys/bus/pci/slots//power. The fix is analogous to the changes in commit 0ee223b2e1f6 ("scsi: core: Avoid that SCSI device removal through sysfs triggers a deadlock") that fixed a potential deadlock on removing a SCSI device via sysfs. [ 204.830107] ====================================================== [ 204.830109] WARNING: possible circular locking dependency detected [ 204.830111] 5.5.0-rc2-06072-gbc03ecc9a672 #6 Tainted: G W [ 204.830112] ------------------------------------------------------ [ 204.830113] bash/1034 is trying to acquire lock: [ 204.830115] 0000000192a1a610 (kn->count#200){++++}, at: kernfs_remove_by_name_ns+0x5c/0xa8 [ 204.830122] but task is already holding lock: [ 204.830123] 00000000c16134a8 (pci_rescan_remove_lock){+.+.}, at: pci_stop_and_remove_bus_device_locked+0x26/0x48 [ 204.830128] which lock already depends on the new lock. [ 204.830129] the existing dependency chain (in reverse order) is: [ 204.830130] -> #1 (pci_rescan_remove_lock){+.+.}: [ 204.830134] validate_chain+0x93a/0xd08 [ 204.830136] __lock_acquire+0x4ae/0x9d0 [ 204.830137] lock_acquire+0x114/0x280 [ 204.830140] __mutex_lock+0xa2/0x960 [ 204.830142] mutex_lock_nested+0x32/0x40 [ 204.830145] recover_store+0x4c/0xa8 [ 204.830147] kernfs_fop_write+0xe6/0x218 [ 204.830151] vfs_write+0xb0/0x1b8 [ 204.830152] ksys_write+0x6c/0xf8 [ 204.830154] system_call+0xd8/0x2d8 [ 204.830155] -> #0 (kn->count#200){++++}: [ 204.830187] check_noncircular+0x1e6/0x240 [ 204.830189] check_prev_add+0xfc/0xdb0 [ 204.830190] validate_chain+0x93a/0xd08 [ 204.830192] __lock_acquire+0x4ae/0x9d0 [ 204.830193] lock_acquire+0x114/0x280 [ 204.830194] __kernfs_remove.part.0+0x2e4/0x360 [ 204.830196] kernfs_remove_by_name_ns+0x5c/0xa8 [ 204.830198] remove_files.isra.0+0x4c/0x98 [ 204.830199] sysfs_remove_group+0x66/0xc8 [ 204.830201] sysfs_remove_groups+0x46/0x68 [ 204.830204] device_remove_attrs+0x52/0x90 [ 204.830207] device_del+0x182/0x418 [ 204.830208] pci_remove_bus_device+0x8a/0x130 [ 204.830210] pci_stop_and_remove_bus_device_locked+0x3a/0x48 [ 204.830212] disable_slot+0x68/0x100 [ 204.830213] power_write_file+0x7c/0x130 [ 204.830215] kernfs_fop_write+0xe6/0x218 [ 204.830217] vfs_write+0xb0/0x1b8 [ 204.830218] ksys_write+0x6c/0xf8 [ 204.830220] system_call+0xd8/0x2d8 [ 204.830221] other info that might help us debug this: [ 204.830223] Possible unsafe locking scenario: [ 204.830224] CPU0 CPU1 [ 204.830225] ---- ---- [ 204.830226] lock(pci_rescan_remove_lock); [ 204.830227] lock(kn->count#200); [ 204.830229] lock(pci_rescan_remove_lock); [ 204.830231] lock(kn->count#200); [ 204.830233] *** DEADLOCK *** [ 204.830234] 4 locks held by bash/1034: [ 204.830235] #0: 00000001b6fbc498 (sb_writers#4){.+.+}, at: vfs_write+0x158/0x1b8 [ 204.830239] #1: 000000018c9f5090 (&of->mutex){+.+.}, at: kernfs_fop_write+0xaa/0x218 [ 204.830242] #2: 00000001f7da0810 (kn->count#235){.+.+}, at: kernfs_fop_write+0xb6/0x218 [ 204.830245] #3: 00000000c16134a8 (pci_rescan_remove_lock){+.+.}, at: pci_stop_and_remove_bus_device_locked+0x26/0x48 [ 204.830248] stack backtrace: [ 204.830250] CPU: 2 PID: 1034 Comm: bash Tainted: G W 5.5.0-rc2-06072-gbc03ecc9a672 #6 [ 204.830252] Hardware name: IBM 8561 T01 703 (LPAR) [ 204.830253] Call Trace: [ 204.830257] [<00000000c05e10c0>] show_stack+0x88/0xf0 [ 204.830260] [<00000000c112dca4>] dump_stack+0xa4/0xe0 [ 204.830261] [<00000000c0694c06>] check_noncircular+0x1e6/0x240 [ 204.830263] [<00000000c0695bec>] check_prev_add+0xfc/0xdb0 [ 204.830264] [<00000000c06971da>] validate_chain+0x93a/0xd08 [ 204.830266] [<00000000c06994c6>] __lock_acquire+0x4ae/0x9d0 [ 204.830267] [<00000000c069867c>] lock_acquire+0x114/0x280 [ 204.830269] [<00000000c09ca15c>] __kernfs_remove.part.0+0x2e4/0x360 [ 204.830270] [<00000000c09cb5c4>] kernfs_remove_by_name_ns+0x5c/0xa8 [ 204.830272] [<00000000c09cee14>] remove_files.isra.0+0x4c/0x98 [ 204.830274] [<00000000c09cf2ae>] sysfs_remove_group+0x66/0xc8 [ 204.830276] [<00000000c09cf356>] sysfs_remove_groups+0x46/0x68 [ 204.830278] [<00000000c0e3dfe2>] device_remove_attrs+0x52/0x90 [ 204.830280] [<00000000c0e40382>] device_del+0x182/0x418 [ 204.830281] [<00000000c0dcfd7a>] pci_remove_bus_device+0x8a/0x130 [ 204.830283] [<00000000c0dcfe92>] pci_stop_and_remove_bus_device_locked+0x3a/0x48 [ 204.830285] [<00000000c0de7190>] disable_slot+0x68/0x100 [ 204.830286] [<00000000c0de6514>] power_write_file+0x7c/0x130 [ 204.830288] [<00000000c09cc846>] kernfs_fop_write+0xe6/0x218 [ 204.830290] [<00000000c08f3480>] vfs_write+0xb0/0x1b8 [ 204.830291] [<00000000c08f378c>] ksys_write+0x6c/0xf8 [ 204.830293] [<00000000c1154374>] system_call+0xd8/0x2d8 [ 204.830294] INFO: lockdep is turned off. Signed-off-by: Niklas Schnelle Reviewed-by: Peter Oberparleiter Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin commit 75195959f1f9205afea4ee72a99a9c9d0568dd82 Author: Marc Zyngier Date: Wed Jan 22 13:53:44 2020 +0000 irqchip/gic-v3-its: Fix get_vlpi_map() breakage with doorbells [ Upstream commit 093bf439fee0d40ade7e309c1288b409cdc3b38f ] When updating an LPI configuration, get_vlpi_map() may be passed a irq_data structure relative to an ITS domain (the normal case) or one that is relative to the core GICv3 domain in the case of a GICv4 doorbell. In the latter case, special care must be take not to dereference the irq_chip data as an its_dev structure, as that isn't what is stored there. Instead, check *first* whether the IRQ is forwarded to a vcpu, and only then try to obtain the vlpi mapping. Fixes: c1d4d5cd203c ("irqchip/gic-v3-its: Add its_vlpi_map helpers") Signed-off-by: Marc Zyngier Reported-by: Zenghui Yu Link: https://lore.kernel.org/r/20200122085609.658-1-yuzenghui@huawei.com Signed-off-by: Sasha Levin commit 7465ddb2292dfd497164993b492ffeb17f357aa3 Author: Martin Schiller Date: Tue Jan 21 07:00:34 2020 +0100 wan/hdlc_x25: fix skb handling [ Upstream commit 953c4a08dfc9ffe763a8340ac10f459d6c6cc4eb ] o call skb_reset_network_header() before hdlc->xmit() o change skb proto to HDLC (0x0019) before hdlc->xmit() o call dev_queue_xmit_nit() before hdlc->xmit() This changes make it possible to trace (tcpdump) outgoing layer2 (ETH_P_HDLC) packets Additionally call skb_reset_network_header() after each skb_push() / skb_pull(). Signed-off-by: Martin Schiller Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 165ab52f5a4e7b2a5d423dd3332868f22d326828 Author: Chen Zhou Date: Mon Jan 20 20:58:43 2020 +0800 dmaengine: fsl-qdma: fix duplicated argument to && [ Upstream commit 4b048178854da11656596d36a107577d66fd1e08 ] There is duplicated argument to && in function fsl_qdma_free_chan_resources, which looks like a typo, pointer fsl_queue->desc_pool also needs NULL check, fix it. Detected with coccinelle. Fixes: b092529e0aa0 ("dmaengine: fsl-qdma: Add qDMA controller driver for Layerscape SoCs") Signed-off-by: Chen Zhou Reviewed-by: Peng Ma Tested-by: Peng Ma Link: https://lore.kernel.org/r/20200120125843.34398-1-chenzhou10@huawei.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit e240f143604c12667686c5402053b8ec8cf7d2ce Author: Jan Kara Date: Fri Jan 17 12:11:14 2020 +0100 udf: Allow writing to 'Rewritable' partitions [ Upstream commit 15fb05fd286ac57a0802d71624daeb5c1c2d5b07 ] UDF 2.60 standard states in section 2.2.14.2: A partition with Access Type 3 (rewritable) shall define a Freed Space Bitmap or a Freed Space Table, see 2.3.3. All other partitions shall not define a Freed Space Bitmap or a Freed Space Table. Rewritable partitions are used on media that require some form of preprocessing before re-writing data (for example legacy MO). Such partitions shall use Access Type 3. Overwritable partitions are used on media that do not require preprocessing before overwriting data (for example: CD-RW, DVD-RW, DVD+RW, DVD-RAM, BD-RE, HD DVD-Rewritable). Such partitions shall use Access Type 4. however older versions of the standard didn't have this wording and there are tools out there that create UDF filesystems with rewritable partitions but that don't contain a Freed Space Bitmap or a Freed Space Table on media that does not require pre-processing before overwriting a block. So instead of forcing media with rewritable partition read-only, base this decision on presence of a Freed Space Bitmap or a Freed Space Table. Reported-by: Pali Rohár Reviewed-by: Pali Rohár Fixes: b085fbe2ef7f ("udf: Fix crash during mount") Link: https://lore.kernel.org/linux-fsdevel/20200112144735.hj2emsoy4uwsouxz@pali Signed-off-by: Jan Kara Signed-off-by: Sasha Levin commit 175a45ac8168b06302ac81df4293da19a7a09754 Author: Uwe Kleine-König Date: Mon Nov 11 10:03:55 2019 +0100 pwm: omap-dmtimer: Simplify error handling [ Upstream commit c4cf7aa57eb83b108d2d9c6c37c143388fee2a4d ] Instead of doing error handling in the middle of ->probe(), move error handling and freeing the reference to timer to the end. This fixes a resource leak as dm_timer wasn't freed when allocating *omap failed. Implementation note: The put: label was never reached without a goto and ret being unequal to 0, so the removed return statement is fine. Fixes: 6604c6556db9 ("pwm: Add PWM driver for OMAP using dual-mode timers") Signed-off-by: Uwe Kleine-König Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit 284eee6449127ba629b97e6acab1f1dbe332be1e Author: Arvind Sankar Date: Tue Jan 7 18:04:10 2020 -0500 x86/sysfb: Fix check for bad VRAM size [ Upstream commit dacc9092336be20b01642afe1a51720b31f60369 ] When checking whether the reported lfb_size makes sense, the height * stride result is page-aligned before seeing whether it exceeds the reported size. This doesn't work if height * stride is not an exact number of pages. For example, as reported in the kernel bugzilla below, an 800x600x32 EFI framebuffer gets skipped because of this. Move the PAGE_ALIGN to after the check vs size. Reported-by: Christopher Head Tested-by: Christopher Head Signed-off-by: Arvind Sankar Signed-off-by: Borislav Petkov Link: https://bugzilla.kernel.org/show_bug.cgi?id=206051 Link: https://lkml.kernel.org/r/20200107230410.2291947-1-nivedita@alum.mit.edu Signed-off-by: Sasha Levin commit cecf27e2edabd335ad8a4fd4702c5fc1c8f1a122 Author: Grygorii Strashko Date: Sat Dec 21 13:00:04 2019 +0200 clk: ti: dra7: fix parent for gmac_clkctrl [ Upstream commit 69e300283796dae7e8c2e6acdabcd31336c0c93e ] The parent clk for gmac clk ctrl has to be gmac_main_clk (125MHz) instead of dpll_gmac_ck (1GHz). This is caused incorrect CPSW MDIO operation. Hence, fix it. Fixes: dffa9051d546 ('clk: ti: dra7: add new clkctrl data') Signed-off-by: Grygorii Strashko Signed-off-by: Tero Kristo Signed-off-by: Sasha Levin commit c5d2a5d70c8b39241d005783827b8c715b4034bc Author: Eric Biggers Date: Tue Dec 31 12:12:22 2019 -0600 ext4: fix deadlock allocating bio_post_read_ctx from mempool [ Upstream commit 68e45330e341dad2d3a0a3f8ef2ec46a2a0a3bbc ] Without any form of coordination, any case where multiple allocations from the same mempool are needed at a time to make forward progress can deadlock under memory pressure. This is the case for struct bio_post_read_ctx, as one can be allocated to decrypt a Merkle tree page during fsverity_verify_bio(), which itself is running from a post-read callback for a data bio which has its own struct bio_post_read_ctx. Fix this by freeing the first bio_post_read_ctx before calling fsverity_verify_bio(). This works because verity (if enabled) is always the last post-read step. This deadlock can be reproduced by trying to read from an encrypted verity file after reducing NUM_PREALLOC_POST_READ_CTXS to 1 and patching mempool_alloc() to pretend that pool->alloc() always fails. Note that since NUM_PREALLOC_POST_READ_CTXS is actually 128, to actually hit this bug in practice would require reading from lots of encrypted verity files at the same time. But it's theoretically possible, as N available objects isn't enough to guarantee forward progress when > N/2 threads each need 2 objects at a time. Fixes: 22cfe4b48ccb ("ext4: add fs-verity read support") Signed-off-by: Eric Biggers Link: https://lore.kernel.org/r/20191231181222.47684-1-ebiggers@kernel.org Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 92f09081a2b20754c4cc6770e486ccfd054f0ed6 Author: Kai Li Date: Sat Jan 11 10:25:42 2020 +0800 jbd2: clear JBD2_ABORT flag before journal_reset to update log tail info when load journal [ Upstream commit a09decff5c32060639a685581c380f51b14e1fc2 ] If the journal is dirty when the filesystem is mounted, jbd2 will replay the journal but the journal superblock will not be updated by journal_reset() because JBD2_ABORT flag is still set (it was set in journal_init_common()). This is problematic because when a new transaction is then committed, it will be recorded in block 1 (journal->j_tail was set to 1 in journal_reset()). If unclean shutdown happens again before the journal superblock is updated, the new recorded transaction will not be replayed during the next mount (because of stale sb->s_start and sb->s_sequence values) which can lead to filesystem corruption. Fixes: 85e0c4e89c1b ("jbd2: if the journal is aborted then don't allow update of the log tail") Signed-off-by: Kai Li Link: https://lore.kernel.org/r/20200111022542.5008-1-li.kai4@h3c.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 18f1a5bfacb166c5570815e6e148b5cd2bfd08d7 Author: Siddhesh Poyarekar Date: Mon Jan 13 22:11:58 2020 +0530 kselftest: Minimise dependency of get_size on C library interfaces [ Upstream commit 6b64a650f0b2ae3940698f401732988699eecf7a ] It was observed[1] on arm64 that __builtin_strlen led to an infinite loop in the get_size selftest. This is because __builtin_strlen (and other builtins) may sometimes result in a call to the C library function. The C library implementation of strlen uses an IFUNC resolver to load the most efficient strlen implementation for the underlying machine and hence has a PLT indirection even for static binaries. Because this binary avoids the C library startup routines, the PLT initialization never happens and hence the program gets stuck in an infinite loop. On x86_64 the __builtin_strlen just happens to expand inline and avoid the call but that is not always guaranteed. Further, while testing on x86_64 (Fedora 31), it was observed that the test also failed with a segfault inside write() because the generated code for the write function in glibc seems to access TLS before the syscall (probably due to the cancellation point check) and fails because TLS is not initialised. To mitigate these problems, this patch reduces the interface with the C library to just the syscall function. The syscall function still sets errno on failure, which is undesirable but for now it only affects cases where syscalls fail. [1] https://bugs.linaro.org/show_bug.cgi?id=5479 Signed-off-by: Siddhesh Poyarekar Reported-by: Masami Hiramatsu Tested-by: Masami Hiramatsu Reviewed-by: Tim Bird Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit c183d59ba7a0cda10e01729e98fd97a457337bdb Author: Amanda Liu Date: Fri Dec 6 15:12:30 2019 -0500 drm/amd/display: Clear state after exiting fixed active VRR state [ Upstream commit 6f8f76444baf405bacb0591d97549a71a9aaa1ac ] [why] Upon exiting a fixed active VRR state, the state isn't cleared. This leads to the variable VRR range to be calculated incorrectly. [how] Set fixed active state to false when updating vrr params Signed-off-by: Amanda Liu Reviewed-by: Anthony Koo Acked-by: Harry Wentland Acked-by: Rodrigo Siqueira Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 3019eab8600908cbed7c4bdf4a08fc6a8c20402f Author: Colin Ian King Date: Thu Dec 19 21:32:46 2019 +0000 clocksource/drivers/bcm2835_timer: Fix memory leak of timer [ Upstream commit 2052d032c06761330bca4944bb7858b00960e868 ] Currently when setup_irq fails the error exit path will leak the recently allocated timer structure. Originally the code would throw a panic but a later commit changed the behaviour to return via the err_iounmap path and hence we now have a memory leak. Fix this by adding a err_timer_free error path that kfree's timer. Addresses-Coverity: ("Resource Leak") Fixes: 524a7f08983d ("clocksource/drivers/bcm2835_timer: Convert init function to return error") Signed-off-by: Colin Ian King Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20191219213246.34437-1-colin.king@canonical.com Signed-off-by: Sasha Levin commit 22c3cfeca6b12c83217c1b1123ced8394841806d Author: John Keeping Date: Thu Dec 19 11:34:31 2019 +0000 usb: dwc2: Fix IN FIFO allocation [ Upstream commit 644139f8b64d818f6345351455f14471510879a5 ] On chips with fewer FIFOs than endpoints (for example RK3288 which has 9 endpoints, but only 6 which are cabable of input), the DPTXFSIZN registers above the FIFO count may return invalid values. With logging added on startup, I see: dwc2 ff580000.usb: dwc2_hsotg_init_fifo: ep=1 sz=256 dwc2 ff580000.usb: dwc2_hsotg_init_fifo: ep=2 sz=128 dwc2 ff580000.usb: dwc2_hsotg_init_fifo: ep=3 sz=128 dwc2 ff580000.usb: dwc2_hsotg_init_fifo: ep=4 sz=64 dwc2 ff580000.usb: dwc2_hsotg_init_fifo: ep=5 sz=64 dwc2 ff580000.usb: dwc2_hsotg_init_fifo: ep=6 sz=32 dwc2 ff580000.usb: dwc2_hsotg_init_fifo: ep=7 sz=0 dwc2 ff580000.usb: dwc2_hsotg_init_fifo: ep=8 sz=0 dwc2 ff580000.usb: dwc2_hsotg_init_fifo: ep=9 sz=0 dwc2 ff580000.usb: dwc2_hsotg_init_fifo: ep=10 sz=0 dwc2 ff580000.usb: dwc2_hsotg_init_fifo: ep=11 sz=0 dwc2 ff580000.usb: dwc2_hsotg_init_fifo: ep=12 sz=0 dwc2 ff580000.usb: dwc2_hsotg_init_fifo: ep=13 sz=0 dwc2 ff580000.usb: dwc2_hsotg_init_fifo: ep=14 sz=0 dwc2 ff580000.usb: dwc2_hsotg_init_fifo: ep=15 sz=0 but: # cat /sys/kernel/debug/ff580000.usb/fifo Non-periodic FIFOs: RXFIFO: Size 275 NPTXFIFO: Size 16, Start 0x00000113 Periodic TXFIFOs: DPTXFIFO 1: Size 256, Start 0x00000123 DPTXFIFO 2: Size 128, Start 0x00000223 DPTXFIFO 3: Size 128, Start 0x000002a3 DPTXFIFO 4: Size 64, Start 0x00000323 DPTXFIFO 5: Size 64, Start 0x00000363 DPTXFIFO 6: Size 32, Start 0x000003a3 DPTXFIFO 7: Size 0, Start 0x000003e3 DPTXFIFO 8: Size 0, Start 0x000003a3 DPTXFIFO 9: Size 256, Start 0x00000123 so it seems that FIFO 9 is mirroring FIFO 1. Fix the allocation by using the FIFO count instead of the endpoint count when selecting a FIFO for an endpoint. Acked-by: Minas Harutyunyan Signed-off-by: John Keeping Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit a5f9e28e452aadb12e0a5d5efab4e5facb4eb34f Author: Jia-Ju Bai Date: Wed Dec 18 11:43:49 2019 +0800 usb: gadget: udc: fix possible sleep-in-atomic-context bugs in gr_probe() [ Upstream commit 9c1ed62ae0690dfe5d5e31d8f70e70a95cb48e52 ] The driver may sleep while holding a spinlock. The function call path (from bottom to top) in Linux 4.19 is: drivers/usb/gadget/udc/core.c, 1175: kzalloc(GFP_KERNEL) in usb_add_gadget_udc_release drivers/usb/gadget/udc/core.c, 1272: usb_add_gadget_udc_release in usb_add_gadget_udc drivers/usb/gadget/udc/gr_udc.c, 2186: usb_add_gadget_udc in gr_probe drivers/usb/gadget/udc/gr_udc.c, 2183: spin_lock in gr_probe drivers/usb/gadget/udc/core.c, 1195: mutex_lock in usb_add_gadget_udc_release drivers/usb/gadget/udc/core.c, 1272: usb_add_gadget_udc_release in usb_add_gadget_udc drivers/usb/gadget/udc/gr_udc.c, 2186: usb_add_gadget_udc in gr_probe drivers/usb/gadget/udc/gr_udc.c, 2183: spin_lock in gr_probe drivers/usb/gadget/udc/gr_udc.c, 212: debugfs_create_file in gr_probe drivers/usb/gadget/udc/gr_udc.c, 2197: gr_dfs_create in gr_probe drivers/usb/gadget/udc/gr_udc.c, 2183: spin_lock in gr_probe drivers/usb/gadget/udc/gr_udc.c, 2114: devm_request_threaded_irq in gr_request_irq drivers/usb/gadget/udc/gr_udc.c, 2202: gr_request_irq in gr_probe drivers/usb/gadget/udc/gr_udc.c, 2183: spin_lock in gr_probe kzalloc(GFP_KERNEL), mutex_lock(), debugfs_create_file() and devm_request_threaded_irq() can sleep at runtime. To fix these possible bugs, usb_add_gadget_udc(), gr_dfs_create() and gr_request_irq() are called without handling the spinlock. These bugs are found by a static analysis tool STCheck written by myself. Signed-off-by: Jia-Ju Bai Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit e0a8628196bbe0785c6a6bbd67e3eefa079ab7cf Author: Colin Ian King Date: Fri Nov 29 16:28:28 2019 +0000 drm/nouveau/nouveau: fix incorrect sizeof on args.src an args.dst [ Upstream commit f42e4b337b327b1336c978c4b5174990a25f68a0 ] The sizeof is currently on args.src and args.dst and should be on *args.src and *args.dst. Fortunately these sizes just so happen to be the same size so it worked, however, this should be fixed and it also cleans up static analysis warnings Addresses-Coverity: ("sizeof not portable") Fixes: f268307ec7c7 ("nouveau: simplify nouveau_dmem_migrate_vma") Signed-off-by: Colin Ian King Signed-off-by: Ben Skeggs Signed-off-by: Sasha Levin commit 6bfd7fa390a958c4afb00aa5a97d03313a41c7e9 Author: Philippe Schenker Date: Wed Dec 4 14:13:33 2019 +0000 spi: fsl-lpspi: fix only one cs-gpio working [ Upstream commit bc3a8b295e5bca9d1ec2622a6ba38289f9fd3d8a ] Why it does not work at the moment: - num_chipselect sets the number of cs-gpios that are in the DT. This comes from drivers/spi/spi.c - num_chipselect gets set with devm_spi_register_controller, that is called in drivers/spi/spi.c - devm_spi_register_controller got called after num_chipselect has been used. How this commit fixes the issue: - devm_spi_register_controller gets called before num_chipselect is being used. Fixes: c7a402599504 ("spi: lpspi: use the core way to implement cs-gpio function") Signed-off-by: Philippe Schenker Link: https://lore.kernel.org/r/20191204141312.1411251-1-philippe.schenker@toradex.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 6fe61eeb6af192fe246ef4a0baa8e51d878d1ebf Author: Tiecheng Zhou Date: Wed Jan 8 13:44:29 2020 +0800 drm/amdgpu/sriov: workaround on rev_id for Navi12 under sriov [ Upstream commit df5e984c8bd414561c320d6cbbb66d53abf4c7e2 ] guest vm gets 0xffffffff when reading RCC_DEV0_EPF0_STRAP0, as a consequence, the rev_id and external_rev_id are wrong. workaround it by hardcoding the rev_id to 0, which is the default value. v2. add comment in the code Signed-off-by: Tiecheng Zhou Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 1d52cd8b52876145b0f6344be95fc750e30d9ecb Author: Jia-Ju Bai Date: Wed Dec 18 17:44:05 2019 +0800 uio: fix a sleep-in-atomic-context bug in uio_dmem_genirq_irqcontrol() [ Upstream commit b74351287d4bd90636c3f48bc188c2f53824c2d4 ] The driver may sleep while holding a spinlock. The function call path (from bottom to top) in Linux 4.19 is: kernel/irq/manage.c, 523: synchronize_irq in disable_irq drivers/uio/uio_dmem_genirq.c, 140: disable_irq in uio_dmem_genirq_irqcontrol drivers/uio/uio_dmem_genirq.c, 134: _raw_spin_lock_irqsave in uio_dmem_genirq_irqcontrol synchronize_irq() can sleep at runtime. To fix this bug, disable_irq() is called without holding the spinlock. This bug is found by a static analysis tool STCheck written by myself. Signed-off-by: Jia-Ju Bai Link: https://lore.kernel.org/r/20191218094405.6009-1-baijiaju1990@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 955843f87d6af961acd5b4b4560d4991115dee2d Author: Lorenzo Bianconi Date: Thu Jan 2 09:36:29 2020 +0100 iio: imu: st_lsm6dsx: check return value from st_lsm6dsx_sensor_set_enable [ Upstream commit a2dd9bd9334efb8dc0bdc0109abff3a7b57effb1 ] Add missing return value check in st_lsm6dsx_read_oneshot disabling the sensor. The issue is reported by coverity with the following error: Unchecked return value: If the function returns an error value, the error value may be mistaken for a normal value. Addresses-Coverity-ID: 1446733 ("Unchecked return value") Fixes: b5969abfa8b8 ("iio: imu: st_lsm6dsx: add motion events") Fixes: 290a6ce11d93 ("iio: imu: add support to lsm6dsx driver") Signed-off-by: Lorenzo Bianconi Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit b17fec432e2dead9c5668914735a97739b3c5025 Author: Zhengyuan Liu Date: Fri Dec 20 10:21:26 2019 +0800 raid6/test: fix a compilation error [ Upstream commit 6b8651aac1dca6140dd7fb4c9fec2736ed3f6223 ] The compilation error is redeclaration showed as following: In file included from ../../../include/linux/limits.h:6, from /usr/include/x86_64-linux-gnu/bits/local_lim.h:38, from /usr/include/x86_64-linux-gnu/bits/posix1_lim.h:161, from /usr/include/limits.h:183, from /usr/lib/gcc/x86_64-linux-gnu/8/include-fixed/limits.h:194, from /usr/lib/gcc/x86_64-linux-gnu/8/include-fixed/syslimits.h:7, from /usr/lib/gcc/x86_64-linux-gnu/8/include-fixed/limits.h:34, from ../../../include/linux/raid/pq.h:30, from algos.c:14: ../../../include/linux/types.h:114:15: error: conflicting types for ‘int64_t’ typedef s64 int64_t; ^~~~~~~ In file included from /usr/include/stdint.h:34, from /usr/lib/gcc/x86_64-linux-gnu/8/include/stdint.h:9, from /usr/include/inttypes.h:27, from ../../../include/linux/raid/pq.h:29, from algos.c:14: /usr/include/x86_64-linux-gnu/bits/stdint-intn.h:27:19: note: previous \ declaration of ‘int64_t’ was here typedef __int64_t int64_t; Fixes: 54d50897d544 ("linux/kernel.h: split *_MAX and *_MIN macros into ") Signed-off-by: Zhengyuan Liu Signed-off-by: Song Liu Signed-off-by: Sasha Levin commit 74d583fca6a89b6148397b27b74a7801dc52f59f Author: Linus Walleij Date: Sun Jan 12 13:04:46 2020 +0100 net: ethernet: ixp4xx: Standard module init [ Upstream commit c83db9ef5640548631707e8b4a7bcddc115fdbae ] The IXP4xx driver was initializing the MDIO bus before even probing, in the callbacks supposed to be used for setting up the module itself, and with the side effect of trying to register the MDIO bus as soon as this module was loaded or compiled into the kernel whether the device was discovered or not. This does not work with multiplatform environments. To get rid of this: set up the MDIO bus from the probe() callback and remove it in the remove() callback. Rename the probe() and remove() calls to reflect the most common conventions. Since there is a bit of checking for the ethernet feature to be present in the MDIO registering function, making the whole module not even be registered if we can't find an MDIO bus, we need something similar: register the MDIO bus when the corresponding ethernet is probed, and return -EPROBE_DEFER on the other interfaces until this happens. If no MDIO bus is present on any of the registered interfaces we will eventually bail out. None of the platforms I've seen has e.g. MDIO on EthB and only uses EthC, there is always a Ethernet hardware on the NPE (B, C) that has the MDIO bus, we just might have to wait for it. Signed-off-by: Linus Walleij Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 464db384e14693ccd846001ff9b9220421944142 Author: David S. Miller Date: Sun Jan 12 00:07:42 2020 -0800 sparc: Add .exit.data section. [ Upstream commit 548f0b9a5f4cffa0cecf62eb12aa8db682e4eee6 ] This fixes build errors of all sorts. Also, emit .exit.text unconditionally. Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 0450bf55bee7b5ed8b1fff2d26dea57b5ac08752 Author: Ard Biesheuvel Date: Fri Jan 3 12:39:37 2020 +0100 efi/x86: Map the entire EFI vendor string before copying it [ Upstream commit ffc2760bcf2dba0dbef74013ed73eea8310cc52c ] Fix a couple of issues with the way we map and copy the vendor string: - we map only 2 bytes, which usually works since you get at least a page, but if the vendor string happens to cross a page boundary, a crash will result - only call early_memunmap() if early_memremap() succeeded, or we will call it with a NULL address which it doesn't like, - while at it, switch to early_memremap_ro(), and array indexing rather than pointer dereferencing to read the CHAR16 characters. Signed-off-by: Ard Biesheuvel Cc: Andy Lutomirski Cc: Ard Biesheuvel Cc: Arvind Sankar Cc: Matthew Garrett Cc: linux-efi@vger.kernel.org Fixes: 5b83683f32b1 ("x86: EFI runtime service support") Link: https://lkml.kernel.org/r/20200103113953.9571-5-ardb@kernel.org Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit a92681aca64981c54375dccc43fcf6d6d7fb4e4d Author: Masami Hiramatsu Date: Tue Jan 7 23:42:24 2020 +0900 kprobes: Fix optimize_kprobe()/unoptimize_kprobe() cancellation logic [ Upstream commit e4add247789e4ba5e08ad8256183ce2e211877d4 ] optimize_kprobe() and unoptimize_kprobe() cancels if a given kprobe is on the optimizing_list or unoptimizing_list already. However, since the following commit: f66c0447cca1 ("kprobes: Set unoptimized flag after unoptimizing code") modified the update timing of the KPROBE_FLAG_OPTIMIZED, it doesn't work as expected anymore. The optimized_kprobe could be in the following states: - [optimizing]: Before inserting jump instruction op.kp->flags has KPROBE_FLAG_OPTIMIZED and op->list is not empty. - [optimized]: jump inserted op.kp->flags has KPROBE_FLAG_OPTIMIZED and op->list is empty. - [unoptimizing]: Before removing jump instruction (including unused optprobe) op.kp->flags has KPROBE_FLAG_OPTIMIZED and op->list is not empty. - [unoptimized]: jump removed op.kp->flags doesn't have KPROBE_FLAG_OPTIMIZED and op->list is empty. Current code mis-expects [unoptimizing] state doesn't have KPROBE_FLAG_OPTIMIZED, and that can cause incorrect results. To fix this, introduce optprobe_queued_unopt() to distinguish [optimizing] and [unoptimizing] states and fixes the logic in optimize_kprobe() and unoptimize_kprobe(). [ mingo: Cleaned up the changelog and the code a bit. ] Signed-off-by: Masami Hiramatsu Reviewed-by: Steven Rostedt (VMware) Cc: Alexei Starovoitov Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: bristot@redhat.com Fixes: f66c0447cca1 ("kprobes: Set unoptimized flag after unoptimizing code") Link: https://lkml.kernel.org/r/157840814418.7181.13478003006386303481.stgit@devnote2 Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit da49ba52dc6a8c4732d3323ea64903bec9dfd3b2 Author: Hans de Goede Date: Sat Dec 28 00:04:47 2019 +0100 pinctrl: baytrail: Do not clear IRQ flags on direct-irq enabled pins [ Upstream commit a23680594da7a9e2696dbcf4f023e9273e2fa40b ] Suspending Goodix touchscreens requires changing the interrupt pin to output before sending them a power-down command. Followed by wiggling the interrupt pin to wake the device up, after which it is put back in input mode. On Bay Trail devices with a Goodix touchscreen direct-irq mode is used in combination with listing the pin as a normal GpioIo resource. This works fine, until the goodix driver gets rmmod-ed and then insmod-ed again. In this case byt_gpio_disable_free() calls byt_gpio_clear_triggering() which clears the IRQ flags and after that the (direct) IRQ no longer triggers. This commit fixes this by adding a check for the BYT_DIRECT_IRQ_EN flag to byt_gpio_clear_triggering(). Note that byt_gpio_clear_triggering() only gets called from byt_gpio_disable_free() for direct-irq enabled pins, as these are excluded from the irq_valid mask by byt_init_irq_valid_mask(). Signed-off-by: Hans de Goede Acked-by: Mika Westerberg Reviewed-by: Linus Walleij Signed-off-by: Andy Shevchenko Signed-off-by: Sasha Levin commit 747c5a43ee4cc0aa6ac9f7601c393fc7543ca4c9 Author: Parav Pandit Date: Thu Dec 12 13:30:22 2019 +0200 IB/core: Let IB core distribute cache update events [ Upstream commit 6b57cea9221b0247ad5111b348522625e489a8e4 ] Currently when the low level driver notifies Pkey, GID, and port change events they are notified to the registered handlers in the order they are registered. IB core and other ULPs such as IPoIB are interested in GID, LID, Pkey change events. Since all GID queries done by ULPs are serviced by IB core, and the IB core deferes cache updates to a work queue, it is possible for other clients to see stale cache data when they handle their own events. For example, the below call tree shows how ipoib will call rdma_query_gid() concurrently with the update to the cache sitting in the WQ. mlx5_ib_handle_event() ib_dispatch_event() ib_cache_event() queue_work() -> slow cache update [..] ipoib_event() queue_work() [..] work handler ipoib_ib_dev_flush_light() __ipoib_ib_dev_flush() ipoib_dev_addr_changed_valid() rdma_query_gid() <- Returns old GID, cache not updated. Move all the event dispatch to a work queue so that the cache update is always done before any clients are notified. Fixes: f35faa4ba956 ("IB/core: Simplify ib_query_gid to always refer to cache") Link: https://lore.kernel.org/r/20191212113024.336702-3-leon@kernel.org Signed-off-by: Parav Pandit Signed-off-by: Leon Romanovsky Reviewed-by: Jason Gunthorpe Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit b83ff1374ed5677a4d35d48b5be5208131d9961d Author: YueHaibing Date: Sat Dec 28 19:54:55 2019 +0800 kernel/module: Fix memleak in module_add_modinfo_attrs() [ Upstream commit f6d061d617124abbd55396a3bc37b9bf7d33233c ] In module_add_modinfo_attrs() if sysfs_create_file() fails on the first iteration of the loop (so i = 0), we forget to free the modinfo_attrs. Fixes: bc6f2a757d52 ("kernel/module: Fix mem leak in module_add_modinfo_attrs") Reviewed-by: Miroslav Benes Signed-off-by: YueHaibing Signed-off-by: Jessica Yu Signed-off-by: Sasha Levin commit e6bc6f9b1a67514f4be4a44572397cf4e3a6153e Author: Jia-Ju Bai Date: Thu Dec 19 11:34:01 2019 +0100 media: sti: bdisp: fix a possible sleep-in-atomic-context bug in bdisp_device_run() [ Upstream commit bb6d42061a05d71dd73f620582d9e09c8fbf7f5b ] The driver may sleep while holding a spinlock. The function call path (from bottom to top) in Linux 4.19 is: drivers/media/platform/sti/bdisp/bdisp-hw.c, 385: msleep in bdisp_hw_reset drivers/media/platform/sti/bdisp/bdisp-v4l2.c, 341: bdisp_hw_reset in bdisp_device_run drivers/media/platform/sti/bdisp/bdisp-v4l2.c, 317: _raw_spin_lock_irqsave in bdisp_device_run To fix this bug, msleep() is replaced with udelay(). This bug is found by a static analysis tool STCheck written by myself. Signed-off-by: Jia-Ju Bai Reviewed-by: Fabien Dessenne Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 1c70f45e24d2ff7bd12efd12fe0ab0a3d9081168 Author: Sergey Senozhatsky Date: Wed Nov 13 16:16:25 2019 -0500 char/random: silence a lockdep splat with printk() [ Upstream commit 1b710b1b10eff9d46666064ea25f079f70bc67a8 ] Sergey didn't like the locking order, uart_port->lock -> tty_port->lock uart_write (uart_port->lock) __uart_start pl011_start_tx pl011_tx_chars uart_write_wakeup tty_port_tty_wakeup tty_port_default tty_port_tty_get (tty_port->lock) but those code is so old, and I have no clue how to de-couple it after checking other locks in the splat. There is an onging effort to make all printk() as deferred, so until that happens, workaround it for now as a short-term fix. LTP: starting iogen01 (export LTPROOT; rwtest -N iogen01 -i 120s -s read,write -Da -Dv -n 2 500b:$TMPDIR/doio.f1.$$ 1000b:$TMPDIR/doio.f2.$$) WARNING: possible circular locking dependency detected ------------------------------------------------------ doio/49441 is trying to acquire lock: ffff008b7cff7290 (&(&zone->lock)->rlock){..-.}, at: rmqueue+0x138/0x2050 but task is already holding lock: 60ff000822352818 (&pool->lock/1){-.-.}, at: start_flush_work+0xd8/0x3f0 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #4 (&pool->lock/1){-.-.}: lock_acquire+0x320/0x360 _raw_spin_lock+0x64/0x80 __queue_work+0x4b4/0xa10 queue_work_on+0xac/0x11c tty_schedule_flip+0x84/0xbc tty_flip_buffer_push+0x1c/0x28 pty_write+0x98/0xd0 n_tty_write+0x450/0x60c tty_write+0x338/0x474 __vfs_write+0x88/0x214 vfs_write+0x12c/0x1a4 redirected_tty_write+0x90/0xdc do_loop_readv_writev+0x140/0x180 do_iter_write+0xe0/0x10c vfs_writev+0x134/0x1cc do_writev+0xbc/0x130 __arm64_sys_writev+0x58/0x8c el0_svc_handler+0x170/0x240 el0_sync_handler+0x150/0x250 el0_sync+0x164/0x180 -> #3 (&(&port->lock)->rlock){-.-.}: lock_acquire+0x320/0x360 _raw_spin_lock_irqsave+0x7c/0x9c tty_port_tty_get+0x24/0x60 tty_port_default_wakeup+0x1c/0x3c tty_port_tty_wakeup+0x34/0x40 uart_write_wakeup+0x28/0x44 pl011_tx_chars+0x1b8/0x270 pl011_start_tx+0x24/0x70 __uart_start+0x5c/0x68 uart_write+0x164/0x1c8 do_output_char+0x33c/0x348 n_tty_write+0x4bc/0x60c tty_write+0x338/0x474 redirected_tty_write+0xc0/0xdc do_loop_readv_writev+0x140/0x180 do_iter_write+0xe0/0x10c vfs_writev+0x134/0x1cc do_writev+0xbc/0x130 __arm64_sys_writev+0x58/0x8c el0_svc_handler+0x170/0x240 el0_sync_handler+0x150/0x250 el0_sync+0x164/0x180 -> #2 (&port_lock_key){-.-.}: lock_acquire+0x320/0x360 _raw_spin_lock+0x64/0x80 pl011_console_write+0xec/0x2cc console_unlock+0x794/0x96c vprintk_emit+0x260/0x31c vprintk_default+0x54/0x7c vprintk_func+0x218/0x254 printk+0x7c/0xa4 register_console+0x734/0x7b0 uart_add_one_port+0x734/0x834 pl011_register_port+0x6c/0xac sbsa_uart_probe+0x234/0x2ec platform_drv_probe+0xd4/0x124 really_probe+0x250/0x71c driver_probe_device+0xb4/0x200 __device_attach_driver+0xd8/0x188 bus_for_each_drv+0xbc/0x110 __device_attach+0x120/0x220 device_initial_probe+0x20/0x2c bus_probe_device+0x54/0x100 device_add+0xae8/0xc2c platform_device_add+0x278/0x3b8 platform_device_register_full+0x238/0x2ac acpi_create_platform_device+0x2dc/0x3a8 acpi_bus_attach+0x390/0x3cc acpi_bus_attach+0x108/0x3cc acpi_bus_attach+0x108/0x3cc acpi_bus_attach+0x108/0x3cc acpi_bus_scan+0x7c/0xb0 acpi_scan_init+0xe4/0x304 acpi_init+0x100/0x114 do_one_initcall+0x348/0x6a0 do_initcall_level+0x190/0x1fc do_basic_setup+0x34/0x4c kernel_init_freeable+0x19c/0x260 kernel_init+0x18/0x338 ret_from_fork+0x10/0x18 -> #1 (console_owner){-...}: lock_acquire+0x320/0x360 console_lock_spinning_enable+0x6c/0x7c console_unlock+0x4f8/0x96c vprintk_emit+0x260/0x31c vprintk_default+0x54/0x7c vprintk_func+0x218/0x254 printk+0x7c/0xa4 get_random_u64+0x1c4/0x1dc shuffle_pick_tail+0x40/0xac __free_one_page+0x424/0x710 free_one_page+0x70/0x120 __free_pages_ok+0x61c/0xa94 __free_pages_core+0x1bc/0x294 memblock_free_pages+0x38/0x48 __free_pages_memory+0xcc/0xfc __free_memory_core+0x70/0x78 free_low_memory_core_early+0x148/0x18c memblock_free_all+0x18/0x54 mem_init+0xb4/0x17c mm_init+0x14/0x38 start_kernel+0x19c/0x530 -> #0 (&(&zone->lock)->rlock){..-.}: validate_chain+0xf6c/0x2e2c __lock_acquire+0x868/0xc2c lock_acquire+0x320/0x360 _raw_spin_lock+0x64/0x80 rmqueue+0x138/0x2050 get_page_from_freelist+0x474/0x688 __alloc_pages_nodemask+0x3b4/0x18dc alloc_pages_current+0xd0/0xe0 alloc_slab_page+0x2b4/0x5e0 new_slab+0xc8/0x6bc ___slab_alloc+0x3b8/0x640 kmem_cache_alloc+0x4b4/0x588 __debug_object_init+0x778/0x8b4 debug_object_init_on_stack+0x40/0x50 start_flush_work+0x16c/0x3f0 __flush_work+0xb8/0x124 flush_work+0x20/0x30 xlog_cil_force_lsn+0x88/0x204 [xfs] xfs_log_force_lsn+0x128/0x1b8 [xfs] xfs_file_fsync+0x3c4/0x488 [xfs] vfs_fsync_range+0xb0/0xd0 generic_write_sync+0x80/0xa0 [xfs] xfs_file_buffered_aio_write+0x66c/0x6e4 [xfs] xfs_file_write_iter+0x1a0/0x218 [xfs] __vfs_write+0x1cc/0x214 vfs_write+0x12c/0x1a4 ksys_write+0xb0/0x120 __arm64_sys_write+0x54/0x88 el0_svc_handler+0x170/0x240 el0_sync_handler+0x150/0x250 el0_sync+0x164/0x180 other info that might help us debug this: Chain exists of: &(&zone->lock)->rlock --> &(&port->lock)->rlock --> &pool->lock/1 Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&pool->lock/1); lock(&(&port->lock)->rlock); lock(&pool->lock/1); lock(&(&zone->lock)->rlock); *** DEADLOCK *** 4 locks held by doio/49441: #0: a0ff00886fc27408 (sb_writers#8){.+.+}, at: vfs_write+0x118/0x1a4 #1: 8fff00080810dfe0 (&xfs_nondir_ilock_class){++++}, at: xfs_ilock+0x2a8/0x300 [xfs] #2: ffff9000129f2390 (rcu_read_lock){....}, at: rcu_lock_acquire+0x8/0x38 #3: 60ff000822352818 (&pool->lock/1){-.-.}, at: start_flush_work+0xd8/0x3f0 stack backtrace: CPU: 48 PID: 49441 Comm: doio Tainted: G W Hardware name: HPE Apollo 70 /C01_APACHE_MB , BIOS L50_5.13_1.11 06/18/2019 Call trace: dump_backtrace+0x0/0x248 show_stack+0x20/0x2c dump_stack+0xe8/0x150 print_circular_bug+0x368/0x380 check_noncircular+0x28c/0x294 validate_chain+0xf6c/0x2e2c __lock_acquire+0x868/0xc2c lock_acquire+0x320/0x360 _raw_spin_lock+0x64/0x80 rmqueue+0x138/0x2050 get_page_from_freelist+0x474/0x688 __alloc_pages_nodemask+0x3b4/0x18dc alloc_pages_current+0xd0/0xe0 alloc_slab_page+0x2b4/0x5e0 new_slab+0xc8/0x6bc ___slab_alloc+0x3b8/0x640 kmem_cache_alloc+0x4b4/0x588 __debug_object_init+0x778/0x8b4 debug_object_init_on_stack+0x40/0x50 start_flush_work+0x16c/0x3f0 __flush_work+0xb8/0x124 flush_work+0x20/0x30 xlog_cil_force_lsn+0x88/0x204 [xfs] xfs_log_force_lsn+0x128/0x1b8 [xfs] xfs_file_fsync+0x3c4/0x488 [xfs] vfs_fsync_range+0xb0/0xd0 generic_write_sync+0x80/0xa0 [xfs] xfs_file_buffered_aio_write+0x66c/0x6e4 [xfs] xfs_file_write_iter+0x1a0/0x218 [xfs] __vfs_write+0x1cc/0x214 vfs_write+0x12c/0x1a4 ksys_write+0xb0/0x120 __arm64_sys_write+0x54/0x88 el0_svc_handler+0x170/0x240 el0_sync_handler+0x150/0x250 el0_sync+0x164/0x180 Reviewed-by: Sergey Senozhatsky Signed-off-by: Qian Cai Link: https://lore.kernel.org/r/1573679785-21068-1-git-send-email-cai@lca.pw Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 50b48321ee52397ad877a397bff73732394ccbff Author: Heinz Mauelshagen Date: Thu Dec 19 17:58:46 2019 +0100 dm raid: table line rebuild status fixes [ Upstream commit 43f3952a51f8198d365acb7f51fe42d578fe5d0a ] raid_status() wasn't emitting rebuild flags on the table line properly because the rdev number was not yet set properly; index raid component devices array directly to solve. Also fix wrong argument count on emitted table line caused by 1 too many rebuild/write_mostly argument and consider any journal_(dev|mode) pairs. Link: https://bugzilla.redhat.com/1782045 Signed-off-by: Heinz Mauelshagen Signed-off-by: Mike Snitzer Signed-off-by: Sasha Levin commit c9ef2302c2243ae6f5a7d7cd7e244522743f0675 Author: Sebastian Andrzej Siewior Date: Fri Dec 20 20:59:06 2019 +0100 x86/fpu: Deactivate FPU state after failure during state load [ Upstream commit bbc55341b9c67645d1a5471506370caf7dd4a203 ] In __fpu__restore_sig(), fpu_fpregs_owner_ctx needs to be reset if the FPU state was not fully restored. Otherwise the following may happen (on the same CPU): Task A Task B fpu_fpregs_owner_ctx *active* A.fpu __fpu__restore_sig() ctx switch load B.fpu *active* B.fpu fpregs_lock() copy_user_to_fpregs_zeroing() copy_kernel_to_xregs() *modify* copy_user_to_xregs() *fails* fpregs_unlock() ctx switch skip loading B.fpu, *active* B.fpu In the success case, fpu_fpregs_owner_ctx is set to the current task. In the failure case, the FPU state might have been modified by loading the init state. In this case, fpu_fpregs_owner_ctx needs to be reset in order to ensure that the FPU state of the following task is loaded from saved state (and not skipped because it was the previous state). Reset fpu_fpregs_owner_ctx after a failure during restore occurred, to ensure that the FPU state for the next task is always loaded. The problem was debugged-by Yu-cheng Yu . [ bp: Massage commit message. ] Fixes: 5f409e20b7945 ("x86/fpu: Defer FPU state load until return to userspace") Reported-by: Yu-cheng Yu Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Borislav Petkov Cc: Andy Lutomirski Cc: Dave Hansen Cc: Fenghua Yu Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: Jann Horn Cc: Peter Zijlstra Cc: "Ravi V. Shankar" Cc: Rik van Riel Cc: Thomas Gleixner Cc: Tony Luck Cc: x86-ml Link: https://lkml.kernel.org/r/20191220195906.plk6kpmsrikvbcfn@linutronix.de Signed-off-by: Sasha Levin commit 29ebe0274d10b22edfa2c98892b7390776d3632d Author: Jacob Pan Date: Thu Jan 2 08:18:07 2020 +0800 iommu/vt-d: Fix off-by-one in PASID allocation [ Upstream commit 39d630e332144028f56abba83d94291978e72df1 ] PASID allocator uses IDR which is exclusive for the end of the allocation range. There is no need to decrement pasid_max. Fixes: af39507305fb ("iommu/vt-d: Apply global PASID in SVA") Reported-by: Eric Auger Signed-off-by: Jacob Pan Reviewed-by: Eric Auger Signed-off-by: Lu Baolu Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 11462f21f9fc8cfcac31ef73d7cd0f30f95d49e8 Author: Jia-Ju Bai Date: Wed Dec 18 21:26:05 2019 +0800 gpio: gpio-grgpio: fix possible sleep-in-atomic-context bugs in grgpio_irq_map/unmap() [ Upstream commit e36eaf94be8f7bc4e686246eed3cf92d845e2ef8 ] The driver may sleep while holding a spinlock. The function call path (from bottom to top) in Linux 4.19 is: drivers/gpio/gpio-grgpio.c, 261: request_irq in grgpio_irq_map drivers/gpio/gpio-grgpio.c, 255: _raw_spin_lock_irqsave in grgpio_irq_map drivers/gpio/gpio-grgpio.c, 318: free_irq in grgpio_irq_unmap drivers/gpio/gpio-grgpio.c, 299: _raw_spin_lock_irqsave in grgpio_irq_unmap request_irq() and free_irq() can sleep at runtime. To fix these bugs, request_irq() and free_irq() are called without holding the spinlock. These bugs are found by a static analysis tool STCheck written by myself. Signed-off-by: Jia-Ju Bai Link: https://lore.kernel.org/r/20191218132605.10594-1-baijiaju1990@gmail.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit e0f49fe698f04bbec156290133674a46db1293b0 Author: Martin Blumenstingl Date: Thu Dec 26 20:12:23 2019 +0100 clk: meson: meson8b: make the CCF use the glitch-free mali mux [ Upstream commit 8daeaea99caabe24a0929fac17977ebfb882fa86 ] The "mali_0" or "mali_1" clock trees should not be updated while the clock is running. Enforce this by setting CLK_SET_RATE_GATE on the "mali_0" and "mali_1" gates. This makes the CCF switch to the "mali_1" tree when "mali_0" is currently active and vice versa, which is exactly what the vendor driver does when updating the frequency of the mali clock. This fixes a potential hang when changing the GPU frequency at runtime. Fixes: 74e1f2521f16ff ("clk: meson: meson8b: add the GPU clock tree") Signed-off-by: Martin Blumenstingl Signed-off-by: Jerome Brunet Signed-off-by: Sasha Levin commit 14d0c7d2a9dfa8cf7740f8e5fd4126c0182e3836 Author: Oliver O'Halloran Date: Mon Oct 28 19:54:22 2019 +1100 powerpc/powernv/iov: Ensure the pdn for VFs always contains a valid PE number [ Upstream commit 3b5b9997b331e77ce967eba2c4bc80dc3134a7fe ] On pseries there is a bug with adding hotplugged devices to an IOMMU group. For a number of dumb reasons fixing that bug first requires re-working how VFs are configured on PowerNV. For background, on PowerNV we use the pcibios_sriov_enable() hook to do two things: 1. Create a pci_dn structure for each of the VFs, and 2. Configure the PHB's internal BARs so the MMIO range for each VF maps to a unique PE. Roughly speaking a PE is the hardware counterpart to a Linux IOMMU group since all the devices in a PE share the same IOMMU table. A PE also defines the set of devices that should be isolated in response to a PCI error (i.e. bad DMA, UR/CA, AER events, etc). When isolated all MMIO and DMA traffic to and from devicein the PE is blocked by the root complex until the PE is recovered by the OS. The requirement to block MMIO causes a giant headache because the P8 PHB generally uses a fixed mapping between MMIO addresses and PEs. As a result we need to delay configuring the IOMMU groups for device until after MMIO resources are assigned. For physical devices (i.e. non-VFs) the PE assignment is done in pcibios_setup_bridge() which is called immediately after the MMIO resources for downstream devices (and the bridge's windows) are assigned. For VFs the setup is more complicated because: a) pcibios_setup_bridge() is not called again when VFs are activated, and b) The pci_dev for VFs are created by generic code which runs after pcibios_sriov_enable() is called. The work around for this is a two step process: 1. A fixup in pcibios_add_device() is used to initialised the cached pe_number in pci_dn, then 2. A bus notifier then adds the device to the IOMMU group for the PE specified in pci_dn->pe_number. A side effect fixing the pseries bug mentioned in the first paragraph is moving the fixup out of pcibios_add_device() and into pcibios_bus_add_device(), which is called much later. This results in step 2. failing because pci_dn->pe_number won't be initialised when the bus notifier is run. We can fix this by removing the need for the fixup. The PE for a VF is known before the VF is even scanned so we can initialise pci_dn->pe_number pcibios_sriov_enable() instead. Unfortunately, moving the initialisation causes two problems: 1. We trip the WARN_ON() in the current fixup code, and 2. The EEH core clears pdn->pe_number when recovering a VF and relies on the fixup to correctly re-set it. The only justification for either of these is a comment in eeh_rmv_device() suggesting that pdn->pe_number *must* be set to IODA_INVALID_PE in order for the VF to be scanned. However, this comment appears to have no basis in reality. Both bugs can be fixed by just deleting the code. Tested-by: Alexey Kardashevskiy Reviewed-by: Alexey Kardashevskiy Signed-off-by: Oliver O'Halloran Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20191028085424.12006-1-oohall@gmail.com Signed-off-by: Sasha Levin commit 7c958ef1d0e906fd9f803d5e8fd3c77186895dc7 Author: Eugen Hristev Date: Tue Dec 10 11:25:19 2019 +0000 clk: at91: sam9x60: fix programmable clock prescaler [ Upstream commit 66d9f5214c9ba1c151478f99520b6817302d50dc ] The prescaler works as parent rate divided by (PRES + 1) (is_pres_direct == 1) It does not work in the way of parent rate shifted to the right by (PRES + 1), which means division by 2^(PRES + 1) (is_pres_direct == 0) Thus is_pres_direct must be enabled for this SoC, to make the right computation. This field was added in commit 45b06682113b ("clk: at91: fix programmable clock for sama5d2") SAM9X60 has the same field as SAMA5D2 in the PCK Fixes: 01e2113de9a5 ("clk: at91: add sam9x60 pmc driver") Signed-off-by: Eugen Hristev Link: https://lkml.kernel.org/r/1575977088-16781-1-git-send-email-eugen.hristev@microchip.com Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 826ea5eedbd5093fb3a4036dc00c97a4862a5ce5 Author: Chen-Yu Tsai Date: Sun Dec 15 17:59:14 2019 +0100 media: sun4i-csi: Fix [HV]sync polarity handling [ Upstream commit 1948dcf0f928b8bcdca57ca3fba8545ba380fc29 ] The Allwinner camera sensor interface has a different definition of [HV]sync. While the timing diagram uses the names HSYNC and VSYNC, the note following the diagram and register names use HREF and VREF. Combined they imply the hardware uses either [HV]REF or inverted [HV]SYNC. There are also registers to set horizontal skip lengths in pixels and vertical skip lengths in lines, also known as back porches. Fix the polarity handling by using the opposite polarity flag for the checks. Also rename `[hv]sync_pol` to `[hv]ref_pol` to better match the hardware register description. Fixes: 577bbf23b758 ("media: sunxi: Add A10 CSI driver") Signed-off-by: Chen-Yu Tsai Acked-by: Maxime Ripard Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 29e021f75114f4ba0af605d59ba2f03661b281aa Author: Chen-Yu Tsai Date: Sun Dec 15 17:59:13 2019 +0100 media: sun4i-csi: Fix data sampling polarity handling [ Upstream commit cf9e6d5dbdd56ef2aa72f28c806711c4293c8848 ] The CLK_POL field specifies whether data is sampled on the falling or rising edge of PCLK, not whether the data lines are active high or low. Evidence of this can be found in the timing diagram labeled "horizontal size setting and pixel clock timing". Fix the setting by checking the correct flag, V4L2_MBUS_PCLK_SAMPLE_RISING. While at it, reorder the three polarity flag checks so HSYNC and VSYNC are grouped together. Fixes: 577bbf23b758 ("media: sunxi: Add A10 CSI driver") Signed-off-by: Chen-Yu Tsai Acked-by: Maxime Ripard Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit a530c0153fcdebf5a0eb4f24f9e220b6026f1e0f Author: Chen-Yu Tsai Date: Sun Dec 15 17:59:15 2019 +0100 media: sun4i-csi: Deal with DRAM offset [ Upstream commit 249b286171fa9c358e8d5c825b48c4ebea97c498 ] On Allwinner SoCs, some high memory bandwidth devices do DMA directly over the memory bus (called MBUS), instead of the system bus. These devices include the CSI camera sensor interface, video (codec) engine, display subsystem, etc.. The memory bus has a different addressing scheme without the DRAM starting offset. Deal with this using the "interconnects" property from the device tree, or if that is not available, set dev->dma_pfn_offset to PHYS_PFN_OFFSET. Fixes: 577bbf23b758 ("media: sunxi: Add A10 CSI driver") Signed-off-by: Chen-Yu Tsai Acked-by: Maxime Ripard Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 0d654587c040542fa44af2aabaed221d97c20ba5 Author: Eugen Hristev Date: Thu Nov 21 08:55:24 2019 +0100 media: i2c: mt9v032: fix enum mbus codes and frame sizes [ Upstream commit 1451d5ae351d938a0ab1677498c893f17b9ee21d ] This driver supports both the mt9v032 (color) and the mt9v022 (mono) sensors. Depending on which sensor is used, the format from the sensor is different. The format.code inside the dev struct holds this information. The enum mbus and enum frame sizes need to take into account both type of sensors, not just the color one. To solve this, use the format.code in these functions instead of the hardcoded bayer color format (which is only used for mt9v032). [Sakari Ailus: rewrapped commit message] Suggested-by: Wenyou Yang Signed-off-by: Eugen Hristev Reviewed-by: Laurent Pinchart Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit d16175aa4b8002f33971144c1a9d6982846104c1 Author: Adam Ford Date: Tue Oct 29 13:42:11 2019 +0100 media: ov5640: Fix check for PLL1 exceeding max allowed rate [ Upstream commit 2e3df204f9af42a47823ee955c08950373417420 ] The variable _rate is by ov5640_compute_sys_clk() which returns zero if the PLL exceeds 1GHz. Unfortunately, the check to see if the max PLL1 output is checking 'rate' and not '_rate' and 'rate' does not ever appear to be 0. This patch changes the check against the returned value of '_rate' to determine if the PLL1 output exceeds 1GHz. Fixes: aa2882481cad ("media: ov5640: Adjust the clock based on the expected rate") Signed-off-by: Adam Ford Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit ce962bfa5a431850f3015f0b9beb2a69dbf3f5f2 Author: Christophe JAILLET Date: Sat Aug 31 12:00:24 2019 +0200 pxa168fb: Fix the function used to release some memory in an error handling path [ Upstream commit 3c911fe799d1c338d94b78e7182ad452c37af897 ] In the probe function, some resources are allocated using 'dma_alloc_wc()', they should be released with 'dma_free_wc()', not 'dma_free_coherent()'. We already use 'dma_free_wc()' in the remove function, but not in the error handling path of the probe function. Also, remove a useless 'PAGE_ALIGN()'. 'info->fix.smem_len' is already PAGE_ALIGNed. Fixes: 638772c7553f ("fb: add support of LCD display controller on pxa168/910 (base layer)") Signed-off-by: Christophe JAILLET Reviewed-by: Lubomir Rintel CC: YueHaibing Signed-off-by: Bartlomiej Zolnierkiewicz Link: https://patchwork.freedesktop.org/patch/msgid/20190831100024.3248-1-christophe.jaillet@wanadoo.fr Signed-off-by: Sasha Levin commit f68251ec2fdb571d9163561d92c77df4f5020307 Author: Rob Clark Date: Sun Nov 24 14:23:38 2019 -0800 drm/msm/adreno: fix zap vs no-zap handling [ Upstream commit 15ab987c423df561e0949d77fb5043921ae59956 ] We can have two cases, when it comes to "zap" fw. Either the fw requires zap fw to take the GPU out of secure mode at boot, or it does not and we can write RBBM_SECVID_TRUST_CNTL directly. Previously we decided based on whether zap fw load succeeded, but this is not a great plan because: 1) we could have zap fw in the filesystem on a device where it is not required 2) we could have the inverse case Instead, shift to deciding based on whether we have a 'zap-shader' node in dt. In practice, there is only one device (currently) with upstream dt that does not use zap (cheza), and it already has a /delete-node/ for the zap-shader node. Fixes: abccb9fe3267 ("drm/msm/a6xx: Add zap shader load") Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit a346d7a189d741b47e268230f047c8a1d7b8d6a4 Author: Geert Uytterhoeven Date: Mon Dec 30 14:06:04 2019 +0100 drm/mipi_dbi: Fix off-by-one bugs in mipi_dbi_blank() [ Upstream commit 2ce18249af5a28031b3f909cfafccc88ea966c9d ] When configuring the frame memory window, the last column and row numbers are written to the column resp. page address registers. These numbers are thus one less than the actual window width resp. height. While this is handled correctly in mipi_dbi_fb_dirty() since commit 03ceb1c8dfd1e293 ("drm/tinydrm: Fix setting of the column/page end addresses."), it is not in mipi_dbi_blank(). The latter still forgets to subtract one when calculating the most significant bytes of the column and row numbers, thus programming wrong values when the display width or height is a multiple of 256. Fixes: 02dd95fe31693626 ("drm/tinydrm: Add MIPI DBI support") Signed-off-by: Geert Uytterhoeven Signed-off-by: Noralf Trønnes Link: https://patchwork.freedesktop.org/patch/msgid/20191230130604.31006-1-geert+renesas@glider.be Signed-off-by: Sasha Levin commit f6d43de37882d04f3c4bfe1700648e5c2e1a78d0 Author: John Ogness Date: Thu Dec 19 12:59:22 2019 +0106 printk: fix exclusive_console replaying [ Upstream commit def97da136515cb289a14729292c193e0a93bc64 ] Commit f92b070f2dc8 ("printk: Do not miss new messages when replaying the log") introduced a new variable @exclusive_console_stop_seq to store when an exclusive console should stop printing. It should be set to the @console_seq value at registration. However, @console_seq is previously set to @syslog_seq so that the exclusive console knows where to begin. This results in the exclusive console immediately reactivating all the other consoles and thus repeating the messages for those consoles. Set @console_seq after @exclusive_console_stop_seq has stored the current @console_seq value. Fixes: f92b070f2dc8 ("printk: Do not miss new messages when replaying the log") Link: http://lkml.kernel.org/r/20191219115322.31160-1-john.ogness@linutronix.de Cc: Steven Rostedt Cc: linux-kernel@vger.kernel.org Signed-off-by: John Ogness Acked-by: Sergey Senozhatsky Signed-off-by: Petr Mladek Signed-off-by: Sasha Levin commit ea8088d73ac88caa622ca872a05fde9681fd239b Author: Geert Uytterhoeven Date: Wed Dec 18 20:48:09 2019 +0100 pinctrl: sh-pfc: sh7264: Fix CAN function GPIOs [ Upstream commit 55b1cb1f03ad5eea39897d0c74035e02deddcff2 ] pinmux_func_gpios[] contains a hole due to the missing function GPIO definition for the "CTX0&CTX1" signal, which is the logical "AND" of the two CAN outputs. Fix this by: - Renaming CRX0_CRX1_MARK to CTX0_CTX1_MARK, as PJ2MD[2:0]=010 configures the combined "CTX0&CTX1" output signal, - Renaming CRX0X1_MARK to CRX0_CRX1_MARK, as PJ3MD[1:0]=10 configures the shared "CRX0/CRX1" input signal, which is fed to both CAN inputs, - Adding the missing function GPIO definition for "CTX0&CTX1" to pinmux_func_gpios[], - Moving all CAN enums next to each other. See SH7262 Group, SH7264 Group User's Manual: Hardware, Rev. 4.00: [1] Figure 1.2 (3) (Pin Assignment for the SH7264 Group (1-Mbyte Version), [2] Figure 1.2 (4) Pin Assignment for the SH7264 Group (640-Kbyte Version, [3] Table 1.4 List of Pins, [4] Figure 20.29 Connection Example when Using This Module as 1-Channel Module (64 Mailboxes x 1 Channel), [5] Table 32.10 Multiplexed Pins (Port J), [6] Section 32.2.30 (3) Port J Control Register 0 (PJCR0). Note that the last 2 disagree about PJ2MD[2:0], which is probably the root cause of this bug. But considering [4], "CTx0&CTx1" in [5] must be correct, and "CRx0&CRx1" in [6] must be wrong. Signed-off-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/20191218194812.12741-4-geert+renesas@glider.be Signed-off-by: Sasha Levin commit 82adaf541fb2e93edeff9048879afc434dae82bd Author: Vladimir Oltean Date: Sat Dec 28 15:30:45 2019 +0200 gianfar: Fix TX timestamping with a stacked DSA driver [ Upstream commit c26a2c2ddc0115eb088873f5c309cf46b982f522 ] The driver wrongly assumes that it is the only entity that can set the SKBTX_IN_PROGRESS bit of the current skb. Therefore, in the gfar_clean_tx_ring function, where the TX timestamp is collected if necessary, the aforementioned bit is used to discriminate whether or not the TX timestamp should be delivered to the socket's error queue. But a stacked driver such as a DSA switch can also set the SKBTX_IN_PROGRESS bit, which is actually exactly what it should do in order to denote that the hardware timestamping process is undergoing. Therefore, gianfar would misinterpret the "in progress" bit as being its own, and deliver a second skb clone in the socket's error queue, completely throwing off a PTP process which is not expecting to receive it, _even though_ TX timestamping is not enabled for gianfar. There have been discussions [0] as to whether non-MAC drivers need or not to set SKBTX_IN_PROGRESS at all (whose purpose is to avoid sending 2 timestamps, a sw and a hw one, to applications which only expect one). But as of this patch, there are at least 2 PTP drivers that would break in conjunction with gianfar: the sja1105 DSA switch and the felix switch, by way of its ocelot core driver. So regardless of that conclusion, fix the gianfar driver to not do stuff based on flags set by others and not intended for it. [0]: https://www.spinics.net/lists/netdev/msg619699.html Fixes: f0ee7acfcdd4 ("gianfar: Add hardware TX timestamping support") Signed-off-by: Vladimir Oltean Acked-by: Richard Cochran Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 1dc2cef4cbaa0016c7d749a2ee429c4dc50637fc Author: Takashi Sakamoto Date: Mon Dec 23 18:33:47 2019 +0900 ALSA: ctl: allow TLV read operation for callback type of element in locked case [ Upstream commit d61fe22c2ae42d9fd76c34ef4224064cca4b04b0 ] A design of ALSA control core allows applications to execute three operations for TLV feature; read, write and command. Furthermore, it allows driver developers to process the operations by two ways; allocated array or callback function. In the former, read operation is just allowed, thus developers uses the latter when device driver supports variety of models or the target model is expected to dynamically change information stored in TLV container. The core also allows applications to lock any element so that the other applications can't perform write operation to the element for element value and TLV information. When the element is locked, write and command operation for TLV information are prohibited as well as element value. Any read operation should be allowed in the case. At present, when an element has callback function for TLV information, TLV read operation returns EPERM if the element is locked. On the other hand, the read operation is success when an element has allocated array for TLV information. In both cases, read operation is success for element value expectedly. This commit fixes the bug. This change can be backported to v4.14 kernel or later. Signed-off-by: Takashi Sakamoto Reviewed-by: Jaroslav Kysela Link: https://lore.kernel.org/r/20191223093347.15279-1-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 7d76c73903cc5dc2f06645e6f584f25f7d5f95ac Author: Ritesh Harjani Date: Thu Dec 12 11:25:55 2019 +0530 ext4: fix ext4_dax_read/write inode locking sequence for IOCB_NOWAIT [ Upstream commit f629afe3369e9885fd6e9cc7a4f514b6a65cf9e9 ] Apparently our current rwsem code doesn't like doing the trylock, then lock for real scheme. So change our dax read/write methods to just do the trylock for the RWF_NOWAIT case. This seems to fix AIM7 regression in some scalable filesystems upto ~25% in some cases. Claimed in commit 942491c9e6d6 ("xfs: fix AIM7 regression") Reviewed-by: Jan Kara Reviewed-by: Matthew Bobrowski Tested-by: Joseph Qi Signed-off-by: Ritesh Harjani Link: https://lore.kernel.org/r/20191212055557.11151-2-riteshh@linux.ibm.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit ed1e1ac052361a0d143cdda5882882a706df897d Author: Zahari Petkov Date: Mon Nov 18 23:02:55 2019 +0200 leds: pca963x: Fix open-drain initialization [ Upstream commit 697529091ac7a0a90ca349b914bb30641c13c753 ] Before commit bb29b9cccd95 ("leds: pca963x: Add bindings to invert polarity") Mode register 2 was initialized directly with either 0x01 or 0x05 for open-drain or totem pole (push-pull) configuration. Afterwards, MODE2 initialization started using bitwise operations on top of the default MODE2 register value (0x05). Using bitwise OR for setting OUTDRV with 0x01 and 0x05 does not produce correct results. When open-drain is used, instead of setting OUTDRV to 0, the driver keeps it as 1: Open-drain: 0x05 | 0x01 -> 0x05 (0b101 - incorrect) Totem pole: 0x05 | 0x05 -> 0x05 (0b101 - correct but still wrong) Now OUTDRV setting uses correct bitwise operations for initialization: Open-drain: 0x05 & ~0x04 -> 0x01 (0b001 - correct) Totem pole: 0x05 | 0x04 -> 0x05 (0b101 - correct) Additional MODE2 register definitions are introduced now as well. Fixes: bb29b9cccd95 ("leds: pca963x: Add bindings to invert polarity") Signed-off-by: Zahari Petkov Signed-off-by: Pavel Machek Signed-off-by: Sasha Levin commit 91cbd7ad5f94f335f3d58dd86085e939e6819528 Author: Nikola Cornij Date: Tue Nov 26 15:18:31 2019 -0500 drm/amd/display: Map ODM memory correctly when doing ODM combine [ Upstream commit ec5b356c58941bb8930858155d9ce14ceb3d30a0 ] [why] Up to 4 ODM memory pieces are required per ODM combine and cannot overlap, i.e. each ODM "session" has to use its own memory pieces. The ODM-memory mapping is currently broken for generic case. The maximum number of memory pieces is ASIC-dependent, but it's always big enough to satisfy maximum number of ODM combines. Memory pieces are mapped as a bit-map, i.e. one memory piece corresponds to one bit. The OPTC doing ODM needs to select memory pieces by setting the corresponding bits, making sure there's no overlap with other OPTC instances that might be doing ODM. The current mapping works only for OPTC instance indexes smaller than 3. For instance indexes 3 and up it practically maps no ODM memory, causing black, gray or white screen in display configs that include ODM on OPTC instance 3 or up. [how] Statically map two unique ODM memory pieces for each OPTC instance and piece them together when programming ODM combine mode. Signed-off-by: Nikola Cornij Reviewed-by: Jun Lei Acked-by: Rodrigo Siqueira Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 1f4037adfa4110297532628e008cc83c25553bf2 Author: James Sewart Date: Tue Dec 10 15:51:33 2019 -0600 PCI: Fix pci_add_dma_alias() bitmask size [ Upstream commit f8bf2aeb651b3460a4b36fd7ba1ba1d31777d35c ] The number of possible devfns is 256, but pci_add_dma_alias() allocated a bitmap of size 255. Fix this off-by-one error. This fixes commits 338c3149a221 ("PCI: Add support for multiple DMA aliases") and c6635792737b ("PCI: Allocate dma_alias_mask with bitmap_zalloc()"), but I doubt it was possible to see a problem because it takes 4 64-bit longs (or 8 32-bit longs) to hold 255 bits, and bitmap_zalloc() doesn't save the 255-bit size anywhere. [bhelgaas: commit log, move #define to drivers/pci/pci.h, include loop limit fix from Qian Cai: https://lore.kernel.org/r/20191218170004.5297-1-cai@lca.pw] Signed-off-by: James Sewart Signed-off-by: Bjorn Helgaas Reviewed-by: Logan Gunthorpe Signed-off-by: Sasha Levin commit fa0c8172a900f8e770c66a42999a70f11fd01f0a Author: Dan Carpenter Date: Tue Dec 3 12:58:55 2019 +0300 brcmfmac: Fix use after free in brcmf_sdio_readframes() [ Upstream commit 216b44000ada87a63891a8214c347e05a4aea8fe ] The brcmu_pkt_buf_free_skb() function frees "pkt" so it leads to a static checker warning: drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c:1974 brcmf_sdio_readframes() error: dereferencing freed memory 'pkt' It looks like there was supposed to be a continue after we free "pkt". Fixes: 4754fceeb9a6 ("brcmfmac: streamline SDIO read frame routine") Signed-off-by: Dan Carpenter Acked-by: Franky Lin Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit 9f969d4a56777c6264a7492c412511ee52d0e9d1 Author: Navid Emamdoost Date: Fri Nov 22 13:19:48 2019 -0600 brcmfmac: Fix memory leak in brcmf_p2p_create_p2pdev() [ Upstream commit 5cc509aa83c6acd2c5cd94f99065c39d2bd0a490 ] In the implementation of brcmf_p2p_create_p2pdev() the allocated memory for p2p_vif is leaked when the mac address is the same as primary interface. To fix this, go to error path to release p2p_vif via brcmf_free_vif(). Fixes: cb746e47837a ("brcmfmac: check p2pdev mac address uniqueness") Signed-off-by: Navid Emamdoost Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit 946f53efafd21ab6f172560bd62fe27b15175c76 Author: Wei Yongjun Date: Thu Dec 12 11:46:22 2019 +0000 dmaengine: ti: edma: Fix error return code in edma_probe() [ Upstream commit d1fd03a35efc6285e43f4ef35ef04dbf2c9389c6 ] Fix to return negative error code -ENOMEM from the error handling case instead of 0, as done elsewhere in this function. Fixes: 2a03c1314506 ("dmaengine: ti: edma: add missed operations") Signed-off-by: Wei Yongjun Acked-by: Peter Ujfalusi Link: https://lore.kernel.org/r/20191212114622.127322-1-weiyongjun1@huawei.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 1989fb67952380ab203de5e7475cba79456da485 Author: Geert Uytterhoeven Date: Tue Nov 5 19:35:03 2019 +0100 drm: rcar-du: Recognize "renesas,vsps" in addition to "vsps" [ Upstream commit 7b627ce80fbd05885b27f711a5f9820f2b40749a ] The Renesas-specific "vsps" property lacks a vendor prefix. Add a "renesas," prefix to comply with DT best practises. Retain backward compatibility with old DTBs by falling back to "vsps" when needed. Fixes: 6d62ef3ac30be756 ("drm: rcar-du: Expose the VSP1 compositor through KMS planes") Signed-off-by: Geert Uytterhoeven Reviewed-by: Laurent Pinchart Signed-off-by: Laurent Pinchart Signed-off-by: Sasha Levin commit bb197164fbd34a0f738928407bfdb55631cb5a54 Author: Peter Zijlstra Date: Tue Dec 10 09:34:54 2019 +0100 cpu/hotplug, stop_machine: Fix stop_machine vs hotplug order [ Upstream commit 45178ac0cea853fe0e405bf11e101bdebea57b15 ] Paul reported a very sporadic, rcutorture induced, workqueue failure. When the planets align, the workqueue rescuer's self-migrate fails and then triggers a WARN for running a work on the wrong CPU. Tejun then figured that set_cpus_allowed_ptr()'s stop_one_cpu() call could be ignored! When stopper->enabled is false, stop_machine will insta complete the work, without actually doing the work. Worse, it will not WARN about this (we really should fix this). It turns out there is a small window where a freshly online'ed CPU is marked 'online' but doesn't yet have the stopper task running: BP AP bringup_cpu() __cpu_up(cpu, idle) --> start_secondary() ... cpu_startup_entry() bringup_wait_for_ap() wait_for_ap_thread() <-- cpuhp_online_idle() while (1) do_idle() ... available to run kthreads ... stop_machine_unpark() stopper->enable = true; Close this by moving the stop_machine_unpark() into cpuhp_online_idle(), such that the stopper thread is ready before we start the idle loop and schedule. Reported-by: "Paul E. McKenney" Debugged-by: Tejun Heo Signed-off-by: Peter Zijlstra (Intel) Tested-by: "Paul E. McKenney" Signed-off-by: Sasha Levin commit 3afc6cef6a0aa04e311c3884818643cc9f72e946 Author: Remi Pommarel Date: Sun Dec 15 12:47:05 2019 +0100 clk: meson: pll: Fix by 0 division in __pll_params_to_rate() [ Upstream commit d8488a41800d9f5c80bc0d17b9cc2c91b4841464 ] Some meson pll registers can be initialized with 0 as N value, introducing the following division by 0 when computing rate : UBSAN: Undefined behaviour in drivers/clk/meson/clk-pll.c:75:9 division by zero CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.4.0-rc3-608075-g86c9af8630e1-dirty #400 Call trace: dump_backtrace+0x0/0x1c0 show_stack+0x14/0x20 dump_stack+0xc4/0x100 ubsan_epilogue+0x14/0x68 __ubsan_handle_divrem_overflow+0x98/0xb8 __pll_params_to_rate+0xdc/0x140 meson_clk_pll_recalc_rate+0x278/0x3a0 __clk_register+0x7c8/0xbb0 devm_clk_hw_register+0x54/0xc0 meson_eeclkc_probe+0xf4/0x1a0 platform_drv_probe+0x54/0xd8 really_probe+0x16c/0x438 driver_probe_device+0xb0/0xf0 device_driver_attach+0x94/0xa0 __driver_attach+0x70/0x108 bus_for_each_dev+0xd8/0x128 driver_attach+0x30/0x40 bus_add_driver+0x1b0/0x2d8 driver_register+0xbc/0x1d0 __platform_driver_register+0x78/0x88 axg_driver_init+0x18/0x20 do_one_initcall+0xc8/0x24c kernel_init_freeable+0x2b0/0x344 kernel_init+0x10/0x128 ret_from_fork+0x10/0x18 This checks if N is null before doing the division. Fixes: 7a29a869434e ("clk: meson: Add support for Meson clock controller") Reviewed-by: Martin Blumenstingl Signed-off-by: Remi Pommarel [jbrunet@baylibre.com: update the comment in above the fix] Signed-off-by: Jerome Brunet Signed-off-by: Sasha Levin commit e4629dcf3e9b0f216028e7ef68661fb4e2535bf6 Author: Colin Ian King Date: Wed Dec 4 15:11:59 2019 +0100 media: meson: add missing allocation failure check on new_buf [ Upstream commit 11e0e167d071a28288a7a0a211d48c571d19b56f ] Currently if the allocation of new_buf fails then a null pointer dereference occurs when assiging new_buf->vb. Avoid this by returning early on a memory allocation failure as there is not much more can be done at this point. Addresses-Coverity: ("Dereference null return") Fixes: 3e7f51bd9607 ("media: meson: add v4l2 m2m video decoder driver") Signed-off-by: Colin Ian King Reviewed-by: Kevin Hilman Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit c0be016cba16e7b08d3d673a397addd35f53c749 Author: Jaegeuk Kim Date: Tue Dec 3 15:53:16 2019 -0800 f2fs: call f2fs_balance_fs outside of locked page [ Upstream commit bdf03299248916640a835a05d32841bb3d31912d ] Otherwise, we can hit deadlock by waiting for the locked page in move_data_block in GC. Thread A Thread B - do_page_mkwrite - f2fs_vm_page_mkwrite - lock_page - f2fs_balance_fs - mutex_lock(gc_mutex) - f2fs_gc - do_garbage_collect - ra_data_block - grab_cache_page - f2fs_balance_fs - mutex_lock(gc_mutex) Fixes: 39a8695824510 ("f2fs: refactor ->page_mkwrite() flow") Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 87ca739b1e9057115b1cd01c47388f0143cf4ea4 Author: Jaegeuk Kim Date: Tue Nov 26 15:01:42 2019 -0800 f2fs: preallocate DIO blocks when forcing buffered_io [ Upstream commit 47501f87c61ad2aa234add63e1ae231521dbc3f5 ] The previous preallocation and DIO decision like below. allow_outplace_dio !allow_outplace_dio f2fs_force_buffered_io (*) No_Prealloc / Buffered_IO Prealloc / Buffered_IO !f2fs_force_buffered_io No_Prealloc / DIO Prealloc / DIO But, Javier reported Case (*) where zoned device bypassed preallocation but fell back to buffered writes in f2fs_direct_IO(), resulting in stale data being read. In order to fix the issue, actually we need to preallocate blocks whenever we fall back to buffered IO like this. No change is made in the other cases. allow_outplace_dio !allow_outplace_dio f2fs_force_buffered_io (*) Prealloc / Buffered_IO Prealloc / Buffered_IO !f2fs_force_buffered_io No_Prealloc / DIO Prealloc / DIO Reported-and-tested-by: Javier Gonzalez Signed-off-by: Damien Le Moal Tested-by: Shin'ichiro Kawasaki Reviewed-by: Chao Yu Reviewed-by: Javier González Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 84260a1940b84078101a254dfc7c97df14f71e7b Author: Chuhong Yuan Date: Sun Nov 24 13:28:55 2019 +0800 dmaengine: ti: edma: add missed operations [ Upstream commit 2a03c1314506557277829562dd2ec5c11a6ea914 ] The driver forgets to call pm_runtime_disable and pm_runtime_put_sync in probe failure and remove. Add the calls and modify probe failure handling to fix it. To simplify the fix, the patch adjusts the calling order and merges checks for devm_kcalloc. Fixes: 2b6b3b742019 ("ARM/dmaengine: edma: Merge the two drivers under drivers/dma/") Signed-off-by: Chuhong Yuan Acked-by: Peter Ujfalusi Link: https://lore.kernel.org/r/20191124052855.6472-1-hslester96@gmail.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 708d5ca30ff954393c7d934b415238c85bef8942 Author: Marco Elver Date: Wed Oct 9 17:57:43 2019 +0200 rcu: Fix data-race due to atomic_t copy-by-value [ Upstream commit 6cf539a87a61a4fbc43f625267dbcbcf283872ed ] This fixes a data-race where `atomic_t dynticks` is copied by value. The copy is performed non-atomically, resulting in a data-race if `dynticks` is updated concurrently. This data-race was found with KCSAN: ================================================================== BUG: KCSAN: data-race in dyntick_save_progress_counter / rcu_irq_enter write to 0xffff989dbdbe98e0 of 4 bytes by task 10 on cpu 3: atomic_add_return include/asm-generic/atomic-instrumented.h:78 [inline] rcu_dynticks_snap kernel/rcu/tree.c:310 [inline] dyntick_save_progress_counter+0x43/0x1b0 kernel/rcu/tree.c:984 force_qs_rnp+0x183/0x200 kernel/rcu/tree.c:2286 rcu_gp_fqs kernel/rcu/tree.c:1601 [inline] rcu_gp_fqs_loop+0x71/0x880 kernel/rcu/tree.c:1653 rcu_gp_kthread+0x22c/0x3b0 kernel/rcu/tree.c:1799 kthread+0x1b5/0x200 kernel/kthread.c:255 read to 0xffff989dbdbe98e0 of 4 bytes by task 154 on cpu 7: rcu_nmi_enter_common kernel/rcu/tree.c:828 [inline] rcu_irq_enter+0xda/0x240 kernel/rcu/tree.c:870 irq_enter+0x5/0x50 kernel/softirq.c:347 Reported by Kernel Concurrency Sanitizer on: CPU: 7 PID: 154 Comm: kworker/7:1H Not tainted 5.3.0+ #5 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 Workqueue: kblockd blk_mq_run_work_fn ================================================================== Signed-off-by: Marco Elver Cc: Paul E. McKenney Cc: Josh Triplett Cc: Steven Rostedt Cc: Mathieu Desnoyers Cc: Joel Fernandes Cc: Ingo Molnar Cc: Dmitry Vyukov Cc: rcu@vger.kernel.org Cc: linux-kernel@vger.kernel.org Reviewed-by: Joel Fernandes (Google) Signed-off-by: Paul E. McKenney Signed-off-by: Sasha Levin commit d8f649f2d63768508f514f1ae781358a1ddcf95f Author: Neeraj Upadhyay Date: Tue Nov 19 03:17:07 2019 +0000 rcu: Fix missed wakeup of exp_wq waiters [ Upstream commit fd6bc19d7676a060a171d1cf3dcbf6fd797eb05f ] Tasks waiting within exp_funnel_lock() for an expedited grace period to elapse can be starved due to the following sequence of events: 1. Tasks A and B both attempt to start an expedited grace period at about the same time. This grace period will have completed when the lower four bits of the rcu_state structure's ->expedited_sequence field are 0b'0100', for example, when the initial value of this counter is zero. Task A wins, and thus does the actual work of starting the grace period, including acquiring the rcu_state structure's .exp_mutex and sets the counter to 0b'0001'. 2. Because task B lost the race to start the grace period, it waits on ->expedited_sequence to reach 0b'0100' inside of exp_funnel_lock(). This task therefore blocks on the rcu_node structure's ->exp_wq[1] field, keeping in mind that the end-of-grace-period value of ->expedited_sequence (0b'0100') is shifted down two bits before indexing the ->exp_wq[] field. 3. Task C attempts to start another expedited grace period, but blocks on ->exp_mutex, which is still held by Task A. 4. The aforementioned expedited grace period completes, so that ->expedited_sequence now has the value 0b'0100'. A kworker task therefore acquires the rcu_state structure's ->exp_wake_mutex and starts awakening any tasks waiting for this grace period. 5. One of the first tasks awakened happens to be Task A. Task A therefore releases the rcu_state structure's ->exp_mutex, which allows Task C to start the next expedited grace period, which causes the lower four bits of the rcu_state structure's ->expedited_sequence field to become 0b'0101'. 6. Task C's expedited grace period completes, so that the lower four bits of the rcu_state structure's ->expedited_sequence field now become 0b'1000'. 7. The kworker task from step 4 above continues its wakeups. Unfortunately, the wake_up_all() refetches the rcu_state structure's .expedited_sequence field: wake_up_all(&rnp->exp_wq[rcu_seq_ctr(rcu_state.expedited_sequence) & 0x3]); This results in the wakeup being applied to the rcu_node structure's ->exp_wq[2] field, which is unfortunate given that Task B is instead waiting on ->exp_wq[1]. On a busy system, no harm is done (or at least no permanent harm is done). Some later expedited grace period will redo the wakeup. But on a quiet system, such as many embedded systems, it might be a good long time before there was another expedited grace period. On such embedded systems, this situation could therefore result in a system hang. This issue manifested as DPM device timeout during suspend (which usually qualifies as a quiet time) due to a SCSI device being stuck in _synchronize_rcu_expedited(), with the following stack trace: schedule() synchronize_rcu_expedited() synchronize_rcu() scsi_device_quiesce() scsi_bus_suspend() dpm_run_callback() __device_suspend() This commit therefore prevents such delays, timeouts, and hangs by making rcu_exp_wait_wake() use its "s" argument consistently instead of refetching from rcu_state.expedited_sequence. Fixes: 3b5f668e715b ("rcu: Overlap wakeups with next expedited grace period") Signed-off-by: Neeraj Upadhyay Signed-off-by: Paul E. McKenney Signed-off-by: Sasha Levin commit 6be1b9794e7e93eb785783a543c091e9bc645b9e Author: Stefan Reiter Date: Fri Oct 4 19:49:10 2019 +0000 rcu/nocb: Fix dump_tree hierarchy print always active [ Upstream commit 610dea36d3083a977e4f156206cbe1eaa2a532f0 ] Commit 18cd8c93e69e ("rcu/nocb: Print gp/cb kthread hierarchy if dump_tree") added print statements to rcu_organize_nocb_kthreads for debugging, but incorrectly guarded them, causing the function to always spew out its message. This patch fixes it by guarding both pr_alert statements with dump_tree, while also changing the second pr_alert to a pr_cont, to print the hierarchy in a single line (assuming that's how it was supposed to work). Fixes: 18cd8c93e69e ("rcu/nocb: Print gp/cb kthread hierarchy if dump_tree") Signed-off-by: Stefan Reiter [ paulmck: Make single-nocbs-CPU GP kthreads look less erroneous. ] Signed-off-by: Paul E. McKenney Signed-off-by: Sasha Levin commit 12a2bc13056ada36af2f7cdf1a0c1b69cf3d12a4 Author: Markus Elfring Date: Thu Nov 7 18:05:08 2019 +0100 drm/qxl: Complete exception handling in qxl_device_init() [ Upstream commit dbe3ad61dcebc49fe3efca70a0f752a95b4600f2 ] A coccicheck run provided information like the following. drivers/gpu/drm/qxl/qxl_kms.c:295:1-7: ERROR: missing iounmap; ioremap on line 178 and execution via conditional on line 185 Generated by: scripts/coccinelle/free/iounmap.cocci A jump target was specified in an if branch. The corresponding function call did not release the desired system resource then. Thus use the label “rom_unmap” instead to fix the exception handling for this function implementation. Fixes: 5043348a4969ae1661c008efe929abd0d76e3792 ("drm: qxl: Fix error handling at qxl_device_init") Signed-off-by: Markus Elfring Link: http://patchwork.freedesktop.org/patch/msgid/5e5ef9c4-4d85-3c93-cf28-42cfcb5b0649@web.de Signed-off-by: Gerd Hoffmann Signed-off-by: Sasha Levin commit c0b4d16b828627c166bb79ada02cf245d1942ceb Author: Gerd Hoffmann Date: Wed Oct 23 08:25:37 2019 +0200 drm/virtio: fix byteorder handling in virtio_gpu_cmd_transfer_{from, to}_host_3d functions [ Upstream commit 1dc3485247170d3b88a21cadee7f7da1f0433495 ] Be consistent with the rest of the code base. No functional change. v2: - fix sparse warnings for virtio_gpu_cmd_transfer_to_host_2d call. - move convert_to_hw_box helper function. Signed-off-by: Gerd Hoffmann Reviewed-by: Gurchetan Singh Link: http://patchwork.freedesktop.org/patch/msgid/20191023062539.11728-2-kraxel@redhat.com Signed-off-by: Sasha Levin commit 88c967ce4ae84792585eb58d19166aaf1e85ce6a Author: Colin Ian King Date: Fri Nov 15 12:09:53 2019 +0000 wil6210: fix break that is never reached because of zero'ing of a retry counter [ Upstream commit 5b1413f00b5beb9f5fed94e43ea0c497d5db9633 ] There is a check on the retry counter invalid_buf_id_retry that is always false because invalid_buf_id_retry is initialized to zero on each iteration of a while-loop. Fix this by initializing the retry counter before the while-loop starts. Addresses-Coverity: ("Logically dead code") Fixes: b4a967b7d0f5 ("wil6210: reset buff id in status message after completion") Signed-off-by: Colin Ian King Reviewed-by: Maya Erez Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit 9ad8cf00519b0c99c47e75a900d5eac704c6ab59 Author: Jeffrey Hugo Date: Wed Nov 13 07:40:16 2019 -0800 ath10k: Fix qmi init error handling [ Upstream commit f8a595a87e93a33a10879f4b856be818d2f53c84 ] When ath10k_qmi_init() fails, the error handling does not free the irq resources, which causes an issue if we EPROBE_DEFER as we'll attempt to (re-)register irqs which are already registered. Fix this by doing a power off since we just powered on the hardware, and freeing the irqs as error handling. Fixes: ba94c753ccb4 ("ath10k: add QMI message handshake for wcn3990 client") Signed-off-by: Jeffrey Hugo Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit 47a84a554af9f802bac0e37ac037ffe78c1ce110 Author: Colin Ian King Date: Wed Nov 20 17:35:09 2019 +0000 drm/dp_mst: fix multiple frees of tx->bytes [ Upstream commit 2c8bc91488fc57438c43b3bb19deb7fdbc1e5119 ] Currently tx->bytes is being freed r->num_transactions number of times because tx is not being set correctly. Fix this by setting tx to &r->transactions[i] so that the correct objects are being freed on each loop iteration. Addresses-Coverity: ("Double free") Fixes: 2f015ec6eab6 ("drm/dp_mst: Add sideband down request tracing + selftests") Signed-off-by: Colin Ian King Signed-off-by: Lyude Paul Link: https://patchwork.freedesktop.org/patch/msgid/20191120173509.347490-1-colin.king@canonical.com Signed-off-by: Sasha Levin commit 5d3eb3d8e56a80e656795c6c3779e39ee7b6aa48 Author: Paul Kocialkowski Date: Thu Nov 7 16:30:48 2019 +0100 drm/gma500: Fixup fbdev stolen size usage evaluation [ Upstream commit fd1a5e521c3c083bb43ea731aae0f8b95f12b9bd ] psbfb_probe performs an evaluation of the required size from the stolen GTT memory, but gets it wrong in two distinct ways: - The resulting size must be page-size-aligned; - The size to allocate is derived from the surface dimensions, not the fb dimensions. When two connectors are connected with different modes, the smallest will be stored in the fb dimensions, but the size that needs to be allocated must match the largest (surface) dimensions. This is what is used in the actual allocation code. Fix this by correcting the evaluation to conform to the two points above. It allows correctly switching to 16bpp when one connector is e.g. 1920x1080 and the other is 1024x768. Signed-off-by: Paul Kocialkowski Signed-off-by: Patrik Jakobsson Link: https://patchwork.freedesktop.org/patch/msgid/20191107153048.843881-1-paul.kocialkowski@bootlin.com Signed-off-by: Sasha Levin commit ba7cd5ea6f58548001901fb90bdef88e7450959a Author: Davide Caratti Date: Tue Feb 11 19:33:40 2020 +0100 net/sched: flower: add missing validation of TCA_FLOWER_FLAGS [ Upstream commit e2debf0852c4d66ba1a8bde12869b196094c70a7 ] unlike other classifiers that can be offloaded (i.e. users can set flags like 'skip_hw' and 'skip_sw'), 'cls_flower' doesn't validate the size of netlink attribute 'TCA_FLOWER_FLAGS' provided by user: add a proper entry to fl_policy. Fixes: 5b33f48842fa ("net/flower: Introduce hardware offload support") Signed-off-by: Davide Caratti Acked-by: Jiri Pirko Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 77148b7ae8494347fffbf9467c1f7c732de4eab2 Author: Davide Caratti Date: Tue Feb 11 19:33:39 2020 +0100 net/sched: matchall: add missing validation of TCA_MATCHALL_FLAGS [ Upstream commit 1afa3cc90f8fb745c777884d79eaa1001d6927a6 ] unlike other classifiers that can be offloaded (i.e. users can set flags like 'skip_hw' and 'skip_sw'), 'cls_matchall' doesn't validate the size of netlink attribute 'TCA_MATCHALL_FLAGS' provided by user: add a proper entry to mall_policy. Fixes: b87f7936a932 ("net/sched: Add match-all classifier hw offloading.") Signed-off-by: Davide Caratti Acked-by: Jiri Pirko Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 67fd7af31fe05d725debcf2b2fe88740d8de26d0 Author: Per Forlin Date: Thu Feb 13 15:37:09 2020 +0100 net: dsa: tag_qca: Make sure there is headroom for tag [ Upstream commit 04fb91243a853dbde216d829c79d9632e52aa8d9 ] Passing tag size to skb_cow_head will make sure there is enough headroom for the tag data. This change does not introduce any overhead in case there is already available headroom for tag. Signed-off-by: Per Forlin Reviewed-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 50113bbd2ce29e5351fd74a469fd3e9c5b4ec49b Author: Eric Dumazet Date: Mon Feb 10 11:36:13 2020 -0800 net/smc: fix leak of kernel memory to user space [ Upstream commit 457fed775c97ac2c0cd1672aaf2ff2c8a6235e87 ] As nlmsg_put() does not clear the memory that is reserved, it this the caller responsability to make sure all of this memory will be written, in order to not reveal prior content. While we are at it, we can provide the socket cookie even if clsock is not set. syzbot reported : BUG: KMSAN: uninit-value in __arch_swab32 arch/x86/include/uapi/asm/swab.h:10 [inline] BUG: KMSAN: uninit-value in __fswab32 include/uapi/linux/swab.h:59 [inline] BUG: KMSAN: uninit-value in __swab32p include/uapi/linux/swab.h:179 [inline] BUG: KMSAN: uninit-value in __be32_to_cpup include/uapi/linux/byteorder/little_endian.h:82 [inline] BUG: KMSAN: uninit-value in get_unaligned_be32 include/linux/unaligned/access_ok.h:30 [inline] BUG: KMSAN: uninit-value in ____bpf_skb_load_helper_32 net/core/filter.c:240 [inline] BUG: KMSAN: uninit-value in ____bpf_skb_load_helper_32_no_cache net/core/filter.c:255 [inline] BUG: KMSAN: uninit-value in bpf_skb_load_helper_32_no_cache+0x14a/0x390 net/core/filter.c:252 CPU: 1 PID: 5262 Comm: syz-executor.5 Not tainted 5.5.0-rc5-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1c9/0x220 lib/dump_stack.c:118 kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:118 __msan_warning+0x58/0xa0 mm/kmsan/kmsan_instr.c:215 __arch_swab32 arch/x86/include/uapi/asm/swab.h:10 [inline] __fswab32 include/uapi/linux/swab.h:59 [inline] __swab32p include/uapi/linux/swab.h:179 [inline] __be32_to_cpup include/uapi/linux/byteorder/little_endian.h:82 [inline] get_unaligned_be32 include/linux/unaligned/access_ok.h:30 [inline] ____bpf_skb_load_helper_32 net/core/filter.c:240 [inline] ____bpf_skb_load_helper_32_no_cache net/core/filter.c:255 [inline] bpf_skb_load_helper_32_no_cache+0x14a/0x390 net/core/filter.c:252 Uninit was created at: kmsan_save_stack_with_flags mm/kmsan/kmsan.c:144 [inline] kmsan_internal_poison_shadow+0x66/0xd0 mm/kmsan/kmsan.c:127 kmsan_kmalloc_large+0x73/0xc0 mm/kmsan/kmsan_hooks.c:128 kmalloc_large_node_hook mm/slub.c:1406 [inline] kmalloc_large_node+0x282/0x2c0 mm/slub.c:3841 __kmalloc_node_track_caller+0x44b/0x1200 mm/slub.c:4368 __kmalloc_reserve net/core/skbuff.c:141 [inline] __alloc_skb+0x2fd/0xac0 net/core/skbuff.c:209 alloc_skb include/linux/skbuff.h:1049 [inline] netlink_dump+0x44b/0x1ab0 net/netlink/af_netlink.c:2224 __netlink_dump_start+0xbb2/0xcf0 net/netlink/af_netlink.c:2352 netlink_dump_start include/linux/netlink.h:233 [inline] smc_diag_handler_dump+0x2ba/0x300 net/smc/smc_diag.c:242 sock_diag_rcv_msg+0x211/0x610 net/core/sock_diag.c:256 netlink_rcv_skb+0x451/0x650 net/netlink/af_netlink.c:2477 sock_diag_rcv+0x63/0x80 net/core/sock_diag.c:275 netlink_unicast_kernel net/netlink/af_netlink.c:1302 [inline] netlink_unicast+0xf9e/0x1100 net/netlink/af_netlink.c:1328 netlink_sendmsg+0x1248/0x14d0 net/netlink/af_netlink.c:1917 sock_sendmsg_nosec net/socket.c:639 [inline] sock_sendmsg net/socket.c:659 [inline] kernel_sendmsg+0x433/0x440 net/socket.c:679 sock_no_sendpage+0x235/0x300 net/core/sock.c:2740 kernel_sendpage net/socket.c:3776 [inline] sock_sendpage+0x1e1/0x2c0 net/socket.c:937 pipe_to_sendpage+0x38c/0x4c0 fs/splice.c:458 splice_from_pipe_feed fs/splice.c:512 [inline] __splice_from_pipe+0x539/0xed0 fs/splice.c:636 splice_from_pipe fs/splice.c:671 [inline] generic_splice_sendpage+0x1d5/0x2d0 fs/splice.c:844 do_splice_from fs/splice.c:863 [inline] do_splice fs/splice.c:1170 [inline] __do_sys_splice fs/splice.c:1447 [inline] __se_sys_splice+0x2380/0x3350 fs/splice.c:1427 __x64_sys_splice+0x6e/0x90 fs/splice.c:1427 do_syscall_64+0xb8/0x160 arch/x86/entry/common.c:296 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Fixes: f16a7dd5cf27 ("smc: netlink interface for SMC sockets") Signed-off-by: Eric Dumazet Cc: Ursula Braun Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit fbaaba9639efd03e34c4361ec7e76b7a776d0e77 Author: Firo Yang Date: Wed Feb 12 06:09:17 2020 +0100 enic: prevent waking up stopped tx queues over watchdog reset [ Upstream commit 0f90522591fd09dd201065c53ebefdfe3c6b55cb ] Recent months, our customer reported several kernel crashes all preceding with following message: NETDEV WATCHDOG: eth2 (enic): transmit queue 0 timed out Error message of one of those crashes: BUG: unable to handle kernel paging request at ffffffffa007e090 After analyzing severl vmcores, I found that most of crashes are caused by memory corruption. And all the corrupted memory areas are overwritten by data of network packets. Moreover, I also found that the tx queues were enabled over watchdog reset. After going through the source code, I found that in enic_stop(), the tx queues stopped by netif_tx_disable() could be woken up over a small time window between netif_tx_disable() and the napi_disable() by the following code path: napi_poll-> enic_poll_msix_wq-> vnic_cq_service-> enic_wq_service-> netif_wake_subqueue(enic->netdev, q_number)-> test_and_clear_bit(__QUEUE_STATE_DRV_XOFF, &txq->state) In turn, upper netowrk stack could queue skb to ENIC NIC though enic_hard_start_xmit(). And this might introduce some race condition. Our customer comfirmed that this kind of kernel crash doesn't occur over 90 days since they applied this patch. Signed-off-by: Firo Yang Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 1d4b33306388339b6cb02d889b43295ef81c79ed Author: Toke Høiland-Jørgensen Date: Mon Feb 10 17:10:46 2020 +0100 core: Don't skip generic XDP program execution for cloned SKBs [ Upstream commit ad1e03b2b3d4430baaa109b77bc308dc73050de3 ] The current generic XDP handler skips execution of XDP programs entirely if an SKB is marked as cloned. This leads to some surprising behaviour, as packets can end up being cloned in various ways, which will make an XDP program not see all the traffic on an interface. This was discovered by a simple test case where an XDP program that always returns XDP_DROP is installed on a veth device. When combining this with the Scapy packet sniffer (which uses an AF_PACKET) socket on the sending side, SKBs reliably end up in the cloned state, causing them to be passed through to the receiving interface instead of being dropped. A minimal reproducer script for this is included below. This patch fixed the issue by simply triggering the existing linearisation code for cloned SKBs instead of skipping the XDP program execution. This behaviour is in line with the behaviour of the native XDP implementation for the veth driver, which will reallocate and copy the SKB data if the SKB is marked as shared. Reproducer Python script (requires BCC and Scapy): from scapy.all import TCP, IP, Ether, sendp, sniff, AsyncSniffer, Raw, UDP from bcc import BPF import time, sys, subprocess, shlex SKB_MODE = (1 << 1) DRV_MODE = (1 << 2) PYTHON=sys.executable def client(): time.sleep(2) # Sniffing on the sender causes skb_cloned() to be set s = AsyncSniffer() s.start() for p in range(10): sendp(Ether(dst="aa:aa:aa:aa:aa:aa", src="cc:cc:cc:cc:cc:cc")/IP()/UDP()/Raw("Test"), verbose=False) time.sleep(0.1) s.stop() return 0 def server(mode): prog = BPF(text="int dummy_drop(struct xdp_md *ctx) {return XDP_DROP;}") func = prog.load_func("dummy_drop", BPF.XDP) prog.attach_xdp("a_to_b", func, mode) time.sleep(1) s = sniff(iface="a_to_b", count=10, timeout=15) if len(s): print(f"Got {len(s)} packets - should have gotten 0") return 1 else: print("Got no packets - as expected") return 0 if len(sys.argv) < 2: print(f"Usage: {sys.argv[0]} ") sys.exit(1) if sys.argv[1] == "client": sys.exit(client()) elif sys.argv[1] == "server": mode = SKB_MODE if sys.argv[2] == 'skb' else DRV_MODE sys.exit(server(mode)) else: try: mode = sys.argv[1] if mode not in ('skb', 'drv'): print(f"Usage: {sys.argv[0]} ") sys.exit(1) print(f"Running in {mode} mode") for cmd in [ 'ip netns add netns_a', 'ip netns add netns_b', 'ip -n netns_a link add a_to_b type veth peer name b_to_a netns netns_b', # Disable ipv6 to make sure there's no address autoconf traffic 'ip netns exec netns_a sysctl -qw net.ipv6.conf.a_to_b.disable_ipv6=1', 'ip netns exec netns_b sysctl -qw net.ipv6.conf.b_to_a.disable_ipv6=1', 'ip -n netns_a link set dev a_to_b address aa:aa:aa:aa:aa:aa', 'ip -n netns_b link set dev b_to_a address cc:cc:cc:cc:cc:cc', 'ip -n netns_a link set dev a_to_b up', 'ip -n netns_b link set dev b_to_a up']: subprocess.check_call(shlex.split(cmd)) server = subprocess.Popen(shlex.split(f"ip netns exec netns_a {PYTHON} {sys.argv[0]} server {mode}")) client = subprocess.Popen(shlex.split(f"ip netns exec netns_b {PYTHON} {sys.argv[0]} client")) client.wait() server.wait() sys.exit(server.returncode) finally: subprocess.run(shlex.split("ip netns delete netns_a")) subprocess.run(shlex.split("ip netns delete netns_b")) Fixes: d445516966dc ("net: xdp: support xdp generic on virtual devices") Reported-by: Stepan Horacek Suggested-by: Paolo Abeni Signed-off-by: Toke Høiland-Jørgensen Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman