commit 664b18deb02a3e43fbe5b9af3b313ab3014fe904 Author: Alexandre Frade Date: Sat Oct 9 17:41:04 2021 +0000 Linux 5.14.11-xanmod1-cacule Signed-off-by: Alexandre Frade commit 96f227b9aae84678203fbaa2b599ceb4710a7922 Merge: 96d3f62c4e2b 924356b31dcb Author: Alexandre Frade Date: Sat Oct 9 17:30:13 2021 +0000 Merge tag 'v5.14.11' into 5.14-cacule This is the 5.14.11 stable release commit 924356b31dcbb1d5a4a210d3614372fc4c27e6f3 Author: Greg Kroah-Hartman Date: Sat Oct 9 15:02:42 2021 +0200 Linux 5.14.11 Link: https://lore.kernel.org/r/20211008112720.008415452@linuxfoundation.org Tested-by: Jon Hunter Tested-by: Fox Chen Tested-by: Florian Fainelli Tested-by: Shuah Khan Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Signed-off-by: Greg Kroah-Hartman commit add46a06b8d375bc79e93c8c21a03cd3dac1e883 Author: Fabio Estevam Date: Mon Sep 20 20:43:11 2021 -0300 Revert "ARM: imx6q: drop of_platform_default_populate() from init_machine" commit 4497b40ca8217fce9f33c9886f5a1b0408661e03 upstream. This reverts commit cc8870bf4c3ab0af385538460500a9d342ed945f. Since commit cc8870bf4c3a ("ARM: imx6q: drop of_platform_default_populate() from init_machine") the following errors are seen on boot: [ 0.123372] imx6q_suspend_init: failed to find ocram device! [ 0.123537] imx6_pm_common_init: No DDR LPM support with suspend -19! , which break suspend/resume on imx6q/dl. Revert the offeding commit to avoid the regression. Thanks to Tim Harvey for bisecting this problem. Cc: stable@vger.kernel.org Fixes: cc8870bf4c3a ("ARM: imx6q: drop of_platform_default_populate() from init_machine") Signed-off-by: Fabio Estevam Acked-by: Russell King (Oracle) Signed-off-by: Shawn Guo Signed-off-by: Greg Kroah-Hartman commit cfd436c4b683b2076dda60b72796944719cc4ad2 Author: Soeren Moch Date: Sun Sep 26 22:19:05 2021 +0200 Revert "brcmfmac: use ISO3166 country code and 0 rev as fallback" commit 151a7c12c4fc8340b51e849e4d1fcb7d794777a5 upstream. This reverts commit b0b524f079a23e440dd22b04e369368dde847533. Commit b0b524f079a2 ("brcmfmac: use ISO3166 country code and 0 rev as fallback") changes country setup to directly use ISO3166 country codes if no more specific code is configured. This was done under the assumption that brcmfmac firmwares can handle such simple direct mapping from country codes to firmware ccode values. Unfortunately this is not true for all chipset/firmware combinations. E.g. BCM4359/9 devices stop working as access point with this change, so revert the offending commit to avoid the regression. Signed-off-by: Soeren Moch Cc: stable@vger.kernel.org # 5.14.x Acked-by: Shawn Guo Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210926201905.211605-1-smoch@web.de Signed-off-by: Greg Kroah-Hartman commit 86524ac0ddacaaf39edf90ef7473ffc868dd6089 Author: Kate Hsuan Date: Fri Sep 3 17:44:11 2021 +0800 libata: Add ATA_HORKAGE_NO_NCQ_ON_ATI for Samsung 860 and 870 SSD. commit 7a8526a5cd51cf5f070310c6c37dd7293334ac49 upstream. Many users are reporting that the Samsung 860 and 870 SSD are having various issues when combined with AMD/ATI (vendor ID 0x1002) SATA controllers and only completely disabling NCQ helps to avoid these issues. Always disabling NCQ for Samsung 860/870 SSDs regardless of the host SATA adapter vendor will cause I/O performance degradation with well behaved adapters. To limit the performance impact to ATI adapters, introduce the ATA_HORKAGE_NO_NCQ_ON_ATI flag to force disable NCQ only for these adapters. Also, two libata.force parameters (noncqati and ncqati) are introduced to disable and enable the NCQ for the system which equipped with ATI SATA adapter and Samsung 860 and 870 SSDs. The user can determine NCQ function to be enabled or disabled according to the demand. After verifying the chipset from the user reports, the issue appears on AMD/ATI SB7x0/SB8x0/SB9x0 SATA Controllers and does not appear on recent AMD SATA adapters. The vendor ID of ATI should be 0x1002. Therefore, ATA_HORKAGE_NO_NCQ_ON_AMD was modified to ATA_HORKAGE_NO_NCQ_ON_ATI. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=201693 Signed-off-by: Kate Hsuan Reviewed-by: Hans de Goede Link: https://lore.kernel.org/r/20210903094411.58749-1-hpa@redhat.com Reviewed-by: Martin K. Petersen Signed-off-by: Jens Axboe Cc: Krzysztof Olędzki Signed-off-by: Greg Kroah-Hartman commit 2cef02f53d59ad8b9ba270160ae26f189150792b Author: Anand K Mistry Date: Wed Sep 29 17:04:21 2021 +1000 perf/x86: Reset destroy callback on event init failure commit 02d029a41dc986e2d5a77ecca45803857b346829 upstream. perf_init_event tries multiple init callbacks and does not reset the event state between tries. When x86_pmu_event_init runs, it unconditionally sets the destroy callback to hw_perf_event_destroy. On the next init attempt after x86_pmu_event_init, in perf_try_init_event, if the pmu's capabilities includes PERF_PMU_CAP_NO_EXCLUDE, the destroy callback will be run. However, if the next init didn't set the destroy callback, hw_perf_event_destroy will be run (since the callback wasn't reset). Looking at other pmu init functions, the common pattern is to only set the destroy callback on a successful init. Resetting the callback on failure tries to replicate that pattern. This was discovered after commit f11dd0d80555 ("perf/x86/amd/ibs: Extend PERF_PMU_CAP_NO_EXCLUDE to IBS Op") when the second (and only second) run of the perf tool after a reboot results in 0 samples being generated. The extra run of hw_perf_event_destroy results in active_events having an extra decrement on each perf run. The second run has active_events == 0 and every subsequent run has active_events < 0. When active_events == 0, the NMI handler will early-out and not record any samples. Signed-off-by: Anand K Mistry Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20210929170405.1.I078b98ee7727f9ae9d6df8262bad7e325e40faf0@changeid Signed-off-by: Greg Kroah-Hartman commit 12058756a2206eb08e59a96516855ad1264ebcc7 Author: Maxim Levitsky Date: Tue Sep 14 18:48:12 2021 +0300 KVM: x86: nSVM: restore int_vector in svm_clear_vintr [ Upstream commit aee77e1169c1900fe4248dc186962e745b479d9e ] In svm_clear_vintr we try to restore the virtual interrupt injection that might be pending, but we fail to restore the interrupt vector. Signed-off-by: Maxim Levitsky Message-Id: <20210914154825.104886-2-mlevitsk@redhat.com> Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit b232ba59feb992b527c440d6b30643c84ff382f1 Author: Fares Mehanna Date: Wed Sep 15 13:39:50 2021 +0000 kvm: x86: Add AMD PMU MSRs to msrs_to_save_all[] [ Upstream commit e1fc1553cd78292ab3521c94c9dd6e3e70e606a1 ] Intel PMU MSRs is in msrs_to_save_all[], so add AMD PMU MSRs to have a consistent behavior between Intel and AMD when using KVM_GET_MSRS, KVM_SET_MSRS or KVM_GET_MSR_INDEX_LIST. We have to add legacy and new MSRs to handle guests running without X86_FEATURE_PERFCTR_CORE. Signed-off-by: Fares Mehanna Message-Id: <20210915133951.22389-1-faresx@amazon.de> Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 9c827ab0cb09ade38421d9a2b3769e4a37a7ea4b Author: Maxim Levitsky Date: Mon Sep 13 17:09:50 2021 +0300 KVM: x86: reset pdptrs_from_userspace when exiting smm [ Upstream commit 37687c403a641f251cb2ef2e7830b88aa0647ba9 ] When exiting SMM, pdpts are loaded again from the guest memory. This fixes a theoretical bug, when exit from SMM triggers entry to the nested guest which re-uses some of the migration code which uses this flag as a workaround for a legacy userspace. Signed-off-by: Maxim Levitsky Message-Id: <20210913140954.165665-4-mlevitsk@redhat.com> Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit ce64d61801d9fef31350e65749e6cdbf53df6409 Author: Sergey Senozhatsky Date: Thu Sep 2 12:11:00 2021 +0900 KVM: do not shrink halt_poll_ns below grow_start [ Upstream commit ae232ea460888dc5a8b37e840c553b02521fbf18 ] grow_halt_poll_ns() ignores values between 0 and halt_poll_ns_grow_start (10000 by default). However, when we shrink halt_poll_ns we may fall way below halt_poll_ns_grow_start and endup with halt_poll_ns values that don't make a lot of sense: like 1 or 9, or 19. VCPU1 trace (halt_poll_ns_shrink equals 2): VCPU1 grow 10000 VCPU1 shrink 5000 VCPU1 shrink 2500 VCPU1 shrink 1250 VCPU1 shrink 625 VCPU1 shrink 312 VCPU1 shrink 156 VCPU1 shrink 78 VCPU1 shrink 39 VCPU1 shrink 19 VCPU1 shrink 9 VCPU1 shrink 4 Mirror what grow_halt_poll_ns() does and set halt_poll_ns to 0 as soon as new shrink-ed halt_poll_ns value falls below halt_poll_ns_grow_start. Signed-off-by: Sergey Senozhatsky Signed-off-by: Paolo Bonzini Message-Id: <20210902031100.252080-1-senozhatsky@chromium.org> Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 11e4acd09e3fda3233225a131c2121684209720f Author: Oliver Upton Date: Tue Sep 21 17:11:21 2021 +0000 selftests: KVM: Align SMCCC call with the spec in steal_time [ Upstream commit 01f91acb55be7aac3950b89c458bcea9ef6e4f49 ] The SMC64 calling convention passes a function identifier in w0 and its parameters in x1-x17. Given this, there are two deviations in the SMC64 call performed by the steal_time test: the function identifier is assigned to a 64 bit register and the parameter is only 32 bits wide. Align the call with the SMCCC by using a 32 bit register to handle the function identifier and increasing the parameter width to 64 bits. Suggested-by: Andrew Jones Signed-off-by: Oliver Upton Reviewed-by: Andrew Jones Message-Id: <20210921171121.2148982-3-oupton@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 96320e3316f8b891ae66dd9ea9c96a8ac660885f Author: Nathan Chancellor Date: Fri Sep 24 15:44:00 2021 -0700 kasan: always respect CONFIG_KASAN_STACK [ Upstream commit 19532869feb9b0a97d17ddc14609d1e53a5b60db ] Currently, the asan-stack parameter is only passed along if CFLAGS_KASAN_SHADOW is not empty, which requires KASAN_SHADOW_OFFSET to be defined in Kconfig so that the value can be checked. In RISC-V's case, KASAN_SHADOW_OFFSET is not defined in Kconfig, which means that asan-stack does not get disabled with clang even when CONFIG_KASAN_STACK is disabled, resulting in large stack warnings with allmodconfig: drivers/video/fbdev/omap2/omapfb/displays/panel-lgphilips-lb035q02.c:117:12: error: stack frame size (14400) exceeds limit (2048) in function 'lb035q02_connect' [-Werror,-Wframe-larger-than] static int lb035q02_connect(struct omap_dss_device *dssdev) ^ 1 error generated. Ensure that the value of CONFIG_KASAN_STACK is always passed along to the compiler so that these warnings do not happen when CONFIG_KASAN_STACK is disabled. Link: https://github.com/ClangBuiltLinux/linux/issues/1453 References: 6baec880d7a5 ("kasan: turn off asan-stack for clang-8 and earlier") Link: https://lkml.kernel.org/r/20210922205525.570068-1-nathan@kernel.org Signed-off-by: Nathan Chancellor Reviewed-by: Marco Elver Cc: Andrey Ryabinin Cc: Alexander Potapenko Cc: Andrey Konovalov Cc: Dmitry Vyukov Cc: Nick Desaulniers Cc: Arnd Bergmann Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 7d434c5f4687f31201f87c24e7f3a5efb277896e Author: Changbin Du Date: Fri Sep 24 15:43:41 2021 -0700 tools/vm/page-types: remove dependency on opt_file for idle page tracking [ Upstream commit ebaeab2fe87987cef28eb5ab174c42cd28594387 ] Idle page tracking can also be used for process address space, not only file mappings. Without this change, using with '-i' option for process address space encounters below errors reported. $ sudo ./page-types -p $(pidof bash) -i mark page idle: Bad file descriptor mark page idle: Bad file descriptor mark page idle: Bad file descriptor mark page idle: Bad file descriptor ... Link: https://lkml.kernel.org/r/20210917032826.10669-1-changbin.du@gmail.com Signed-off-by: Changbin Du Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 004b8f8a691205a93d9e80d98b786b2b97424d6e Author: Ming Lei Date: Fri Sep 24 19:07:04 2021 +0800 block: don't call rq_qos_ops->done_bio if the bio isn't tracked [ Upstream commit a647a524a46736786c95cdb553a070322ca096e3 ] rq_qos framework is only applied on request based driver, so: 1) rq_qos_done_bio() needn't to be called for bio based driver 2) rq_qos_done_bio() needn't to be called for bio which isn't tracked, such as bios ended from error handling code. Especially in bio_endio(): 1) request queue is referred via bio->bi_bdev->bd_disk->queue, which may be gone since request queue refcount may not be held in above two cases 2) q->rq_qos may be freed in blk_cleanup_queue() when calling into __rq_qos_done_bio() Fix the potential kernel panic by not calling rq_qos_ops->done_bio if the bio isn't tracked. This way is safe because both ioc_rqos_done_bio() and blkcg_iolatency_done_bio() are nop if the bio isn't tracked. Reported-by: Yu Kuai Cc: tj@kernel.org Signed-off-by: Ming Lei Reviewed-by: Christoph Hellwig Acked-by: Tejun Heo Link: https://lore.kernel.org/r/20210924110704.1541818-1-ming.lei@redhat.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 648f59a06b0e1fec7a4158cdee9acd362e493ce1 Author: Jens Axboe Date: Fri Sep 24 07:12:27 2021 -0600 io_uring: allow conditional reschedule for intensive iterators [ Upstream commit 8bab4c09f24ec8d4a7a78ab343620f89d3a24804 ] If we have a lot of threads and rings, the tctx list can get quite big. This is especially true if we keep creating new threads and rings. Likewise for the provided buffers list. Be nice and insert a conditional reschedule point while iterating the nodes for deletion. Link: https://lore.kernel.org/io-uring/00000000000064b6b405ccb41113@google.com/ Reported-by: syzbot+111d2a03f51f5ae73775@syzkaller.appspotmail.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 1b5b6666e23537247aae9fa0873916fee045d87c Author: Numfor Mbiziwo-Tiapo Date: Thu Sep 23 09:18:43 2021 -0700 x86/insn, tools/x86: Fix undefined behavior due to potential unaligned accesses [ Upstream commit 5ba1071f7554c4027bdbd712a146111de57918de ] Don't perform unaligned loads in __get_next() and __peek_nbyte_next() as these are forms of undefined behavior: "A pointer to an object or incomplete type may be converted to a pointer to a different object or incomplete type. If the resulting pointer is not correctly aligned for the pointed-to type, the behavior is undefined." (from http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf) These problems were identified using the undefined behavior sanitizer (ubsan) with the tools version of the code and perf test. [ bp: Massage commit message. ] Signed-off-by: Numfor Mbiziwo-Tiapo Signed-off-by: Ian Rogers Signed-off-by: Borislav Petkov Acked-by: Masami Hiramatsu Link: https://lkml.kernel.org/r/20210923161843.751834-1-irogers@google.com Signed-off-by: Sasha Levin commit d022e4c48e16b5a345578895c58a191880e0908f Author: Steve French Date: Thu Sep 23 16:00:31 2021 -0500 smb3: correct smb3 ACL security descriptor [ Upstream commit b06d893ef2492245d0319b4136edb4c346b687a3 ] Address warning: fs/smbfs_client/smb2pdu.c:2425 create_sd_buf() warn: struct type mismatch 'smb3_acl vs cifs_acl' Pointed out by Dan Carpenter via smatch code analysis tool Reported-by: Dan Carpenter Acked-by: Ronnie Sahlberg Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 629c6e725d10c2f7723ae4585c2d0b7b4b0b2846 Author: Marc Zyngier Date: Fri Sep 10 18:29:25 2021 +0100 irqchip/gic: Work around broken Renesas integration [ Upstream commit b78f26926b17cc289e4f16b63363abe0aa2e8efc ] Geert reported that the GIC driver locks up on a Renesas system since 005c34ae4b44f085 ("irqchip/gic: Atomically update affinity") fixed the driver to use writeb_relaxed() instead of writel_relaxed(). As it turns out, the interconnect used on this system mandates 32bit wide accesses for all MMIO transactions, even if the GIC architecture specifically mandates for some registers to be byte accessible. Gahhh... Work around the issue by crudly detecting the offending system, and falling back to an inefficient RMW+lock implementation. Reported-by: Geert Uytterhoeven Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/CAMuHMdV+Ev47K5NO8XHsanSq5YRMCHn2gWAQyV-q2LpJVy9HiQ@mail.gmail.com Signed-off-by: Sasha Levin commit ab0a257d15919022a57ab4b826deee268c7276b4 Author: Wen Xiong Date: Thu Sep 16 22:24:21 2021 -0500 scsi: ses: Retry failed Send/Receive Diagnostic commands [ Upstream commit fbdac19e642899455b4e64c63aafe2325df7aafa ] Setting SCSI logging level with error=3, we saw some errors from enclosues: [108017.360833] ses 0:0:9:0: tag#641 Done: NEEDS_RETRY Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK cmd_age=0s [108017.360838] ses 0:0:9:0: tag#641 CDB: Receive Diagnostic 1c 01 01 00 20 00 [108017.427778] ses 0:0:9:0: Power-on or device reset occurred [108017.427784] ses 0:0:9:0: tag#641 Done: SUCCESS Result: hostbyte=DID_OK driverbyte=DRIVER_OK cmd_age=0s [108017.427788] ses 0:0:9:0: tag#641 CDB: Receive Diagnostic 1c 01 01 00 20 00 [108017.427791] ses 0:0:9:0: tag#641 Sense Key : Unit Attention [current] [108017.427793] ses 0:0:9:0: tag#641 Add. Sense: Bus device reset function occurred [108017.427801] ses 0:0:9:0: Failed to get diagnostic page 0x1 [108017.427804] ses 0:0:9:0: Failed to bind enclosure -19 [108017.427895] ses 0:0:10:0: Attached Enclosure device [108017.427942] ses 0:0:10:0: Attached scsi generic sg18 type 13 Retry if the Send/Receive Diagnostic commands complete with a transient error status (NOT_READY or UNIT_ATTENTION with ASC 0x29). Link: https://lore.kernel.org/r/1631849061-10210-2-git-send-email-wenxiong@linux.ibm.com Reviewed-by: Brian King Reviewed-by: James Bottomley Signed-off-by: Wen Xiong Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit cd402c666fe71f4eb59bf143e9cd2ec466768025 Author: Ansuel Smith Date: Tue Sep 7 23:25:42 2021 +0200 thermal/drivers/tsens: Fix wrong check for tzd in irq handlers [ Upstream commit cf96921876dcee4d6ac07b9de470368a075ba9ad ] Some devices can have some thermal sensors disabled from the factory. The current two irq handler functions check all the sensor by default and the check if the sensor was actually registered is wrong. The tzd is actually never set if the registration fails hence the IS_ERR check is wrong. Signed-off-by: Ansuel Smith Reviewed-by: Matthias Kaehlcke Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20210907212543.20220-1-ansuelsmth@gmail.com Signed-off-by: Sasha Levin commit 7efa50dd020c9b77783659a7f7d28582e7c8b24e Author: James Smart Date: Tue Sep 14 11:20:07 2021 +0200 nvme-fc: avoid race between time out and tear down [ Upstream commit e5445dae29d25d7b03e0a10d3d4277a1d0c8119b ] To avoid race between time out and tear down, in tear down process, first we quiesce the queue, and then delete the timer and cancel the time out work for the queue. This patch merges the admin and io sync ops into the queue teardown logic as shown in the RDMA patch 3017013dcc "nvme-rdma: avoid race between time out and tear down". There is no teardown_lock in nvme-fc. Signed-off-by: James Smart Tested-by: Daniel Wagner Reviewed-by: Himanshu Madhani Reviewed-by: Hannes Reinecke Reviewed-by: Daniel Wagner Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 70f57c93f10b4fdf2dcb33958eea9bb3b550bd24 Author: Daniel Wagner Date: Tue Sep 14 11:20:06 2021 +0200 nvme-fc: update hardware queues before using them [ Upstream commit 555f66d0f8a38537456acc77043d0e4469fcbe8e ] In case the number of hardware queues changes, we need to update the tagset and the mapping of ctx to hctx first. If we try to create and connect the I/O queues first, this operation will fail (target will reject the connect call due to the wrong number of queues) and hence we bail out of the recreate function. Then we will to try the very same operation again, thus we don't make any progress. Signed-off-by: Daniel Wagner Reviewed-by: Ming Lei Reviewed-by: Himanshu Madhani Reviewed-by: Hannes Reinecke Reviewed-by: James Smart Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 2e4a7695c8df896ad325610a87a776f185c62ee1 Author: Jan Beulich Date: Fri Sep 17 12:45:49 2021 +0200 swiotlb-xen: ensure to issue well-formed XENMEM_exchange requests [ Upstream commit 9074c79b62b6e0d91d7f716c6e4e9968eaf9e043 ] While the hypervisor hasn't been enforcing this, we would still better avoid issuing requests with GFNs not aligned to the requested order. Instead of altering the value also in the call to panic(), drop it there for being static and hence easy to determine without being part of the panic message. Signed-off-by: Jan Beulich Reviewed-by: Stefano Stabellini Link: https://lore.kernel.org/r/7b3998e3-1233-4e5a-89ec-d740e77eb166@suse.com Signed-off-by: Juergen Gross Signed-off-by: Sasha Levin commit 3ad674aa17420bb0bf805d7eae9b708a439c0204 Author: Jan Beulich Date: Fri Sep 17 08:13:08 2021 +0200 Xen/gntdev: don't ignore kernel unmapping error [ Upstream commit f28347cc66395e96712f5c2db0a302ee75bafce6 ] While working on XSA-361 and its follow-ups, I failed to spot another place where the kernel mapping part of an operation was not treated the same as the user space part. Detect and propagate errors and add a 2nd pr_debug(). Signed-off-by: Jan Beulich Reviewed-by: Juergen Gross Link: https://lore.kernel.org/r/c2513395-74dc-aea3-9192-fd265aa44e35@suse.com Signed-off-by: Juergen Gross Signed-off-by: Sasha Levin commit 95342046ba4e885eaaa042fabafec4e7a7c8d742 Author: Shuah Khan Date: Wed Sep 15 15:28:09 2021 -0600 selftests: kvm: fix get_run_delay() ignoring fscanf() return warn [ Upstream commit f5013d412a43662b63f3d5f3a804d63213acd471 ] Fix get_run_delay() to check fscanf() return value to get rid of the following warning. When fscanf() fails return MIN_RUN_DELAY_NS from get_run_delay(). Move MIN_RUN_DELAY_NS from steal_time.c to test_util.h so get_run_delay() and steal_time.c can use it. lib/test_util.c: In function ‘get_run_delay’: lib/test_util.c:316:2: warning: ignoring return value of ‘fscanf’ declared with attribute ‘warn_unused_result’ [-Wunused-result] 316 | fscanf(fp, "%ld %ld ", &val[0], &val[1]); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Signed-off-by: Shuah Khan Acked-by: Paolo Bonzini Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit 80b7cc21401b9eb4cf4e4ecc1258877bd5419d58 Author: Shuah Khan Date: Wed Sep 15 15:28:08 2021 -0600 selftests: kvm: move get_run_delay() into lib/test_util [ Upstream commit 20175d5eac5bb94a7a3719ef275337fc9abf26ac ] get_run_delay() is defined static in xen_shinfo_test and steal_time test. Move it to lib and remove code duplication. Signed-off-by: Shuah Khan Acked-by: Paolo Bonzini Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit b6d7e8c09c4086d51e277cd00f136448750364ef Author: Shuah Khan Date: Wed Sep 15 15:28:07 2021 -0600 selftests:kvm: fix get_trans_hugepagesz() ignoring fscanf() return warn [ Upstream commit 3a4f0cc693cd3d80e66a255f0bff0e2c0461eef1 ] Fix get_trans_hugepagesz() to check fscanf() return value to get rid of the following warning: lib/test_util.c: In function ‘get_trans_hugepagesz’: lib/test_util.c:138:2: warning: ignoring return value of ‘fscanf’ declared with attribute ‘warn_unused_result’ [-Wunused-result] 138 | fscanf(f, "%ld", &size); | ^~~~~~~~~~~~~~~~~~~~~~~ Signed-off-by: Shuah Khan Acked-by: Paolo Bonzini Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit b664df7bb40ae9328bd5e7937338f8f229ea7cb2 Author: Shuah Khan Date: Wed Sep 15 15:28:06 2021 -0600 selftests:kvm: fix get_warnings_count() ignoring fscanf() return warn [ Upstream commit 39a71f712d8a13728febd8f3cb3f6db7e1fa7221 ] Fix get_warnings_count() to check fscanf() return value to get rid of the following warning: x86_64/mmio_warning_test.c: In function ‘get_warnings_count’: x86_64/mmio_warning_test.c:85:2: warning: ignoring return value of ‘fscanf’ declared with attribute ‘warn_unused_result’ [-Wunused-result] 85 | fscanf(f, "%d", &warnings); | ^~~~~~~~~~~~~~~~~~~~~~~~~~ Signed-off-by: Shuah Khan Acked-by: Paolo Bonzini Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit 2085e5ad67f4f1122277c3a4d848c67d53e50cea Author: Li Zhijian Date: Wed Sep 15 21:45:54 2021 +0800 selftests: be sure to make khdr before other targets [ Upstream commit 8914a7a247e065438a0ec86a58c1c359223d2c9e ] LKP/0Day reported some building errors about kvm, and errors message are not always same: - lib/x86_64/processor.c:1083:31: error: ‘KVM_CAP_NESTED_STATE’ undeclared (first use in this function); did you mean ‘KVM_CAP_PIT_STATE2’? - lib/test_util.c:189:30: error: ‘MAP_HUGE_16KB’ undeclared (first use in this function); did you mean ‘MAP_HUGE_16GB’? Although kvm relies on the khdr, they still be built in parallel when -j is specified. In this case, it will cause compiling errors. Here we mark target khdr as NOTPARALLEL to make it be always built first. CC: Philip Li Reported-by: kernel test robot Signed-off-by: Li Zhijian Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit 65699820041027e072ef78e7f11dca6e3a44b901 Author: Oded Gabbay Date: Sun Sep 12 10:25:49 2021 +0300 habanalabs/gaudi: fix LBW RR configuration [ Upstream commit 0a5ff77bf0a94468d541735f919a633f167787e9 ] Couple of fixes to the LBW RR configuration: 1. Add missing configuration of the SM RR registers in the DMA_IF. 2. Remove HBW range that doesn't belong. 3. Add entire gap + DBG area, from end of TPC7 to end of entire DBG space. Signed-off-by: Oded Gabbay Signed-off-by: Sasha Levin commit 6874cdba4daabe1d751d12e419a4891b56090d6a Author: Ofir Bitton Date: Thu Sep 2 09:47:53 2021 +0300 habanalabs: fail collective wait when not supported [ Upstream commit d09ff62c820b5950ab9958e77620a8498efe9386 ] As collective wait operation is required only when NIC ports are available, we disable the option to submit a CS in case all the ports are disabled, which is the current situation in the upstream driver. Signed-off-by: Ofir Bitton Reviewed-by: Oded Gabbay Signed-off-by: Oded Gabbay Signed-off-by: Sasha Levin commit 1c806d5a425b59b467c7c8c4c5ef752b415208b3 Author: Omer Shpigelman Date: Wed Dec 30 08:05:18 2020 +0200 habanalabs/gaudi: use direct MSI in single mode [ Upstream commit 3e08f157c2587fc7ada93abed41aae19bcbf8a6b ] Due to FLR scenario when running inside a VM, we must not use indirect MSI because it might cause some issues on VM destroy. In a VM we use single MSI mode in contrary to multi MSI mode which is used in bare-metal. Hence direct MSI should be used in single MSI mode only. Signed-off-by: Omer Shpigelman Reviewed-by: Oded Gabbay Signed-off-by: Oded Gabbay Signed-off-by: Sasha Levin commit 337f00a0bc62d7cb7d10ec0b872c79009a1641df Author: Yang Yingliang Date: Tue Aug 31 16:42:36 2021 +0800 usb: dwc2: check return value after calling platform_get_resource() [ Upstream commit 856e6e8e0f9300befa87dde09edb578555c99a82 ] It will cause null-ptr-deref if platform_get_resource() returns NULL, we need check the return value. Signed-off-by: Yang Yingliang Link: https://lore.kernel.org/r/20210831084236.1359677-1-yangyingliang@huawei.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 6b5af31c50ac0970f4edeebafb6e6c1b46916b3a Author: Faizel K B Date: Thu Sep 2 17:14:44 2021 +0530 usb: testusb: Fix for showing the connection speed [ Upstream commit f81c08f897adafd2ed43f86f00207ff929f0b2eb ] testusb' application which uses 'usbtest' driver reports 'unknown speed' from the function 'find_testdev'. The variable 'entry->speed' was not updated from the application. The IOCTL mentioned in the FIXME comment can only report whether the connection is low speed or not. Speed is read using the IOCTL USBDEVFS_GET_SPEED which reports the proper speed grade. The call is implemented in the function 'handle_testdev' where the file descriptor was availble locally. Sample output is given below where 'high speed' is printed as the connected speed. sudo ./testusb -a high speed /dev/bus/usb/001/011 0 /dev/bus/usb/001/011 test 0, 0.000015 secs /dev/bus/usb/001/011 test 1, 0.194208 secs /dev/bus/usb/001/011 test 2, 0.077289 secs /dev/bus/usb/001/011 test 3, 0.170604 secs /dev/bus/usb/001/011 test 4, 0.108335 secs /dev/bus/usb/001/011 test 5, 2.788076 secs /dev/bus/usb/001/011 test 6, 2.594610 secs /dev/bus/usb/001/011 test 7, 2.905459 secs /dev/bus/usb/001/011 test 8, 2.795193 secs /dev/bus/usb/001/011 test 9, 8.372651 secs /dev/bus/usb/001/011 test 10, 6.919731 secs /dev/bus/usb/001/011 test 11, 16.372687 secs /dev/bus/usb/001/011 test 12, 16.375233 secs /dev/bus/usb/001/011 test 13, 2.977457 secs /dev/bus/usb/001/011 test 14 --> 22 (Invalid argument) /dev/bus/usb/001/011 test 17, 0.148826 secs /dev/bus/usb/001/011 test 18, 0.068718 secs /dev/bus/usb/001/011 test 19, 0.125992 secs /dev/bus/usb/001/011 test 20, 0.127477 secs /dev/bus/usb/001/011 test 21 --> 22 (Invalid argument) /dev/bus/usb/001/011 test 24, 4.133763 secs /dev/bus/usb/001/011 test 27, 2.140066 secs /dev/bus/usb/001/011 test 28, 2.120713 secs /dev/bus/usb/001/011 test 29, 0.507762 secs Signed-off-by: Faizel K B Link: https://lore.kernel.org/r/20210902114444.15106-1-faizel.kb@dicortech.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 6a48e3f46ef4b2011e8ea63832b4cffcc4e01bc2 Author: James Smart Date: Tue Sep 7 09:52:25 2021 -0700 scsi: elx: efct: Do not hold lock while calling fc_vport_terminate() [ Upstream commit 450907424d9ebcc28fab42a065c3cddce49ee97d ] Smatch checker reported the following error: drivers/base/power/sysfs.c:833 dpm_sysfs_remove() warn: sleeping in atomic context With a calling sequence of: efct_lio_npiv_drop_nport() <- disables preempt -> fc_vport_terminate() -> device_del() -> dpm_sysfs_remove() Issue is efct_lio_npiv_drop_nport() is making the fc_vport_terminate() call while holding a lock w/ ipl raised. It is unnecessary to hold the lock over this call, shift where the lock is taken. Link: https://lore.kernel.org/r/20210907165225.10821-1-jsmart2021@gmail.com Reported-by: Dan Carpenter Co-developed-by: Ram Vegesna Signed-off-by: Ram Vegesna Signed-off-by: James Smart Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit e95f62013a1159eeea752bb52df0683ee77f70ca Author: Ming Lei Date: Mon Sep 6 17:01:12 2021 +0800 scsi: sd: Free scsi_disk device via put_device() [ Upstream commit 265dfe8ebbabae7959060bd1c3f75c2473b697ed ] After a device is initialized via device_initialize() it should be freed via put_device(). sd_probe() currently gets this wrong, fix it up. Link: https://lore.kernel.org/r/20210906090112.531442-1-ming.lei@redhat.com Reviewed-by: Bart Van Assche Reviewed-by: Christoph Hellwig Signed-off-by: Ming Lei Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit ac7d732b24f4061f8a732ada49b054ab38c63e15 Author: Philip Yang Date: Mon Sep 20 17:25:52 2021 -0400 drm/amdkfd: fix svm_migrate_fini warning [ Upstream commit 197ae17722e989942b36e33e044787877f158574 ] Device manager releases device-specific resources when a driver disconnects from a device, devm_memunmap_pages and devm_release_mem_region calls in svm_migrate_fini are redundant. It causes below warning trace after patch "drm/amdgpu: Split amdgpu_device_fini into early and late", so remove function svm_migrate_fini. BUG: https://gitlab.freedesktop.org/drm/amd/-/issues/1718 WARNING: CPU: 1 PID: 3646 at drivers/base/devres.c:795 devm_release_action+0x51/0x60 Call Trace: ? memunmap_pages+0x360/0x360 svm_migrate_fini+0x2d/0x60 [amdgpu] kgd2kfd_device_exit+0x23/0xa0 [amdgpu] amdgpu_amdkfd_device_fini_sw+0x1d/0x30 [amdgpu] amdgpu_device_fini_sw+0x45/0x290 [amdgpu] amdgpu_driver_release_kms+0x12/0x30 [amdgpu] drm_dev_release+0x20/0x40 [drm] release_nodes+0x196/0x1e0 device_release_driver_internal+0x104/0x1d0 driver_detach+0x47/0x90 bus_remove_driver+0x7a/0xd0 pci_unregister_driver+0x3d/0x90 amdgpu_exit+0x11/0x20 [amdgpu] Signed-off-by: Philip Yang Reviewed-by: Felix Kuehling Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 4c5a564bf968b5a440a28e40d09d90d33e600513 Author: Philip Yang Date: Fri Sep 17 14:32:14 2021 -0400 drm/amdkfd: handle svm migrate init error [ Upstream commit 7d6687200a939176847090bbde5cb79a82792a2f ] If svm migration init failed to create pgmap for device memory, set pgmap type to 0 to disable device SVM support capability. Signed-off-by: Philip Yang Reviewed-by: Felix Kuehling Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 3c2830d0cb6ffa8c2a767e62792456e8beb22bdc Author: Dan Carpenter Date: Tue Sep 21 23:32:33 2021 +0300 ext2: fix sleeping in atomic bugs on error [ Upstream commit 372d1f3e1bfede719864d0d1fbf3146b1e638c88 ] The ext2_error() function syncs the filesystem so it sleeps. The caller is holding a spinlock so it's not allowed to sleep. ext2_statfs() <- disables preempt -> ext2_count_free_blocks() -> ext2_get_group_desc() Fix this by using WARN() to print an error message and a stack trace instead of using ext2_error(). Link: https://lore.kernel.org/r/20210921203233.GA16529@kili Signed-off-by: Dan Carpenter Signed-off-by: Jan Kara Signed-off-by: Sasha Levin commit a3b450333d640f0705d53d8701a94194d99ad987 Author: Tobias Jakobi Date: Tue Sep 21 12:07:02 2021 +0200 platform/x86: gigabyte-wmi: add support for B550I Aorus Pro AX [ Upstream commit 6f6aab1caf6c7fef46852aaab03f4e8250779e52 ] Tested with a AMD Ryzen 7 5800X. Signed-off-by: Tobias Jakobi Acked-by: Thomas Weißschuh Link: https://lore.kernel.org/r/20210921100702.3838-1-tjakobi@math.uni-bielefeld.de Signed-off-by: Hans de Goede Signed-off-by: Sasha Levin commit 3702afcf0aaced8267ce09ba5099eee937875f78 Author: Linus Torvalds Date: Mon Sep 20 10:56:32 2021 -0700 sparc64: fix pci_iounmap() when CONFIG_PCI is not set [ Upstream commit d8b1e10a2b8efaf71d151aa756052fbf2f3b6d57 ] Guenter reported [1] that the pci_iounmap() changes remain problematic, with sparc64 allnoconfig and tinyconfig still not building due to the header file changes and confusion with the arch-specific pci_iounmap() implementation. I'm pretty convinced that sparc should just use GENERIC_IOMAP instead of doing its own thing, since it turns out that the sparc64 version of pci_iounmap() is somewhat buggy (see [2]). But in the meantime, this just fixes the build by avoiding the trivial re-definition of the empty case. Link: https://lore.kernel.org/lkml/20210920134424.GA346531@roeck-us.net/ [1] Link: https://lore.kernel.org/lkml/CAHk-=wgheheFx9myQyy5osh79BAazvmvYURAtub2gQtMvLrhqQ@mail.gmail.com/ [2] Reported-by: Guenter Roeck Cc: David Miller Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit e4cff35be8ff6b3c1529d16f49b577baf0dcc3f6 Author: Jan Beulich Date: Fri Sep 17 08:27:10 2021 +0200 xen-netback: correct success/error reporting for the SKB-with-fraglist case [ Upstream commit 3ede7f84c7c21f93c5eac611d60eba3f2c765e0f ] When re-entering the main loop of xenvif_tx_check_gop() a 2nd time, the special considerations for the head of the SKB no longer apply. Don't mistakenly report ERROR to the frontend for the first entry in the list, even if - from all I can tell - this shouldn't matter much as the overall transmit will need to be considered failed anyway. Signed-off-by: Jan Beulich Reviewed-by: Paul Durrant Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 0cfda0cc59d4651c0135bd7c921b03758da507e8 Author: Vladimir Oltean Date: Fri Sep 17 16:34:32 2021 +0300 net: mdio: introduce a shutdown method to mdio device drivers [ Upstream commit cf9579976f724ad517cc15b7caadea728c7e245c ] MDIO-attached devices might have interrupts and other things that might need quiesced when we kexec into a new kernel. Things are even more creepy when those interrupt lines are shared, and in that case it is absolutely mandatory to disable all interrupt sources. Moreover, MDIO devices might be DSA switches, and DSA needs its own shutdown method to unlink from the DSA master, which is a new requirement that appeared after commit 2f1e8ea726e9 ("net: dsa: link interfaces with the DSA master to get rid of lockdep warnings"). So introduce a ->shutdown method in the MDIO device driver structure. Signed-off-by: Vladimir Oltean Reviewed-by: Andrew Lunn Reviewed-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 7a08b2e1e477058baaf584121bbed2001f9cd8e0 Author: Filipe Manana Date: Wed Sep 8 19:05:44 2021 +0100 btrfs: fix mount failure due to past and transient device flush error [ Upstream commit 6b225baababf1e3d41a4250e802cbd193e1343fb ] When we get an error flushing one device, during a super block commit, we record the error in the device structure, in the field 'last_flush_error'. This is used to later check if we should error out the super block commit, depending on whether the number of flush errors is greater than or equals to the maximum tolerated device failures for a raid profile. However if we get a transient device flush error, unmount the filesystem and later try to mount it, we can fail the mount because we treat that past error as critical and consider the device is missing. Even if it's very likely that the error will happen again, as it's probably due to a hardware related problem, there may be cases where the error might not happen again. One example is during testing, and a test case like the new generic/648 from fstests always triggers this. The test cases generic/019 and generic/475 also trigger this scenario, but very sporadically. When this happens we get an error like this: $ mount /dev/sdc /mnt mount: /mnt wrong fs type, bad option, bad superblock on /dev/sdc, missing codepage or helper program, or other error. $ dmesg (...) [12918.886926] BTRFS warning (device sdc): chunk 13631488 missing 1 devices, max tolerance is 0 for writable mount [12918.888293] BTRFS warning (device sdc): writable mount is not allowed due to too many missing devices [12918.890853] BTRFS error (device sdc): open_ctree failed The failure happens because when btrfs_check_rw_degradable() is called at mount time, or at remount from RO to RW time, is sees a non zero value in a device's ->last_flush_error attribute, and therefore considers that the device is 'missing'. Fix this by setting a device's ->last_flush_error to zero when we close a device, making sure the error is not seen on the next mount attempt. We only need to track flush errors during the current mount, so that we never commit a super block if such errors happened. Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 31e401cb05ac71d8aa84ba8b2b850fbf47d6cd01 Author: Qu Wenruo Date: Tue Aug 17 07:55:40 2021 +0800 btrfs: replace BUG_ON() in btrfs_csum_one_bio() with proper error handling [ Upstream commit bbc9a6eb5eec03dcafee266b19f56295e3b2aa8f ] There is a BUG_ON() in btrfs_csum_one_bio() to catch code logic error. It has indeed caught several bugs during subpage development. But the BUG_ON() itself will bring down the whole system which is an overkill. Replace it with a WARN() and exit gracefully, so that it won't crash the whole system while we can still catch the code logic error. Signed-off-by: Qu Wenruo Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 20282e53d6bdbbfbeb1afdd813bc7c54728dccef Author: Dai Ngo Date: Thu Sep 16 14:22:12 2021 -0400 nfsd: back channel stuck in SEQ4_STATUS_CB_PATH_DOWN [ Upstream commit 02579b2ff8b0becfb51d85a975908ac4ab15fba8 ] When the back channel enters SEQ4_STATUS_CB_PATH_DOWN state, the client recovers by sending BIND_CONN_TO_SESSION but the server fails to recover the back channel and leaves it as NFSD4_CB_DOWN. Fix by enhancing nfsd4_bind_conn_to_session to probe the back channel by calling nfsd4_probe_callback. Signed-off-by: Dai Ngo Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit 5c1e84b7ae047072c18a62fcdc4d53031768c4f5 Author: Hans de Goede Date: Sun Sep 5 15:02:10 2021 +0200 platform/x86: touchscreen_dmi: Update info for the Chuwi Hi10 Plus (CWI527) tablet [ Upstream commit 196159d278ae3b49e7bbb7c76822e6008fd89b97 ] Add info for getting the firmware directly from the UEFI for the Chuwi Hi10 Plus (CWI527), so that the user does not need to manually install the firmware in /lib/firmware/silead. This change will make the touchscreen on these devices work OOTB, without requiring any manual setup. Also tweak the min and width/height values a bit for more accurate position reporting. Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20210905130210.32810-2-hdegoede@redhat.com Signed-off-by: Sasha Levin commit 77e6b00985f60dd38be6af85703da2d413b20970 Author: Hans de Goede Date: Sun Sep 5 15:02:09 2021 +0200 platform/x86: touchscreen_dmi: Add info for the Chuwi HiBook (CWI514) tablet [ Upstream commit 3bf1669b0e033c885ebcb1ddc2334088dd125f2d ] Add touchscreen info for the Chuwi HiBook (CWI514) tablet. This includes info for getting the firmware directly from the UEFI, so that the user does not need to manually install the firmware in /lib/firmware/silead. This change will make the touchscreen on these devices work OOTB, without requiring any manual setup. Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20210905130210.32810-1-hdegoede@redhat.com Signed-off-by: Sasha Levin commit bf4597f45f31521f06d6304424f902b4c65d48cf Author: David Howells Date: Wed Sep 1 19:22:50 2021 +0100 afs: Add missing vnode validation checks [ Upstream commit 3978d816523991dd86cf9aae88c295230a5ea3b2 ] afs_d_revalidate() should only be validating the directory entry it is given and the directory to which that belongs; it shouldn't be validating the inode/vnode to which that dentry points. Besides, validation need to be done even if we don't call afs_d_revalidate() - which might be the case if we're starting from a file descriptor. In order for afs_d_revalidate() to be fixed, validation points must be added in some other places. Certain directory operations, such as afs_unlink(), already check this, but not all and not all file operations either. Note that the validation of a vnode not only checks to see if the attributes we have are correct, but also gets a promise from the server to notify us if that file gets changed by a third party. Add the following checks: - Check the vnode we're going to make a hard link to. - Check the vnode we're going to move/rename. - Check the vnode we're going to read from. - Check the vnode we're going to write to. - Check the vnode we're going to sync. - Check the vnode we're going to make a mapped page writable for. Some of these aren't strictly necessary as we're going to perform a server operation that might get the attributes anyway from which we can determine if something changed - though it might not get us a callback promise. Signed-off-by: David Howells Tested-by: Markus Suvanto cc: linux-afs@lists.infradead.org Link: https://lore.kernel.org/r/163111667354.283156.12720698333342917516.stgit@warthog.procyon.org.uk/ Signed-off-by: Sasha Levin commit 20137432e1816db4837434225c4647ec9676f4d9 Author: Tobias Schramm Date: Fri Aug 27 07:03:57 2021 +0200 spi: rockchip: handle zero length transfers without timing out [ Upstream commit 5457773ef99f25fcc4b238ac76b68e28273250f4 ] Previously zero length transfers submitted to the Rokchip SPI driver would time out in the SPI layer. This happens because the SPI peripheral does not trigger a transfer completion interrupt for zero length transfers. Fix that by completing zero length transfers immediately at start of transfer. Signed-off-by: Tobias Schramm Link: https://lore.kernel.org/r/20210827050357.165409-1-t.schramm@manjaro.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin