commit c31c2cca229aa5280d108618bb264c713840a4c2 Author: Greg Kroah-Hartman Date: Wed Sep 15 09:50:49 2021 +0200 Linux 5.10.65 Link: https://lore.kernel.org/r/20210913131100.316353015@linuxfoundation.org Tested-by: Fox Chen Tested-by: Florian Fainelli Tested-by: Shuah Khan Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Jon Hunter Tested-by: Hulk Robot Tested-by: Guenter Roeck Tested-by: Sudip Mukherjee Signed-off-by: Greg Kroah-Hartman commit b216a075a9abca1401118feb1dde8fad533f245e Author: Linus Walleij Date: Sun Aug 15 01:55:14 2021 +0200 clk: kirkwood: Fix a clocking boot regression commit aaedb9e00e5400220a8871180d23a83e67f29f63 upstream. Since a few kernel releases the Pogoplug 4 has crashed like this during boot: Unable to handle kernel NULL pointer dereference at virtual address 00000002 (...) [] (strlen) from [] (kstrdup+0x1c/0x4c) [] (kstrdup) from [] (__clk_register+0x44/0x37c) [] (__clk_register) from [] (clk_hw_register+0x20/0x44) [] (clk_hw_register) from [] (__clk_hw_register_mux+0x198/0x1e4) [] (__clk_hw_register_mux) from [] (clk_register_mux_table+0x5c/0x6c) [] (clk_register_mux_table) from [] (kirkwood_clk_muxing_setup.constprop.0+0x13c/0x1ac) [] (kirkwood_clk_muxing_setup.constprop.0) from [] (of_clk_init+0x12c/0x214) [] (of_clk_init) from [] (time_init+0x20/0x2c) [] (time_init) from [] (start_kernel+0x3dc/0x56c) [] (start_kernel) from [<00000000>] (0x0) Code: e3130020 1afffffb e12fff1e c08a1078 (e5d03000) This is because the "powersave" mux clock 0 was provided in an unterminated array, which is required by the loop in the driver: /* Count, allocate, and register clock muxes */ for (n = 0; desc[n].name;) n++; Here n will go out of bounds and then call clk_register_mux() on random memory contents after the mux clock. Fix this by terminating the array with a blank entry. Fixes: 105299381d87 ("cpufreq: kirkwood: use the powersave multiplexer") Cc: stable@vger.kernel.org Cc: Andrew Lunn Cc: Chris Packham Cc: Gregory CLEMENT Cc: Sebastian Hesselbarth Signed-off-by: Linus Walleij Link: https://lore.kernel.org/r/20210814235514.403426-1-linus.walleij@linaro.org Reviewed-by: Andrew Lunn Signed-off-by: Stephen Boyd Signed-off-by: Greg Kroah-Hartman commit 5866b1175df086cb0b3451b11ad88667b53d4018 Author: Daniel Thompson Date: Thu Jul 22 15:46:23 2021 +0100 backlight: pwm_bl: Improve bootloader/kernel device handover commit 79fad92f2e596f5a8dd085788a24f540263ef887 upstream. Currently there are (at least) two problems in the way pwm_bl starts managing the enable_gpio pin. Both occur when the backlight is initially off and the driver finds the pin not already in output mode and, as a result, unconditionally switches it to output-mode and asserts the signal. Problem 1: This could cause the backlight to flicker since, at this stage in driver initialisation, we have no idea what the PWM and regulator are doing (an unconfigured PWM could easily "rest" at 100% duty cycle). Problem 2: This will cause us not to correctly honour the post_pwm_on_delay (which also risks flickers). Fix this by moving the code to configure the GPIO output mode until after we have examines the handover state. That allows us to initialize enable_gpio to off if the backlight is currently off and on if the backlight is on. Cc: stable@vger.kernel.org Reported-by: Marek Vasut Signed-off-by: Daniel Thompson Acked-by: Marek Vasut Tested-by: Marek Vasut Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman commit 4c00435cb813691c6a887184109dc46172147c33 Author: Tetsuo Handa Date: Wed Sep 8 19:27:49 2021 +0900 fbmem: don't allow too huge resolutions commit 8c28051cdcbe9dfcec6bd0a4709d67a09df6edae upstream. syzbot is reporting page fault at vga16fb_fillrect() [1], for vga16fb_check_var() is failing to detect multiplication overflow. if (vxres * vyres > maxmem) { vyres = maxmem / vxres; if (vyres < yres) return -ENOMEM; } Since no module would accept too huge resolutions where multiplication overflow happens, let's reject in the common path. Link: https://syzkaller.appspot.com/bug?extid=04168c8063cfdde1db5e [1] Reported-by: syzbot Debugged-by: Randy Dunlap Signed-off-by: Tetsuo Handa Reviewed-by: Geert Uytterhoeven Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/185175d6-227a-7b55-433d-b070929b262c@i-love.sakura.ne.jp Signed-off-by: Greg Kroah-Hartman commit 34d099a330e78122eb3da35dfd6db860fa8f230f Author: THOBY Simon Date: Mon Aug 16 08:10:59 2021 +0000 IMA: remove the dependency on CRYPTO_MD5 commit 8510505d55e194d3f6c9644c9f9d12c4f6b0395a upstream. MD5 is a weak digest algorithm that shouldn't be used for cryptographic operation. It hinders the efficiency of a patch set that aims to limit the digests allowed for the extended file attribute namely security.ima. MD5 is no longer a requirement for IMA, nor should it be used there. The sole place where we still use the MD5 algorithm inside IMA is setting the ima_hash algorithm to MD5, if the user supplies 'ima_hash=md5' parameter on the command line. With commit ab60368ab6a4 ("ima: Fallback to the builtin hash algorithm"), setting "ima_hash=md5" fails gracefully when CRYPTO_MD5 is not set: ima: Can not allocate md5 (reason: -2) ima: Allocating md5 failed, going to use default hash algorithm sha256 Remove the CRYPTO_MD5 dependency for IMA. Signed-off-by: THOBY Simon Reviewed-by: Lakshmi Ramasubramanian [zohar@linux.ibm.com: include commit number in patch description for stable.] Cc: stable@vger.kernel.org # 4.17 Signed-off-by: Mimi Zohar Signed-off-by: Greg Kroah-Hartman commit 5cc1ee31353bd45e236c8679ebb561a5ee65fc5c Author: Austin Kim Date: Tue Jun 29 14:50:50 2021 +0100 IMA: remove -Wmissing-prototypes warning commit a32ad90426a9c8eb3915eed26e08ce133bd9e0da upstream. With W=1 build, the compiler throws warning message as below: security/integrity/ima/ima_mok.c:24:12: warning: no previous prototype for ‘ima_mok_init’ [-Wmissing-prototypes] __init int ima_mok_init(void) Silence the warning by adding static keyword to ima_mok_init(). Signed-off-by: Austin Kim Fixes: 41c89b64d718 ("IMA: create machine owner and blacklist keyrings") Cc: stable@vger.kernel.org Signed-off-by: Mimi Zohar Signed-off-by: Greg Kroah-Hartman commit 1319689981096b34fc96f6e2dc0f8eade0434062 Author: Miklos Szeredi Date: Tue Aug 31 14:18:08 2021 +0200 fuse: flush extending writes commit 59bda8ecee2ffc6a602b7bf2b9e43ca669cdbdcd upstream. Callers of fuse_writeback_range() assume that the file is ready for modification by the server in the supplied byte range after the call returns. If there's a write that extends the file beyond the end of the supplied range, then the file needs to be extended to at least the end of the range, but currently that's not done. There are at least two cases where this can cause problems: - copy_file_range() will return short count if the file is not extended up to end of the source range. - FALLOC_FL_ZERO_RANGE | FALLOC_FL_KEEP_SIZE will not extend the file, hence the region may not be fully allocated. Fix by flushing writes from the start of the range up to the end of the file. This could be optimized if the writes are non-extending, etc, but it's probably not worth the trouble. Fixes: a2bc92362941 ("fuse: fix copy_file_range() in the writeback case") Fixes: 6b1bdb56b17c ("fuse: allow fallocate(FALLOC_FL_ZERO_RANGE)") Cc: # v5.2 Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit 8018100c544458351bbd445d0c2829aebf57d520 Author: Miklos Szeredi Date: Tue Aug 17 21:05:16 2021 +0200 fuse: truncate pagecache on atomic_o_trunc commit 76224355db7570cbe6b6f75c8929a1558828dd55 upstream. fuse_finish_open() will be called with FUSE_NOWRITE in case of atomic O_TRUNC. This can deadlock with fuse_wait_on_page_writeback() in fuse_launder_page() triggered by invalidate_inode_pages2(). Fix by replacing invalidate_inode_pages2() in fuse_finish_open() with a truncate_pagecache() call. This makes sense regardless of FOPEN_KEEP_CACHE or fc->writeback cache, so do it unconditionally. Reported-by: Xie Yongji Reported-and-tested-by: syzbot+bea44a5189836d956894@syzkaller.appspotmail.com Fixes: e4648309b85a ("fuse: truncate pending writes on O_TRUNC") Cc: Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit a8ca1fba54be12a2872d90ba934171fba8ddd9aa Author: Claudiu Beznea Date: Tue Jul 27 10:40:05 2021 +0300 ARM: dts: at91: add pinctrl-{names, 0} for all gpios commit bf781869e5cf3e4ec1a47dad69b6f0df97629cbd upstream. Add pinctrl-names and pinctrl-0 properties on controllers that claims to use pins to avoid failures due to commit 2ab73c6d8323 ("gpio: Support GPIO controllers without pin-ranges") and also to avoid using pins that may be claimed my other IPs. Fixes: b7c2b6157079 ("ARM: at91: add Atmel's SAMA5D3 Xplained board") Fixes: 1e5f532c2737 ("ARM: dts: at91: sam9x60: add device tree for soc and board") Fixes: 38153a017896 ("ARM: at91/dt: sama5d4: add dts for sama5d4 xplained board") Signed-off-by: Claudiu Beznea Signed-off-by: Nicolas Ferre Link: https://lore.kernel.org/r/20210727074006.1609989-1-claudiu.beznea@microchip.com Cc: # v5.7+ Signed-off-by: Greg Kroah-Hartman commit c2c7eefc93718a3bdffe031350d23a665aac15aa Author: Sean Christopherson Date: Tue Aug 10 07:45:26 2021 -0700 KVM: nVMX: Unconditionally clear nested.pi_pending on nested VM-Enter commit f7782bb8d818d8f47c26b22079db10599922787a upstream. Clear nested.pi_pending on nested VM-Enter even if L2 will run without posted interrupts enabled. If nested.pi_pending is left set from a previous L2, vmx_complete_nested_posted_interrupt() will pick up the stale flag and exit to userspace with an "internal emulation error" due the new L2 not having a valid nested.pi_desc. Arguably, vmx_complete_nested_posted_interrupt() should first check for posted interrupts being enabled, but it's also completely reasonable that KVM wouldn't screw up a fundamental flag. Not to mention that the mere existence of nested.pi_pending is a long-standing bug as KVM shouldn't move the posted interrupt out of the IRR until it's actually processed, e.g. KVM effectively drops an interrupt when it performs a nested VM-Exit with a "pending" posted interrupt. Fixing the mess is a future problem. Prior to vmx_complete_nested_posted_interrupt() interpreting a null PI descriptor as an error, this was a benign bug as the null PI descriptor effectively served as a check on PI not being enabled. Even then, the new flow did not become problematic until KVM started checking the result of kvm_check_nested_events(). Fixes: 705699a13994 ("KVM: nVMX: Enable nested posted interrupt processing") Fixes: 966eefb89657 ("KVM: nVMX: Disable vmcs02 posted interrupts if vmcs12 PID isn't mappable") Fixes: 47d3530f86c0 ("KVM: x86: Exit to userspace when kvm_check_nested_events fails") Cc: stable@vger.kernel.org Cc: Jim Mattson Signed-off-by: Sean Christopherson Message-Id: <20210810144526.2662272-1-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit bf36224463356526f56d992d3f6d09cbd57e2d2f Author: Maxim Levitsky Date: Thu Aug 26 12:57:49 2021 +0300 KVM: VMX: avoid running vmx_handle_exit_irqoff in case of emulation commit 81b4b56d4f8130bbb99cf4e2b48082e5b4cfccb9 upstream. If we are emulating an invalid guest state, we don't have a correct exit reason, and thus we shouldn't do anything in this function. Signed-off-by: Maxim Levitsky Message-Id: <20210826095750.1650467-2-mlevitsk@redhat.com> Cc: stable@vger.kernel.org Fixes: 95b5a48c4f2b ("KVM: VMX: Handle NMIs, #MCs and async #PFs in common irqs-disabled fn", 2019-06-18) Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit c06e6ff2fcc34476eda29c5c14ca0db962f500cf Author: Zelin Deng Date: Wed Apr 28 10:22:01 2021 +0800 KVM: x86: Update vCPU's hv_clock before back to guest when tsc_offset is adjusted commit d9130a2dfdd4b21736c91b818f87dbc0ccd1e757 upstream. When MSR_IA32_TSC_ADJUST is written by guest due to TSC ADJUST feature especially there's a big tsc warp (like a new vCPU is hot-added into VM which has been up for a long time), tsc_offset is added by a large value then go back to guest. This causes system time jump as tsc_timestamp is not adjusted in the meantime and pvclock monotonic character. To fix this, just notify kvm to update vCPU's guest time before back to guest. Cc: stable@vger.kernel.org Signed-off-by: Zelin Deng Signed-off-by: Paolo Bonzini Message-Id: <1619576521-81399-2-git-send-email-zelin.deng@linux.alibaba.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 1db337b10d127a6876e7f83066b06663e1ddf11f Author: Halil Pasic Date: Fri Aug 27 14:54:29 2021 +0200 KVM: s390: index kvm->arch.idle_mask by vcpu_idx commit a3e03bc1368c1bc16e19b001fc96dc7430573cc8 upstream. While in practice vcpu->vcpu_idx == vcpu->vcp_id is often true, it may not always be, and we must not rely on this. Reason is that KVM decides the vcpu_idx, userspace decides the vcpu_id, thus the two might not match. Currently kvm->arch.idle_mask is indexed by vcpu_id, which implies that code like for_each_set_bit(vcpu_id, kvm->arch.idle_mask, online_vcpus) { vcpu = kvm_get_vcpu(kvm, vcpu_id); do_stuff(vcpu); } is not legit. Reason is that kvm_get_vcpu expects an vcpu_idx, not an vcpu_id. The trouble is, we do actually use kvm->arch.idle_mask like this. To fix this problem we have two options. Either use kvm_get_vcpu_by_id(vcpu_id), which would loop to find the right vcpu_id, or switch to indexing via vcpu_idx. The latter is preferable for obvious reasons. Let us make switch from indexing kvm->arch.idle_mask by vcpu_id to indexing it by vcpu_idx. To keep gisa_int.kicked_mask indexed by the same index as idle_mask lets make the same change for it as well. Fixes: 1ee0bc559dc3 ("KVM: s390: get rid of local_int array") Signed-off-by: Halil Pasic Reviewed-by: Christian Bornträger Reviewed-by: Claudio Imbrenda Cc: # 3.15+ Link: https://lore.kernel.org/r/20210827125429.1912577-1-pasic@linux.ibm.com Signed-off-by: Christian Borntraeger Signed-off-by: Greg Kroah-Hartman commit dc9db2a2aae4c031f95c3e35528670b0520da365 Author: Sean Christopherson Date: Tue Aug 31 09:42:22 2021 -0700 Revert "KVM: x86: mmu: Add guest physical address check in translate_gpa()" commit e7177339d7b5f9594b316842122b5fda9513d5e2 upstream. Revert a misguided illegal GPA check when "translating" a non-nested GPA. The check is woefully incomplete as it does not fill in @exception as expected by all callers, which leads to KVM attempting to inject a bogus exception, potentially exposing kernel stack information in the process. WARNING: CPU: 0 PID: 8469 at arch/x86/kvm/x86.c:525 exception_type+0x98/0xb0 arch/x86/kvm/x86.c:525 CPU: 1 PID: 8469 Comm: syz-executor531 Not tainted 5.14.0-rc7-syzkaller #0 RIP: 0010:exception_type+0x98/0xb0 arch/x86/kvm/x86.c:525 Call Trace: x86_emulate_instruction+0xef6/0x1460 arch/x86/kvm/x86.c:7853 kvm_mmu_page_fault+0x2f0/0x1810 arch/x86/kvm/mmu/mmu.c:5199 handle_ept_misconfig+0xdf/0x3e0 arch/x86/kvm/vmx/vmx.c:5336 __vmx_handle_exit arch/x86/kvm/vmx/vmx.c:6021 [inline] vmx_handle_exit+0x336/0x1800 arch/x86/kvm/vmx/vmx.c:6038 vcpu_enter_guest+0x2a1c/0x4430 arch/x86/kvm/x86.c:9712 vcpu_run arch/x86/kvm/x86.c:9779 [inline] kvm_arch_vcpu_ioctl_run+0x47d/0x1b20 arch/x86/kvm/x86.c:10010 kvm_vcpu_ioctl+0x49e/0xe50 arch/x86/kvm/../../../virt/kvm/kvm_main.c:3652 The bug has escaped notice because practically speaking the GPA check is useless. The GPA check in question only comes into play when KVM is walking guest page tables (or "translating" CR3), and KVM already handles illegal GPA checks by setting reserved bits in rsvd_bits_mask for each PxE, or in the case of CR3 for loading PTDPTRs, manually checks for an illegal CR3. This particular failure doesn't hit the existing reserved bits checks because syzbot sets guest.MAXPHYADDR=1, and IA32 architecture simply doesn't allow for such an absurd MAXPHYADDR, e.g. 32-bit paging doesn't define any reserved PA bits checks, which KVM emulates by only incorporating the reserved PA bits into the "high" bits, i.e. bits 63:32. Simply remove the bogus check. There is zero meaningful value and no architectural justification for supporting guest.MAXPHYADDR < 32, and properly filling the exception would introduce non-trivial complexity. This reverts commit ec7771ab471ba6a945350353617e2e3385d0e013. Fixes: ec7771ab471b ("KVM: x86: mmu: Add guest physical address check in translate_gpa()") Cc: stable@vger.kernel.org Reported-by: syzbot+200c08e88ae818f849ce@syzkaller.appspotmail.com Signed-off-by: Sean Christopherson Message-Id: <20210831164224.1119728-2-seanjc@google.com> Reviewed-by: Vitaly Kuznetsov Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit c6b42ec1c93655f00f4438ed32acb8c84ff127f2 Author: Babu Moger Date: Fri Aug 20 16:52:42 2021 -0500 x86/resctrl: Fix a maybe-uninitialized build warning treated as error commit 527f721478bce3f49b513a733bacd19d6f34b08c upstream. The recent commit 064855a69003 ("x86/resctrl: Fix default monitoring groups reporting") caused a RHEL build failure with an uninitialized variable warning treated as an error because it removed the default case snippet. The RHEL Makefile uses '-Werror=maybe-uninitialized' to force possibly uninitialized variable warnings to be treated as errors. This is also reported by smatch via the 0day robot. The error from the RHEL build is: arch/x86/kernel/cpu/resctrl/monitor.c: In function ‘__mon_event_count’: arch/x86/kernel/cpu/resctrl/monitor.c:261:12: error: ‘m’ may be used uninitialized in this function [-Werror=maybe-uninitialized] m->chunks += chunks; ^~ The upstream Makefile does not build using '-Werror=maybe-uninitialized'. So, the problem is not seen there. Fix the problem by putting back the default case snippet. [ bp: note that there's nothing wrong with the code and other compilers do not trigger this warning - this is being done just so the RHEL compiler is happy. ] Fixes: 064855a69003 ("x86/resctrl: Fix default monitoring groups reporting") Reported-by: Terry Bowman Reported-by: kernel test robot Signed-off-by: Babu Moger Signed-off-by: Borislav Petkov Reviewed-by: Reinette Chatre Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/162949631908.23903.17090272726012848523.stgit@bmoger-ubuntu Signed-off-by: Greg Kroah-Hartman commit bafece6cd1f9908d73be31b534bf91c15fbedd94 Author: Kim Phillips Date: Tue Aug 17 17:10:41 2021 -0500 perf/x86/amd/ibs: Extend PERF_PMU_CAP_NO_EXCLUDE to IBS Op commit f11dd0d80555cdc8eaf5cfc9e19c9e198217f9f1 upstream. Commit: 2ff40250691e ("perf/core, arch/x86: Use PERF_PMU_CAP_NO_EXCLUDE for exclusion incapable PMUs") neglected to do so. Fixes: 2ff40250691e ("perf/core, arch/x86: Use PERF_PMU_CAP_NO_EXCLUDE for exclusion incapable PMUs") Signed-off-by: Kim Phillips Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20210817221048.88063-2-kim.phillips@amd.com Signed-off-by: Greg Kroah-Hartman commit ae95c3a147d5a40465c39e538ed82ba9bb0ea4d0 Author: Nguyen Dinh Phi Date: Mon Aug 23 08:06:41 2021 +0800 tty: Fix data race between tiocsti() and flush_to_ldisc() commit bb2853a6a421a052268eee00fd5d3f6b3504b2b1 upstream. The ops->receive_buf() may be accessed concurrently from these two functions. If the driver flushes data to the line discipline receive_buf() method while tiocsti() is waiting for the ops->receive_buf() to finish its work, the data race will happen. For example: tty_ioctl |tty_ldisc_receive_buf ->tioctsi | ->tty_port_default_receive_buf | ->tty_ldisc_receive_buf ->hci_uart_tty_receive | ->hci_uart_tty_receive ->h4_recv | ->h4_recv In this case, the h4 receive buffer will be overwritten by the latecomer, and we will lost the data. Hence, change tioctsi() function to use the exclusive lock interface from tty_buffer to avoid the data race. Reported-by: syzbot+97388eb9d31b997fe1d0@syzkaller.appspotmail.com Reviewed-by: Jiri Slaby Signed-off-by: Nguyen Dinh Phi Link: https://lore.kernel.org/r/20210823000641.2082292-1-phind.uet@gmail.com Cc: stable Signed-off-by: Greg Kroah-Hartman commit 4d0e6d6fe4e26c06c0e306e489aadef8b5183ff4 Author: Pavel Begunkov Date: Mon Jul 19 11:53:00 2021 +0100 bio: fix page leak bio_add_hw_page failure commit d9cf3bd531844ffbfe94b16e417037a16efc988d upstream. __bio_iov_append_get_pages() doesn't put not appended pages on bio_add_hw_page() failure, so potentially leaking them, fix it. Also, do the same for __bio_iov_iter_get_pages(), even though it looks like it can't be triggered by userspace in this case. Fixes: 0512a75b98f8 ("block: Introduce REQ_OP_ZONE_APPEND") Cc: stable@vger.kernel.org # 5.8+ Signed-off-by: Pavel Begunkov Link: https://lore.kernel.org/r/1edfa6a2ffd66d55e6345a477df5387d2c1415d0.1626653825.git.asml.silence@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 24fbd77d5a0fd2f22d5a0e8570499302b2dea2be Author: Jens Axboe Date: Mon Aug 30 19:37:41 2021 -0600 io_uring: IORING_OP_WRITE needs hash_reg_file set commit 7b3188e7ed54102a5dcc73d07727f41fb528f7c8 upstream. During some testing, it became evident that using IORING_OP_WRITE doesn't hash buffered writes like the other writes commands do. That's simply an oversight, and can cause performance regressions when doing buffered writes with this command. Correct that and add the flag, so that buffered writes are correctly hashed when using the non-iovec based write command. Cc: stable@vger.kernel.org Fixes: 3a6820f2bb8a ("io_uring: add non-vectored read/write commands") Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 656f343d724b45295f73000eb6e7bd3d212af116 Author: Lukas Hannen Date: Wed Aug 25 10:12:43 2021 +0000 time: Handle negative seconds correctly in timespec64_to_ns() commit 39ff83f2f6cc5cc1458dfcea9697f96338210beb upstream. timespec64_ns() prevents multiplication overflows by comparing the seconds value of the timespec to KTIME_SEC_MAX. If the value is greater or equal it returns KTIME_MAX. But that check casts the signed seconds value to unsigned which makes the comparision true for all negative values and therefore return wrongly KTIME_MAX. Negative second values are perfectly valid and required in some places, e.g. ptp_clock_adjtime(). Remove the cast and add a check for the negative boundary which is required to prevent undefined behaviour due to multiplication underflow. Fixes: cb47755725da ("time: Prevent undefined behaviour in timespec64_to_ns()")' Signed-off-by: Lukas Hannen Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/AM6PR01MB541637BD6F336B8FFB72AF80EEC69@AM6PR01MB5416.eurprd01.prod.exchangelabs.com Signed-off-by: Greg Kroah-Hartman commit 611b7f9dc9f696ba0f9ab03b5c6500f3718cbebe Author: Jaegeuk Kim Date: Thu Aug 19 14:00:57 2021 -0700 f2fs: guarantee to write dirty data when enabling checkpoint back commit dddd3d65293a52c2c3850c19b1e5115712e534d8 upstream. We must flush all the dirty data when enabling checkpoint back. Let's guarantee that first by adding a retry logic on sync_inodes_sb(). In addition to that, this patch adds to flush data in fsync when checkpoint is disabled, which can mitigate the sync_inodes_sb() failures in advance. Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 75ffcd85dff52e3e94a62587d339bc2fb81aba07 Author: Justin M. Forbes Date: Fri Jul 2 17:31:53 2021 -0500 iwlwifi Add support for ax201 in Samsung Galaxy Book Flex2 Alpha commit 2f32c147a3816d789722c0bd242a9431332ec3ed upstream. The Samsung Galaxy Book Flex2 Alpha uses an ax201 with the ID a0f0/6074. This works fine with the existing driver once it knows to claim it. Simple patch to add the device. Signed-off-by: Justin M. Forbes Reviewed-by: Jaehoon Chung Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210702223155.1981510-1-jforbes@fedoraproject.org Signed-off-by: Greg Kroah-Hartman commit 3853c0c0703d945c5589e314d9a919761eb28254 Author: Douglas Anderson Date: Fri Aug 13 07:34:05 2021 -0700 ASoC: rt5682: Remove unused variable in rt5682_i2c_remove() commit a1ea05723c27a6f77894a60038a7b2b12fcec9a7 upstream. In commit 772d44526e20 ("ASoC: rt5682: Properly turn off regulators if wrong device ID") I deleted code but forgot to delete a variable that's now unused. Delete it. Fixes: 772d44526e20 ("ASoC: rt5682: Properly turn off regulators if wrong device ID") Reported-by: Stephen Rothwell Signed-off-by: Douglas Anderson Reviewed-by: Stephen Boyd Link: https://lore.kernel.org/r/20210813073402.1.Iaa9425cfab80f5233afa78b32d02b6dc23256eb3@changeid Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit c4f1ad3930261ee153b5a1230662fdfb54725e1a Author: Eric Dumazet Date: Mon Aug 30 19:02:10 2021 -0700 ipv4: fix endianness issue in inet_rtm_getroute_build_skb() [ Upstream commit 92548b0ee220e000d81c27ac9a80e0ede895a881 ] The UDP length field should be in network order. This removes the following sparse error: net/ipv4/route.c:3173:27: warning: incorrect type in assignment (different base types) net/ipv4/route.c:3173:27: expected restricted __be16 [usertype] len net/ipv4/route.c:3173:27: got unsigned long Fixes: 404eb77ea766 ("ipv4: support sport, dport and ip_proto in RTM_GETROUTE") Signed-off-by: Eric Dumazet Cc: Roopa Prabhu Cc: David Ahern Reviewed-by: David Ahern Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit dc4ff31506f464aee303bb632829568c1c85b9f9 Author: Sunil Goutham Date: Mon Aug 30 23:30:46 2021 +0530 octeontx2-af: Set proper errorcode for IPv4 checksum errors [ Upstream commit 1e4428b6dba9b683dc2ec0a56ed7879de3200cce ] With current config, for packets with IPv4 checksum errors, errorcode is being set to UNKNOWN. Hence added a separate errorcodes for outer and inner IPv4 checksum and changed NPC configuration accordingly. Also turn on L2 multicast address check in NPC protocol check block. Fixes: 6b3321bacc5a ("octeontx2-af: Enable packet length and csum validation") Signed-off-by: Sunil Goutham Signed-off-by: Subbaraya Sundeep Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit bf2991f8e78338fbb95a74473dea2c8988e63ac1 Author: Subbaraya Sundeep Date: Mon Aug 30 23:30:45 2021 +0530 octeontx2-af: Fix static code analyzer reported issues [ Upstream commit 698a82ebfb4b2f2014baf31b7324b328a2a6366e ] This patch fixes the static code analyzer reported issues in rvu_npc.c. The reported errors are different sizes of operands in bitops and returning uninitialized values. Fixes: 651cd2652339 ("octeontx2-af: MCAM entry installation support") Signed-off-by: Subbaraya Sundeep Signed-off-by: Sunil Goutham Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit ee485124b7fac8ba42832c68f99f757bbd6ea864 Author: Subbaraya Sundeep Date: Mon Aug 30 23:30:43 2021 +0530 octeontx2-af: Fix loop in free and unmap counter [ Upstream commit 6537e96d743b89294b397b4865c6c061abae31b0 ] When the given counter does not belong to the entry then code ends up in infinite loop because the loop cursor, entry is not getting updated further. This patch fixes that by updating entry for every iteration. Fixes: a958dd59f9ce ("octeontx2-af: Map or unmap NPC MCAM entry and counter") Signed-off-by: Subbaraya Sundeep Signed-off-by: Sunil Goutham Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit a67c66c1bb1244c0a9028fa1003e99a264a1abd8 Author: Stefan Wahren Date: Sat Aug 28 16:23:15 2021 +0200 net: qualcomm: fix QCA7000 checksum handling [ Upstream commit 429205da6c834447a57279af128bdd56ccd5225e ] Based on tests the QCA7000 doesn't support checksum offloading. So assume ip_summed is CHECKSUM_NONE and let the kernel take care of the checksum handling. This fixes data transfer issues in noisy environments. Reported-by: Michael Heimpold Fixes: 291ab06ecf67 ("net: qualcomm: new Ethernet over SPI driver for QCA7000") Signed-off-by: Stefan Wahren Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f96bc82e0348be15def7b98ebfd6e276d2c1e8a1 Author: Xiyu Yang Date: Sun Aug 29 23:58:01 2021 +0800 net: sched: Fix qdisc_rate_table refcount leak when get tcf_block failed [ Upstream commit c66070125837900163b81a03063ddd657a7e9bfb ] The reference counting issue happens in one exception handling path of cbq_change_class(). When failing to get tcf_block, the function forgets to decrease the refcount of "rtab" increased by qdisc_put_rtab(), causing a refcount leak. Fix this issue by jumping to "failure" label when get tcf_block failed. Fixes: 6529eaba33f0 ("net: sched: introduce tcf block infractructure") Signed-off-by: Xiyu Yang Reviewed-by: Cong Wang Link: https://lore.kernel.org/r/1630252681-71588-1-git-send-email-xiyuyang19@fudan.edu.cn Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5867e20e1808acd0c832ddea2587e5ee49813874 Author: Eric Dumazet Date: Sun Aug 29 15:16:15 2021 -0700 ipv4: make exception cache less predictible [ Upstream commit 67d6d681e15b578c1725bad8ad079e05d1c48a8e ] Even after commit 6457378fe796 ("ipv4: use siphash instead of Jenkins in fnhe_hashfun()"), an attacker can still use brute force to learn some secrets from a victim linux host. One way to defeat these attacks is to make the max depth of the hash table bucket a random value. Before this patch, each bucket of the hash table used to store exceptions could contain 6 items under attack. After the patch, each bucket would contains a random number of items, between 6 and 10. The attacker can no longer infer secrets. This is slightly increasing memory size used by the hash table, by 50% in average, we do not expect this to be a problem. This patch is more complex than the prior one (IPv6 equivalent), because IPv4 was reusing the oldest entry. Since we need to be able to evict more than one entry per update_or_create_fnhe() call, I had to replace fnhe_oldest() with fnhe_remove_oldest(). Also note that we will queue extra kfree_rcu() calls under stress, which hopefully wont be a too big issue. Fixes: 4895c771c7f0 ("ipv4: Add FIB nexthop exceptions.") Signed-off-by: Eric Dumazet Reported-by: Keyu Man Cc: Willy Tarreau Signed-off-by: David S. Miller Reviewed-by: David Ahern Tested-by: David Ahern Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 8692f0bb29927d13a871b198adff1d336a8d2d00 Author: Eric Dumazet Date: Sun Aug 29 15:16:14 2021 -0700 ipv6: make exception cache less predictible [ Upstream commit a00df2caffed3883c341d5685f830434312e4a43 ] Even after commit 4785305c05b2 ("ipv6: use siphash in rt6_exception_hash()"), an attacker can still use brute force to learn some secrets from a victim linux host. One way to defeat these attacks is to make the max depth of the hash table bucket a random value. Before this patch, each bucket of the hash table used to store exceptions could contain 6 items under attack. After the patch, each bucket would contains a random number of items, between 6 and 10. The attacker can no longer infer secrets. This is slightly increasing memory size used by the hash table, we do not expect this to be a problem. Following patch is dealing with the same issue in IPv4. Fixes: 35732d01fe31 ("ipv6: introduce a hash table to store dst cache") Signed-off-by: Eric Dumazet Reported-by: Keyu Man Cc: Wei Wang Cc: Martin KaFai Lau Reviewed-by: David Ahern Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 4663aaef24dffd004fa030b7434de7a7e9a34f26 Author: Ahmad Fatoum Date: Tue Aug 17 08:35:22 2021 +0200 brcmfmac: pcie: fix oops on failure to resume and reprobe [ Upstream commit d745ca4f2c4ae9f1bd8cf7d8ac6e22d739bffd19 ] When resuming from suspend, brcmf_pcie_pm_leave_D3 will first attempt a hot resume and then fall back to removing the PCI device and then reprobing. If this probe fails, the kernel will oops, because brcmf_err, which is called to report the failure will dereference the stale bus pointer. Open code and use the default bus-less brcmf_err to avoid this. Fixes: 8602e62441ab ("brcmfmac: pass bus to the __brcmf_err() in pcie.c") Signed-off-by: Ahmad Fatoum Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210817063521.22450-1-a.fatoum@pengutronix.de Signed-off-by: Sasha Levin commit e68128e078da52e4bfd1cd5a9db3a46365c2e05b Author: Zenghui Yu Date: Tue Jul 27 10:52:31 2021 +0800 bcma: Fix memory leak for internally-handled cores [ Upstream commit b63aed3ff195130fef12e0af590f4838cf0201d8 ] kmemleak reported that dev_name() of internally-handled cores were leaked on driver unbinding. Let's use device_initialize() to take refcounts for them and put_device() to properly free the related stuff. While looking at it, there's another potential issue for those which should be *registered* into driver core. If device_register() failed, we put device once and freed bcma_device structures. In bcma_unregister_cores(), they're treated as unregistered and we hit both UAF and double-free. That smells not good and has also been fixed now. Fixes: ab54bc8460b5 ("bcma: fill core details for every device") Signed-off-by: Zenghui Yu Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210727025232.663-2-yuzenghui@huawei.com Signed-off-by: Sasha Levin commit 26fae720c1124cbfdc95a37379f402a1ced8a11a Author: Sudarsana Reddy Kalluru Date: Fri Aug 27 04:52:25 2021 -0700 atlantic: Fix driver resume flow. [ Upstream commit 57f780f1c43362b86fd23d20bd940e2468237716 ] Driver crashes when restoring from the Hibernate. In the resume flow, driver need to clean up the older nic/vec objects and re-initialize them. Fixes: 8aaa112a57c1d ("net: atlantic: refactoring pm logic") Signed-off-by: Sudarsana Reddy Kalluru Signed-off-by: Igor Russkikh Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit cb996dc9f93785145f129c183e17bd6abb3177b3 Author: Dan Carpenter Date: Fri Aug 13 14:34:38 2021 +0300 ath6kl: wmi: fix an error code in ath6kl_wmi_sync_point() [ Upstream commit fd6729ec534cffbbeb3917761e6d1fe6a412d3fe ] This error path is unlikely because of it checked for NULL and returned -ENOMEM earlier in the function. But it should return an error code here as well if we ever do hit it because of a race condition or something. Fixes: bdcd81707973 ("Add ath6kl cleaned up driver") Signed-off-by: Dan Carpenter Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210813113438.GB30697@kili Signed-off-by: Sasha Levin commit baecab8c469f45e0b56695a2921eb908cc446052 Author: Brett Creeley Date: Tue Aug 24 12:27:53 2021 -0700 ice: Only lock to update netdev dev_addr [ Upstream commit b357d9717be7f95fde2c6c4650b186a995b71e59 ] commit 3ba7f53f8bf1 ("ice: don't remove netdev->dev_addr from uc sync list") introduced calls to netif_addr_lock_bh() and netif_addr_unlock_bh() in the driver's ndo_set_mac() callback. This is fine since the driver is updated the netdev's dev_addr, but since this is a spinlock, the driver cannot sleep when the lock is held. Unfortunately the functions to add/delete MAC filters depend on a mutex. This was causing a trace with the lock debug kernel config options enabled when changing the mac address via iproute. [ 203.273059] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:281 [ 203.273065] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 6698, name: ip [ 203.273068] Preemption disabled at: [ 203.273068] [] ice_set_mac_address+0x8b/0x1c0 [ice] [ 203.273097] CPU: 31 PID: 6698 Comm: ip Tainted: G S W I 5.14.0-rc4 #2 [ 203.273100] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0010.010620200716 01/06/2020 [ 203.273102] Call Trace: [ 203.273107] dump_stack_lvl+0x33/0x42 [ 203.273113] ? ice_set_mac_address+0x8b/0x1c0 [ice] [ 203.273124] ___might_sleep.cold.150+0xda/0xea [ 203.273131] mutex_lock+0x1c/0x40 [ 203.273136] ice_remove_mac+0xe3/0x180 [ice] [ 203.273155] ? ice_fltr_add_mac_list+0x20/0x20 [ice] [ 203.273175] ice_fltr_prepare_mac+0x43/0xa0 [ice] [ 203.273194] ice_set_mac_address+0xab/0x1c0 [ice] [ 203.273206] dev_set_mac_address+0xb8/0x120 [ 203.273210] dev_set_mac_address_user+0x2c/0x50 [ 203.273212] do_setlink+0x1dd/0x10e0 [ 203.273217] ? __nla_validate_parse+0x12d/0x1a0 [ 203.273221] __rtnl_newlink+0x530/0x910 [ 203.273224] ? __kmalloc_node_track_caller+0x17f/0x380 [ 203.273230] ? preempt_count_add+0x68/0xa0 [ 203.273236] ? _raw_spin_lock_irqsave+0x1f/0x30 [ 203.273241] ? kmem_cache_alloc_trace+0x4d/0x440 [ 203.273244] rtnl_newlink+0x43/0x60 [ 203.273245] rtnetlink_rcv_msg+0x13a/0x380 [ 203.273248] ? rtnl_calcit.isra.40+0x130/0x130 [ 203.273250] netlink_rcv_skb+0x4e/0x100 [ 203.273256] netlink_unicast+0x1a2/0x280 [ 203.273258] netlink_sendmsg+0x242/0x490 [ 203.273260] sock_sendmsg+0x58/0x60 [ 203.273263] ____sys_sendmsg+0x1ef/0x260 [ 203.273265] ? copy_msghdr_from_user+0x5c/0x90 [ 203.273268] ? ____sys_recvmsg+0xe6/0x170 [ 203.273270] ___sys_sendmsg+0x7c/0xc0 [ 203.273272] ? copy_msghdr_from_user+0x5c/0x90 [ 203.273274] ? ___sys_recvmsg+0x89/0xc0 [ 203.273276] ? __netlink_sendskb+0x50/0x50 [ 203.273278] ? mod_objcg_state+0xee/0x310 [ 203.273282] ? __dentry_kill+0x114/0x170 [ 203.273286] ? get_max_files+0x10/0x10 [ 203.273288] __sys_sendmsg+0x57/0xa0 [ 203.273290] do_syscall_64+0x37/0x80 [ 203.273295] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 203.273296] RIP: 0033:0x7f8edf96e278 [ 203.273298] Code: 89 02 48 c7 c0 ff ff ff ff eb b5 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 8d 05 25 63 2c 00 8b 00 85 c0 75 17 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 58 c3 0f 1f 80 00 00 00 00 41 54 41 89 d4 55 [ 203.273300] RSP: 002b:00007ffcb8bdac08 EFLAGS: 00000246 ORIG_RAX: 000000000000002e [ 203.273303] RAX: ffffffffffffffda RBX: 000000006115e0ae RCX: 00007f8edf96e278 [ 203.273304] RDX: 0000000000000000 RSI: 00007ffcb8bdac70 RDI: 0000000000000003 [ 203.273305] RBP: 0000000000000000 R08: 0000000000000001 R09: 00007ffcb8bda5b0 [ 203.273306] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 [ 203.273306] R13: 0000555e10092020 R14: 0000000000000000 R15: 0000000000000005 Fix this by only locking when changing the netdev->dev_addr. Also, make sure to restore the old netdev->dev_addr on any failures. Fixes: 3ba7f53f8bf1 ("ice: don't remove netdev->dev_addr from uc sync list") Signed-off-by: Brett Creeley Tested-by: Gurucharan G Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit bd6d9c83f44d1a1c7483eebd4ffd67016d9ceb24 Author: Abhishek Naik Date: Thu Aug 5 14:21:53 2021 +0300 iwlwifi: skip first element in the WTAS ACPI table [ Upstream commit 19426d54302e199b3fd2d575f926a13af66be2b9 ] By mistake we were considering the first element of the WTAS wifi package as part of the data we want to rid, but that element is the wifi package signature (always 0x07), so it should be skipped. Change the code to read the data starting from element 1 instead. Signed-off-by: Abhishek Naik Fixes: 28dd7ccdc56f ("iwlwifi: acpi: read TAS table from ACPI and send it to the FW") Signed-off-by: Luca Coelho Link: https://lore.kernel.org/r/iwlwifi.20210805141826.ff8148197b15.I70636c04e37b2b57a5df3ce611511f62203d27a7@changeid Signed-off-by: Luca Coelho Signed-off-by: Sasha Levin commit 4c4f868082ed70186bfe19460e6b6dc717e6df09 Author: Emmanuel Grumbach Date: Wed Dec 9 23:16:20 2020 +0200 iwlwifi: follow the new inclusive terminology [ Upstream commit cdaba917268d7b58bf02fcc587cb2a7a277dc931 ] The new inclusive terminology requires to change a few terms that were used in iwlwifi. Signed-off-by: Emmanuel Grumbach Signed-off-by: Luca Coelho Link: https://lore.kernel.org/r/iwlwifi.20201209231352.1eb4c8625f36.I1b17b68d4a8e77071da3e15ffbd902d15c1d4938@changeid Signed-off-by: Luca Coelho Signed-off-by: Sasha Levin commit 5c305b90d8a1c825455cb41f0d59a73ff17f638b Author: Christophe JAILLET Date: Mon Aug 16 07:25:28 2021 +0200 ASoC: wcd9335: Disable irq on slave ports in the remove function [ Upstream commit d3efd26af2e044ff2b48d38bb871630282d77e60 ] The probe calls 'wcd9335_setup_irqs()' to enable interrupts on all slave ports. This must be undone in the remove function. Add a 'wcd9335_teardown_irqs()' function that undoes 'wcd9335_setup_irqs()' function, and call it from the remove function. Fixes: 20aedafdf492 ("ASoC: wcd9335: add support to wcd9335 codec") Signed-off-by: Christophe JAILLET Message-Id: <8f761244d79bd4c098af8a482be9121d3a486d1b.1629091028.git.christophe.jaillet@wanadoo.fr> Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 729a459efd30dbb8d57410560d8eafe1268e3d63 Author: Christophe JAILLET Date: Mon Aug 16 07:25:20 2021 +0200 ASoC: wcd9335: Fix a memory leak in the error handling path of the probe function [ Upstream commit fc6fc81caa63900cef9ebb8b2e365c3ed5a9effb ] If 'wcd9335_setup_irqs()' fails, me must release the memory allocated in 'wcd_clsh_ctrl_alloc()', as already done in the remove function. Add an error handling path and the missing 'wcd_clsh_ctrl_free()' call. Fixes: 20aedafdf492 ("ASoC: wcd9335: add support to wcd9335 codec") Signed-off-by: Christophe JAILLET Message-Id: <6dc12372f09fabb70bf05941dbe6a1382dc93e43.1629091028.git.christophe.jaillet@wanadoo.fr> Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 9c640a2bb5515832993728150e261b91553e9ee5 Author: Christophe JAILLET Date: Mon Aug 16 07:25:10 2021 +0200 ASoC: wcd9335: Fix a double irq free in the remove function [ Upstream commit 7a6a723e98aa45f393e6add18f7309dfffa1b0e2 ] There is no point in calling 'free_irq()' explicitly for 'WCD9335_IRQ_SLIMBUS' in the remove function. The irqs are requested in 'wcd9335_setup_irqs()' using a resource managed function (i.e. 'devm_request_threaded_irq()'). 'wcd9335_setup_irqs()' requests all what is defined in the 'wcd9335_irqs' structure. This structure has only one entry for 'WCD9335_IRQ_SLIMBUS'. So 'devm_request...irq()' + explicit 'free_irq()' would lead to a double free. Remove the unneeded 'free_irq()' from the remove function. Fixes: 20aedafdf492 ("ASoC: wcd9335: add support to wcd9335 codec") Signed-off-by: Christophe JAILLET Message-Id: <0614d63bc00edd7e81dd367504128f3d84f72efa.1629091028.git.christophe.jaillet@wanadoo.fr> Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 8446bb0ff1d01ba1fbe27d4d2c511e47b1a472c3 Author: Andy Duan Date: Thu Aug 19 10:10:33 2021 +0800 tty: serial: fsl_lpuart: fix the wrong mapbase value [ Upstream commit d5c38948448abc2bb6b36dbf85a554bf4748885e ] Register offset needs to be applied on mapbase also. dma_tx/rx_request use the physical address of UARTDATA. Register offset is currently only applied to membase (the corresponding virtual addr) but not on mapbase. Fixes: 24b1e5f0e83c ("tty: serial: lpuart: add imx7ulp support") Reviewed-by: Leonard Crestez Signed-off-by: Adriana Reus Signed-off-by: Sherry Sun Signed-off-by: Andy Duan Link: https://lore.kernel.org/r/20210819021033.32606-1-sherry.sun@nxp.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 9ee4ff8cbe392669e187e9c370a09d16493ae1ef Author: Christophe JAILLET Date: Wed Aug 18 21:32:49 2021 +0200 usb: bdc: Fix a resource leak in the error handling path of 'bdc_probe()' [ Upstream commit 6f15a2a09cecb7a2faba4a75bbd101f6f962294b ] If an error occurs after a successful 'clk_prepare_enable()' call, it must be undone by a corresponding 'clk_disable_unprepare()' call. This call is already present in the remove function. Add this call in the error handling path and reorder the code so that the 'clk_prepare_enable()' call happens later in the function. The goal is to have as much managed resources functions as possible before the 'clk_prepare_enable()' call in order to keep the error handling path simple. While at it, remove the now unneeded 'clk' variable. Fixes: c87dca047849 ("usb: bdc: Add clock enable for new chips with a separate BDC clock") Acked-by: Florian Fainelli Signed-off-by: Christophe JAILLET Link: https://lore.kernel.org/r/f8a4a6897deb0c8cb2e576580790303550f15fcd.1629314734.git.christophe.jaillet@wanadoo.fr Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 4d2823abd1fe4e21653b3efafdbefa012d9d38d4 Author: Christophe JAILLET Date: Wed Aug 18 21:32:38 2021 +0200 usb: bdc: Fix an error handling path in 'bdc_probe()' when no suitable DMA config is available [ Upstream commit d2f42e09393c774ab79088d8e3afcc62b3328fc9 ] If no suitable DMA configuration is available, a previous 'bdc_phy_init()' call must be undone by a corresponding 'bdc_phy_exit()' call. Branch to the existing error handling path instead of returning directly. Fixes: cc29d4f67757 ("usb: bdc: Add support for USB phy") Acked-by: Florian Fainelli Signed-off-by: Christophe JAILLET Link: https://lore.kernel.org/r/0c5910979f39225d5d8fe68c9ab1c147c68ddee1.1629314734.git.christophe.jaillet@wanadoo.fr Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 86b79054d76bc244e04b6d2f9171016d9daf8639 Author: Evgeny Novikov Date: Wed Aug 25 20:09:02 2021 +0300 usb: ehci-orion: Handle errors of clk_prepare_enable() in probe [ Upstream commit 4720f1bf4ee4a784d9ece05420ba33c9222a3004 ] ehci_orion_drv_probe() did not account for possible errors of clk_prepare_enable() that in particular could cause invocation of clk_disable_unprepare() on clocks that were not prepared/enabled yet, e.g. in remove or on handling errors of usb_add_hcd() in probe. Though, there were several patches fixing different issues with clocks in this driver, they did not solve this problem. Add handling of errors of clk_prepare_enable() in ehci_orion_drv_probe() to avoid calls of clk_disable_unprepare() without previous successful invocation of clk_prepare_enable(). Found by Linux Driver Verification project (linuxtesting.org). Fixes: 8c869edaee07 ("ARM: Orion: EHCI: Add support for enabling clocks") Co-developed-by: Kirill Shilimanov Reviewed-by: Andrew Lunn Acked-by: Alan Stern Signed-off-by: Evgeny Novikov Signed-off-by: Kirill Shilimanov Link: https://lore.kernel.org/r/20210825170902.11234-1-novikov@ispras.ru Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit f0bb63127354dfd03f0c93e63a2b286f455b813e Author: Sergey Shtylyov Date: Sun Jul 4 17:47:54 2021 +0300 i2c: xlp9xx: fix main IRQ check [ Upstream commit 661e8a88e8317eb9ffe69c69d6cb4876370fe7e2 ] Iff platform_get_irq() returns 0 for the main IRQ, the driver's probe() method will return 0 early (as if the method's call was successful). Let's consider IRQ0 valid for simplicity -- devm_request_irq() can always override that decision... Fixes: 2bbd681ba2b ("i2c: xlp9xx: Driver for Netlogic XLP9XX/5XX I2C controller") Signed-off-by: Sergey Shtylyov Reviewed-by: George Cherian Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 7ac3090e0123680a32d0bceee7ae4d11a64d0e6b Author: Sergey Shtylyov Date: Sun Jul 4 17:38:45 2021 +0300 i2c: mt65xx: fix IRQ check [ Upstream commit 58fb7c643d346e2364404554f531cfa6a1a3917c ] Iff platform_get_irq() returns 0, the driver's probe() method will return 0 early (as if the method's call was successful). Let's consider IRQ0 valid for simplicity -- devm_request_irq() can always override that decision... Fixes: ce38815d39ea ("I2C: mediatek: Add driver for MediaTek I2C controller") Signed-off-by: Sergey Shtylyov Reviewed-by: Qii Wang Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 6c4857203ffa36918136756a889b12c5864bc4ad Author: Len Baker Date: Tue Aug 17 12:27:09 2021 +0200 CIFS: Fix a potencially linear read overflow [ Upstream commit f980d055a0f858d73d9467bb0b570721bbfcdfb8 ] strlcpy() reads the entire source buffer first. This read may exceed the destination size limit. This is both inefficient and can lead to linear read overflows if a source string is not NUL-terminated. Also, the strnlen() call does not avoid the read overflow in the strlcpy function when a not NUL-terminated string is passed. So, replace this block by a call to kstrndup() that avoids this type of overflow and does the same. Fixes: 066ce6899484d ("cifs: rename cifs_strlcpy_to_host and make it use new functions") Signed-off-by: Len Baker Reviewed-by: Paulo Alcantara (SUSE) Reviewed-by: Jeff Layton Signed-off-by: Steve French Signed-off-by: Sasha Levin commit b0491ab7d4c7ec44f9ed93298ba11b9aa1e9fd20 Author: Andrey Ignatov Date: Fri Aug 20 09:39:35 2021 -0700 bpf: Fix possible out of bound write in narrow load handling [ Upstream commit d7af7e497f0308bc97809cc48b58e8e0f13887e1 ] Fix a verifier bug found by smatch static checker in [0]. This problem has never been seen in prod to my best knowledge. Fixing it still seems to be a good idea since it's hard to say for sure whether it's possible or not to have a scenario where a combination of convert_ctx_access() and a narrow load would lead to an out of bound write. When narrow load is handled, one or two new instructions are added to insn_buf array, but before it was only checked that cnt >= ARRAY_SIZE(insn_buf) And it's safe to add a new instruction to insn_buf[cnt++] only once. The second try will lead to out of bound write. And this is what can happen if `shift` is set. Fix it by making sure that if the BPF_RSH instruction has to be added in addition to BPF_AND then there is enough space for two more instructions in insn_buf. The full report [0] is below: kernel/bpf/verifier.c:12304 convert_ctx_accesses() warn: offset 'cnt' incremented past end of array kernel/bpf/verifier.c:12311 convert_ctx_accesses() warn: offset 'cnt' incremented past end of array kernel/bpf/verifier.c 12282 12283 insn->off = off & ~(size_default - 1); 12284 insn->code = BPF_LDX | BPF_MEM | size_code; 12285 } 12286 12287 target_size = 0; 12288 cnt = convert_ctx_access(type, insn, insn_buf, env->prog, 12289 &target_size); 12290 if (cnt == 0 || cnt >= ARRAY_SIZE(insn_buf) || ^^^^^^^^^^^^^^^^^^^^^^^^^^^ Bounds check. 12291 (ctx_field_size && !target_size)) { 12292 verbose(env, "bpf verifier is misconfigured\n"); 12293 return -EINVAL; 12294 } 12295 12296 if (is_narrower_load && size < target_size) { 12297 u8 shift = bpf_ctx_narrow_access_offset( 12298 off, size, size_default) * 8; 12299 if (ctx_field_size <= 4) { 12300 if (shift) 12301 insn_buf[cnt++] = BPF_ALU32_IMM(BPF_RSH, ^^^^^ increment beyond end of array 12302 insn->dst_reg, 12303 shift); --> 12304 insn_buf[cnt++] = BPF_ALU32_IMM(BPF_AND, insn->dst_reg, ^^^^^ out of bounds write 12305 (1 << size * 8) - 1); 12306 } else { 12307 if (shift) 12308 insn_buf[cnt++] = BPF_ALU64_IMM(BPF_RSH, 12309 insn->dst_reg, 12310 shift); 12311 insn_buf[cnt++] = BPF_ALU64_IMM(BPF_AND, insn->dst_reg, ^^^^^^^^^^^^^^^ Same. 12312 (1ULL << size * 8) - 1); 12313 } 12314 } 12315 12316 new_prog = bpf_patch_insn_data(env, i + delta, insn_buf, cnt); 12317 if (!new_prog) 12318 return -ENOMEM; 12319 12320 delta += cnt - 1; 12321 12322 /* keep walking new program and skip insns we just inserted */ 12323 env->prog = new_prog; 12324 insn = new_prog->insnsi + i + delta; 12325 } 12326 12327 return 0; 12328 } [0] https://lore.kernel.org/bpf/20210817050843.GA21456@kili/ v1->v2: - clarify that problem was only seen by static checker but not in prod; Fixes: 46f53a65d2de ("bpf: Allow narrow loads with offset > 0") Reported-by: Dan Carpenter Signed-off-by: Andrey Ignatov Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20210820163935.1902398-1-rdna@fb.com Signed-off-by: Sasha Levin commit cfaefbcc6bc4c2bf76b9c9779cf6d6ff95a2fbac Author: Tony Lindgren Date: Tue Aug 10 11:16:44 2021 +0300 mmc: moxart: Fix issue with uninitialized dma_slave_config [ Upstream commit ee5165354d498e5bceb0b386e480ac84c5f8c28c ] Depending on the DMA driver being used, the struct dma_slave_config may need to be initialized to zero for the unused data. For example, we have three DMA drivers using src_port_window_size and dst_port_window_size. If these are left uninitialized, it can cause DMA failures. For moxart, this is probably not currently an issue but is still good to fix though. Fixes: 1b66e94e6b99 ("mmc: moxart: Add MOXA ART SD/MMC driver") Cc: Jonas Jensen Cc: Vinod Koul Cc: Peter Ujfalusi Signed-off-by: Tony Lindgren Link: https://lore.kernel.org/r/20210810081644.19353-3-tony@atomide.com Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit ced0bc748185663a94bc5ae69d7f462a63c66080 Author: Tony Lindgren Date: Tue Aug 10 11:16:43 2021 +0300 mmc: dw_mmc: Fix issue with uninitialized dma_slave_config [ Upstream commit c3ff0189d3bc9c03845fe37472c140f0fefd0c79 ] Depending on the DMA driver being used, the struct dma_slave_config may need to be initialized to zero for the unused data. For example, we have three DMA drivers using src_port_window_size and dst_port_window_size. If these are left uninitialized, it can cause DMA failures. For dw_mmc, this is probably not currently an issue but is still good to fix though. Fixes: 3fc7eaef44db ("mmc: dw_mmc: Add external dma interface support") Cc: Shawn Lin Cc: Jaehoon Chung Cc: Peter Ujfalusi Cc: Vinod Koul Signed-off-by: Tony Lindgren Link: https://lore.kernel.org/r/20210810081644.19353-2-tony@atomide.com Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 8a9f9b97558e85a6bf1b5b8c8240b14bdf5cb500 Author: Tony Lindgren Date: Tue Aug 10 11:16:42 2021 +0300 mmc: sdhci: Fix issue with uninitialized dma_slave_config [ Upstream commit 522654d534d315d540710124c57b49ca22ac5f72 ] Depending on the DMA driver being used, the struct dma_slave_config may need to be initialized to zero for the unused data. For example, we have three DMA drivers using src_port_window_size and dst_port_window_size. If these are left uninitialized, it can cause DMA failures at least if external TI SDMA is ever configured for sdhci. For other external DMA cases, this is probably not currently an issue but is still good to fix though. Fixes: 18e762e3b7a7 ("mmc: sdhci: add support for using external DMA devices") Cc: Adrian Hunter Cc: Chunyan Zhang Cc: Faiz Abbas Cc: Peter Ujfalusi Cc: Vinod Koul Signed-off-by: Tony Lindgren Acked-by: Adrian Hunter Reviewed-by: Peter Ujfalusi Link: https://lore.kernel.org/r/20210810081644.19353-1-tony@atomide.com Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit dd903083cbe433b56e7998d3e855b77f4b17eb01 Author: Cezary Rojewski Date: Wed Aug 18 09:57:35 2021 +0200 ASoC: Intel: Skylake: Fix module resource and format selection [ Upstream commit e8b374b649afe756c2470e0e6668022e90bf8518 ] Module configuration may differ between its instances depending on resources required and input and output audio format. Available parameters to select from are stored in module resource and interface (format) lists. These come from topology, together with description of each of pipe's modules. Ignoring index value provided by topology and relying always on 0th entry leads to unexpected module behavior due to under/overbudged resources assigned or impropper format selection. Fix by taking entry at index specified by topology. Fixes: f6fa56e22559 ("ASoC: Intel: Skylake: Parse and update module config structure") Signed-off-by: Cezary Rojewski Tested-by: Lukasz Majczak Link: https://lore.kernel.org/r/20210818075742.1515155-5-cezary.rojewski@intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit b0159dbd1dd6011befed7c125ca7d2690f24b7d4 Author: Cezary Rojewski Date: Wed Aug 18 09:57:33 2021 +0200 ASoC: Intel: Skylake: Leave data as is when invoking TLV IPCs [ Upstream commit 126b3422adc80f29d2129db7f61e0113a8a526c6 ] Advancing pointer initially fixed issue for some users but caused regression for others. Leave data as it to make it easier for end users to adjust their topology files if needed. Fixes: a8cd7066f042 ("ASoC: Intel: Skylake: Strip T and L from TLV IPCs") Signed-off-by: Cezary Rojewski Tested-by: Lukasz Majczak Link: https://lore.kernel.org/r/20210818075742.1515155-3-cezary.rojewski@intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 7934c79fb0ed6ca4a282f44ca1e1424d74438f39 Author: Cezary Rojewski Date: Wed Aug 18 09:57:32 2021 +0200 ASoC: Intel: kbl_da7219_max98927: Fix format selection for max98373 [ Upstream commit 6d41bbf2fd3615c56dbf2b67f6cbf9e83d14a2e2 ] Contrary to what is said in board's file, topology targeting kbl_da7219_max98373 expects format 16b, not 24/32b. Partially revert changes added in 'ASoC: Intel: Boards: Add Maxim98373 support' to bring old behavior back, aligning with topology expectations. Fixes: 716d53cc7837 ("ASoC: Intel: Boards: Add Maxim98373 support") Signed-off-by: Cezary Rojewski Tested-by: Lukasz Majczak Link: https://lore.kernel.org/r/20210818075742.1515155-2-cezary.rojewski@intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 56d976f45000f0b8fec0611baf9e3af6c58fc177 Author: Dan Carpenter Date: Mon Aug 16 21:39:47 2021 +0300 rsi: fix an error code in rsi_probe() [ Upstream commit 9adcdf6758d7c4c9bdaf22d78eb9fcae260ed113 ] Return -ENODEV instead of success for unsupported devices. Fixes: 54fdb318c111 ("rsi: add new device model for 9116") Signed-off-by: Dan Carpenter Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210816183947.GA2119@kili Signed-off-by: Sasha Levin commit 110ce7d256a34489e340bfa27f12cda94ab1f751 Author: Dan Carpenter Date: Thu Aug 5 13:37:46 2021 +0300 rsi: fix error code in rsi_load_9116_firmware() [ Upstream commit d0f8430332a16c7baa80ce2886339182c5d85f37 ] This code returns success if the kmemdup() fails, but obviously it should return -ENOMEM instead. Fixes: e5a1ecc97e5f ("rsi: add firmware loading for 9116 device") Signed-off-by: Dan Carpenter Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210805103746.GA26417@kili Signed-off-by: Sasha Levin commit b4bbb77d886b4d3b5915593a9d97a0d3da82ff8d Author: Bob Peterson Date: Fri May 14 07:42:33 2021 -0500 gfs2: init system threads before freeze lock [ Upstream commit a28dc123fa66ba7f3eca7cffc4b01d96bfd35c27 ] Patch 96b1454f2e ("gfs2: move freeze glock outside the make_fs_rw and _ro functions") changed the gfs2 mount sequence so that it holds the freeze lock before calling gfs2_make_fs_rw. Before this patch, gfs2_make_fs_rw called init_threads to initialize the quotad and logd threads. That is a problem if the system needs to withdraw due to IO errors early in the mount sequence, for example, while initializing the system statfs inode: 1. An IO error causes the statfs glock to not sync properly after recovery, and leaves items on the ail list. 2. The leftover items on the ail list causes its do_xmote call to fail, which makes it want to withdraw. But since the glock code cannot withdraw (because the withdraw sequence uses glocks) it relies upon the logd daemon to initiate the withdraw. 3. The withdraw can never be performed by the logd daemon because all this takes place before the logd daemon is started. This patch moves function init_threads from super.c to ops_fstype.c and it changes gfs2_fill_super to start its threads before holding the freeze lock, and if there's an error, stop its threads after releasing it. This allows the logd to run unblocked by the freeze lock. Thus, the logd daemon can perform its withdraw sequence properly. Fixes: 96b1454f2e8e ("gfs2: move freeze glock outside the make_fs_rw and _ro functions") Signed-off-by: Bob Peterson Signed-off-by: Sasha Levin commit ee029e3aa129572437c2d45082d5555d0ba7eb42 Author: Sergey Shtylyov Date: Sun Jul 4 17:35:54 2021 +0300 i2c: hix5hd2: fix IRQ check [ Upstream commit f9b459c2ba5edfe247e86b45ad5dea8da542f3ea ] Iff platform_get_irq() returns 0, the driver's probe() method will return 0 early (as if the method's call was successful). Let's consider IRQ0 valid for simplicity -- devm_request_irq() can always override that decision... Fixes: 15ef27756b23 ("i2c: hix5hd2: add i2c controller driver") Signed-off-by: Sergey Shtylyov Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit d36ab9b3ee495c984d7a700566879bd69835f61d Author: Tian Tao Date: Fri Dec 25 16:40:06 2020 +0800 i2c: fix platform_get_irq.cocci warnings [ Upstream commit 2478b9c1dcc9aa84cfd71ed7b5ca2a2c0ede75b7 ] Remove dev_err() messages after platform_get_irq*() failures. drivers/i2c/busses/i2c-hix5hd2.c:417:2-9: line 417 is redundant because platform_get_irq() already prints an error Signed-off-by: Tian Tao Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 187705a4b1fa05e3368a95b0dbfa4469ec84a490 Author: Sergey Shtylyov Date: Sun Jul 4 17:45:25 2021 +0300 i2c: s3c2410: fix IRQ check [ Upstream commit d6840a5e370b7ea4fde16ce2caf431bcc87f9a75 ] Iff platform_get_irq() returns 0, the driver's probe() method will return 0 early (as if the method's call was successful). Let's consider IRQ0 valid for simplicity -- devm_request_irq() can always override that decision... Fixes: e0d1ec97853f ("i2c-s3c2410: Change IRQ to be plain integer.") Signed-off-by: Sergey Shtylyov Reviewed-by: Krzysztof Kozlowski Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 3913fa307a33921e5caf74616ada55d15052cf72 Author: Sergey Shtylyov Date: Thu Aug 12 23:35:09 2021 +0300 i2c: iop3xx: fix deferred probing [ Upstream commit a1299505162ad00def3573260c2c68b9c8e8d697 ] When adding the code to handle platform_get_irq*() errors in the commit 489447380a29 ("handle errors returned by platform_get_irq*()"), the actual error code was enforced to be -ENXIO in the driver for some strange reason. This didn't matter much until the deferred probing was introduced -- which requires an actual error code to be propagated upstream from the failure site. While fixing this, also stop overriding the errors from request_irq() to -EIO (done since the pre-git era). Fixes: 489447380a29 ("[PATCH] handle errors returned by platform_get_irq*()") Signed-off-by: Sergey Shtylyov Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 50e6f34499a548a9ebe43a36d2c85915e95cc3d8 Author: Pavel Skripkin Date: Thu Aug 19 18:15:21 2021 +0300 Bluetooth: add timeout sanity check to hci_inquiry [ Upstream commit f41a4b2b5eb7872109723dab8ae1603bdd9d9ec1 ] Syzbot hit "task hung" bug in hci_req_sync(). The problem was in unreasonable huge inquiry timeout passed from userspace. Fix it by adding sanity check for timeout value to hci_inquiry(). Since hci_inquiry() is the only user of hci_req_sync() with user controlled timeout value, it makes sense to check timeout value in hci_inquiry() and don't touch hci_req_sync(). Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-and-tested-by: syzbot+be2baed593ea56c6a84c@syzkaller.appspotmail.com Signed-off-by: Pavel Skripkin Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit cc59ad70cfb654c6fa3acc07db21d2231c9ffce9 Author: Kevin Mitchell Date: Wed Aug 18 19:29:39 2021 -0700 lkdtm: replace SCSI_DISPATCH_CMD with SCSI_QUEUE_RQ [ Upstream commit d1f278da6b11585f05b2755adfc8851cbf14a1ec ] When scsi_dispatch_cmd was moved to scsi_lib.c and made static, some compilers (i.e., at least gcc 8.4.0) decided to compile this inline. This is a problem for lkdtm.ko, which inserted a kprobe on this function for the SCSI_DISPATCH_CMD crashpoint. Move this crashpoint one function up the call chain to scsi_queue_rq. Though this is also a static function, it should never be inlined because it is assigned as a structure entry. Therefore, kprobe_register should always be able to find it. Fixes: 82042a2cdb55 ("scsi: move scsi_dispatch_cmd to scsi_lib.c") Acked-by: Kees Cook Signed-off-by: Kevin Mitchell Link: https://lore.kernel.org/r/20210819022940.561875-2-kevmitch@arista.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 9295566a136cc26a3f6166eff6e2f5525432f73b Author: Xu Yu Date: Wed Aug 18 12:47:52 2021 -0700 mm/swap: consider max pages in iomap_swapfile_add_extent [ Upstream commit 36ca7943ac18aebf8aad4c50829eb2ea5ec847df ] When the max pages (last_page in the swap header + 1) is smaller than the total pages (inode size) of the swapfile, iomap_swapfile_activate overwrites sis->max with total pages. However, frontswap_map is a swap page state bitmap allocated using the initial sis->max page count read from the swap header. If swapfile activation increases sis->max, it's possible for the frontswap code to walk off the end of the bitmap, thereby corrupting kernel memory. [djwong: modify the description a bit; the original paragraph reads: "However, frontswap_map is allocated using max pages. When test and clear the sis offset, which is larger than max pages, of frontswap_map in __frontswap_invalidate_page(), neighbors of frontswap_map may be overwritten, i.e., slab is polluted." Note also that this bug resulted in a behavioral change: activating a swap file that was formatted and later extended results in all pages being activated, not the number of pages recorded in the swap header.] This fixes the issue by considering the limitation of max pages of swap info in iomap_swapfile_add_extent(). To reproduce the case, compile kernel with slub RED ZONE, then run test: $ sudo stress-ng -a 1 -x softlockup,resources -t 72h --metrics --times \ --verify -v -Y /root/tmpdir/stress-ng/stress-statistic-12.yaml \ --log-file /root/tmpdir/stress-ng/stress-logfile-12.txt \ --temp-path /root/tmpdir/stress-ng/ We'll get the error log as below: [ 1151.015141] ============================================================================= [ 1151.016489] BUG kmalloc-16 (Not tainted): Right Redzone overwritten [ 1151.017486] ----------------------------------------------------------------------------- [ 1151.017486] [ 1151.018997] Disabling lock debugging due to kernel taint [ 1151.019873] INFO: 0x0000000084e43932-0x0000000098d17cae @offset=7392. First byte 0x0 instead of 0xcc [ 1151.021303] INFO: Allocated in __do_sys_swapon+0xcf6/0x1170 age=43417 cpu=9 pid=3816 [ 1151.022538] __slab_alloc+0xe/0x20 [ 1151.023069] __kmalloc_node+0xfd/0x4b0 [ 1151.023704] __do_sys_swapon+0xcf6/0x1170 [ 1151.024346] do_syscall_64+0x33/0x40 [ 1151.024925] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 1151.025749] INFO: Freed in put_cred_rcu+0xa1/0xc0 age=43424 cpu=3 pid=2041 [ 1151.026889] kfree+0x276/0x2b0 [ 1151.027405] put_cred_rcu+0xa1/0xc0 [ 1151.027949] rcu_do_batch+0x17d/0x410 [ 1151.028566] rcu_core+0x14e/0x2b0 [ 1151.029084] __do_softirq+0x101/0x29e [ 1151.029645] asm_call_irq_on_stack+0x12/0x20 [ 1151.030381] do_softirq_own_stack+0x37/0x40 [ 1151.031037] do_softirq.part.15+0x2b/0x30 [ 1151.031710] __local_bh_enable_ip+0x4b/0x50 [ 1151.032412] copy_fpstate_to_sigframe+0x111/0x360 [ 1151.033197] __setup_rt_frame+0xce/0x480 [ 1151.033809] arch_do_signal+0x1a3/0x250 [ 1151.034463] exit_to_user_mode_prepare+0xcf/0x110 [ 1151.035242] syscall_exit_to_user_mode+0x27/0x190 [ 1151.035970] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 1151.036795] INFO: Slab 0x000000003b9de4dc objects=44 used=9 fp=0x00000000539e349e flags=0xfffffc0010201 [ 1151.038323] INFO: Object 0x000000004855ba01 @offset=7376 fp=0x0000000000000000 [ 1151.038323] [ 1151.039683] Redzone 000000008d0afd3d: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc ................ [ 1151.041180] Object 000000004855ba01: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 1151.042714] Redzone 0000000084e43932: 00 00 00 c0 cc cc cc cc ........ [ 1151.044120] Padding 000000000864c042: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZZZZZ [ 1151.045615] CPU: 5 PID: 3816 Comm: stress-ng Tainted: G B 5.10.50+ #7 [ 1151.046846] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014 [ 1151.048633] Call Trace: [ 1151.049072] dump_stack+0x57/0x6a [ 1151.049585] check_bytes_and_report+0xed/0x110 [ 1151.050320] check_object+0x1eb/0x290 [ 1151.050924] ? __x64_sys_swapoff+0x39a/0x540 [ 1151.051646] free_debug_processing+0x151/0x350 [ 1151.052333] __slab_free+0x21a/0x3a0 [ 1151.052938] ? _cond_resched+0x2d/0x40 [ 1151.053529] ? __vunmap+0x1de/0x220 [ 1151.054139] ? __x64_sys_swapoff+0x39a/0x540 [ 1151.054796] ? kfree+0x276/0x2b0 [ 1151.055307] kfree+0x276/0x2b0 [ 1151.055832] __x64_sys_swapoff+0x39a/0x540 [ 1151.056466] do_syscall_64+0x33/0x40 [ 1151.057084] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 1151.057866] RIP: 0033:0x150340b0ffb7 [ 1151.058481] Code: Unable to access opcode bytes at RIP 0x150340b0ff8d. [ 1151.059537] RSP: 002b:00007fff7f4ee238 EFLAGS: 00000246 ORIG_RAX: 00000000000000a8 [ 1151.060768] RAX: ffffffffffffffda RBX: 00007fff7f4ee66c RCX: 0000150340b0ffb7 [ 1151.061904] RDX: 000000000000000a RSI: 0000000000018094 RDI: 00007fff7f4ee860 [ 1151.063033] RBP: 00007fff7f4ef980 R08: 0000000000000000 R09: 0000150340a672bd [ 1151.064135] R10: 00007fff7f4edca0 R11: 0000000000000246 R12: 0000000000018094 [ 1151.065253] R13: 0000000000000005 R14: 000000000160d930 R15: 00007fff7f4ee66c [ 1151.066413] FIX kmalloc-16: Restoring 0x0000000084e43932-0x0000000098d17cae=0xcc [ 1151.066413] [ 1151.067890] FIX kmalloc-16: Object at 0x000000004855ba01 not freed Fixes: 67482129cdab ("iomap: add a swapfile activation function") Fixes: a45c0eccc564 ("iomap: move the swapfile code into a separate file") Signed-off-by: Gang Deng Signed-off-by: Xu Yu Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Reviewed-by: Christoph Hellwig Signed-off-by: Sasha Levin commit a9c29bc2a5780a6389c501d42b70a67d1b1818fc Author: Nadezda Lutovinova Date: Wed Aug 18 17:12:47 2021 +0300 usb: gadget: mv_u3d: request_irq() after initializing UDC [ Upstream commit 2af0c5ffadaf9d13eca28409d4238b4e672942d3 ] If IRQ occurs between calling request_irq() and mv_u3d_eps_init(), then null pointer dereference occurs since u3d->eps[] wasn't initialized yet but used in mv_u3d_nuke(). The patch puts registration of the interrupt handler after initializing of neccesery data. Found by Linux Driver Verification project (linuxtesting.org). Fixes: 90fccb529d24 ("usb: gadget: Gadget directory cleanup - group UDC drivers") Acked-by: Felipe Balbi Signed-off-by: Nadezda Lutovinova Link: https://lore.kernel.org/r/20210818141247.4794-1-lutovinova@ispras.ru Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit b2f4dd13b211691715e99e28fff9ce9557acc57c Author: Christophe JAILLET Date: Fri Aug 6 08:46:11 2021 +0200 firmware: raspberrypi: Fix a leak in 'rpi_firmware_get()' [ Upstream commit 09cbd1df7d2615c19e40facbe31fdcb5f1ebfa96 ] The reference taken by 'of_find_device_by_node()' must be released when not needed anymore. Add the corresponding 'put_device()' in the normal and error handling paths. Fixes: 4e3d60656a72 ("ARM: bcm2835: Add the Raspberry Pi firmware driver") Signed-off-by: Christophe JAILLET Link: https://lore.kernel.org/r/5e17e5409b934cd08bf6f9279c73be5c1cb11cce.1628232242.git.christophe.jaillet@wanadoo.fr Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 60831f5ae6c713afceb6d29f40899ed112f36059 Author: Nicolas Saenz Julienne Date: Mon Jan 18 13:32:34 2021 +0100 firmware: raspberrypi: Keep count of all consumers [ Upstream commit 1e7c57355a3bc617fc220234889e49fe722a6305 ] When unbinding the firmware device we need to make sure it has no consumers left. Otherwise we'd leave them with a firmware handle pointing at freed memory. Keep a reference count of all consumers and introduce rpi_firmware_put() which will permit automatically decrease the reference count upon unbinding consumer drivers. Suggested-by: Uwe Kleine-König Signed-off-by: Nicolas Saenz Julienne Reviewed-by: Florian Fainelli Reviewed-by: Stephen Boyd Reviewed-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit 5c68b7795b4c7bdbd54148c9343b5a5edeb476d7 Author: Sergey Shtylyov Date: Thu Aug 12 23:39:11 2021 +0300 i2c: synquacer: fix deferred probing [ Upstream commit 8d744da241b81f4211f4813b0d3c1981326fa9ca ] The driver overrides the error codes returned by platform_get_irq() to -ENODEV, so if it returns -EPROBE_DEFER, the driver will fail the probe permanently instead of the deferred probing. Switch to propagating the error codes upstream. Fixes: 0d676a6c4390 ("i2c: add support for Socionext SynQuacer I2C controller") Signed-off-by: Sergey Shtylyov Acked-by: Ard Biesheuvel Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit f577e9f58ff079a61af08fae75b76cb8cc0c3057 Author: Lukas Bulwahn Date: Tue Aug 17 12:54:04 2021 +0200 clk: staging: correct reference to config IOMEM to config HAS_IOMEM [ Upstream commit cbfa6f33e3a685c329d78e06b0cf1dcb23c9d849 ] Commit 0a0a66c984b3 ("clk: staging: Specify IOMEM dependency for Xilinx Clocking Wizard driver") introduces a dependency on the non-existing config IOMEM, which basically makes it impossible to include this driver into any build. Fortunately, ./scripts/checkkconfigsymbols.py warns: IOMEM Referencing files: drivers/staging/clocking-wizard/Kconfig The config for IOMEM support is called HAS_IOMEM. Correct this reference to the intended config. Fixes: 0a0a66c984b3 ("clk: staging: Specify IOMEM dependency for Xilinx Clocking Wizard driver") Signed-off-by: Lukas Bulwahn Link: https://lore.kernel.org/r/20210817105404.13146-1-lukas.bulwahn@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 5ae5f087c9d6cef2178981269418324ced377763 Author: Pali Rohár Date: Thu Jun 24 23:55:46 2021 +0200 arm64: dts: marvell: armada-37xx: Extend PCIe MEM space [ Upstream commit 514ef1e62d6521c2199d192b1c71b79d2aa21d5a ] Current PCIe MEM space of size 16 MB is not enough for some combination of PCIe cards (e.g. NVMe disk together with ath11k wifi card). ARM Trusted Firmware for Armada 3700 platform already assigns 128 MB for PCIe window, so extend PCIe MEM space to the end of 128 MB PCIe window which allows to allocate more PCIe BARs for more PCIe cards. Without this change some combination of PCIe cards cannot be used and kernel show error messages in dmesg during initialization: pci 0000:00:00.0: BAR 8: no space for [mem size 0x01800000] pci 0000:00:00.0: BAR 8: failed to assign [mem size 0x01800000] pci 0000:00:00.0: BAR 6: assigned [mem 0xe8000000-0xe80007ff pref] pci 0000:01:00.0: BAR 8: no space for [mem size 0x01800000] pci 0000:01:00.0: BAR 8: failed to assign [mem size 0x01800000] pci 0000:02:03.0: BAR 8: no space for [mem size 0x01000000] pci 0000:02:03.0: BAR 8: failed to assign [mem size 0x01000000] pci 0000:02:07.0: BAR 8: no space for [mem size 0x00100000] pci 0000:02:07.0: BAR 8: failed to assign [mem size 0x00100000] pci 0000:03:00.0: BAR 0: no space for [mem size 0x01000000 64bit] pci 0000:03:00.0: BAR 0: failed to assign [mem size 0x01000000 64bit] Due to bugs in U-Boot port for Turris Mox, the second range in Turris Mox kernel DTS file for PCIe must start at 16 MB offset. Otherwise U-Boot crashes during loading of kernel DTB file. This bug is present only in U-Boot code for Turris Mox and therefore other Armada 3700 devices are not affected by this bug. Bug is fixed in U-Boot version 2021.07. To not break booting new kernels on existing versions of U-Boot on Turris Mox, use first 16 MB range for IO and second range with rest of PCIe window for MEM. Signed-off-by: Pali Rohár Fixes: 76f6386b25cc ("arm64: dts: marvell: Add Aardvark PCIe support for Armada 3700") Signed-off-by: Gregory CLEMENT Signed-off-by: Sasha Levin commit cb788d698a10ab6a572653a0b3ae3133518a0eee Author: J. Bruce Fields Date: Thu Aug 12 16:41:43 2021 -0400 nfsd4: Fix forced-expiry locking [ Upstream commit f7104cc1a9159cd0d3e8526cb638ae0301de4b61 ] This should use the network-namespace-wide client_lock, not the per-client cl_lock. You shouldn't see any bugs unless you're actually using the forced-expiry interface introduced by 89c905beccbb. Fixes: 89c905beccbb "nfsd: allow forced expiration of NFSv4 clients" Signed-off-by: J. Bruce Fields Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit c9773f42c1debe4d942eb8f05909a98bc8ec9e62 Author: Benjamin Coddington Date: Mon Jul 26 09:33:28 2021 -0400 lockd: Fix invalid lockowner cast after vfs_test_lock [ Upstream commit cd2d644ddba183ec7b451b7c20d5c7cc06fcf0d7 ] After calling vfs_test_lock() the pointer to a conflicting lock can be returned, and that lock is not guarunteed to be owned by nlm. In that case, we cannot cast it to struct nlm_lockowner. Instead return the pid of that conflicting lock. Fixes: 646d73e91b42 ("lockd: Show pid of lockd for remote locks") Signed-off-by: Benjamin Coddington Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit 2600861b9069d57bff1cac0e73fd3aac4f181df1 Author: Thomas Gleixner Date: Sun Aug 15 23:27:37 2021 +0200 locking/local_lock: Add missing owner initialization [ Upstream commit d8bbd97ad0b99a9394f2cd8410b884c48e218cf0 ] If CONFIG_DEBUG_LOCK_ALLOC=y is enabled then local_lock_t has an 'owner' member which is checked for consistency, but nothing initialized it to zero explicitly. The static initializer does so implicit, and the run time allocated per CPU storage is usually zero initialized as well, but relying on that is not really good practice. Fixes: 91710728d172 ("locking: Introduce local_lock()") Signed-off-by: Thomas Gleixner Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Link: https://lore.kernel.org/r/20210815211301.969975279@linutronix.de Signed-off-by: Sasha Levin commit d5462a630f7de9fc9cc25106b2adcb8cc69e51c2 Author: Peter Zijlstra Date: Wed Dec 9 16:06:21 2020 +0100 locking/lockdep: Mark local_lock_t [ Upstream commit dfd5e3f5fe27bda91d5cc028c86ffbb7a0614489 ] The local_lock_t's are special, because they cannot form IRQ inversions, make sure we can tell them apart from the rest of the locks. Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Sasha Levin commit 22b106df73c657e76310cbd9f2da4d745b2c27e9 Author: Chih-Kang Chang Date: Mon Aug 16 16:51:28 2021 +0800 mac80211: Fix insufficient headroom issue for AMSDU [ Upstream commit f50d2ff8f016b79a2ff4acd5943a1eda40c545d4 ] ieee80211_amsdu_realloc_pad() fails to account for extra_tx_headroom, the original reserved headroom might be eaten. Add the necessary extra_tx_headroom. Fixes: 6e0456b54545 ("mac80211: add A-MSDU tx support") Signed-off-by: Chih-Kang Chang Signed-off-by: Ping-Ke Shih Link: https://lore.kernel.org/r/20210816085128.10931-2-pkshih@realtek.com [fix indentation] Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 0ad4ddb27e2b7b83bfc453178ce190988f301991 Author: Andrii Nakryiko Date: Sun Aug 15 00:06:00 2021 -0700 libbpf: Re-build libbpf.so when libbpf.map changes [ Upstream commit 61c7aa5020e98ac2fdcf07d07eec1baf2e9f0a08 ] Ensure libbpf.so is re-built whenever libbpf.map is modified. Without this, changes to libbpf.map are not detected and versioned symbols mismatch error will be reported until `make clean && make` is used, which is a suboptimal developer experience. Fixes: 306b267cb3c4 ("libbpf: Verify versioned symbols") Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20210815070609.987780-8-andrii@kernel.org Signed-off-by: Sasha Levin commit 494629ba62a961de1f2dd0b7125878acb27b8043 Author: Sergey Shtylyov Date: Fri Aug 13 23:32:38 2021 +0300 usb: phy: tahvo: add IRQ check [ Upstream commit 0d45a1373e669880b8beaecc8765f44cb0241e47 ] The driver neglects to check the result of platform_get_irq()'s call and blithely passes the negative error codes to request_threaded_irq() (which takes *unsigned* IRQ #), causing it to fail with -EINVAL, overriding an original error code. Stop calling request_threaded_irq() with the invalid IRQ #s. Fixes: 9ba96ae5074c ("usb: omap1: Tahvo USB transceiver driver") Acked-by: Felipe Balbi Signed-off-by: Sergey Shtylyov Link: https://lore.kernel.org/r/8280d6a4-8e9a-7cfe-1aa9-db586dc9afdf@omp.ru Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 46638d6941ee55fec7a8c62abdb7cece0e231fe8 Author: Sergey Shtylyov Date: Fri Aug 13 23:30:18 2021 +0300 usb: host: ohci-tmio: add IRQ check [ Upstream commit 4ac5132e8a4300637a2da8f5d6bc7650db735b8a ] The driver neglects to check the result of platform_get_irq()'s call and blithely passes the negative error codes to usb_add_hcd() (which takes *unsigned* IRQ #), causing request_irq() that it calls to fail with -EINVAL, overriding an original error code. Stop calling usb_add_hcd() with the invalid IRQ #s. Fixes: 78c73414f4f6 ("USB: ohci: add support for tmio-ohci cell") Acked-by: Alan Stern Signed-off-by: Sergey Shtylyov Link: https://lore.kernel.org/r/402e1a45-a0a4-0e08-566a-7ca1331506b1@omp.ru Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 4b7874a32ec23cc4892e7c9ffac1dd8160ea3697 Author: Valentin Schneider Date: Wed Aug 11 21:14:31 2021 +0100 PM: cpu: Make notifier chain use a raw_spinlock_t [ Upstream commit b2f6662ac08d0e7c25574ce53623c71bdae9dd78 ] Invoking atomic_notifier_chain_notify() requires acquiring a spinlock_t, which can block under CONFIG_PREEMPT_RT. Notifications for members of the cpu_pm notification chain will be issued by the idle task, which can never block. Making *all* atomic_notifiers use a raw_spinlock is too big of a hammer, as only notifications issued by the idle task are problematic. Special-case cpu_pm_notifier_chain by kludging a raw_notifier and raw_spinlock_t together, matching the atomic_notifier behavior with a raw_spinlock_t. Fixes: 70d932985757 ("notifier: Fix broken error handling pattern") Signed-off-by: Valentin Schneider Acked-by: Sebastian Andrzej Siewior Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 471128476819777a7b71f2b90bc868ccf74b185f Author: Kai-Heng Feng Date: Tue Aug 10 12:53:15 2021 +0800 Bluetooth: Move shutdown callback before flushing tx and rx queue [ Upstream commit 0ea53674d07fb6db2dd7a7ec2fdc85a12eb246c2 ] Commit 0ea9fd001a14 ("Bluetooth: Shutdown controller after workqueues are flushed or cancelled") introduced a regression that makes mtkbtsdio driver stops working: [ 36.593956] Bluetooth: hci0: Firmware already downloaded [ 46.814613] Bluetooth: hci0: Execution of wmt command timed out [ 46.814619] Bluetooth: hci0: Failed to send wmt func ctrl (-110) The shutdown callback depends on the result of hdev->rx_work, so we should call it before flushing rx_work: -> btmtksdio_shutdown() -> mtk_hci_wmt_sync() -> __hci_cmd_send() -> wait for BTMTKSDIO_TX_WAIT_VND_EVT gets cleared -> btmtksdio_recv_event() -> hci_recv_frame() -> queue_work(hdev->workqueue, &hdev->rx_work) -> clears BTMTKSDIO_TX_WAIT_VND_EVT So move the shutdown callback before flushing TX/RX queue to resolve the issue. Reported-and-tested-by: Mattijs Korpershoek Tested-by: Hsin-Yi Wang Cc: Guenter Roeck Fixes: 0ea9fd001a14 ("Bluetooth: Shutdown controller after workqueues are flushed or cancelled") Signed-off-by: Kai-Heng Feng Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit d993a6f137ecf473859186081f36e5590eb9eb4e Author: Juhee Kang Date: Fri Aug 13 00:08:13 2021 +0900 samples: pktgen: add missing IPv6 option to pktgen scripts [ Upstream commit 0f0c4f1b72e090b23131700bb155944cc28b2a7b ] Currently, "sample04" and "sample05" are not working properly when running with an IPv6 option("-6"). The commit 0f06a6787e05 ("samples: Add an IPv6 "-6" option to the pktgen scripts") has omitted the addition of this option at "sample04" and "sample05". In order to support IPv6 option, this commit adds logic related to IPv6 option. Fixes: 0f06a6787e05 ("samples: Add an IPv6 "-6" option to the pktgen scripts") Signed-off-by: Juhee Kang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 2c0b826f4a7906e833a343423a8bf814d9cc8b34 Author: Leon Romanovsky Date: Sat Aug 14 12:57:30 2021 +0300 devlink: Clear whole devlink_flash_notify struct [ Upstream commit ed43fbac717882165a2a4bd64f7b1f56f7467bb7 ] The { 0 } doesn't clear all fields in the struct, but tells to the compiler to set all fields to zero and doesn't touch any sub-fields if they exists. The {} is an empty initialiser that instructs to fully initialize whole struct including sub-fields, which is error-prone for future devlink_flash_notify extensions. Fixes: 6700acc5f1fe ("devlink: collect flash notify params into a struct") Signed-off-by: Leon Romanovsky Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 2aa3d5c9e19e2db01985856bb87c1b46e1f64d50 Author: Ilya Leoshkevich Date: Fri Aug 13 00:48:14 2021 +0200 selftests/bpf: Fix test_core_autosize on big-endian machines [ Upstream commit d164dd9a5c08c16a883b3de97d13948c7be7fa4d ] The "probed" part of test_core_autosize copies an integer using bpf_core_read() into an integer of a potentially different size. On big-endian machines a destination offset is required for this to produce a sensible result. Fixes: 888d83b961f6 ("selftests/bpf: Validate libbpf's auto-sizing of LD/ST/STX instructions") Signed-off-by: Ilya Leoshkevich Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20210812224814.187460-1-iii@linux.ibm.com Signed-off-by: Sasha Levin commit c03bf1bc84ea0189863aa808d233e42556568c5c Author: Geert Uytterhoeven Date: Wed Aug 11 17:52:54 2021 +0200 usb: gadget: udc: renesas_usb3: Fix soc_device_match() abuse [ Upstream commit cea45a3bd2dd4d9c35581328f571afd32b3c9f48 ] soc_device_match() is intended as a last resort, to handle e.g. quirks that cannot be handled by matching based on a compatible value. As the device nodes for the Renesas USB 3.0 Peripheral Controller on R-Car E3 and RZ/G2E do have SoC-specific compatible values, the latter can and should be used to match against these devices. This also fixes support for the USB 3.0 Peripheral Controller on the R-Car E3e (R8A779M6) SoC, which is a different grading of the R-Car E3 (R8A77990) SoC, using the same SoC-specific compatible value. Fixes: 30025efa8b5e75f5 ("usb: gadget: udc: renesas_usb3: add support for r8a77990") Fixes: 546970fdab1da5fe ("usb: gadget: udc: renesas_usb3: add support for r8a774c0") Reviewed-by: Niklas Söderlund Signed-off-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/760981fb4cd110d7cbfc9dcffa365e7c8b25c6e5.1628696960.git.geert+renesas@glider.be Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit eabbb2e8cc41a4c1149ea6ec2e3c51572301accb Author: Sergey Shtylyov Date: Mon Aug 9 23:53:16 2021 +0300 usb: phy: twl6030: add IRQ checks [ Upstream commit 0881e22c06e66af0b64773c91c8868ead3d01aa1 ] The driver neglects to check the result of platform_get_irq()'s calls and blithely passes the negative error codes to request_threaded_irq() (which takes *unsigned* IRQ #), causing them both to fail with -EINVAL, overriding an original error code. Stop calling request_threaded_irq() with the invalid IRQ #s. Fixes: c33fad0c3748 ("usb: otg: Adding twl6030-usb transceiver driver for OMAP4430") Acked-by: Felipe Balbi Signed-off-by: Sergey Shtylyov Link: https://lore.kernel.org/r/9507f50b-50f1-6dc4-f57c-3ed4e53a1c25@omp.ru Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit fa5dbfd53982fd98d1ccc234a9595d8e0489eff5 Author: Sergey Shtylyov Date: Mon Aug 9 23:50:18 2021 +0300 usb: phy: fsl-usb: add IRQ check [ Upstream commit ecc2f30dbb25969908115c81ec23650ed982b004 ] The driver neglects to check the result of platform_get_irq()'s call and blithely passes the negative error codes to request_irq() (which takes *unsigned* IRQ #), causing it to fail with -EINVAL, overriding an original error code. Stop calling request_irq() with the invalid IRQ #s. Fixes: 0807c500a1a6 ("USB: add Freescale USB OTG Transceiver driver") Acked-by: Felipe Balbi Signed-off-by: Sergey Shtylyov Link: https://lore.kernel.org/r/b0a86089-8b8b-122e-fd6d-73e8c2304964@omp.ru Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 99ad1be3e9cb1e9eba0c494c8dbff3b21295b101 Author: Sergey Shtylyov Date: Mon Aug 9 23:35:11 2021 +0300 usb: gadget: udc: s3c2410: add IRQ check [ Upstream commit ecff88e819e31081d41cd05bb199b9bd10e13e90 ] The driver neglects to check the result of platform_get_irq()'s call and blithely passes the negative error codes to request_irq() (which takes *unsigned* IRQ #), causing it to fail with -EINVAL, overriding an original error code. Stop calling request_irq() with the invalid IRQ #s. Fixes: 188db4435ac6 ("usb: gadget: s3c: use platform resources") Reviewed-by: Krzysztof Kozlowski Acked-by: Felipe Balbi Signed-off-by: Sergey Shtylyov Link: https://lore.kernel.org/r/bd69b22c-b484-5a1f-c798-78d4b78405f2@omp.ru Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 0a77314589685d4a325c6170b237b84867ab4ade Author: Sergey Shtylyov Date: Mon Aug 9 23:27:28 2021 +0300 usb: gadget: udc: at91: add IRQ check [ Upstream commit 50855c31573b02963f0aa2aacfd4ea41c31ae0e0 ] The driver neglects to check the result of platform_get_irq()'s call and blithely passes the negative error codes to devm_request_irq() (which takes *unsigned* IRQ #), causing it to fail with -EINVAL, overriding an original error code. Stop calling devm_request_irq() with the invalid IRQ #s. Fixes: 8b2e76687b39 ("USB: AT91 UDC updates, mostly power management") Signed-off-by: Sergey Shtylyov Acked-by: Felipe Balbi Link: https://lore.kernel.org/r/6654a224-739a-1a80-12f0-76d920f87b6c@omp.ru Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 27f102bcee52cf12d023fd76c8f15f16c665b687 Author: Sergey Shtylyov Date: Mon Aug 9 23:23:51 2021 +0300 usb: dwc3: qcom: add IRQ check [ Upstream commit 175006956740f70ca23394c58f8d7804776741bd ] In dwc3_qcom_acpi_register_core(), the driver neglects to check the result of platform_get_irq()'s call and blithely assigns the negative error codes to the allocated child device's IRQ resource and then passing this resource to platform_device_add_resources() and later causing dwc3_otg_get_irq() to fail anyway. Stop calling platform_device_add_resources() with the invalid IRQ #s, so that there's less complexity in the IRQ error checking. Fixes: 2bc02355f8ba ("usb: dwc3: qcom: Add support for booting with ACPI") Acked-by: Felipe Balbi Signed-off-by: Sergey Shtylyov Link: https://lore.kernel.org/r/45fec3da-1679-5bfe-5d74-219ca3fb28e7@omp.ru Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit c4e0f54a56d04d1126034d5049a26c33ca1ae7ef Author: Sergey Shtylyov Date: Mon Aug 9 23:21:14 2021 +0300 usb: dwc3: meson-g12a: add IRQ check [ Upstream commit baa2986bda3f7b2386607587a4185e3dff8f98df ] The driver neglects to check the result of platform_get_irq()'s call and blithely passes the negative error codes to devm_request_threaded_irq() (which takes *unsigned* IRQ #), causing it to fail with -EINVAL, overriding an original error code. Stop calling devm_request_threaded_irq() with the invalid IRQ #s. Fixes: f90db10779ad ("usb: dwc3: meson-g12a: Add support for IRQ based OTG switching") Reviewed-by: Martin Blumenstingl Acked-by: Felipe Balbi Signed-off-by: Sergey Shtylyov Link: https://lore.kernel.org/r/96106462-5538-0b2f-f2ab-ee56e4853912@omp.ru Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 96ba1e20e25259f46d1645a46976240510740216 Author: Douglas Anderson Date: Wed Aug 11 08:17:56 2021 -0700 ASoC: rt5682: Properly turn off regulators if wrong device ID [ Upstream commit 772d44526e203c062171786e514373f129616278 ] When I booted up on a board that had a slightly different codec stuffed on it, I got this message at bootup: rt5682 9-001a: Device with ID register 6749 is not rt5682 That's normal/expected, but what wasn't normal was the splat that I got after: WARNING: CPU: 7 PID: 176 at drivers/regulator/core.c:2151 _regulator_put+0x150/0x158 pc : _regulator_put+0x150/0x158 ... Call trace: _regulator_put+0x150/0x158 regulator_bulk_free+0x48/0x70 devm_regulator_bulk_release+0x20/0x2c release_nodes+0x1cc/0x244 devres_release_all+0x44/0x60 really_probe+0x17c/0x378 ... This is because the error paths don't turn off the regulator. Let's fix that. Fixes: 0ddce71c21f0 ("ASoC: rt5682: add rt5682 codec driver") Fixes: 87b42abae99d ("ASoC: rt5682: Implement remove callback") Signed-off-by: Douglas Anderson Reviewed-by: Stephen Boyd Link: https://lore.kernel.org/r/20210811081751.v2.1.I4a1d9aa5d99e05aeee15c2768db600158d76cab8@changeid Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 1a2feb23043ba9a54fb54fcbd21c02b1fc7eefd2 Author: Stephen Boyd Date: Sat May 8 00:51:51 2021 -0700 ASoC: rt5682: Implement remove callback [ Upstream commit 87b42abae99d3d851aec64cd4d0f7def8113950e ] Let's implement a remove callback for this driver that's similar to the shutdown hook, but also disables the regulators before they're put by devm code. Cc: Jairaj Arava Cc: Sathyanarayana Nujella Cc: Pierre-Louis Bossart Cc: Shuming Fan Cc: Ranjani Sridharan Signed-off-by: Stephen Boyd Link: https://lore.kernel.org/r/20210508075151.1626903-2-swboyd@chromium.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 628acf6ee2f1236c866e794f631739e5292801aa Author: Parav Pandit Date: Tue Aug 10 16:24:21 2021 +0300 net/mlx5: Fix unpublish devlink parameters [ Upstream commit 6f35723864b42ec9e9bb95a503449633395c4975 ] Cleanup routine missed to unpublish the parameters. Add it. Fixes: e890acd5ff18 ("net/mlx5: Add devlink flow_steering_mode parameter") Signed-off-by: Parav Pandit Reviewed-by: Jiri Pirko Reviewed-by: Leon Romanovsky Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit fe6322774ca28669868a7e231e173e09f7422118 Author: Aya Levin Date: Tue Jan 26 15:24:08 2021 -0800 net/mlx5: Register to devlink ingress VLAN filter trap [ Upstream commit 82e6c96f04e13c72d91777455836ffd012853caa ] Add traps registration to mlx5_core devlink register/unregister flow. This patch registers INGRESS_VLAN_FILTER trap. Signed-off-by: Aya Levin Reviewed-by: Tariq Toukan Signed-off-by: Tariq Toukan Signed-off-by: Saeed Mahameed Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit dbeb4574ddf07c072e17d773fd33f1e8dd539b1a Author: Christophe JAILLET Date: Fri Aug 6 11:15:13 2021 +0200 drm/msm/dsi: Fix some reference counted resource leaks [ Upstream commit 6977cc89c87506ff17e6c05f0e37f46752256e82 ] 'of_find_device_by_node()' takes a reference that must be released when not needed anymore. This is expected to be done in 'dsi_destroy()'. However, there are 2 issues in 'dsi_get_phy()'. First, if 'of_find_device_by_node()' succeeds but 'platform_get_drvdata()' returns NULL, 'msm_dsi->phy_dev' will still be NULL, and the reference won't be released in 'dsi_destroy()'. Secondly, as 'of_find_device_by_node()' already takes a reference, there is no need for an additional 'get_device()'. Move the assignment to 'msm_dsi->phy_dev' a few lines above and remove the unneeded 'get_device()' to solve both issues. Fixes: ec31abf6684e ("drm/msm/dsi: Separate PHY to another platform device") Signed-off-by: Christophe JAILLET Link: https://lore.kernel.org/r/f15bc57648a00e7c99f943903468a04639d50596.1628241097.git.christophe.jaillet@wanadoo.fr Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 059c2c09f4b7f97711d0d8eaa0b9877f5e7d0a75 Author: Desmond Cheong Zhi Xi Date: Tue Aug 10 12:14:10 2021 +0800 Bluetooth: fix repeated calls to sco_sock_kill [ Upstream commit e1dee2c1de2b4dd00eb44004a4bda6326ed07b59 ] In commit 4e1a720d0312 ("Bluetooth: avoid killing an already killed socket"), a check was added to sco_sock_kill to skip killing a socket if the SOCK_DEAD flag was set. This was done after a trace for a use-after-free bug showed that the same sock pointer was being killed twice. Unfortunately, this check prevents sco_sock_kill from running on any socket. sco_sock_kill kills a socket only if it's zapped and orphaned, however sock_orphan announces that the socket is dead before detaching it. i.e., orphaned sockets have the SOCK_DEAD flag set. To fix this, we remove the check for SOCK_DEAD, and avoid repeated calls to sco_sock_kill by removing incorrect calls in: 1. sco_sock_timeout. The socket should not be killed on timeout as further processing is expected to be done. For example, sco_sock_connect sets the timer then waits for the socket to be connected or for an error to be returned. 2. sco_conn_del. This function should clean up resources for the connection, but the socket itself should be cleaned up in sco_sock_release. 3. sco_sock_close. Calls to sco_sock_close in sco_sock_cleanup_listen and sco_sock_release are followed by sco_sock_kill. Hence the duplicated call should be removed. Fixes: 4e1a720d0312 ("Bluetooth: avoid killing an already killed socket") Signed-off-by: Desmond Cheong Zhi Xi Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 6df58421da1313a9e37d70fb5ea97d5591bed446 Author: Curtis Malainey Date: Mon Aug 9 14:35:39 2021 -0700 ASoC: Intel: Fix platform ID matching [ Upstream commit f4eeaed04e861b95f1f2c911263f2fcaa959c078 ] Sparse warnings triggered truncating the IDs of some platform device tables. Unfortunately some of the IDs in the match tables were missed which breaks audio. The KBL change has been verified to fix audio, the CML change was not tested as it was found through grepping the broken changes and found to match the same situation in anticipation that it should also be fixed. Fixes: 94efd726b947 ("ASoC: Intel: kbl_da7219_max98357a: shrink platform_id below 20 characters") Fixes: 24e46fb811e9 ("ASoC: Intel: bxt_da7219_max98357a: shrink platform_id below 20 characters") Signed-off-by: Curtis Malainey Tested-by: Matt Davis Reviewed-by: Cezary Rojewski Acked-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20210809213544.1682444-1-cujomalainey@chromium.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 10dfcfda5c6f532726caf3b0e63a6d705592942b Author: Waiman Long Date: Tue Jul 20 10:18:28 2021 -0400 cgroup/cpuset: Fix violation of cpuset locking rule [ Upstream commit 6ba34d3c73674e46d9e126e4f0cee79e5ef2481c ] The cpuset fields that manage partition root state do not strictly follow the cpuset locking rule that update to cpuset has to be done with both the callback_lock and cpuset_mutex held. This is now fixed by making sure that the locking rule is upheld. Fixes: 3881b86128d0 ("cpuset: Add an error state to cpuset.sched.partition") Fixes: 4b842da276a8 ("cpuset: Make CPU hotplug work with partition") Signed-off-by: Waiman Long Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit cbc97661439d9dd7693ebd6b9d7b8f5c4084e7e8 Author: Waiman Long Date: Tue Jul 20 10:18:26 2021 -0400 cgroup/cpuset: Miscellaneous code cleanup [ Upstream commit 0f3adb8a1e5f36e792598c1d77a2cfac9c90a4f9 ] Use more descriptive variable names for update_prstate(), remove unnecessary code and fix some typos. There is no functional change. Signed-off-by: Waiman Long Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit 974ab0a04fe6d2757a4a0b027deca28f263f51bb Author: William Breathitt Gray Date: Tue Aug 3 21:06:11 2021 +0900 counter: 104-quad-8: Return error when invalid mode during ceiling_write [ Upstream commit 728246e8f7269ecd35a2c6e6795323e6d8f48db7 ] The 104-QUAD-8 only has two count modes where a ceiling value makes sense: Range Limit and Modulo-N. Outside of these two modes, setting a ceiling value is an invalid operation -- so let's report it as such by returning -EINVAL. Fixes: fc069262261c ("counter: 104-quad-8: Add lock guards - generic interface") Acked-by: Syed Nayyar Waris Signed-off-by: William Breathitt Gray Link: https://lore.kernel.org/r/a2147f022829b66839a1db5530a7fada47856847.1627990337.git.vilhelm.gray@gmail.com Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit c158f9b232796a94dc55c4b0fa0147d30312b96c Author: Krzysztof Kozlowski Date: Thu Aug 5 09:21:10 2021 +0200 arm64: dts: exynos: correct GIC CPU interfaces address range on Exynos7 [ Upstream commit 01c72cad790cb6cd3ccbe4c1402b6cb6c6bbffd0 ] The GIC-400 CPU interfaces address range is defined as 0x2000-0x3FFF (by ARM). Reported-by: Sam Protsenko Reported-by: Marc Zyngier Signed-off-by: Krzysztof Kozlowski Reviewed-by: Sam Protsenko Reviewed-by: Alim Akhtar Fixes: b9024cbc937d ("arm64: dts: Add initial device tree support for exynos7") Link: https://lore.kernel.org/r/20210805072110.4730-1-krzysztof.kozlowski@canonical.com Signed-off-by: Sasha Levin commit 7125705623f9ebef50f547d4e324daa889317f18 Author: Dmitry Baryshkov Date: Mon Jul 5 02:05:19 2021 +0300 drm/msm/dpu: make dpu_hw_ctl_clear_all_blendstages clear necessary LMs [ Upstream commit a41cdb693595ae1904dd793fc15d6954f4295e27 ] dpu_hw_ctl_clear_all_blendstages() clears settings for the few first LMs instead of mixers actually used for the CTL. Change it to clear necessary data, using provided mixer ids. Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support") Signed-off-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20210704230519.4081467-1-dmitry.baryshkov@linaro.org Signed-off-by: Dmitry Baryshkov Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit a6e980b110d27bc8da84c28e41ed2c4df35bc286 Author: David Heidelberg Date: Tue Jul 6 01:16:41 2021 +0200 drm/msm/mdp4: move HW revision detection to earlier phase [ Upstream commit 4af4fc92939dc811ef291c0673946555aa4fb71f ] Fixes if condition, which never worked inside mdp4_kms_init, since HW detection has been done later in mdp4_hw_init. Fixes: eb2b47bb9a03 ("drm/msm/mdp4: only use lut_clk on mdp4.2+") Signed-off-by: David Heidelberg Link: https://lore.kernel.org/r/20210705231641.315804-2-david@ixit.cz Reviewed-by: Dmitry Baryshkov Signed-off-by: Dmitry Baryshkov Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 90363618b5529ae6c70dffd88bfcacaef5676cc7 Author: David Heidelberg Date: Tue Jul 6 01:16:40 2021 +0200 drm/msm/mdp4: refactor HW revision detection into read_mdp_hw_revision [ Upstream commit 4d319afe666b0fc9a9855ba9bdf9ae3710ecf431 ] Inspired by MDP5 code. Also use DRM_DEV_INFO for MDP version as MDP5 does. Cosmetic change: uint32_t -> u32 - checkpatch suggestion. Signed-off-by: David Heidelberg Link: https://lore.kernel.org/r/20210705231641.315804-1-david@ixit.cz Reviewed-by: Dmitry Baryshkov Signed-off-by: Dmitry Baryshkov Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 416929eaf44e94351e458f4e7aa484977a11abd2 Author: Jose Blanquicet Date: Thu Aug 5 18:40:36 2021 +0200 selftests/bpf: Fix bpf-iter-tcp4 test to print correctly the dest IP [ Upstream commit 277b134057036df8c657079ca92c3e5e7d10aeaf ] Currently, this test is incorrectly printing the destination port in place of the destination IP. Fixes: 2767c97765cb ("selftests/bpf: Implement sample tcp/tcp6 bpf_iter programs") Signed-off-by: Jose Blanquicet Signed-off-by: Daniel Borkmann Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20210805164044.527903-1-josebl@microsoft.com Signed-off-by: Sasha Levin commit d6337dfd1e772660102316ec04c5a2d3ef7bf7d1 Author: Lukasz Luba Date: Tue Aug 3 11:27:43 2021 +0100 PM: EM: Increase energy calculation precision [ Upstream commit 7fcc17d0cb12938d2b3507973a6f93fc9ed2c7a1 ] The Energy Model (EM) provides useful information about device power in each performance state to other subsystems like: Energy Aware Scheduler (EAS). The energy calculation in EAS does arithmetic operation based on the EM em_cpu_energy(). Current implementation of that function uses em_perf_state::cost as a pre-computed cost coefficient equal to: cost = power * max_frequency / frequency. The 'power' is expressed in milli-Watts (or in abstract scale). There are corner cases when the EAS energy calculation for two Performance Domains (PDs) return the same value. The EAS compares these values to choose smaller one. It might happen that this values are equal due to rounding error. In such scenario, we need better resolution, e.g. 1000 times better. To provide this possibility increase the resolution in the em_perf_state::cost for 64-bit architectures. The cost of increasing resolution on 32-bit is pretty high (64-bit division) and is not justified since there are no new 32bit big.LITTLE EAS systems expected which would benefit from this higher resolution. This patch allows to avoid the rounding to milli-Watt errors, which might occur in EAS energy estimation for each PD. The rounding error is common for small tasks which have small utilization value. There are two places in the code where it makes a difference: 1. In the find_energy_efficient_cpu() where we are searching for best_delta. We might suffer there when two PDs return the same result, like in the example below. Scenario: Low utilized system e.g. ~200 sum_util for PD0 and ~220 for PD1. There are quite a few small tasks ~10-15 util. These tasks would suffer for the rounding error. These utilization values are typical when running games on Android. One of our partners has reported 5..10mA less battery drain when running with increased resolution. Some details: We have two PDs: PD0 (big) and PD1 (little) Let's compare w/o patch set ('old') and w/ patch set ('new') We are comparing energy w/ task and w/o task placed in the PDs a) 'old' w/o patch set, PD0 task_util = 13 cost = 480 sum_util_w/o_task = 215 sum_util_w_task = 228 scale_cpu = 1024 energy_w/o_task = 480 * 215 / 1024 = 100.78 => 100 energy_w_task = 480 * 228 / 1024 = 106.87 => 106 energy_diff = 106 - 100 = 6 (this is equal to 'old' PD1's energy_diff in 'c)') b) 'new' w/ patch set, PD0 task_util = 13 cost = 480 * 1000 = 480000 sum_util_w/o_task = 215 sum_util_w_task = 228 energy_w/o_task = 480000 * 215 / 1024 = 100781 energy_w_task = 480000 * 228 / 1024 = 106875 energy_diff = 106875 - 100781 = 6094 (this is not equal to 'new' PD1's energy_diff in 'd)') c) 'old' w/o patch set, PD1 task_util = 13 cost = 160 sum_util_w/o_task = 283 sum_util_w_task = 293 scale_cpu = 355 energy_w/o_task = 160 * 283 / 355 = 127.55 => 127 energy_w_task = 160 * 296 / 355 = 133.41 => 133 energy_diff = 133 - 127 = 6 (this is equal to 'old' PD0's energy_diff in 'a)') d) 'new' w/ patch set, PD1 task_util = 13 cost = 160 * 1000 = 160000 sum_util_w/o_task = 283 sum_util_w_task = 293 scale_cpu = 355 energy_w/o_task = 160000 * 283 / 355 = 127549 energy_w_task = 160000 * 296 / 355 = 133408 energy_diff = 133408 - 127549 = 5859 (this is not equal to 'new' PD0's energy_diff in 'b)') 2. Difference in the 6% energy margin filter at the end of find_energy_efficient_cpu(). With this patch the margin comparison also has better resolution, so it's possible to have better task placement thanks to that. Fixes: 27871f7a8a341ef ("PM: Introduce an Energy Model management framework") Reported-by: CCJ Yeh Reviewed-by: Dietmar Eggemann Signed-off-by: Lukasz Luba Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 5014a8453f0241cf4f8d35580a0129f76151907e Author: Colin Ian King Date: Wed Aug 4 16:09:51 2021 +0100 Bluetooth: increase BTNAMSIZ to 21 chars to fix potential buffer overflow [ Upstream commit 713baf3dae8f45dc8ada4ed2f5fdcbf94a5c274d ] An earlier commit replaced using batostr to using %pMR sprintf for the construction of session->name. Static analysis detected that this new method can use a total of 21 characters (including the trailing '\0') so we need to increase the BTNAMSIZ from 18 to 21 to fix potential buffer overflows. Addresses-Coverity: ("Out-of-bounds write") Fixes: fcb73338ed53 ("Bluetooth: Use %pMR in sprintf/seq_printf instead of batostr") Signed-off-by: Colin Ian King Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit afffa7b4c6e47967cfac323dd7debd342abb15c7 Author: Sven Eckelmann Date: Mon Aug 2 18:24:44 2021 +0200 debugfs: Return error during {full/open}_proxy_open() on rmmod [ Upstream commit 112cedc8e600b668688eb809bf11817adec58ddc ] If a kernel module gets unloaded then it printed report about a leak before commit 275678e7a9be ("debugfs: Check module state before warning in {full/open}_proxy_open()"). An additional check was added in this commit to avoid this printing. But it was forgotten that the function must return an error in this case because it was not actually opened. As result, the systems started to crash or to hang when a module was unloaded while something was trying to open a file. Fixes: 275678e7a9be ("debugfs: Check module state before warning in {full/open}_proxy_open()") Cc: Taehee Yoo Reported-by: Mário Lopes Signed-off-by: Sven Eckelmann Link: https://lore.kernel.org/r/20210802162444.7848-1-sven@narfation.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 17830b041534b13a80f9ca794c136174b44baf63 Author: Stephan Gerhold Date: Mon Jul 12 15:57:03 2021 +0200 soc: qcom: smsm: Fix missed interrupts if state changes while masked [ Upstream commit e3d4571955050736bbf3eda0a9538a09d9fcfce8 ] The SMSM driver detects interrupt edges by tracking the last state it has seen (and has triggered the interrupt handler for). This works fine, but only if the interrupt does not change state while masked. For example, if an interrupt is unmasked while the state is HIGH, the stored last_value for that interrupt might still be LOW. Then, when the remote processor triggers smsm_intr() we assume that nothing has changed, even though the state might have changed from HIGH to LOW. Attempt to fix this by checking the current remote state before unmasking an IRQ. Use atomic operations to avoid the interrupt handler from interfering with the unmask function. This fixes modem crashes in some edge cases with the BAM-DMUX driver. Specifically, the BAM-DMUX interrupt handler is not called for the HIGH -> LOW smsm state transition if the BAM-DMUX driver is loaded (and therefore unmasks the interrupt) after the modem was already started: qcom-q6v5-mss 4080000.remoteproc: fatal error received: a2_task.c:3188: Assert FALSE failed: A2 DL PER deadlock timer expired waiting for Apps ACK Fixes: c97c4090ff72 ("soc: qcom: smsm: Add driver for Qualcomm SMSM") Signed-off-by: Stephan Gerhold Link: https://lore.kernel.org/r/20210712135703.324748-2-stephan@gerhold.net Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit b8361513ac76919023352a33607e60d66136eb8e Author: Matthew Cover Date: Fri Jul 30 17:56:32 2021 -0700 bpf, samples: Add missing mprog-disable to xdp_redirect_cpu's optstring [ Upstream commit 34ad6d9d8c27293e1895b448af7d6cf5d351ad8d ] Commit ce4dade7f12a ("samples/bpf: xdp_redirect_cpu: Load a eBPF program on cpumap") added the following option, but missed adding it to optstring: - mprog-disable: disable loading XDP program on cpumap entries Fix it and add the missing option character. Fixes: ce4dade7f12a ("samples/bpf: xdp_redirect_cpu: Load a eBPF program on cpumap") Signed-off-by: Matthew Cover Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20210731005632.13228-1-matthew.cover@stackpath.com Signed-off-by: Sasha Levin commit cd6008e31af00822987ee62853f8e646467a4f7f Author: Rafael J. Wysocki Date: Thu Jul 29 16:49:10 2021 +0200 PCI: PM: Enable PME if it can be signaled from D3cold [ Upstream commit 0e00392a895c95c6d12d42158236c8862a2f43f2 ] PME signaling is only enabled by __pci_enable_wake() if the target device can signal PME from the given target power state (to avoid pointless reconfiguration of the device), but if the hierarchy above the device goes into D3cold, the device itself will end up in D3cold too, so if it can signal PME from D3cold, it should be enabled to do so in __pci_enable_wake(). [Note that if the device does not end up in D3cold and it cannot signal PME from the original target power state, it will not signal PME, so in that case the behavior does not change.] Link: https://lore.kernel.org/linux-pm/3149540.aeNJFYEL58@kreacher/ Fixes: 5bcc2fb4e815 ("PCI PM: Simplify PCI wake-up code") Reported-by: Mika Westerberg Reported-by: Utkarsh H Patel Reported-by: Koba Ko Signed-off-by: Rafael J. Wysocki Reviewed-by: Mika Westerberg Tested-by: Mika Westerberg Signed-off-by: Sasha Levin commit 3890c6e1da3146545f9c34611fc94672667a0ce5 Author: Rafael J. Wysocki Date: Thu Jul 29 17:54:28 2021 +0200 PCI: PM: Avoid forcing PCI_D0 for wakeup reasons inconsistently [ Upstream commit da9f2150684ea684a7ddd6d7f0e38b2bdf43dcd8 ] It is inconsistent to return PCI_D0 from pci_target_state() instead of the original target state if 'wakeup' is true and the device cannot signal PME from D0. This only happens when the device cannot signal PME from the original target state and any shallower power states (including D0) and that case is effectively equivalent to the one in which PME singaling is not supported at all. Since the original target state is returned in the latter case, make the function do that in the former one too. Link: https://lore.kernel.org/linux-pm/3149540.aeNJFYEL58@kreacher/ Fixes: 666ff6f83e1d ("PCI/PM: Avoid using device_may_wakeup() for runtime PM") Reported-by: Mika Westerberg Reported-by: Utkarsh H Patel Reported-by: Koba Ko Signed-off-by: Rafael J. Wysocki Reviewed-by: Mika Westerberg Tested-by: Mika Westerberg Signed-off-by: Sasha Levin commit eda4ccca906fa2b007d7e4a4f97fb53977633d3f Author: Colin Ian King Date: Fri Jul 9 14:30:25 2021 +0200 media: venus: venc: Fix potential null pointer dereference on pointer fmt [ Upstream commit 09ea9719a423fc675d40dd05407165e161ea0c48 ] Currently the call to find_format can potentially return a NULL to fmt and the nullpointer is later dereferenced on the assignment of pixmp->num_planes = fmt->num_planes. Fix this by adding a NULL pointer check and returning NULL for the failure case. Addresses-Coverity: ("Dereference null return") Fixes: aaaa93eda64b ("[media] media: venus: venc: add video encoder files") Signed-off-by: Colin Ian King Signed-off-by: Stanimir Varbanov Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 519ad41a098963755818690108cfbe6b0ff1ff00 Author: Dongliang Mu Date: Wed Jul 7 11:34:09 2021 +0200 media: em28xx-input: fix refcount bug in em28xx_usb_disconnect [ Upstream commit 6fa54bc713c262e1cfbc5613377ef52280d7311f ] If em28xx_ir_init fails, it would decrease the refcount of dev. However, in the em28xx_ir_fini, when ir is NULL, it goes to ref_put and decrease the refcount of dev. This will lead to a refcount bug. Fix this bug by removing the kref_put in the error handling code of em28xx_ir_init. refcount_t: underflow; use-after-free. WARNING: CPU: 0 PID: 7 at lib/refcount.c:28 refcount_warn_saturate+0x18e/0x1a0 lib/refcount.c:28 Modules linked in: CPU: 0 PID: 7 Comm: kworker/0:1 Not tainted 5.13.0 #3 Workqueue: usb_hub_wq hub_event RIP: 0010:refcount_warn_saturate+0x18e/0x1a0 lib/refcount.c:28 Call Trace: kref_put.constprop.0+0x60/0x85 include/linux/kref.h:69 em28xx_usb_disconnect.cold+0xd7/0xdc drivers/media/usb/em28xx/em28xx-cards.c:4150 usb_unbind_interface+0xbf/0x3a0 drivers/usb/core/driver.c:458 __device_release_driver drivers/base/dd.c:1201 [inline] device_release_driver_internal+0x22a/0x230 drivers/base/dd.c:1232 bus_remove_device+0x108/0x160 drivers/base/bus.c:529 device_del+0x1fe/0x510 drivers/base/core.c:3540 usb_disable_device+0xd1/0x1d0 drivers/usb/core/message.c:1419 usb_disconnect+0x109/0x330 drivers/usb/core/hub.c:2221 hub_port_connect drivers/usb/core/hub.c:5151 [inline] hub_port_connect_change drivers/usb/core/hub.c:5440 [inline] port_event drivers/usb/core/hub.c:5586 [inline] hub_event+0xf81/0x1d40 drivers/usb/core/hub.c:5668 process_one_work+0x2c9/0x610 kernel/workqueue.c:2276 process_scheduled_works kernel/workqueue.c:2338 [inline] worker_thread+0x333/0x5b0 kernel/workqueue.c:2424 kthread+0x188/0x1d0 kernel/kthread.c:319 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295 Reported-by: Dongliang Mu Fixes: ac5688637144 ("media: em28xx: Fix possible memory leak of em28xx struct") Signed-off-by: Dongliang Mu Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit a7dd8b778a4dc5bd3637a1364918f22ffd6ff7cf Author: Hans de Goede Date: Sun Feb 21 12:52:08 2021 +0100 leds: trigger: audio: Add an activate callback to ensure the initial brightness is set [ Upstream commit 64f67b5240db79eceb0bd57dae8e591fd3103ba0 ] Some 2-in-1s with a detachable (USB) keyboard(dock) have mute-LEDs in the speaker- and/or mic-mute keys on the keyboard. Examples of this are the Lenovo Thinkpad10 tablet (with its USB kbd-dock) and the HP x2 10 series. The detachable nature of these keyboards means that the keyboard and thus the mute LEDs may show up after the user (or userspace restoring old mixer settings) has muted the speaker and/or mic. Current LED-class devices with a default_trigger of "audio-mute" or "audio-micmute" initialize the brightness member of led_classdev with ledtrig_audio_get() before registering the LED. This makes the software state after attaching the keyboard match the actual audio mute state, e.g. cat /sys/class/leds/foo/brightness will show the right value. But before this commit nothing was actually calling the led_classdev's brightness_set[_blocking] callback so the value returned by ledtrig_audio_get() was never actually being sent to the hw, leading to the mute LEDs staying in their default power-on state, after attaching the keyboard, even if ledtrig_audio_get() returned a different state. This could be fixed by having the individual LED drivers call brightness_set[_blocking] themselves after registering the LED, but this really is something which should be done by a led-trigger activate callback. Add an activate callback for this, fixing the issue of the mute LEDs being out of sync after (re)attaching the keyboard. Cc: Takashi Iwai Fixes: faa2541f5b1a ("leds: trigger: Introduce audio mute LED trigger") Reviewed-by: Marek Behún Signed-off-by: Hans de Goede Signed-off-by: Pavel Machek Signed-off-by: Sasha Levin commit 917191d582f965958232673daa8c3369db6ad706 Author: Andy Shevchenko Date: Sat May 29 14:19:33 2021 +0300 leds: lt3593: Put fwnode in any case during ->probe() [ Upstream commit 7e1baaaa2407a642ea19b58e214fab9a69cda1d7 ] device_get_next_child_node() bumps a reference counting of a returned variable. We have to balance it whenever we return to the caller. Fixes: 8cd7d6daba93 ("leds: lt3593: Add device tree probing glue") Cc: Daniel Mack Signed-off-by: Andy Shevchenko Signed-off-by: Pavel Machek Signed-off-by: Sasha Levin commit eef8496579de75ee1482f717634fdb5378497bb1 Author: Sergey Shtylyov Date: Sun May 30 22:13:45 2021 +0300 i2c: highlander: add IRQ check [ Upstream commit f16a3bb69aa6baabf8f0aca982c8cf21e2a4f6bc ] The driver is written as if platform_get_irq() returns 0 on errors (while actually it returns a negative error code), blithely passing these error codes to request_irq() (which takes *unsigned* IRQ #) -- which fails with -EINVAL. Add the necessary error check to the pre-existing *if* statement forcing the driver into the polling mode... Fixes: 4ad48e6ab18c ("i2c: Renesas Highlander FPGA SMBus support") Signed-off-by: Sergey Shtylyov Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 11dd40c18918e7788121d25d23d853f8bf9e1fbc Author: Jiapeng Chong Date: Thu Jul 22 17:58:16 2021 +0800 net/mlx5: Fix missing return value in mlx5_devlink_eswitch_inline_mode_set() [ Upstream commit bcd68c04c7692416206414dc8971730aa140eba7 ] The return value is missing in this code scenario, add the return value '0' to the return value 'err'. Eliminate the follow smatch warning: drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c:3083 mlx5_devlink_eswitch_inline_mode_set() warn: missing error code 'err'. Reported-by: Abaci Robot Fixes: 8e0aa4bc959c ("net/mlx5: E-switch, Protect eswitch mode changes") Signed-off-by: Jiapeng Chong Reviewed-by: Leon Romanovsky Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit b376ae5597fcf24968587c99b747e926b3132a93 Author: Leon Romanovsky Date: Thu Jul 29 20:19:24 2021 +0300 devlink: Break parameter notification sequence to be before/after unload/load driver [ Upstream commit 05a7f4a8dff19999ca8a83a35ff4782689de7bfc ] The change of namespaces during devlink reload calls to driver unload before it accesses devlink parameters. The commands below causes to use-after-free bug when trying to get flow steering mode. * ip netns add n1 * devlink dev reload pci/0000:00:09.0 netns n1 ================================================================== BUG: KASAN: use-after-free in mlx5_devlink_fs_mode_get+0x96/0xa0 [mlx5_core] Read of size 4 at addr ffff888009d04308 by task devlink/275 CPU: 6 PID: 275 Comm: devlink Not tainted 5.12.0-rc2+ #2853 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack+0x93/0xc2 print_address_description.constprop.0+0x18/0x140 ? mlx5_devlink_fs_mode_get+0x96/0xa0 [mlx5_core] ? mlx5_devlink_fs_mode_get+0x96/0xa0 [mlx5_core] kasan_report.cold+0x7c/0xd8 ? mlx5_devlink_fs_mode_get+0x96/0xa0 [mlx5_core] mlx5_devlink_fs_mode_get+0x96/0xa0 [mlx5_core] devlink_nl_param_fill+0x1c8/0xe80 ? __free_pages_ok+0x37a/0x8a0 ? devlink_flash_update_timeout_notify+0xd0/0xd0 ? lock_acquire+0x1a9/0x6d0 ? fs_reclaim_acquire+0xb7/0x160 ? lock_is_held_type+0x98/0x110 ? 0xffffffff81000000 ? lock_release+0x1f9/0x6c0 ? fs_reclaim_release+0xa1/0xf0 ? lock_downgrade+0x6d0/0x6d0 ? lock_is_held_type+0x98/0x110 ? lock_is_held_type+0x98/0x110 ? memset+0x20/0x40 ? __build_skb_around+0x1f8/0x2b0 devlink_param_notify+0x6d/0x180 devlink_reload+0x1c3/0x520 ? devlink_remote_reload_actions_performed+0x30/0x30 ? mutex_trylock+0x24b/0x2d0 ? devlink_nl_cmd_reload+0x62b/0x1070 devlink_nl_cmd_reload+0x66d/0x1070 ? devlink_reload+0x520/0x520 ? devlink_get_from_attrs+0x1bc/0x260 ? devlink_nl_pre_doit+0x64/0x4d0 genl_family_rcv_msg_doit+0x1e9/0x2f0 ? mutex_lock_io_nested+0x1130/0x1130 ? genl_family_rcv_msg_attrs_parse.constprop.0+0x240/0x240 ? security_capable+0x51/0x90 genl_rcv_msg+0x27f/0x4a0 ? genl_get_cmd+0x3c0/0x3c0 ? lock_acquire+0x1a9/0x6d0 ? devlink_reload+0x520/0x520 ? lock_release+0x6c0/0x6c0 netlink_rcv_skb+0x11d/0x340 ? genl_get_cmd+0x3c0/0x3c0 ? netlink_ack+0x9f0/0x9f0 ? lock_release+0x1f9/0x6c0 genl_rcv+0x24/0x40 netlink_unicast+0x433/0x700 ? netlink_attachskb+0x730/0x730 ? _copy_from_iter_full+0x178/0x650 ? __alloc_skb+0x113/0x2b0 netlink_sendmsg+0x6f1/0xbd0 ? netlink_unicast+0x700/0x700 ? lock_is_held_type+0x98/0x110 ? netlink_unicast+0x700/0x700 sock_sendmsg+0xb0/0xe0 __sys_sendto+0x193/0x240 ? __x64_sys_getpeername+0xb0/0xb0 ? do_sys_openat2+0x10b/0x370 ? __up_read+0x1a1/0x7b0 ? do_user_addr_fault+0x219/0xdc0 ? __x64_sys_openat+0x120/0x1d0 ? __x64_sys_open+0x1a0/0x1a0 __x64_sys_sendto+0xdd/0x1b0 ? syscall_enter_from_user_mode+0x1d/0x50 do_syscall_64+0x2d/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7fc69d0af14a Code: d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 15 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 76 c3 0f 1f 44 00 00 55 48 83 ec 30 44 89 4c RSP: 002b:00007ffc1d8292f8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 0000000000000005 RCX: 00007fc69d0af14a RDX: 0000000000000038 RSI: 0000555f57c56440 RDI: 0000000000000003 RBP: 0000555f57c56410 R08: 00007fc69d17b200 R09: 000000000000000c R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 Allocated by task 146: kasan_save_stack+0x1b/0x40 __kasan_kmalloc+0x99/0xc0 mlx5_init_fs+0xf0/0x1c50 [mlx5_core] mlx5_load+0xd2/0x180 [mlx5_core] mlx5_init_one+0x2f6/0x450 [mlx5_core] probe_one+0x47d/0x6e0 [mlx5_core] pci_device_probe+0x2a0/0x4a0 really_probe+0x20a/0xc90 driver_probe_device+0xd8/0x380 device_driver_attach+0x1df/0x250 __driver_attach+0xff/0x240 bus_for_each_dev+0x11e/0x1a0 bus_add_driver+0x309/0x570 driver_register+0x1ee/0x380 0xffffffffa06b8062 do_one_initcall+0xd5/0x410 do_init_module+0x1c8/0x760 load_module+0x6d8b/0x9650 __do_sys_finit_module+0x118/0x1b0 do_syscall_64+0x2d/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xae Freed by task 275: kasan_save_stack+0x1b/0x40 kasan_set_track+0x1c/0x30 kasan_set_free_info+0x20/0x30 __kasan_slab_free+0x102/0x140 slab_free_freelist_hook+0x74/0x1b0 kfree+0xd7/0x2a0 mlx5_unload+0x16/0xb0 [mlx5_core] mlx5_unload_one+0xae/0x120 [mlx5_core] mlx5_devlink_reload_down+0x1bc/0x380 [mlx5_core] devlink_reload+0x141/0x520 devlink_nl_cmd_reload+0x66d/0x1070 genl_family_rcv_msg_doit+0x1e9/0x2f0 genl_rcv_msg+0x27f/0x4a0 netlink_rcv_skb+0x11d/0x340 genl_rcv+0x24/0x40 netlink_unicast+0x433/0x700 netlink_sendmsg+0x6f1/0xbd0 sock_sendmsg+0xb0/0xe0 __sys_sendto+0x193/0x240 __x64_sys_sendto+0xdd/0x1b0 do_syscall_64+0x2d/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xae The buggy address belongs to the object at ffff888009d04300 which belongs to the cache kmalloc-128 of size 128 The buggy address is located 8 bytes inside of 128-byte region [ffff888009d04300, ffff888009d04380) The buggy address belongs to the page: page:0000000086a64ecc refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888009d04000 pfn:0x9d04 head:0000000086a64ecc order:1 compound_mapcount:0 flags: 0x4000000000010200(slab|head) raw: 4000000000010200 ffffea0000203980 0000000200000002 ffff8880050428c0 raw: ffff888009d04000 000000008020001d 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff888009d04200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff888009d04280: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffff888009d04300: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff888009d04380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff888009d04400: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== The right solution to devlink reload is to notify about deletion of parameters, unload driver, change net namespaces, load driver and notify about addition of parameters. Fixes: 070c63f20f6c ("net: devlink: allow to change namespaces during reload") Reviewed-by: Parav Pandit Signed-off-by: Leon Romanovsky Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9fa9ff10408f13d53ef4a306e632140bae9f27d2 Author: Biju Das Date: Wed Jul 21 19:06:32 2021 +0100 arm64: dts: renesas: hihope-rzg2-ex: Add EtherAVB internal rx delay [ Upstream commit c96ca5604a889a142d6b60889cc6da48498806e9 ] Hihope boards use Realtek PHY. From the very beginning it use only tx delays. However the phy driver commit bbc4d71d63549bcd003 ("net: phy: realtek: fix rtl8211e rx/tx delay config") introduced NFS mount failure. Now it needs rx delay inaddition to tx delay for NFS mount to work. This patch fixes NFS mount failure issue by adding MAC internal rx delay. Signed-off-by: Biju Das Fixes: bbc4d71d63549bcd ("net: phy: realtek: fix rtl8211e rx/tx delay config") Link: https://lore.kernel.org/r/20210721180632.15080-1-biju.das.jz@bp.renesas.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit e4da0e0006f93fa4794c2288e7f04f43892f8a1d Author: Geert Uytterhoeven Date: Wed Aug 19 15:43:44 2020 +0200 arm64: dts: renesas: rzg2: Convert EtherAVB to explicit delay handling [ Upstream commit a5200e63af57d05ed8bf0ffd9a6ffefc40e01e89 ] Some EtherAVB variants support internal clock delay configuration, which can add larger delays than the delays that are typically supported by the PHY (using an "rgmii-*id" PHY mode, and/or "[rt]xc-skew-ps" properties). Historically, the EtherAVB driver configured these delays based on the "rgmii-*id" PHY mode. This was wrong, as these are meant solely for the PHY, not for the MAC. Hence properties were introduced for explicit configuration of these delays. Convert the RZ/G2 DTS files from the old to the new scheme: - Add default "rx-internal-delay-ps" and "tx-internal-delay-ps" properties to the SoC .dtsi files, to be overridden by board files where needed, - Convert board files from "rgmii-*id" PHY modes to "rgmii", adding the appropriate "rx-internal-delay-ps" and/or "tx-internal-delay-ps" overrides. Notes: - RZ/G2E does not support TX internal delay handling. Signed-off-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/20200819134344.27813-8-geert+renesas@glider.be Signed-off-by: Sasha Levin commit 61b1db2358686101db62f6bd200cb0eaf86f9ff6 Author: Tedd Ho-Jeong An Date: Mon Jul 26 13:22:36 2021 -0700 Bluetooth: mgmt: Fix wrong opcode in the response for add_adv cmd [ Upstream commit a25fca4d3c18766b6f7a3c95fa8faec23ef464c5 ] This patch fixes the MGMT add_advertising command repsones with the wrong opcode when it is trying to return the not supported error. Fixes: cbbdfa6f33198 ("Bluetooth: Enable controller RPA resolution using Experimental feature") Signed-off-by: Tedd Ho-Jeong An Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit bca46d228393682d47f91923da46675346ec2110 Author: Pavel Skripkin Date: Tue Jul 27 19:35:30 2021 +0300 net: cipso: fix warnings in netlbl_cipsov4_add_std [ Upstream commit 8ca34a13f7f9b3fa2c464160ffe8cc1a72088204 ] Syzbot reported warning in netlbl_cipsov4_add(). The problem was in too big doi_def->map.std->lvl.local_size passed to kcalloc(). Since this value comes from userpace there is no need to warn if value is not correct. The same problem may occur with other kcalloc() calls in this function, so, I've added __GFP_NOWARN flag to all kcalloc() calls there. Reported-and-tested-by: syzbot+cdd51ee2e6b0b2e18c0d@syzkaller.appspotmail.com Fixes: 96cb8e3313c7 ("[NetLabel]: CIPSOv4 and Unlabeled packet integration") Acked-by: Paul Moore Signed-off-by: Pavel Skripkin Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit b6b5dc12bd7cb70792db0c02dd74392be4189183 Author: Marek Vasut Date: Mon Jun 21 00:49:46 2021 +0200 drm: mxsfb: Clear FIFO_CLEAR bit [ Upstream commit 5e23c98178eb1a2cdb7c4fee9a39baf8cabf282d ] Make sure the FIFO_CLEAR bit is latched in when configuring the controller, so that the FIFO is really cleared. And then clear the FIFO_CLEAR bit, since it is not self-clearing. Fixes: 45d59d704080 ("drm: Add new driver for MXSFB controller") Signed-off-by: Marek Vasut Cc: Daniel Abrecht Cc: Emil Velikov Cc: Laurent Pinchart Cc: Lucas Stach Cc: Stefan Agner Reviewed-by: Jagan Teki Tested-by: Jagan Teki # i.Core MX8MM Acked-by: Lucas Stach Signed-off-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/20210620224946.189524-1-marex@denx.de Signed-off-by: Sasha Levin commit 1a0014c1c62cb2d7d8cc0d9d6ffd398c7ba79ccc Author: Marek Vasut Date: Mon Jun 21 00:47:59 2021 +0200 drm: mxsfb: Increase number of outstanding requests on V4 and newer HW [ Upstream commit 9891cb54445bc65bf156bda416b6215048c7f617 ] In case the DRAM is under high load, the MXSFB FIFO might underflow and that causes visible artifacts. This could be triggered on i.MX8MM using e.g. "$ memtester 128M" on a device with 1920x1080 panel. The first "Stuck Address" test of the memtester will completely corrupt the image on the panel and leave the MXSFB FIFO in odd state. To avoid this underflow, increase number of outstanding requests to DRAM from 2 to 16, which is the maximum. This mitigates the issue and it can no longer be triggered. Fixes: 45d59d704080 ("drm: Add new driver for MXSFB controller") Signed-off-by: Marek Vasut Cc: Daniel Abrecht Cc: Emil Velikov Cc: Laurent Pinchart Cc: Lucas Stach Cc: Stefan Agner Reviewed-by: Lucas Stach Signed-off-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/20210620224759.189351-1-marex@denx.de Signed-off-by: Sasha Levin commit 46f546394063fc1eaeb0ef56ac3d265974d9c146 Author: Marek Vasut Date: Mon Jun 21 00:47:01 2021 +0200 drm: mxsfb: Enable recovery on underflow [ Upstream commit 0c9856e4edcdcac22d65618e8ceff9eb41447880 ] There is some sort of corner case behavior of the controller, which could rarely be triggered at least on i.MX6SX connected to 800x480 DPI panel and i.MX8MM connected to DPI->DSI->LVDS bridged 1920x1080 panel (and likely on other setups too), where the image on the panel shifts to the right and wraps around. This happens either when the controller is enabled on boot or even later during run time. The condition does not correct itself automatically, i.e. the display image remains shifted. It seems this problem is known and is due to sporadic underflows of the LCDIF FIFO. While the LCDIF IP does have underflow/overflow IRQs, neither of the IRQs trigger and neither IRQ status bit is asserted when this condition occurs. All known revisions of the LCDIF IP have CTRL1 RECOVER_ON_UNDERFLOW bit, which is described in the reference manual since i.MX23 as " Set this bit to enable the LCDIF block to recover in the next field/frame if there was an underflow in the current field/frame. " Enable this bit to mitigate the sporadic underflows. Fixes: 45d59d704080 ("drm: Add new driver for MXSFB controller") Signed-off-by: Marek Vasut Cc: Daniel Abrecht Cc: Emil Velikov Cc: Laurent Pinchart Cc: Lucas Stach Cc: Stefan Agner Reviewed-by: Lucas Stach Reviewed-by: Laurent Pinchart Reviewed-by: Jagan Teki Signed-off-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/20210620224701.189289-1-marex@denx.de Signed-off-by: Sasha Levin commit e0f3de1573fd00cfcff5252ebc66d70df92ce717 Author: Waiman Long Date: Tue Jul 20 10:18:27 2021 -0400 cgroup/cpuset: Fix a partition bug with hotplug [ Upstream commit 15d428e6fe77fffc3f4fff923336036f5496ef17 ] In cpuset_hotplug_workfn(), the detection of whether the cpu list has been changed is done by comparing the effective cpus of the top cpuset with the cpu_active_mask. However, in the rare case that just all the CPUs in the subparts_cpus are offlined, the detection fails and the partition states are not updated correctly. Fix it by forcing the cpus_updated flag to true in this particular case. Fixes: 4b842da276a8 ("cpuset: Make CPU hotplug work with partition") Signed-off-by: Waiman Long Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit 7a0b297480ddfc1416393cea49ae93bc4cfb3739 Author: Maxim Mikityanskiy Date: Fri Apr 23 20:34:48 2021 +0300 net/mlx5e: Block LRO if firmware asks for tunneled LRO [ Upstream commit 26ab7b384525ccfa678c518577f7f0d841209c8b ] This commit does a cleanup in LRO configuration. LRO is a parameter of an RQ, but its state is changed by modifying a TIR related to the RQ. The current status: LRO for tunneled packets is not supported in the driver, inner TIRs may enable LRO on creation, but LRO status of inner TIRs isn't changed in mlx5e_modify_tirs_lro(). This is inconsistent, but as long as the firmware doesn't declare support for tunneled LRO, it works, because the same RQs are shared between the inner and outer TIRs. This commit does two fixes: 1. If the firmware has the tunneled LRO capability, LRO is blocked altogether, because it's not possible to block it for inner TIRs only, when the same RQs are shared between inner and outer TIRs, and the driver won't be able to handle tunneled LRO traffic. 2. mlx5e_modify_tirs_lro() is patched to modify LRO state for all TIRs, including inner ones, because all TIRs related to an RQ should agree on their LRO state. Fixes: 7b3722fa9ef6 ("net/mlx5e: Support RSS for GRE tunneled packets") Signed-off-by: Maxim Mikityanskiy Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit c40ed983b874bd077223e0db0fca4bb0f3d6dcc4 Author: Maxim Mikityanskiy Date: Thu Apr 8 17:20:04 2021 +0300 net/mlx5e: Prohibit inner indir TIRs in IPoIB [ Upstream commit 9c43f3865c2a03be104f1c1d5e9129c2a2bdba88 ] TIR's rx_hash_field_selector_inner can be enabled only when tunneled_offload_en = 1. tunneled_offload_en is filled according to the tunneled_offload_en field in struct mlx5e_params, which is false in the IPoIB profile. On the other hand, the IPoIB profile passes inner_ttc = true to mlx5e_create_indirect_tirs, which potentially allows the latter function to attempt to create inner indirect TIRs without having tunneled_offload_en set. This commit prohibits this behavior by passing inner_ttc = false to mlx5e_create_indirect_tirs. The latter function won't attempt to create inner indirect TIRs. As inner indirect TIRs are not created in the IPoIB profile (this commit blocks it explicitly, and even before they would have failed to be created), the call to mlx5e_create_inner_ttc_table in mlx5i_create_flow_steering is a no-op and can be removed. Fixes: 46dc933cee82 ("net/mlx5e: Provide explicit directive if to create inner indirect tirs") Fixes: 458821c72bd0 ("net/mlx5e: IPoIB, Add inner TTC table to IPoIB flow steering") Signed-off-by: Maxim Mikityanskiy Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit a11fc1cd8a31f48cae98da86c9aeb6c1b187d731 Author: Anand Moon Date: Mon Jul 5 11:23:55 2021 +0000 ARM: dts: meson8b: ec100: Fix the pwm regulator supply properties [ Upstream commit 72ccc373b064ae3ac0c5b5f2306069b60ca118df ] After enabling CONFIG_REGULATOR_DEBUG=y we observer below debug logs. Changes help link VCCK and VDDEE pwm regulator to 5V regulator supply instead of dummy regulator. [ 7.117140] pwm-regulator regulator-vcck: Looking up pwm-supply from device tree [ 7.117153] pwm-regulator regulator-vcck: Looking up pwm-supply property in node /regulator-vcck failed [ 7.117184] VCCK: supplied by regulator-dummy [ 7.117194] regulator-dummy: could not add device link regulator.8: -ENOENT [ 7.117266] VCCK: 860 <--> 1140 mV at 986 mV, enabled [ 7.118498] VDDEE: will resolve supply early: pwm [ 7.118515] pwm-regulator regulator-vddee: Looking up pwm-supply from device tree [ 7.118526] pwm-regulator regulator-vddee: Looking up pwm-supply property in node /regulator-vddee failed [ 7.118553] VDDEE: supplied by regulator-dummy [ 7.118563] regulator-dummy: could not add device link regulator.9: -ENOENT Fixes: 087a1d8b4e4c ("ARM: dts: meson8b: ec100: add the VDDEE regulator") Fixes: 3e7db1c1b7a3 ("ARM: dts: meson8b: ec100: improve the description of the regulators") Cc: Martin Blumenstingl Signed-off-by: Anand Moon Reviewed-by: Martin Blumenstingl Signed-off-by: Neil Armstrong Link: https://lore.kernel.org/r/20210705112358.3554-4-linux.amoon@gmail.com Signed-off-by: Sasha Levin commit 2e68547e99a763b80c2ef892681bbf0d8a3920a9 Author: Anand Moon Date: Mon Jul 5 11:23:54 2021 +0000 ARM: dts: meson8b: mxq: Fix the pwm regulator supply properties [ Upstream commit 632062e540becbbcb067523ec8bcadb1239d9578 ] After enabling CONFIG_REGULATOR_DEBUG=y we observer below debug logs. Changes help link VCCK and VDDEE pwm regulator to 5V regulator supply instead of dummy regulator. Add missing pwm-supply for regulator-vcck regulator node. [ 7.117140] pwm-regulator regulator-vcck: Looking up pwm-supply from device tree [ 7.117153] pwm-regulator regulator-vcck: Looking up pwm-supply property in node /regulator-vcck failed [ 7.117184] VCCK: supplied by regulator-dummy [ 7.117194] regulator-dummy: could not add device link regulator.8: -ENOENT [ 7.117266] VCCK: 860 <--> 1140 mV at 986 mV, enabled [ 7.118498] VDDEE: will resolve supply early: pwm [ 7.118515] pwm-regulator regulator-vddee: Looking up pwm-supply from device tree [ 7.118526] pwm-regulator regulator-vddee: Looking up pwm-supply property in node /regulator-vddee failed [ 7.118553] VDDEE: supplied by regulator-dummy [ 7.118563] regulator-dummy: could not add device link regulator.9: -ENOENT Fixes: dee51cd0d2e8 ("ARM: dts: meson8b: mxq: add the VDDEE regulator") Fixes: d94f60e3dfa0 ("ARM: dts: meson8b: mxq: improve support for the TRONFY MXQ S805") Cc: Martin Blumenstingl Signed-off-by: Anand Moon Reviewed-by: Martin Blumenstingl Signed-off-by: Neil Armstrong Link: https://lore.kernel.org/r/20210705112358.3554-3-linux.amoon@gmail.com Signed-off-by: Sasha Levin commit 0d40e59c03b83494901b07f500f58186f7d53be4 Author: Anand Moon Date: Mon Jul 5 11:23:53 2021 +0000 ARM: dts: meson8b: odroidc1: Fix the pwm regulator supply properties [ Upstream commit 876228e9f935f19c7afc7ba394d17e2ec9143b65 ] After enabling CONFIG_REGULATOR_DEBUG=y we observe below debug logs. Changes help link VCCK and VDDEE pwm regulator to 5V regulator supply instead of dummy regulator. [ 7.117140] pwm-regulator regulator-vcck: Looking up pwm-supply from device tree [ 7.117153] pwm-regulator regulator-vcck: Looking up pwm-supply property in node /regulator-vcck failed [ 7.117184] VCCK: supplied by regulator-dummy [ 7.117194] regulator-dummy: could not add device link regulator.8: -ENOENT [ 7.117266] VCCK: 860 <--> 1140 mV at 986 mV, enabled [ 7.118498] VDDEE: will resolve supply early: pwm [ 7.118515] pwm-regulator regulator-vddee: Looking up pwm-supply from device tree [ 7.118526] pwm-regulator regulator-vddee: Looking up pwm-supply property in node /regulator-vddee failed [ 7.118553] VDDEE: supplied by regulator-dummy [ 7.118563] regulator-dummy: could not add device link regulator.9: -ENOENT Fixes: 524d96083b66 ("ARM: dts: meson8b: odroidc1: add the CPU voltage regulator") Fixes: 8bdf38be712d ("ARM: dts: meson8b: odroidc1: add the VDDEE regulator") Tested-by: Martin Blumenstingl Cc: Martin Blumenstingl Signed-off-by: Anand Moon Reviewed-by: Martin Blumenstingl [narmstrong: fixed typo in commit s/observer/observe/] Signed-off-by: Neil Armstrong Link: https://lore.kernel.org/r/20210705112358.3554-2-linux.amoon@gmail.com Signed-off-by: Sasha Levin commit eda87dd4738a3248a91933bbd7414b99c2aaf048 Author: Martin Blumenstingl Date: Sun Jul 11 23:40:23 2021 +0200 ARM: dts: meson8: Use a higher default GPU clock frequency [ Upstream commit 44cf630bcb8c5ec78125805c9447dd5766792224 ] We are seeing "imprecise external abort (0x1406)" errors during boot (which then cause the whole board to hang) on Meson8 (but not Meson8m2). These are observed while trying to access the GPU's registers when the MALI clock is running at it's default setting of 24MHz. The 3.10 vendor kernel uses 318.75MHz as "default" GPU frequency. Using that makes the "imprecise external aborts" go away. Add the assigned-clocks and assigned-clock-rates properties to also bump the MALI clock to 318.75MHz before accessing any of it's registers. Fixes: 7d3f6b536e72c9 ("ARM: dts: meson8: add the Mali-450 MP6 GPU") Reported-by: Demetris Ierokipides Signed-off-by: Martin Blumenstingl Reviewed-by: Neil Armstrong Signed-off-by: Neil Armstrong Link: https://lore.kernel.org/r/20210711214023.2163565-1-martin.blumenstingl@googlemail.com Signed-off-by: Sasha Levin commit a7d0a59e21efef97d6499b2ce387711edb206cb0 Author: Martin KaFai Lau Date: Thu Jul 1 13:05:41 2021 -0700 tcp: seq_file: Avoid skipping sk during tcp_seek_last_pos [ Upstream commit 525e2f9fd0229eb10cb460a9e6d978257f24804e ] st->bucket stores the current bucket number. st->offset stores the offset within this bucket that is the sk to be seq_show(). Thus, st->offset only makes sense within the same st->bucket. These two variables are an optimization for the common no-lseek case. When resuming the seq_file iteration (i.e. seq_start()), tcp_seek_last_pos() tries to continue from the st->offset at bucket st->bucket. However, it is possible that the bucket pointed by st->bucket has changed and st->offset may end up skipping the whole st->bucket without finding a sk. In this case, tcp_seek_last_pos() currently continues to satisfy the offset condition in the next (and incorrect) bucket. Instead, regardless of the offset value, the first sk of the next bucket should be returned. Thus, "bucket == st->bucket" check is added to tcp_seek_last_pos(). The chance of hitting this is small and the issue is a decade old, so targeting for the next tree. Fixes: a8b690f98baf ("tcp: Fix slowness in read /proc/net/tcp") Signed-off-by: Martin KaFai Lau Signed-off-by: Andrii Nakryiko Reviewed-by: Eric Dumazet Acked-by: Kuniyuki Iwashima Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20210701200541.1033917-1-kafai@fb.com Signed-off-by: Sasha Levin commit 1f60072320b5f8071946e4b765cbf78a34d22a67 Author: Kai-Heng Feng Date: Wed Jul 21 01:22:15 2021 +0800 drm/amdgpu/acp: Make PM domain really work [ Upstream commit aff890288de2d818e4f83ec40c9315e2d735df07 ] Devices created by mfd_add_hotplug_devices() don't really increase the index of its name, so get_mfd_cell_dev() cannot find any device, hence a NULL dev is passed to pm_genpd_add_device(): [ 56.974926] (NULL device *): amdgpu: device acp_audio_dma.0.auto added to pm domain [ 56.974933] (NULL device *): amdgpu: Failed to add dev to genpd [ 56.974941] [drm:amdgpu_device_ip_init [amdgpu]] *ERROR* hw_init of IP block failed -22 [ 56.975810] amdgpu 0000:00:01.0: amdgpu: amdgpu_device_ip_init failed [ 56.975839] amdgpu 0000:00:01.0: amdgpu: Fatal error during GPU init [ 56.977136] ------------[ cut here ]------------ [ 56.977143] kernel BUG at mm/slub.c:4206! [ 56.977158] invalid opcode: 0000 [#1] SMP NOPTI [ 56.977167] CPU: 1 PID: 1648 Comm: modprobe Not tainted 5.12.0-051200rc8-generic #202104182230 [ 56.977175] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./FM2A68M-HD+, BIOS P5.20 02/13/2019 [ 56.977180] RIP: 0010:kfree+0x3bf/0x410 [ 56.977195] Code: 89 e7 48 d3 e2 f7 da e8 5f 0d 02 00 80 e7 02 75 3e 44 89 ee 4c 89 e7 e8 ef 5f fd ff e9 fa fe ff ff 49 8b 44 24 08 a8 01 75 b7 <0f> 0b 4c 8b 4d b0 48 8b 4d a8 48 89 da 4c 89 e6 41 b8 01 00 00 00 [ 56.977202] RSP: 0018:ffffa48640ff79f0 EFLAGS: 00010246 [ 56.977210] RAX: 0000000000000000 RBX: ffff9286127d5608 RCX: 0000000000000000 [ 56.977215] RDX: 0000000000000000 RSI: ffffffffc099d0fb RDI: ffff9286127d5608 [ 56.977220] RBP: ffffa48640ff7a48 R08: 0000000000000001 R09: 0000000000000001 [ 56.977224] R10: 0000000000000000 R11: ffff9286087d8458 R12: fffff3ae0449f540 [ 56.977229] R13: 0000000000000000 R14: dead000000000122 R15: dead000000000100 [ 56.977234] FS: 00007f9de5929540(0000) GS:ffff928612e80000(0000) knlGS:0000000000000000 [ 56.977240] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 56.977245] CR2: 00007f697dd97160 CR3: 00000001110f0000 CR4: 00000000001506e0 [ 56.977251] Call Trace: [ 56.977261] amdgpu_dm_encoder_destroy+0x1b/0x30 [amdgpu] [ 56.978056] drm_mode_config_cleanup+0x4f/0x2e0 [drm] [ 56.978147] ? kfree+0x3dd/0x410 [ 56.978157] ? drm_managed_release+0xc8/0x100 [drm] [ 56.978232] drm_mode_config_init_release+0xe/0x10 [drm] [ 56.978311] drm_managed_release+0x9d/0x100 [drm] [ 56.978388] devm_drm_dev_init_release+0x4d/0x70 [drm] [ 56.978450] devm_action_release+0x15/0x20 [ 56.978459] release_nodes+0x77/0xc0 [ 56.978469] devres_release_all+0x3f/0x50 [ 56.978477] really_probe+0x245/0x460 [ 56.978485] driver_probe_device+0xe9/0x160 [ 56.978492] device_driver_attach+0xab/0xb0 [ 56.978499] __driver_attach+0x8f/0x150 [ 56.978506] ? device_driver_attach+0xb0/0xb0 [ 56.978513] bus_for_each_dev+0x7e/0xc0 [ 56.978521] driver_attach+0x1e/0x20 [ 56.978528] bus_add_driver+0x135/0x1f0 [ 56.978534] driver_register+0x91/0xf0 [ 56.978540] __pci_register_driver+0x54/0x60 [ 56.978549] amdgpu_init+0x77/0x1000 [amdgpu] [ 56.979246] ? 0xffffffffc0dbc000 [ 56.979254] do_one_initcall+0x48/0x1d0 [ 56.979265] ? kmem_cache_alloc_trace+0x120/0x230 [ 56.979274] ? do_init_module+0x28/0x280 [ 56.979282] do_init_module+0x62/0x280 [ 56.979288] load_module+0x71c/0x7a0 [ 56.979296] __do_sys_finit_module+0xc2/0x120 [ 56.979305] __x64_sys_finit_module+0x1a/0x20 [ 56.979311] do_syscall_64+0x38/0x90 [ 56.979319] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 56.979328] RIP: 0033:0x7f9de54f989d [ 56.979335] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d c3 f5 0c 00 f7 d8 64 89 01 48 [ 56.979342] RSP: 002b:00007ffe3c395a28 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 [ 56.979350] RAX: ffffffffffffffda RBX: 0000560df3ef4330 RCX: 00007f9de54f989d [ 56.979355] RDX: 0000000000000000 RSI: 0000560df3a07358 RDI: 000000000000000f [ 56.979360] RBP: 0000000000040000 R08: 0000000000000000 R09: 0000000000000000 [ 56.979365] R10: 000000000000000f R11: 0000000000000246 R12: 0000560df3a07358 [ 56.979369] R13: 0000000000000000 R14: 0000560df3ef4460 R15: 0000560df3ef4330 [ 56.979377] Modules linked in: amdgpu(+) iommu_v2 gpu_sched drm_ttm_helper ttm drm_kms_helper cec rc_core i2c_algo_bit fb_sys_fops syscopyarea sysfillrect sysimgblt nft_counter xt_tcpudp ipt_REJECT nf_reject_ipv4 xt_conntrack iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 iptable_mangle iptable_raw iptable_security ip_set nf_tables libcrc32c nfnetlink ip6_tables iptable_filter bpfilter input_leds binfmt_misc edac_mce_amd kvm_amd ccp kvm snd_hda_codec_realtek snd_hda_codec_generic crct10dif_pclmul snd_hda_codec_hdmi ledtrig_audio ghash_clmulni_intel aesni_intel snd_hda_intel snd_intel_dspcfg snd_seq_midi crypto_simd snd_intel_sdw_acpi cryptd snd_hda_codec snd_seq_midi_event snd_rawmidi snd_hda_core snd_hwdep snd_seq fam15h_power k10temp snd_pcm snd_seq_device snd_timer snd mac_hid soundcore sch_fq_codel nct6775 hwmon_vid drm ip_tables x_tables autofs4 dm_mirror dm_region_hash dm_log hid_generic usbhid hid uas usb_storage r8169 crc32_pclmul realtek ahci xhci_pci i2c_piix4 [ 56.979521] xhci_pci_renesas libahci video [ 56.979541] ---[ end trace cb8f6a346f18da7b ]--- Instead of finding MFD hotplugged device by its name, simply iterate over the child devices to avoid the issue. Squash in unused variable removal (Alex) BugLink: https://bugs.launchpad.net/bugs/1920674 Fixes: 25030321ba28 ("drm/amd: add pm domain for ACP IP sub blocks") Signed-off-by: Kai-Heng Feng Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit c7ebd3622bf843108809c147270e838ec85dfd90 Author: Colin Ian King Date: Mon Jul 12 13:14:40 2021 +0100 6lowpan: iphc: Fix an off-by-one check of array index [ Upstream commit 9af417610b6142e826fd1ee8ba7ff3e9a2133a5a ] The bounds check of id is off-by-one and the comparison should be >= rather >. Currently the WARN_ON_ONCE check does not stop the out of range indexing of &ldev->ctx.table[id] so also add a return path if the bounds are out of range. Addresses-Coverity: ("Illegal address computation"). Fixes: 5609c185f24d ("6lowpan: iphc: add support for stateful compression") Signed-off-by: Colin Ian King Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit def6efdf91e72c04d5b12158a6a9cfc46bba8573 Author: Dan Carpenter Date: Fri Jun 25 18:00:09 2021 +0300 Bluetooth: sco: prevent information leak in sco_conn_defer_accept() [ Upstream commit 59da0b38bc2ea570ede23a3332ecb3e7574ce6b2 ] Smatch complains that some of these struct members are not initialized leading to a stack information disclosure: net/bluetooth/sco.c:778 sco_conn_defer_accept() warn: check that 'cp.retrans_effort' doesn't leak information This seems like a valid warning. I've added a default case to fix this issue. Fixes: 2f69a82acf6f ("Bluetooth: Use voice setting in deferred SCO connection request") Signed-off-by: Dan Carpenter Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit e9a62740876b286cae4ceb0de4d1d1a04b1e6b0c Author: Yizhuo Date: Fri Jun 25 07:38:56 2021 +0200 media: atomisp: fix the uninitialized use and rename "retvalue" [ Upstream commit c275e5d349b0d2b1143607d28b9c7c14a8a0a9b4 ] Inside function mt9m114_detect(), variable "retvalue" could be uninitialized if mt9m114_read_reg() returns error, however, it is used in the later if statement, which is potentially unsafe. The local variable "retvalue" is renamed to "model" to avoid confusion. Link: https://lore.kernel.org/linux-media/20210625053858.3862-1-yzhai003@ucr.edu Fixes: ad85094 (media / atomisp: fix the uninitialized use of model ID) Signed-off-by: Yizhuo Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit b0e87701b81340af19a265308dd3f990fb4afed3 Author: Philipp Zabel Date: Mon Jul 19 16:57:08 2021 +0200 media: coda: fix frame_mem_ctrl for YUV420 and YVU420 formats [ Upstream commit 44693d74f5653f82cd7ca0fe730eed0f6b83306a ] The frame memory control register value is currently determined before userspace selects the final capture format and never corrected. Update ctx->frame_mem_ctrl in __coda_start_decoding() to fix decoding into YUV420 or YVU420 capture buffers. Reported-by: Andrej Picej Fixes: 497e6b8559a6 ("media: coda: add sequence initialization work") Signed-off-by: Philipp Zabel Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit c062253748d8f56fbab6ca8e037502ed692df063 Author: Dan Carpenter Date: Tue Jul 13 11:24:10 2021 +0200 media: rockchip/rga: fix error handling in probe [ Upstream commit e58430e1d4fd01b74475d2fbe2e25b5817b729a9 ] There are a few bugs in this code. 1) No checks for whether dma_alloc_attrs() or __get_free_pages() failed. 2) If video_register_device() fails it doesn't clean up the dma attrs or the free pages. 3) The video_device_release() function frees "vfd" which leads to a use after free on the next line. The call to video_unregister_device() is not required so I have just removed that. Fixes: f7e7b48e6d79 ("[media] rockchip/rga: v4l2 m2m support") Reported-by: Dongliang Mu Signed-off-by: Dan Carpenter Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit dc49537334a73c34853eb2eb722aca886e89973f Author: Mauro Carvalho Chehab Date: Fri Apr 23 17:19:20 2021 +0200 media: rockchip/rga: use pm_runtime_resume_and_get() [ Upstream commit 0314339a0a49f4a128b61e5e1a0af1df6e64a186 ] Commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter") added pm_runtime_resume_and_get() in order to automatically handle dev->power.usage_count decrement on errors. Use the new API, in order to cleanup the error check logic. Reviewed-by: Ezequiel Garcia Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 94d6aa2b871fdc66d568dd154da95e2a7f892d3a Author: Pavel Skripkin Date: Sun Jun 20 21:45:42 2021 +0200 media: go7007: remove redundant initialization [ Upstream commit 6f5885a7750545973bf1a942d2f0f129aef0aa06 ] In go7007_alloc() kzalloc() is used for struct go7007 allocation. It means that there is no need in zeroing any members, because kzalloc will take care of it. Removing these reduntant initialization steps increases execution speed a lot: Before: + 86.802 us | go7007_alloc(); After: + 29.595 us | go7007_alloc(); Fixes: 866b8695d67e8 ("Staging: add the go7007 video driver") Signed-off-by: Pavel Skripkin Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit ffd9c8cecbadd0619d9617c36e656da8aa5d6ad4 Author: Pavel Skripkin Date: Sun Jun 20 21:45:02 2021 +0200 media: go7007: fix memory leak in go7007_usb_probe [ Upstream commit 47d94dad8e64b2fc1d8f66ce7acf714f9462c60f ] In commit 137641287eb4 ("go7007: add sanity checking for endpoints") endpoint sanity check was introduced, but if check fails it simply returns with leaked pointers. Cutted log from my local syzbot instance: BUG: memory leak unreferenced object 0xffff8880209f0000 (size 8192): comm "kworker/0:4", pid 4916, jiffies 4295263583 (age 29.310s) hex dump (first 32 bytes): 30 b0 27 22 80 88 ff ff 75 73 62 2d 64 75 6d 6d 0.'"....usb-dumm 79 5f 68 63 64 2e 33 2d 31 00 00 00 00 00 00 00 y_hcd.3-1....... backtrace: [] kmalloc include/linux/slab.h:556 [inline] [] kzalloc include/linux/slab.h:686 [inline] [] go7007_alloc+0x46/0xb40 drivers/media/usb/go7007/go7007-driver.c:696 [] go7007_usb_probe+0x13e/0x2200 drivers/media/usb/go7007/go7007-usb.c:1114 [] usb_probe_interface+0x314/0x7f0 drivers/usb/core/driver.c:396 [] really_probe+0x291/0xf60 drivers/base/dd.c:576 BUG: memory leak unreferenced object 0xffff88801e2f2800 (size 512): comm "kworker/0:4", pid 4916, jiffies 4295263583 (age 29.310s) hex dump (first 32 bytes): 00 87 40 8a ff ff ff ff 00 00 00 00 00 00 00 00 ..@............. 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [] kmalloc include/linux/slab.h:556 [inline] [] kzalloc include/linux/slab.h:686 [inline] [] go7007_usb_probe+0x184/0x2200 drivers/media/usb/go7007/go7007-usb.c:1118 [] usb_probe_interface+0x314/0x7f0 drivers/usb/core/driver.c:396 [] really_probe+0x291/0xf60 drivers/base/dd.c:576 Fixes: 137641287eb4 ("go7007: add sanity checking for endpoints") Signed-off-by: Pavel Skripkin Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit fb22665c37b340ed02d71fbcce0b204a6ad348b6 Author: Dongliang Mu Date: Mon Jun 21 07:07:28 2021 +0200 media: dvb-usb: Fix error handling in dvb_usb_i2c_init [ Upstream commit 131ae388b88e3daf4cb0721ed4b4cb8bfc201465 ] In dvb_usb_i2c_init, if i2c_add_adapter fails, it only prints an error message, and then continues to set DVB_USB_STATE_I2C. This affects the logic of dvb_usb_i2c_exit, which leads to that, the deletion of i2c_adap even if the i2c_add_adapter fails. Fix this by returning at the failure of i2c_add_adapter and then move dvb_usb_i2c_exit out of the error handling code of dvb_usb_i2c_init. Fixes: 13a79f14ab28 ("media: dvb-usb: Fix memory leak at error in dvb_usb_device_init()") Signed-off-by: Dongliang Mu Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 6b0fe695343098a2f22bd82d511570d13fe3bb78 Author: Dongliang Mu Date: Fri Jun 25 07:59:04 2021 +0200 media: dvb-usb: fix uninit-value in vp702x_read_mac_addr [ Upstream commit 797c061ad715a9a1480eb73f44b6939fbe3209ed ] If vp702x_usb_in_op fails, the mac address is not initialized. And vp702x_read_mac_addr does not handle this failure, which leads to the uninit-value in dvb_usb_adapter_dvb_init. Fix this by handling the failure of vp702x_usb_in_op. Fixes: 786baecfe78f ("[media] dvb-usb: move it to drivers/media/usb/dvb-usb") Signed-off-by: Dongliang Mu Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 372890e0b41e14d861b003692aa68ad4bca5d274 Author: Dongliang Mu Date: Fri Jun 25 07:33:27 2021 +0200 media: dvb-usb: fix uninit-value in dvb_usb_adapter_dvb_init [ Upstream commit c5453769f77ce19a5b03f1f49946fd3f8a374009 ] If dibusb_read_eeprom_byte fails, the mac address is not initialized. And nova_t_read_mac_address does not handle this failure, which leads to the uninit-value in dvb_usb_adapter_dvb_init. Fix this by handling the failure of dibusb_read_eeprom_byte. Reported-by: syzbot+e27b4fd589762b0b9329@syzkaller.appspotmail.com Fixes: 786baecfe78f ("[media] dvb-usb: move it to drivers/media/usb/dvb-usb") Signed-off-by: Dongliang Mu Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 83f7297a4af45a4dbfa14b02f8215b686d60d167 Author: Leon Romanovsky Date: Wed Jul 21 15:39:44 2021 +0300 ionic: cleanly release devlink instance [ Upstream commit c2255ff47768c94a0ebc3968f007928bb47ea43b ] The failure to register devlink will leave the system with dangled devlink resource, which is not cleaned if devlink_port_register() fails. In order to remove access to ".registered" field of struct devlink_port, require both devlink_register and devlink_port_register to success and check it through device pointer. Fixes: fbfb8031533c ("ionic: Add hardware init and device commands") Reviewed-by: Moshe Shemesh Signed-off-by: Leon Romanovsky Acked-by: Shannon Nelson Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 203537ff35eac98544fb35751826e66ea6cb7da6 Author: Zhen Lei Date: Wed Jul 7 15:43:01 2021 +0800 driver core: Fix error return code in really_probe() [ Upstream commit f04948dea236b000da09c466a7ec931ecd8d7867 ] In the case of error handling, the error code returned by the subfunction should be propagated instead of 0. Fixes: 1901fb2604fb ("Driver core: fix "driver" symlink timing") Fixes: 23b6904442d0 ("driver core: add dev_groups to all drivers") Fixes: 8fd456ec0cf0 ("driver core: Add state_synced sysfs file for devices that support it") Reported-by: Hulk Robot Signed-off-by: Zhen Lei Link: https://lore.kernel.org/r/20210707074301.2722-1-thunder.leizhen@huawei.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 4225d357bc759c4694db01af06e0f85ed374594b Author: Zhen Lei Date: Mon Jul 19 14:45:31 2021 +0800 firmware: fix theoretical UAF race with firmware cache and resume [ Upstream commit 3ecc8cb7c092b2f50e21d2aaaae35b8221ee7214 ] This race was discovered when I carefully analyzed the code to locate another firmware-related UAF issue. It can be triggered only when the firmware load operation is executed during suspend. This possibility is almost impossible because there are few firmware load and suspend actions in the actual environment. CPU0 CPU1 __device_uncache_fw_images(): assign_fw(): fw_cache_piggyback_on_request() <----- P0 spin_lock(&fwc->name_lock); ... list_del(&fce->list); spin_unlock(&fwc->name_lock); uncache_firmware(fce->name); <----- P1 kref_get(&fw_priv->ref); If CPU1 is interrupted at position P0, the new 'fce' has been added to the list fwc->fw_names by the fw_cache_piggyback_on_request(). In this case, CPU0 executes __device_uncache_fw_images() and will be able to see it when it traverses list fwc->fw_names. Before CPU1 executes kref_get() at P1, if CPU0 further executes uncache_firmware(), the count of fw_priv->ref may decrease to 0, causing fw_priv to be released in advance. Move kref_get() to the lock protection range of fwc->name_lock to fix it. Fixes: ac39b3ea73aa ("firmware loader: let caching firmware piggyback on loading firmware") Acked-by: Luis Chamberlain Signed-off-by: Zhen Lei Link: https://lore.kernel.org/r/20210719064531.3733-2-thunder.leizhen@huawei.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit c4aaad8a338958016d4a0633564ec1c15341efea Author: Colin Ian King Date: Mon Jul 12 17:24:30 2021 +0100 gfs2: Fix memory leak of object lsi on error return path [ Upstream commit a6579cbfd7216b071008db13360c322a6b21400b ] In the case where IS_ERR(lsi->si_sc_inode) is true the error exit path to free_local does not kfree the allocated object lsi leading to a memory leak. Fix this by kfree'ing lst before taking the error exit path. Addresses-Coverity: ("Resource leak") Fixes: 97fd734ba17e ("gfs2: lookup local statfs inodes prior to journal recovery") Signed-off-by: Colin Ian King Signed-off-by: Andreas Gruenbacher Signed-off-by: Sasha Levin commit 8c3b5028ec02924f3b037a6d07124a006a9a3c4f Author: Martynas Pumputis Date: Mon Jul 19 19:38:37 2021 +0200 libbpf: Fix removal of inner map in bpf_object__create_map [ Upstream commit a21ab4c59e09c2a9994a6e393b7484e3b3f78a99 ] If creating an outer map of a BTF-defined map-in-map fails (via bpf_object__create_map()), then the previously created its inner map won't be destroyed. Fix this by ensuring that the destroy routines are not bypassed in the case of a failure. Fixes: 646f02ffdd49c ("libbpf: Add BTF-defined map-in-map support") Reported-by: Andrii Nakryiko Signed-off-by: Martynas Pumputis Signed-off-by: Andrii Nakryiko Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20210719173838.423148-2-m@lambda.lt Signed-off-by: Sasha Levin commit ffb887c15f7ff2b0cfb7fb2e7e288b4a3bf4f604 Author: Bjorn Andersson Date: Fri Jul 2 17:54:15 2021 -0700 soc: qcom: rpmhpd: Use corner in power_off [ Upstream commit d43b3a989bc8c06fd4bbb69a7500d180db2d68e8 ] rpmhpd_aggregate_corner() takes a corner as parameter, but in rpmhpd_power_off() the code requests the level of the first corner instead. In all (known) current cases the first corner has level 0, so this change should be a nop, but in case that there's a power domain with a non-zero lowest level this makes sure that rpmhpd_power_off() actually requests the lowest level - which is the closest to "power off" we can get. While touching the code, also skip the unnecessary zero-initialization of "ret". Fixes: 279b7e8a62cc ("soc: qcom: rpmhpd: Add RPMh power domain driver") Reviewed-by: Rajendra Nayak Reviewed-by: Stephen Boyd Reviewed-by: Sibi Sankar Tested-by: Sibi Sankar Link: https://lore.kernel.org/r/20210703005416.2668319-2-bjorn.andersson@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit f32b433d8e25f7f25175726590ea4a3cf6814cc4 Author: Stefan Assmann Date: Thu Mar 4 10:34:30 2021 +0100 i40e: improve locking of mac_filter_hash [ Upstream commit 8b4b06919fd66caf49fdf4fe59f9d6312cf7956d ] i40e_config_vf_promiscuous_mode() calls i40e_getnum_vf_vsi_vlan_filters() without acquiring the mac_filter_hash_lock spinlock. This is unsafe because mac_filter_hash may get altered in another thread while i40e_getnum_vf_vsi_vlan_filters() traverses the hashes. Simply adding the spinlock in i40e_getnum_vf_vsi_vlan_filters() is not possible as it already gets called in i40e_get_vlan_list_sync() with the spinlock held. Therefore adding a wrapper that acquires the spinlock and call the correct function where appropriate. Fixes: 37d318d7805f ("i40e: Remove scheduling while atomic possibility") Fix-suggested-by: Paolo Abeni Signed-off-by: Stefan Assmann Tested-by: Konrad Jankowski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 5ac21a4e6e85959766cdad2e3d2e7a75284d4e93 Author: Geert Uytterhoeven Date: Thu Jul 1 12:15:50 2021 +0200 arm64: dts: renesas: r8a77995: draak: Remove bogus adv7511w properties [ Upstream commit 4ec82a7bb3db8c6005e715c63224c32d458917a2 ] The "max-clock" and "min-vrefresh" properties fail to validate with commit cfe34bb7a770c5d8 ("dt-bindings: drm: bridge: adi,adv7511.txt: convert to yaml"). Drop them, as they are parts of an out-of-tree workaround that is not needed upstream. Fixes: bcf3003438ea4645 ("arm64: dts: renesas: r8a77995: draak: Enable HDMI display output") Signed-off-by: Geert Uytterhoeven Acked-by: Laurent Pinchart Reviewed-by: Ulrich Hecht Link: https://lore.kernel.org/r/975b6686bc423421b147d367fe7fb9a0db99c5af.1625134398.git.geert+renesas@glider.be Signed-off-by: Sasha Levin commit a8c1eaed23741f246a2356d718de2f0d4cca7972 Author: Dylan Hung Date: Thu Oct 29 14:27:23 2020 +0800 ARM: dts: aspeed-g6: Fix HVI3C function-group in pinctrl dtsi [ Upstream commit 8c295b7f3d01359ff4336fcb6e406e6ed37957d6 ] The HVI3C shall be a group of I3C function, not an independent function. Correct the function name from "HVI3C" to "I3C". Signed-off-by: Dylan Hung Reviewed-by: Andrew Jeffery Fixes: f510f04c8c83 ("ARM: dts: aspeed: Add AST2600 pinmux nodes") Link: https://lore.kernel.org/r/20201029062723.20798-1-dylan_hung@aspeedtech.com Signed-off-by: Joel Stanley Signed-off-by: Sasha Levin commit 6ca0b4089166c6e03b95e48866931d23f4ff542f Author: Shuyi Cheng Date: Tue Jul 13 20:42:38 2021 +0800 libbpf: Fix the possible memory leak on error [ Upstream commit 18353c87e0e0440d4c7c746ed740738bbc1b538e ] If the strdup() fails then we need to call bpf_object__close(obj) to avoid a resource leak. Fixes: 166750bc1dd2 ("libbpf: Support libbpf-provided extern variables") Signed-off-by: Shuyi Cheng Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/1626180159-112996-3-git-send-email-chengshuyi@linux.alibaba.com Signed-off-by: Sasha Levin commit f1673e85254d3dae8f595c0367cd33c73530952e Author: Haiyue Wang Date: Wed Jul 14 15:34:59 2021 +0800 gve: fix the wrong AdminQ buffer overflow check [ Upstream commit 63a9192b8fa1ea55efeba1f18fad52bb24d9bf12 ] The 'tail' pointer is also free-running count, so it needs to be masked as 'adminq_prod_cnt' does, to become an index value of AdminQ buffer. Fixes: 5cdad90de62c ("gve: Batch AQ commands for creating and destroying queues.") Signed-off-by: Haiyue Wang Reviewed-by: Catherine Sullivan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 1568dbe8892d10814940564542371b4ec65110e5 Author: Steven Price Date: Wed Jul 14 15:33:00 2021 +0100 drm/of: free the iterator object on failure [ Upstream commit 6f9223a56fabc840836b49de27dc7b27642c6a32 ] When bailing out due to the sanity check the iterator value needs to be freed because the early return prevents for_each_child_of_node() from doing the dereference itself. Fixes: 6529007522de ("drm: of: Add drm_of_lvds_get_dual_link_pixel_order") Signed-off-by: Steven Price Reviewed-by: Laurent Pinchart Link: https://patchwork.freedesktop.org/patch/msgid/20210714143300.20632-1-steven.price@arm.com Signed-off-by: Sasha Levin commit 389dfd11478030e03b69fcbd8bd59e18a840ce64 Author: He Fengqing Date: Wed Jul 14 10:18:15 2021 +0000 bpf: Fix potential memleak and UAF in the verifier. [ Upstream commit 75f0fc7b48ad45a2e5736bcf8de26c8872fe8695 ] In bpf_patch_insn_data(), we first use the bpf_patch_insn_single() to insert new instructions, then use adjust_insn_aux_data() to adjust insn_aux_data. If the old env->prog have no enough room for new inserted instructions, we use bpf_prog_realloc to construct new_prog and free the old env->prog. There have two errors here. First, if adjust_insn_aux_data() return ENOMEM, we should free the new_prog. Second, if adjust_insn_aux_data() return ENOMEM, bpf_patch_insn_data() will return NULL, and env->prog has been freed in bpf_prog_realloc, but we will use it in bpf_check(). So in this patch, we make the adjust_insn_aux_data() never fails. In bpf_patch_insn_data(), we first pre-malloc memory for the new insn_aux_data, then call bpf_patch_insn_single() to insert new instructions, at last call adjust_insn_aux_data() to adjust insn_aux_data. Fixes: 8041902dae52 ("bpf: adjust insn_aux_data when patching insns") Signed-off-by: He Fengqing Signed-off-by: Alexei Starovoitov Acked-by: Song Liu Link: https://lore.kernel.org/bpf/20210714101815.164322-1-hefengqing@huawei.com Signed-off-by: Sasha Levin commit d4213b70931640a327b4693bc3f9b5784f86b6dd Author: Kuniyuki Iwashima Date: Wed Jul 14 21:43:17 2021 +0900 bpf: Fix a typo of reuseport map in bpf.h. [ Upstream commit f170acda7ffaf0473d06e1e17c12cd9fd63904f5 ] Fix s/BPF_MAP_TYPE_REUSEPORT_ARRAY/BPF_MAP_TYPE_REUSEPORT_SOCKARRAY/ typo in bpf.h. Fixes: 2dbb9b9e6df6 ("bpf: Introduce BPF_PROG_TYPE_SK_REUSEPORT") Signed-off-by: Kuniyuki Iwashima Signed-off-by: Alexei Starovoitov Acked-by: Martin KaFai Lau Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20210714124317.67526-1-kuniyu@amazon.co.jp Signed-off-by: Sasha Levin commit 56e5c527cc2edffe7afd9fa6a6d8bc285c1c599b Author: Julia Lawall Date: Fri Jul 9 22:07:17 2021 +0200 drm/of: free the right object [ Upstream commit b557a5f8da5798d27370ed6b73e673aae33efd55 ] There is no need to free a NULL value. Instead, free the object that is leaking due to the iterator. The semantic patch that finds this problem is as follows: // @@ expression x,e; identifier f; @@ x = f(...); if (x == NULL) { ... when any when != x = e * of_node_put(x); ... } // Fixes: 6529007522de ("drm: of: Add drm_of_lvds_get_dual_link_pixel_order") Signed-off-by: Julia Lawall Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20210709200717.3676376-1-Julia.Lawall@inria.fr Signed-off-by: Sasha Levin commit 38235f195de92b172224eedca0e2ac8bdf2c8c6d Author: Christophe JAILLET Date: Thu Jun 10 21:54:31 2021 +0200 media: cxd2880-spi: Fix an error handling path [ Upstream commit dcb0145821017e929a733e2271c85c6f82b9c9f8 ] If an error occurs after a successful 'regulator_enable()' call, 'regulator_disable()' must be called. Fix the error handling path of the probe accordingly. Fixes: cb496cd472af ("media: cxd2880-spi: Add optional vcc regulator") Signed-off-by: Christophe JAILLET Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 25fbfc31ceec99cec4e3284d911d6c975d8561e7 Author: Geert Uytterhoeven Date: Mon Feb 8 15:38:55 2021 +0100 soc: rockchip: ROCKCHIP_GRF should not default to y, unconditionally [ Upstream commit 2a1c55d4762dd34a8b0f2e36fb01b7b16b60735b ] Merely enabling CONFIG_COMPILE_TEST should not enable additional code. To fix this, restrict the automatic enabling of ROCKCHIP_GRF to ARCH_ROCKCHIP, and ask the user in case of compile-testing. Fixes: 4c58063d4258f6be ("soc: rockchip: add driver handling grf setup") Signed-off-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/20210208143855.418374-1-geert+renesas@glider.be Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit c391728c9b25e51a352a65562ae78dde3b11b6e0 Author: Jiapeng Chong Date: Tue Jun 1 19:09:03 2021 +0800 leds: is31fl32xx: Fix missing error code in is31fl32xx_parse_dt() [ Upstream commit e642197562cd9781453f835e1406cfe0feeb917e ] The error code is missing in this code scenario, add the error code '-EINVAL' to the return value 'ret'. Eliminate the follow smatch warning: drivers/leds/leds-is31fl32xx.c:388 is31fl32xx_parse_dt() warn: missing error code 'ret'. Reported-by: Abaci Robot Signed-off-by: Jiapeng Chong Fixes: 9d7cffaf99f5 ("leds: Add driver for the ISSI IS31FL32xx family of LED controllers") Acked-by: David Rivshin Signed-off-by: Pavel Machek Signed-off-by: Sasha Levin commit d4abb6e141051445cd469a0bc9bb40b7cd37904f Author: Krzysztof Hałasa Date: Wed Jun 16 07:13:55 2021 +0200 media: TDA1997x: enable EDID support [ Upstream commit ea3e1c36e38810427485f06c2becc1f29e54521d ] Without this patch, the TDA19971 chip's EDID is inactive. EDID never worked with this driver, it was all tested with HDMI signal sources which don't need EDID support. Signed-off-by: Krzysztof Halasa Fixes: 9ac0038db9a7 ("media: i2c: Add TDA1997x HDMI receiver driver") Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 8ce22f85381f7bc16dd6be7e85143a25d1b30687 Author: Zhang Qilong Date: Fri Jun 18 22:11:04 2021 +0800 ASoC: mediatek: mt8183: Fix Unbalanced pm_runtime_enable in mt8183_afe_pcm_dev_probe [ Upstream commit 19f479c37f76e926a6c0bec974a4d09826e32fc6 ] Add missing pm_runtime_disable() when probe error out. It could avoid pm_runtime implementation complains when removing and probing again the driver. Fixes:a94aec035a122 ("ASoC: mediatek: mt8183: add platform driver") Signed-off-by: Zhang Qilong Link: https://lore.kernel.org/r/20210618141104.105047-3-zhangqilong3@huawei.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 3d58f5e83f97f2e732c3a00949a935e601d42529 Author: Harshvardhan Jha Date: Fri Jul 9 13:09:59 2021 +0530 drm/gma500: Fix end of loop tests for list_for_each_entry [ Upstream commit ea9a897b8affa0f7b4c90182b785dded74e434aa ] The list_for_each_entry() iterator, "connector" in this code, can never be NULL. If we exit the loop without finding the correct connector then "connector" points invalid memory that is an offset from the list head. This will eventually lead to memory corruption and presumably a kernel crash. Fixes: 9bd81acdb648 ("gma500: Convert Oaktrail to work with new output handling") Signed-off-by: Harshvardhan Jha Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20210709073959.11443-1-harshvardhan.jha@oracle.com Signed-off-by: Sasha Levin commit 54912723f16ba0cdd7db57bb0d10f33bfff636f4 Author: Wei Yongjun Date: Tue Jun 8 14:38:56 2021 +0000 drm/panfrost: Fix missing clk_disable_unprepare() on error in panfrost_clk_init() [ Upstream commit f42498705965bd4b026953c1892c686d8b1138e4 ] Fix the missing clk_disable_unprepare() before return from panfrost_clk_init() in the error handling case. Fixes: b681af0bc1cc ("drm: panfrost: add optional bus_clock") Reported-by: Hulk Robot Signed-off-by: Wei Yongjun Reviewed-by: Steven Price Signed-off-by: Steven Price Link: https://patchwork.freedesktop.org/patch/msgid/20210608143856.4154766-1-weiyongjun1@huawei.com Signed-off-by: Sasha Levin commit 1e1423449d1cf0d622a153ec3c6df6ebfc50672f Author: Qiuxu Zhuo Date: Wed Aug 18 10:57:00 2021 -0700 EDAC/i10nm: Fix NVDIMM detection [ Upstream commit 2294a7299f5e51667b841f63c6d69474491753fb ] MCDDRCFG is a per-channel register and uses bit{0,1} to indicate the NVDIMM presence on DIMM slot{0,1}. Current i10nm_edac driver wrongly uses MCDDRCFG as per-DIMM register and fails to detect the NVDIMM. Fix it by reading MCDDRCFG as per-channel register and using its bit{0,1} to check whether the NVDIMM is populated on DIMM slot{0,1}. Fixes: d4dc89d069aa ("EDAC, i10nm: Add a driver for Intel 10nm server processors") Reported-by: Fan Du Tested-by: Wen Jin Signed-off-by: Qiuxu Zhuo Signed-off-by: Tony Luck Link: https://lore.kernel.org/r/20210818175701.1611513-2-tony.luck@intel.com Signed-off-by: Sasha Levin commit a20e6868cbfc7c8c06af777132e3da66fc61921e Author: Quanyang Wang Date: Thu Aug 26 08:59:30 2021 +0800 spi: spi-zynq-qspi: use wait_for_completion_timeout to make zynq_qspi_exec_mem_op not interruptible [ Upstream commit 26cfc0dbe43aae60dc03af27077775244f26c167 ] The function wait_for_completion_interruptible_timeout will return -ERESTARTSYS immediately when receiving SIGKILL signal which is sent by "jffs2_gcd_mtd" during umounting jffs2. This will break the SPI memory operation because the data transmitting may begin before the command or address transmitting completes. Use wait_for_completion_timeout to prevent the process from being interruptible. Fixes: 67dca5e580f1 ("spi: spi-mem: Add support for Zynq QSPI controller") Signed-off-by: Quanyang Wang Link: https://lore.kernel.org/r/20210826005930.20572-1-quanyang.wang@windriver.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit e2cb04c61bcf1856193378ecafcef95ead1c1b93 Author: Chunyan Zhang Date: Thu Aug 26 17:15:46 2021 +0800 spi: sprd: Fix the wrong WDG_LOAD_VAL [ Upstream commit 245ca2cc212bb2a078332ec99afbfbb202f44c2d ] Use 50ms as default timeout value and the time clock is 32768HZ. The original value of WDG_LOAD_VAL is not correct, so this patch fixes it. Fixes: ac1775012058 ("spi: sprd: Add the support of restarting the system") Signed-off-by: Chunyan Zhang Link: https://lore.kernel.org/r/20210826091549.2138125-2-zhang.lyra@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit cd8cca7268a24715d640e68cd19a3645f801c5bd Author: Chen-Yu Tsai Date: Wed Aug 25 11:37:04 2021 +0800 regulator: vctrl: Avoid lockdep warning in enable/disable ops [ Upstream commit 21e39809fd7c4b8ff3662f23e0168e87594c8ca8 ] vctrl_enable() and vctrl_disable() call regulator_enable() and regulator_disable(), respectively. However, vctrl_* are regulator ops and should not be calling the locked regulator APIs. Doing so results in a lockdep warning. Instead of exporting more internal regulator ops, model the ctrl supply as an actual supply to vctrl-regulator. At probe time this driver still needs to use the consumer API to fetch its constraints, but otherwise lets the regulator core handle the upstream supply for it. The enable/disable/is_enabled ops are not removed, but now only track state internally. This preserves the original behavior with the ops being available, but one could argue that the original behavior was already incorrect: the internal state would not match the upstream supply if that supply had another consumer that enabled the supply, while vctrl-regulator was not enabled. The lockdep warning is as follows: WARNING: possible circular locking dependency detected 5.14.0-rc6 #2 Not tainted ------------------------------------------------------ swapper/0/1 is trying to acquire lock: ffffffc011306d00 (regulator_list_mutex){+.+.}-{3:3}, at: regulator_lock_dependent (arch/arm64/include/asm/current.h:19 include/linux/ww_mutex.h:111 drivers/regulator/core.c:329) but task is already holding lock: ffffff8004a77160 (regulator_ww_class_mutex){+.+.}-{3:3}, at: regulator_lock_recursive (drivers/regulator/core.c:156 drivers/regulator/core.c:263) which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (regulator_ww_class_mutex){+.+.}-{3:3}: __mutex_lock_common (include/asm-generic/atomic-instrumented.h:606 include/asm-generic/atomic-long.h:29 kernel/locking/mutex.c:103 kernel/locking/mutex.c:144 kernel/locking/mutex.c:963) ww_mutex_lock (kernel/locking/mutex.c:1199) regulator_lock_recursive (drivers/regulator/core.c:156 drivers/regulator/core.c:263) regulator_lock_dependent (drivers/regulator/core.c:343) regulator_enable (drivers/regulator/core.c:2808) set_machine_constraints (drivers/regulator/core.c:1536) regulator_register (drivers/regulator/core.c:5486) devm_regulator_register (drivers/regulator/devres.c:196) reg_fixed_voltage_probe (drivers/regulator/fixed.c:289) platform_probe (drivers/base/platform.c:1427) [...] -> #1 (regulator_ww_class_acquire){+.+.}-{0:0}: regulator_lock_dependent (include/linux/ww_mutex.h:129 drivers/regulator/core.c:329) regulator_enable (drivers/regulator/core.c:2808) set_machine_constraints (drivers/regulator/core.c:1536) regulator_register (drivers/regulator/core.c:5486) devm_regulator_register (drivers/regulator/devres.c:196) reg_fixed_voltage_probe (drivers/regulator/fixed.c:289) [...] -> #0 (regulator_list_mutex){+.+.}-{3:3}: __lock_acquire (kernel/locking/lockdep.c:3052 (discriminator 4) kernel/locking/lockdep.c:3174 (discriminator 4) kernel/locking/lockdep.c:3789 (discriminator 4) kernel/locking/lockdep.c:5015 (discriminator 4)) lock_acquire (arch/arm64/include/asm/percpu.h:39 kernel/locking/lockdep.c:438 kernel/locking/lockdep.c:5627) __mutex_lock_common (include/asm-generic/atomic-instrumented.h:606 include/asm-generic/atomic-long.h:29 kernel/locking/mutex.c:103 kernel/locking/mutex.c:144 kernel/locking/mutex.c:963) mutex_lock_nested (kernel/locking/mutex.c:1125) regulator_lock_dependent (arch/arm64/include/asm/current.h:19 include/linux/ww_mutex.h:111 drivers/regulator/core.c:329) regulator_enable (drivers/regulator/core.c:2808) vctrl_enable (drivers/regulator/vctrl-regulator.c:400) _regulator_do_enable (drivers/regulator/core.c:2617) _regulator_enable (drivers/regulator/core.c:2764) regulator_enable (drivers/regulator/core.c:308 drivers/regulator/core.c:2809) _set_opp (drivers/opp/core.c:819 drivers/opp/core.c:1072) dev_pm_opp_set_rate (drivers/opp/core.c:1164) set_target (drivers/cpufreq/cpufreq-dt.c:62) __cpufreq_driver_target (drivers/cpufreq/cpufreq.c:2216 drivers/cpufreq/cpufreq.c:2271) cpufreq_online (drivers/cpufreq/cpufreq.c:1488 (discriminator 2)) cpufreq_add_dev (drivers/cpufreq/cpufreq.c:1563) subsys_interface_register (drivers/base/bus.c:?) cpufreq_register_driver (drivers/cpufreq/cpufreq.c:2819) dt_cpufreq_probe (drivers/cpufreq/cpufreq-dt.c:344) [...] other info that might help us debug this: Chain exists of: regulator_list_mutex --> regulator_ww_class_acquire --> regulator_ww_class_mutex Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(regulator_ww_class_mutex); lock(regulator_ww_class_acquire); lock(regulator_ww_class_mutex); lock(regulator_list_mutex); *** DEADLOCK *** 6 locks held by swapper/0/1: #0: ffffff8002d32188 (&dev->mutex){....}-{3:3}, at: __device_driver_lock (drivers/base/dd.c:1030) #1: ffffffc0111a0520 (cpu_hotplug_lock){++++}-{0:0}, at: cpufreq_register_driver (drivers/cpufreq/cpufreq.c:2792 (discriminator 2)) #2: ffffff8002a8d918 (subsys mutex#9){+.+.}-{3:3}, at: subsys_interface_register (drivers/base/bus.c:1033) #3: ffffff800341bb90 (&policy->rwsem){+.+.}-{3:3}, at: cpufreq_online (include/linux/bitmap.h:285 include/linux/cpumask.h:405 drivers/cpufreq/cpufreq.c:1399) #4: ffffffc011f0b7b8 (regulator_ww_class_acquire){+.+.}-{0:0}, at: regulator_enable (drivers/regulator/core.c:2808) #5: ffffff8004a77160 (regulator_ww_class_mutex){+.+.}-{3:3}, at: regulator_lock_recursive (drivers/regulator/core.c:156 drivers/regulator/core.c:263) stack backtrace: CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.14.0-rc6 #2 7c8f8996d021ed0f65271e6aeebf7999de74a9fa Hardware name: Google Scarlet (DT) Call trace: dump_backtrace (arch/arm64/kernel/stacktrace.c:161) show_stack (arch/arm64/kernel/stacktrace.c:218) dump_stack_lvl (lib/dump_stack.c:106 (discriminator 2)) dump_stack (lib/dump_stack.c:113) print_circular_bug (kernel/locking/lockdep.c:?) check_noncircular (kernel/locking/lockdep.c:?) __lock_acquire (kernel/locking/lockdep.c:3052 (discriminator 4) kernel/locking/lockdep.c:3174 (discriminator 4) kernel/locking/lockdep.c:3789 (discriminator 4) kernel/locking/lockdep.c:5015 (discriminator 4)) lock_acquire (arch/arm64/include/asm/percpu.h:39 kernel/locking/lockdep.c:438 kernel/locking/lockdep.c:5627) __mutex_lock_common (include/asm-generic/atomic-instrumented.h:606 include/asm-generic/atomic-long.h:29 kernel/locking/mutex.c:103 kernel/locking/mutex.c:144 kernel/locking/mutex.c:963) mutex_lock_nested (kernel/locking/mutex.c:1125) regulator_lock_dependent (arch/arm64/include/asm/current.h:19 include/linux/ww_mutex.h:111 drivers/regulator/core.c:329) regulator_enable (drivers/regulator/core.c:2808) vctrl_enable (drivers/regulator/vctrl-regulator.c:400) _regulator_do_enable (drivers/regulator/core.c:2617) _regulator_enable (drivers/regulator/core.c:2764) regulator_enable (drivers/regulator/core.c:308 drivers/regulator/core.c:2809) _set_opp (drivers/opp/core.c:819 drivers/opp/core.c:1072) dev_pm_opp_set_rate (drivers/opp/core.c:1164) set_target (drivers/cpufreq/cpufreq-dt.c:62) __cpufreq_driver_target (drivers/cpufreq/cpufreq.c:2216 drivers/cpufreq/cpufreq.c:2271) cpufreq_online (drivers/cpufreq/cpufreq.c:1488 (discriminator 2)) cpufreq_add_dev (drivers/cpufreq/cpufreq.c:1563) subsys_interface_register (drivers/base/bus.c:?) cpufreq_register_driver (drivers/cpufreq/cpufreq.c:2819) dt_cpufreq_probe (drivers/cpufreq/cpufreq-dt.c:344) [...] Reported-by: Brian Norris Fixes: f8702f9e4aa7 ("regulator: core: Use ww_mutex for regulators locking") Fixes: e9153311491d ("regulator: vctrl-regulator: Avoid deadlock getting and setting the voltage") Signed-off-by: Chen-Yu Tsai Link: https://lore.kernel.org/r/20210825033704.3307263-3-wenst@chromium.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 8665e30317c8d448c2d5430e5432c82e6cd2ec0e Author: Chen-Yu Tsai Date: Wed Aug 25 11:37:03 2021 +0800 regulator: vctrl: Use locked regulator_get_voltage in probe path [ Upstream commit 98e47570ba985f2310586c80409238200fa3170f ] In commit e9153311491d ("regulator: vctrl-regulator: Avoid deadlock getting and setting the voltage"), all calls to get/set the voltage of the control regulator were switched to unlocked versions to avoid deadlocks. However, the call in the probe path is done without regulator locks held. In this case the locked version should be used. Switch back to the locked regulator_get_voltage() in the probe path to avoid any mishaps. Fixes: e9153311491d ("regulator: vctrl-regulator: Avoid deadlock getting and setting the voltage") Signed-off-by: Chen-Yu Tsai Link: https://lore.kernel.org/r/20210825033704.3307263-2-wenst@chromium.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 80b1a70b045051ae3e5497565c6f6c24962d6c77 Author: Eric Biggers Date: Tue Aug 24 22:59:18 2021 -0700 blk-crypto: fix check for too-large dun_bytes [ Upstream commit cc40b7225151f611ef837f6403cfaeadc7af214a ] dun_bytes needs to be less than or equal to the IV size of the encryption mode, not just less than or equal to BLK_CRYPTO_MAX_IV_SIZE. Currently this doesn't matter since blk_crypto_init_key() is never actually passed invalid values, but we might as well fix this. Fixes: a892c8d52c02 ("block: Inline encryption support for blk-mq") Signed-off-by: Eric Biggers Link: https://lore.kernel.org/r/20210825055918.51975-1-ebiggers@kernel.org Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit ba6e5af621ab2fb4cd4acb37d4914c832991689c Author: Matija Glavinic Pecotic Date: Tue Aug 24 11:25:56 2021 +0200 spi: davinci: invoke chipselect callback [ Upstream commit ea4ab99cb58cc9f8d64c0961ff9a059825f304cf ] Davinci needs to configure chipselect on transfer. Fixes: 4a07b8bcd503 ("spi: bitbang: Make chipselect callback optional") Signed-off-by: Matija Glavinic Pecotic Reviewed-by: Alexander Sverdlin Link: https://lore.kernel.org/r/735fb7b0-82aa-5b9b-85e4-53f0c348cc0e@nokia.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit c0aec70a256ce63fc53345851988c142c826db62 Author: Borislav Petkov Date: Mon Aug 23 17:31:29 2021 -0700 x86/mce: Defer processing of early errors [ Upstream commit 3bff147b187d5dfccfca1ee231b0761a89f1eff5 ] When a fatal machine check results in a system reset, Linux does not clear the error(s) from machine check bank(s) - hardware preserves the machine check banks across a warm reset. During initialization of the kernel after the reboot, Linux reads, logs, and clears all machine check banks. But there is a problem. In: 5de97c9f6d85 ("x86/mce: Factor out and deprecate the /dev/mcelog driver") the call to mce_register_decode_chain() moved later in the boot sequence. This means that /dev/mcelog doesn't see those early error logs. This was partially fixed by: cd9c57cad3fe ("x86/MCE: Dump MCE to dmesg if no consumers") which made sure that the logs were not lost completely by printing to the console. But parsing console logs is error prone. Users of /dev/mcelog should expect to find any early errors logged to standard places. Add a new flag MCP_QUEUE_LOG to machine_check_poll() to be used in early machine check initialization to indicate that any errors found should just be queued to genpool. When mcheck_late_init() is called it will call mce_schedule_work() to actually log and flush any errors queued in the genpool. [ Based on an original patch, commit message by and completely productized by Tony Luck. ] Fixes: 5de97c9f6d85 ("x86/mce: Factor out and deprecate the /dev/mcelog driver") Reported-by: Sumanth Kamatala Signed-off-by: Borislav Petkov Signed-off-by: Tony Luck Signed-off-by: Borislav Petkov Link: https://lkml.kernel.org/r/20210824003129.GA1642753@agluck-desk2.amr.corp.intel.com Signed-off-by: Sasha Levin commit 6627be8b36dcbe5ad5fb1015f54bf57222a43df4 Author: Stefan Berger Date: Thu Aug 12 22:45:48 2021 +0300 tpm: ibmvtpm: Avoid error message when process gets signal while waiting [ Upstream commit 047d4226b0bca1cda5267dc68bc8291cce5364ac ] When rngd is run as root then lots of these types of message will appear in the kernel log if the TPM has been configured to provide random bytes: [ 7406.275163] tpm tpm0: tpm_transmit: tpm_recv: error -4 The issue is caused by the following call that is interrupted while waiting for the TPM's response. sig = wait_event_interruptible(ibmvtpm->wq, !ibmvtpm->tpm_processing_cmd); Rather than waiting for the response in the low level driver, have it use the polling loop in tpm_try_transmit() that uses a command's duration to poll until a result has been returned by the TPM, thus ending when the timeout has occurred but not responding to signals and ctrl-c anymore. To stay in this polling loop extend tpm_ibmvtpm_status() to return 'true' for as long as the vTPM is indicated as being busy in tpm_processing_cmd. Since the loop requires the TPM's timeouts, get them now using tpm_get_timeouts() after setting the TPM2 version flag on the chip. To recreat the resolved issue start rngd like this: sudo rngd -r /dev/hwrng -t sudo rngd -r /dev/tpm0 -t Link: https://bugzilla.redhat.com/show_bug.cgi?id=1981473 Fixes: 6674ff145eef ("tpm_ibmvtpm: properly handle interrupted packet receptions") Cc: Nayna Jain Cc: George Wilson Reported-by: Nageswara R Sastry Signed-off-by: Stefan Berger Tested-by: Nageswara R Sastry Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Sasha Levin commit bd2028e9e27c09d295f3546d61b042a7dada3ed1 Author: Stefan Berger Date: Tue Jun 29 17:34:20 2021 -0400 certs: Trigger creation of RSA module signing key if it's not an RSA key [ Upstream commit ea35e0d5df6c92fa2e124bb1b91d09b2240715ba ] Address a kbuild issue where a developer created an ECDSA key for signing kernel modules and then builds an older version of the kernel, when bi- secting the kernel for example, that does not support ECDSA keys. If openssl is installed, trigger the creation of an RSA module signing key if it is not an RSA key. Fixes: cfc411e7fff3 ("Move certificate handling to its own directory") Cc: David Howells Cc: David Woodhouse Signed-off-by: Stefan Berger Reviewed-by: Jarkko Sakkinen Tested-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Sasha Levin commit fddf3a72abe11322a593a0a35036f0d9cc132341 Author: Giovanni Cabiddu Date: Thu Aug 12 21:21:10 2021 +0100 crypto: qat - use proper type for vf_mask [ Upstream commit 462354d986b6a89c6449b85f17aaacf44e455216 ] Replace vf_mask type with unsigned long to avoid a stack-out-of-bound. This is to fix the following warning reported by KASAN the first time adf_msix_isr_ae() gets called. [ 692.091987] BUG: KASAN: stack-out-of-bounds in find_first_bit+0x28/0x50 [ 692.092017] Read of size 8 at addr ffff88afdf789e60 by task swapper/32/0 [ 692.092076] Call Trace: [ 692.092089] [ 692.092101] dump_stack+0x9c/0xcf [ 692.092132] print_address_description.constprop.0+0x18/0x130 [ 692.092164] ? find_first_bit+0x28/0x50 [ 692.092185] kasan_report.cold+0x7f/0x111 [ 692.092213] ? static_obj+0x10/0x80 [ 692.092234] ? find_first_bit+0x28/0x50 [ 692.092262] find_first_bit+0x28/0x50 [ 692.092288] adf_msix_isr_ae+0x16e/0x230 [intel_qat] Fixes: ed8ccaef52fa ("crypto: qat - Add support for SRIOV") Signed-off-by: Giovanni Cabiddu Reviewed-by: Marco Chiappero Reviewed-by: Fiona Trahe Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit e7273d57d2b7f7941b06399335a385c53678eb0b Author: Chen-Yu Tsai Date: Thu Aug 12 01:15:05 2021 +0800 irqchip/gic-v3: Fix priority comparison when non-secure priorities are used [ Upstream commit 8d474deaba2c4dd33a5e2f5be82e6798ffa6b8a5 ] When non-secure priorities are used, compared to the raw priority set, the value read back from RPR is also right-shifted by one and the highest bit set. Add a macro to do the modifications to the raw priority when doing the comparison against the RPR value. This corrects the pseudo-NMI behavior when non-secure priorities in the GIC are used. Tested on 5.10 with the "IPI as pseudo-NMI" series [1] applied on MT8195. [1] https://lore.kernel.org/linux-arm-kernel/1604317487-14543-1-git-send-email-sumit.garg@linaro.org/ Fixes: 336780590990 ("irqchip/gic-v3: Support pseudo-NMIs when SCR_EL3.FIQ == 0") Reviewed-by: Alexandru Elisei Signed-off-by: Chen-Yu Tsai [maz: Added comment contributed by Alex] Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/20210811171505.1502090-1-wenst@chromium.org Signed-off-by: Sasha Levin commit f1f6d3d2ada818be13bda3e76883714b5b8ead44 Author: Christophe JAILLET Date: Wed Aug 18 22:55:56 2021 +0200 spi: coldfire-qspi: Use clk_disable_unprepare in the remove function [ Upstream commit d68f4c73d729245a47e70eb216fa24bc174ed2e2 ] 'clk_prepare_enable()' is used in the probe, so 'clk_disable_unprepare()' should be used in the remove function to be consistent. Fixes: 499de01c5c0b ("spi: coldfire-qspi: Use clk_prepare_enable and clk_disable_unprepare") Signed-off-by: Christophe JAILLET Link: https://lore.kernel.org/r/ee91792ddba61342b0d3284cd4558a2b0016c4e7.1629319838.git.christophe.jaillet@wanadoo.fr Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 4b21d4e820bb9a1415ec76dfe565e4c5937337dd Author: Pavel Skripkin Date: Thu Aug 12 12:15:01 2021 +0300 block: nbd: add sanity check for first_minor [ Upstream commit b1a811633f7321cf1ae2bb76a66805b7720e44c9 ] Syzbot hit WARNING in internal_create_group(). The problem was in too big disk->first_minor. disk->first_minor is initialized by value, which comes from userspace and there wasn't any sanity checks about value correctness. It can cause duplicate creation of sysfs files/links, because disk->first_minor will be passed to MKDEV() which causes truncation to byte. Since maximum minor value is 0xff, let's check if first_minor is correct minor number. NOTE: the root case of the reported warning was in wrong error handling in register_disk(), but we can avoid passing knowingly wrong values to sysfs API, because sysfs error messages can confuse users. For example: user passed 1048576 as index, but sysfs complains about duplicate creation of /dev/block/43:0. It's not obvious how 1048576 becomes 0. Log and reproducer for above example can be found on syzkaller bug report page. Link: https://syzkaller.appspot.com/bug?id=03c2ae9146416edf811958d5fd7acfab75b143d1 Fixes: b0d9111a2d53 ("nbd: use an idr to keep track of nbd devices") Reported-by: syzbot+9937dc42271cd87d4b98@syzkaller.appspotmail.com Reviewed-by: Christoph Hellwig Signed-off-by: Pavel Skripkin Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 31fc50cd93cde6529e67837967cdcfc739fe9242 Author: Phong Hoang Date: Thu Apr 22 14:34:43 2021 +0200 clocksource/drivers/sh_cmt: Fix wrong setting if don't request IRQ for clock source channel [ Upstream commit be83c3b6e7b8ff22f72827a613bf6f3aa5afadbb ] If CMT instance has at least two channels, one channel will be used as a clock source and another one used as a clock event device. In that case, IRQ is not requested for clock source channel so sh_cmt_clock_event_program_verify() might work incorrectly. Besides, when a channel is only used for clock source, don't need to re-set the next match_value since it should be maximum timeout as it still is. On the other hand, due to no IRQ, total_cycles is not counted up when reaches compare match time (timer counter resets to zero), so sh_cmt_clocksource_read() returns unexpected value. Therefore, use 64-bit clocksoure's mask for 32-bit or 16-bit variants will also lead to wrong delta calculation. Hence, this mask should correspond to timer counter width, and above function just returns the raw value of timer counter register. Fixes: bfa76bb12f23 ("clocksource: sh_cmt: Request IRQ for clock event device only") Fixes: 37e7742c55ba ("clocksource/drivers/sh_cmt: Fix clocksource width for 32-bit machines") Signed-off-by: Phong Hoang Signed-off-by: Niklas Söderlund Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20210422123443.73334-1-niklas.soderlund+renesas@ragnatech.se Signed-off-by: Sasha Levin commit dde7ff1c197757f03d11dbfb2ef302d412e5ba61 Author: Hongbo Li Date: Thu Aug 5 16:53:32 2021 +0800 lib/mpi: use kcalloc in mpi_resize [ Upstream commit b6f756726e4dfe75be1883f6a0202dcecdc801ab ] We should set the additional space to 0 in mpi_resize(). So use kcalloc() instead of kmalloc_array(). In lib/mpi/ec.c: /**************** * Resize the array of A to NLIMBS. the additional space is cleared * (set to 0) [done by m_realloc()] */ int mpi_resize(MPI a, unsigned nlimbs) Like the comment of kernel's mpi_resize() said, the additional space need to be set to 0, but when a->d is not NULL, it does not set. The kernel's mpi lib is from libgcrypt, the mpi resize in libgcrypt is _gcry_mpi_resize() which set the additional space to 0. This bug may cause mpi api which use mpi_resize() get wrong result under the condition of using the additional space without initiation. If this condition is not met, the bug would not be triggered. Currently in kernel, rsa, sm2 and dh use mpi lib, and they works well, so the bug is not triggered in these cases. add_points_edwards() use the additional space directly, so it will get a wrong result. Fixes: cdec9cb5167a ("crypto: GnuPG based MPI lib - source files (part 1)") Signed-off-by: Hongbo Li Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 20d84fc59e85ab889f7c96546ffb07d036836da8 Author: Huacai Chen Date: Thu Aug 5 21:22:16 2021 +0800 irqchip/loongson-pch-pic: Improve edge triggered interrupt support [ Upstream commit e5dec38ac5d05d17a7110c8045aa101015281e4d ] Edge-triggered mode and level-triggered mode need different handlers, and edge-triggered mode need a specific ack operation. So improve it. Fixes: ef8c01eb64ca6719da449dab0 ("irqchip: Add Loongson PCH PIC controller") Signed-off-by: Chen Zhu Signed-off-by: Huacai Chen Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/20210805132216.3539007-1-chenhuacai@loongson.cn Signed-off-by: Sasha Levin commit e9a902f88207fd2fae394357af1e596a74ac2281 Author: Zhen Lei Date: Wed Aug 11 17:33:32 2021 +0800 genirq/timings: Fix error return code in irq_timings_test_irqs() [ Upstream commit 290fdc4b7ef14e33d0e30058042b0e9bfd02b89b ] Return a negative error code from the error handling case instead of 0, as done elsewhere in this function. Fixes: f52da98d900e ("genirq/timings: Add selftest for irqs circular buffer") Reported-by: Hulk Robot Signed-off-by: Zhen Lei Signed-off-by: Thomas Gleixner Link: https://lore.kernel.org/r/20210811093333.2376-1-thunder.leizhen@huawei.com Signed-off-by: Sasha Levin commit 10d3bdd2d57867a98473a0a4bc153262e9b902b9 Author: Tony Lindgren Date: Tue Aug 10 11:17:27 2021 +0300 spi: spi-pic32: Fix issue with uninitialized dma_slave_config [ Upstream commit 976c1de1de147bb7f4e0d87482f375221c05aeaf ] Depending on the DMA driver being used, the struct dma_slave_config may need to be initialized to zero for the unused data. For example, we have three DMA drivers using src_port_window_size and dst_port_window_size. If these are left uninitialized, it can cause DMA failures. For spi-pic32, this is probably not currently an issue but is still good to fix though. Fixes: 1bcb9f8ceb67 ("spi: spi-pic32: Add PIC32 SPI master driver") Cc: Purna Chandra Mandal Cc: Peter Ujfalusi Cc: Vinod Koul Signed-off-by: Tony Lindgren Link: https://lore.kernel.org/r/20210810081727.19491-2-tony@atomide.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit d4ec971bfa88fb586138ae3861426716b5765371 Author: Tony Lindgren Date: Tue Aug 10 11:17:26 2021 +0300 spi: spi-fsl-dspi: Fix issue with uninitialized dma_slave_config [ Upstream commit 209ab223ad5b18e437289235e3bde12593b94ac4 ] Depending on the DMA driver being used, the struct dma_slave_config may need to be initialized to zero for the unused data. For example, we have three DMA drivers using src_port_window_size and dst_port_window_size. If these are left uninitialized, it can cause DMA failures. For spi-fsl-dspi, this is probably not currently an issue but is still good to fix though. Fixes: 90ba37033cb9 ("spi: spi-fsl-dspi: Add DMA support for Vybrid") Cc: Sanchayan Maity Cc: Vladimir Oltean Cc: Peter Ujfalusi Cc: Vinod Koul Signed-off-by: Tony Lindgren Acked-by: Vladimir Oltean Link: https://lore.kernel.org/r/20210810081727.19491-1-tony@atomide.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 87aa69aa10b420823174eedcfd16366ad3d7fe93 Author: Ming Lei Date: Thu Jul 29 11:42:26 2021 +0800 block: return ELEVATOR_DISCARD_MERGE if possible [ Upstream commit 866663b7b52d2da267b28e12eed89ee781b8fed1 ] When merging one bio to request, if they are discard IO and the queue supports multi-range discard, we need to return ELEVATOR_DISCARD_MERGE because both block core and related drivers(nvme, virtio-blk) doesn't handle mixed discard io merge(traditional IO merge together with discard merge) well. Fix the issue by returning ELEVATOR_DISCARD_MERGE in this situation, so both blk-mq and drivers just need to handle multi-range discard. Reported-by: Oleksandr Natalenko Signed-off-by: Ming Lei Tested-by: Oleksandr Natalenko Fixes: 2705dfb20947 ("block: fix discard request merge") Link: https://lore.kernel.org/r/20210729034226.1591070-1-ming.lei@redhat.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 3868507181534fee3d8d03130f40f579e52cd0a7 Author: Geert Uytterhoeven Date: Sun Jul 25 12:44:13 2021 +0200 m68k: Fix invalid RMW_INSNS on CPUs that lack CAS [ Upstream commit 2189e928b62e91d8efbc9826ae7c0968f0d55790 ] When enabling CONFIG_RMW_INSNS in e.g. a Coldfire build: {standard input}:3068: Error: invalid instruction for this architecture; needs 68020 or higher (68020 [68k, 68ec020], 68030 [68ec030], 68040 [68ec040], 68060 [68ec060]) -- statement `casl %d4,%d0,(%a6)' ignored Fix this by (a) adding a new config symbol to track if support for any CPU that lacks the CAS instruction is enabled, and (b) making CONFIG_RMW_INSNS depend on the new symbol not being set. Fixes: 0e152d80507b75c0 ("m68k: reorganize Kconfig options to improve mmu/non-mmu selections") Reported-by: kernel test robot Reported-by: Arnd Bergmann Signed-off-by: Geert Uytterhoeven Acked-by: Arnd Bergmann Link: https://lore.kernel.org/r/20210725104413.318932-1-geert@linux-m68k.org Signed-off-by: Sasha Levin commit 497f3d9c3f58fba01a45fabe93fa8679a367b48f Author: Yanfei Xu Date: Sun May 16 17:50:10 2021 +0800 rcu: Fix stall-warning deadlock due to non-release of rcu_node ->lock [ Upstream commit dc87740c8a6806bd2162bfb441770e4e53be5601 ] If rcu_print_task_stall() is invoked on an rcu_node structure that does not contain any tasks blocking the current grace period, it takes an early exit that fails to release that rcu_node structure's lock. This results in a self-deadlock, which is detected by lockdep. To reproduce this bug: tools/testing/selftests/rcutorture/bin/kvm.sh --allcpus --duration 3 --trust-make --configs "TREE03" --kconfig "CONFIG_PROVE_LOCKING=y" --bootargs "rcutorture.stall_cpu=30 rcutorture.stall_cpu_block=1 rcutorture.fwd_progress=0 rcutorture.test_boost=0" This will also result in other complaints, including RCU's scheduler hook complaining about blocking rather than preemption and an rcutorture writer stall. Only a partial RCU CPU stall warning message will be printed because of the self-deadlock. This commit therefore releases the lock on the rcu_print_task_stall() function's early exit path. Fixes: c583bcb8f5ed ("rcu: Don't invoke try_invoke_on_locked_down_task() with irqs disabled") Tested-by: Qais Yousef Signed-off-by: Yanfei Xu Signed-off-by: Paul E. McKenney Signed-off-by: Sasha Levin commit ea5e5bc881a4de9b5e09a16af950af2584dd67d2 Author: Paul E. McKenney Date: Thu Nov 19 10:13:06 2020 -0800 rcu: Add lockdep_assert_irqs_disabled() to rcu_sched_clock_irq() and callees [ Upstream commit a649d25dcc671a33b9cc3176411920fdc5fbd98e ] This commit adds a number of lockdep_assert_irqs_disabled() calls to rcu_sched_clock_irq() and a number of the functions that it calls. The point of this is to help track down a situation where lockdep appears to be insisting that interrupts are enabled within these functions, which should only ever be invoked from the scheduling-clock interrupt handler. Link: https://lore.kernel.org/lkml/20201111133813.GA81547@elver.google.com/ Signed-off-by: Paul E. McKenney Signed-off-by: Sasha Levin commit 527b56d7856fc9a6dd5a0a96bca8ce394b97bfa8 Author: Yanfei Xu Date: Sun May 16 00:45:11 2021 +0800 rcu: Fix to include first blocked task in stall warning [ Upstream commit e6a901a44f76878ed1653626c9ff4cfc5a3f58f8 ] The for loop in rcu_print_task_stall() always omits ts[0], which points to the first task blocking the stalled grace period. This in turn fails to count this first task, which means that ndetected will be equal to zero when all CPUs have passed through their quiescent states and only one task is blocking the stalled grace period. This zero value for ndetected will in turn result in an incorrect "All QSes seen" message: rcu: INFO: rcu_preempt detected stalls on CPUs/tasks: rcu: Tasks blocked on level-1 rcu_node (CPUs 12-23): (detected by 15, t=6504 jiffies, g=164777, q=9011209) rcu: All QSes seen, last rcu_preempt kthread activity 1 (4295252379-4295252378), jiffies_till_next_fqs=1, root ->qsmask 0x2 BUG: sleeping function called from invalid context at include/linux/uaccess.h:156 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 70613, name: msgstress04 INFO: lockdep is turned off. Preemption disabled at: [] create_object.isra.0+0x204/0x4b0 CPU: 15 PID: 70613 Comm: msgstress04 Kdump: loaded Not tainted 5.12.2-yoctodev-standard #1 Hardware name: Marvell OcteonTX CN96XX board (DT) Call trace: dump_backtrace+0x0/0x2cc show_stack+0x24/0x30 dump_stack+0x110/0x188 ___might_sleep+0x214/0x2d0 __might_sleep+0x7c/0xe0 This commit therefore fixes the loop to include ts[0]. Fixes: c583bcb8f5ed ("rcu: Don't invoke try_invoke_on_locked_down_task() with irqs disabled") Tested-by: Qais Yousef Signed-off-by: Yanfei Xu Signed-off-by: Paul E. McKenney Signed-off-by: Sasha Levin commit e6778e1b22d090321a715e9f3c4ded352fc2b067 Author: Quentin Perret Date: Thu Aug 5 11:21:53 2021 +0100 sched: Fix UCLAMP_FLAG_IDLE setting [ Upstream commit ca4984a7dd863f3e1c0df775ae3e744bff24c303 ] The UCLAMP_FLAG_IDLE flag is set on a runqueue when dequeueing the last uclamp active task (that is, when buckets.tasks reaches 0 for all buckets) to maintain the last uclamp.max and prevent blocked util from suddenly becoming visible. However, there is an asymmetry in how the flag is set and cleared which can lead to having the flag set whilst there are active tasks on the rq. Specifically, the flag is cleared in the uclamp_rq_inc() path, which is called at enqueue time, but set in uclamp_rq_dec_id() which is called both when dequeueing a task _and_ in the update_uclamp_active() path. As a result, when both uclamp_rq_{dec,ind}_id() are called from update_uclamp_active(), the flag ends up being set but not cleared, hence leaving the runqueue in a broken state. Fix this by clearing the flag in update_uclamp_active() as well. Fixes: e496187da710 ("sched/uclamp: Enforce last task's UCLAMP_MAX") Reported-by: Rick Yiu Signed-off-by: Quentin Perret Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Qais Yousef Tested-by: Dietmar Eggemann Link: https://lore.kernel.org/r/20210805102154.590709-2-qperret@google.com Signed-off-by: Sasha Levin commit 718180c24675e02f090d0d7351ad022fea0c4cea Author: Mika Penttilä Date: Thu Jul 22 09:39:46 2021 +0300 sched/numa: Fix is_core_idle() [ Upstream commit 1c6829cfd3d5124b125e6df41158665aea413b35 ] Use the loop variable instead of the function argument to test the other SMT siblings for idle. Fixes: ff7db0bf24db ("sched/numa: Prefer using an idle CPU as a migration target instead of comparing tasks") Signed-off-by: Mika Penttilä Signed-off-by: Peter Zijlstra (Intel) Acked-by: Mel Gorman Acked-by: Pankaj Gupta Link: https://lkml.kernel.org/r/20210722063946.28951-1-mika.penttila@gmail.com Signed-off-by: Sasha Levin commit bf4b0fa3a2e270f2f093b93a75ab22fff0649435 Author: Pavel Skripkin Date: Mon Jul 5 23:47:27 2021 +0300 m68k: emu: Fix invalid free in nfeth_cleanup() [ Upstream commit 761608f5cf70e8876c2f0e39ca54b516bdcb7c12 ] In the for loop all nfeth_dev array members should be freed, not only the first one. Freeing only the first array member can cause double-free bugs and memory leaks. Fixes: 9cd7b148312f ("m68k/atari: ARAnyM - Add support for network access") Signed-off-by: Pavel Skripkin Link: https://lore.kernel.org/r/20210705204727.10743-1-paskripkin@gmail.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit 246c771b856222e9caa8f7a6b679e45ad6ce3cca Author: Peter Robinson Date: Thu Jul 1 23:05:16 2021 +0100 power: supply: cw2015: use dev_err_probe to allow deferred probe [ Upstream commit ad1abe476995d97bfe7546ea91bb4f3dcdfbf3ab ] Deal with deferred probe using dev_err_probe so the error is handled and avoid logging lots probe defer information like the following: [ 9.125121] cw2015 4-0062: Failed to register power supply [ 9.211131] cw2015 4-0062: Failed to register power supply Fixes: b4c7715c10c1 ("power: supply: add CellWise cw2015 fuel gauge driver") Signed-off-by: Peter Robinson Reviewed-by: Javier Martinez Canillas Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit a758b1d4ca207a5f03a69a210a8b90d86fdd93a1 Author: Harald Freudenberger Date: Wed Aug 25 10:55:02 2021 +0200 s390/ap: fix state machine hang after failure to enable irq [ Upstream commit cabebb697c98fb1f05cc950a747a9b6ec61a5b01 ] If for any reason the interrupt enable for an ap queue fails the state machine run for the queue returned wrong return codes to the caller. So the caller assumed interrupt support for this queue in enabled and thus did not re-establish the high resolution timer used for polling. In the end this let to a hang for the user space process waiting "forever" for the reply. This patch reworks these return codes to return correct indications for the caller to re-establish the timer when a queue runs without interrupt support. Please note that this is fixing a wrong behavior after a first failure (enable interrupt support for the queue) failed. However, looks like this occasionally happens on KVM systems. Signed-off-by: Harald Freudenberger Signed-off-by: Heiko Carstens Signed-off-by: Sasha Levin commit 86f9980909f31ab205323eeeb290fe3cbb4952b4 Author: Peter Oberparleiter Date: Fri Aug 13 15:05:03 2021 +0200 s390/debug: fix debug area life cycle [ Upstream commit 9372a82892c2caa6bccab9a4081166fa769699f8 ] Currently allocation and registration of s390dbf debug areas are tied together. As a result, a debug area cannot be unregistered and re-registered while any process has an associated debugfs file open. Fix this by splitting alloc/release from register/unregister. Signed-off-by: Peter Oberparleiter Signed-off-by: Heiko Carstens Signed-off-by: Sasha Levin commit 0980d2b21f4d0a0895e29aed27e1f3a14e334f6f Author: Peter Oberparleiter Date: Fri Aug 13 15:05:02 2021 +0200 s390/debug: keep debug data on resize [ Upstream commit 1204777867e8486a88dbb4793fe256b31ea05eeb ] Any previously recorded s390dbf debug data is reset when a debug area is resized using the 'pages' sysfs attribute. This can make live-debugging unnecessarily complex. Fix this by copying existing debug data to the newly allocated debug area when resizing. Signed-off-by: Peter Oberparleiter Signed-off-by: Heiko Carstens Signed-off-by: Sasha Levin commit 0404bf4a660ca8d5c82b8252f55f1f64506aa09a Author: Niklas Schnelle Date: Wed Jul 21 19:58:54 2021 +0200 s390/pci: fix misleading rc in clp_set_pci_fn() [ Upstream commit f7addcdd527a6dddfebe20c358b87bdb95624612 ] Currently clp_set_pci_fn() always returns 0 as long as the CLP request itself succeeds even if the operation itself returns a response code other than CLP_RC_OK or CLP_RC_SETPCIFN_ALRDY. This is highly misleading because calling code assumes that a zero rc means that the operation was successful. Fix this by returning the response code or cc on failure with the exception of the special handling for CLP_RC_SETPCIFN_ALRDY. Also let's not assume that the returned function handle for CLP_RC_SETPCIFN_ALRDY is 0, we don't need it anyway. Reviewed-by: Matthew Rosato Signed-off-by: Niklas Schnelle Signed-off-by: Heiko Carstens Signed-off-by: Sasha Levin commit 8b471e72b51e4d2617f27215da3f7840090fb22b Author: Alexander Gordeev Date: Fri Aug 6 12:55:08 2021 +0200 s390/kasan: fix large PMD pages address alignment check [ Upstream commit ddd63c85ef67ea9ea7282ad35eafb6568047126e ] It is currently possible to initialize a large PMD page when the address is not aligned on page boundary. Signed-off-by: Alexander Gordeev Reviewed-by: Vasily Gorbik Signed-off-by: Vasily Gorbik Signed-off-by: Heiko Carstens Signed-off-by: Sasha Levin commit 9d999957cb39ab7f37235808e006cf5b5bef536b Author: Stian Skjelstad Date: Sun Aug 22 11:33:32 2021 +0200 udf_get_extendedattr() had no boundary checks. [ Upstream commit 58bc6d1be2f3b0ceecb6027dfa17513ec6aa2abb ] When parsing the ExtendedAttr data, malicous or corrupt attribute length could cause kernel hangs and buffer overruns in some special cases. Link: https://lore.kernel.org/r/20210822093332.25234-1-stian.skjelstad@gmail.com Signed-off-by: Stian Skjelstad Signed-off-by: Jan Kara Signed-off-by: Sasha Levin commit db2f238d8d12569b92f74ba89b7f2ad79fc4bd1a Author: Desmond Cheong Zhi Xi Date: Fri Jul 2 17:18:31 2021 +0800 fcntl: fix potential deadlock for &fasync_struct.fa_lock [ Upstream commit 2f488f698fda820f8e6fa0407630154eceb145d6 ] There is an existing lock hierarchy of &dev->event_lock --> &fasync_struct.fa_lock --> &f->f_owner.lock from the following call chain: input_inject_event(): spin_lock_irqsave(&dev->event_lock,...); input_handle_event(): input_pass_values(): input_to_handler(): evdev_events(): evdev_pass_values(): spin_lock(&client->buffer_lock); __pass_event(): kill_fasync(): kill_fasync_rcu(): read_lock(&fa->fa_lock); send_sigio(): read_lock_irqsave(&fown->lock,...); &dev->event_lock is HARDIRQ-safe, so interrupts have to be disabled while grabbing &fasync_struct.fa_lock, otherwise we invert the lock hierarchy. However, since kill_fasync which calls kill_fasync_rcu is an exported symbol, it may not necessarily be called with interrupts disabled. As kill_fasync_rcu may be called with interrupts disabled (for example, in the call chain above), we replace calls to read_lock/read_unlock on &fasync_struct.fa_lock in kill_fasync_rcu with read_lock_irqsave/read_unlock_irqrestore. Signed-off-by: Desmond Cheong Zhi Xi Signed-off-by: Jeff Layton Signed-off-by: Sasha Levin commit 349633ed311cb14d9e813b556bf1224866be2fa1 Author: Giovanni Cabiddu Date: Thu Aug 12 21:21:28 2021 +0100 crypto: qat - do not export adf_iov_putmsg() [ Upstream commit 645ae0af1840199086c33e4f841892ebee73f615 ] The function adf_iov_putmsg() is only used inside the intel_qat module therefore should not be exported. Remove EXPORT_SYMBOL for the function adf_iov_putmsg(). Signed-off-by: Giovanni Cabiddu Reviewed-by: Fiona Trahe Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 205cfad5c0caa6961e88ff50190a659fa9adb47a Author: Marco Chiappero Date: Thu Aug 12 21:21:22 2021 +0100 crypto: qat - fix naming for init/shutdown VF to PF notifications [ Upstream commit b90c1c4d3fa8cd90f4e8245b13564380fd0bfad1 ] At start and shutdown, VFs notify the PF about their state. These notifications are carried out through a message exchange using the PFVF protocol. Function names lead to believe they do perform init or shutdown logic. This is to fix the naming to better reflect their purpose. Signed-off-by: Marco Chiappero Co-developed-by: Giovanni Cabiddu Signed-off-by: Giovanni Cabiddu Reviewed-by: Fiona Trahe Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit c29cc43e30baafe4300a1379283e23be20e85177 Author: Marco Chiappero Date: Thu Aug 12 21:21:19 2021 +0100 crypto: qat - fix reuse of completion variable [ Upstream commit 3d655732b0199562267a05c7ff69ecdd11632939 ] Use reinit_completion() to set to a clean state a completion variable, used to coordinate the VF to PF request-response flow, before every new VF request. Signed-off-by: Marco Chiappero Co-developed-by: Giovanni Cabiddu Signed-off-by: Giovanni Cabiddu Reviewed-by: Fiona Trahe Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit e53575ea28d95bb6681a343bd563a58c5ff87d2e Author: Giovanni Cabiddu Date: Thu Aug 12 21:21:14 2021 +0100 crypto: qat - handle both source of interrupt in VF ISR [ Upstream commit 0a73c762e1eee33a5e5dc0e3488f1b7cd17249b3 ] The top half of the VF drivers handled only a source at the time. If an interrupt for PF2VF and bundle occurred at the same time, the ISR scheduled only the bottom half for PF2VF. This patch fixes the VF top half so that if both sources of interrupt trigger at the same time, both bottom halves are scheduled. This patch is based on earlier work done by Conor McLoughlin. Signed-off-by: Giovanni Cabiddu Reviewed-by: Marco Chiappero Reviewed-by: Fiona Trahe Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 9819975c636c366ff46b17ddadac6b11344692dc Author: Giovanni Cabiddu Date: Thu Aug 12 21:21:13 2021 +0100 crypto: qat - do not ignore errors from enable_vf2pf_comms() [ Upstream commit 5147f0906d50a9d26f2b8698cd06b5680e9867ff ] The function adf_dev_init() ignores the error code reported by enable_vf2pf_comms(). If the latter fails, e.g. the VF is not compatible with the pf, then the load of the VF driver progresses. This patch changes adf_dev_init() so that the error code from enable_vf2pf_comms() is returned to the caller. Signed-off-by: Giovanni Cabiddu Reviewed-by: Marco Chiappero Reviewed-by: Fiona Trahe Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 6f3c58bd62f2a39d25cefb0ad313b0c1012b8260 Author: Ben Hutchings Date: Wed Aug 11 02:06:09 2021 +0200 crypto: omap - Fix inconsistent locking of device lists [ Upstream commit fe4d55773b879c785ae61da9b1c2160f0110f67e ] lockdep complains that in omap-aes, the list_lock is taken both with softirqs enabled at probe time, and also in softirq context, which could lead to a deadlock: ================================ WARNING: inconsistent lock state 5.14.0-rc1-00035-gc836005b01c5-dirty #69 Not tainted -------------------------------- inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage. ksoftirqd/0/7 [HC0[0]:SC1[3]:HE1:SE0] takes: bf00e014 (list_lock){+.?.}-{2:2}, at: omap_aes_find_dev+0x18/0x54 [omap_aes_driver] {SOFTIRQ-ON-W} state was registered at: _raw_spin_lock+0x40/0x50 omap_aes_probe+0x1d4/0x664 [omap_aes_driver] platform_probe+0x58/0xb8 really_probe+0xbc/0x314 __driver_probe_device+0x80/0xe4 driver_probe_device+0x30/0xc8 __driver_attach+0x70/0xf4 bus_for_each_dev+0x70/0xb4 bus_add_driver+0xf0/0x1d4 driver_register+0x74/0x108 do_one_initcall+0x84/0x2e4 do_init_module+0x5c/0x240 load_module+0x221c/0x2584 sys_finit_module+0xb0/0xec ret_fast_syscall+0x0/0x2c 0xbed90b30 irq event stamp: 111800 hardirqs last enabled at (111800): [] __kmalloc+0x484/0x5ec hardirqs last disabled at (111799): [] __kmalloc+0x490/0x5ec softirqs last enabled at (111776): [] __do_softirq+0x2b8/0x4d0 softirqs last disabled at (111781): [] run_ksoftirqd+0x34/0x50 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(list_lock); lock(list_lock); *** DEADLOCK *** 2 locks held by ksoftirqd/0/7: #0: c0f5e8c8 (rcu_read_lock){....}-{1:2}, at: netif_receive_skb+0x6c/0x260 #1: c0f5e8c8 (rcu_read_lock){....}-{1:2}, at: ip_local_deliver_finish+0x2c/0xdc stack backtrace: CPU: 0 PID: 7 Comm: ksoftirqd/0 Not tainted 5.14.0-rc1-00035-gc836005b01c5-dirty #69 Hardware name: Generic AM43 (Flattened Device Tree) [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [] (show_stack) from [] (mark_lock.part.17+0x5bc/0xd04) [] (mark_lock.part.17) from [] (__lock_acquire+0x960/0x2fa4) [] (__lock_acquire) from [] (lock_acquire+0x10c/0x358) [] (lock_acquire) from [] (_raw_spin_lock_bh+0x44/0x58) [] (_raw_spin_lock_bh) from [] (omap_aes_find_dev+0x18/0x54 [omap_aes_driver]) [] (omap_aes_find_dev [omap_aes_driver]) from [] (omap_aes_crypt+0x94/0xd4 [omap_aes_driver]) [] (omap_aes_crypt [omap_aes_driver]) from [] (esp_input+0x1b0/0x2c8) [] (esp_input) from [] (xfrm_input+0x410/0x1290) [] (xfrm_input) from [] (xfrm4_esp_rcv+0x54/0x11c) [] (xfrm4_esp_rcv) from [] (ip_protocol_deliver_rcu+0x48/0x3bc) [] (ip_protocol_deliver_rcu) from [] (ip_local_deliver_finish+0x9c/0xdc) [] (ip_local_deliver_finish) from [] (ip_local_deliver+0x148/0x1b0) [] (ip_local_deliver) from [] (ip_rcv+0x11c/0x180) [] (ip_rcv) from [] (__netif_receive_skb_one_core+0x54/0x74) [] (__netif_receive_skb_one_core) from [] (netif_receive_skb+0xa8/0x260) [] (netif_receive_skb) from [] (cpsw_rx_handler+0x224/0x2fc) [] (cpsw_rx_handler) from [] (__cpdma_chan_process+0xf4/0x188) [] (__cpdma_chan_process) from [] (cpdma_chan_process+0x3c/0x5c) [] (cpdma_chan_process) from [] (cpsw_rx_mq_poll+0x44/0x98) [] (cpsw_rx_mq_poll) from [] (__napi_poll+0x28/0x268) [] (__napi_poll) from [] (net_rx_action+0xcc/0x204) [] (net_rx_action) from [] (__do_softirq+0x140/0x4d0) [] (__do_softirq) from [] (run_ksoftirqd+0x34/0x50) [] (run_ksoftirqd) from [] (smpboot_thread_fn+0xf4/0x1d8) [] (smpboot_thread_fn) from [] (kthread+0x14c/0x174) [] (kthread) from [] (ret_from_fork+0x14/0x38) ... The omap-des and omap-sham drivers appear to have a similar issue. Fix this by using spin_{,un}lock_bh() around device list access in all the probe and remove functions. Signed-off-by: Ben Hutchings Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit fc4073df2968a464a58af8be1240cecf393369ea Author: Damien Le Moal Date: Mon Aug 16 10:44:47 2021 +0900 libata: fix ata_host_start() [ Upstream commit 355a8031dc174450ccad2a61c513ad7222d87a97 ] The loop on entry of ata_host_start() may not initialize host->ops to a non NULL value. The test on the host_stop field of host->ops must then be preceded by a check that host->ops is not NULL. Reported-by: kernel test robot Signed-off-by: Damien Le Moal Reviewed-by: Hannes Reinecke Link: https://lore.kernel.org/r/20210816014456.2191776-3-damien.lemoal@wdc.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit cf619a528e010fb6017a45bf8af275110d62d53b Author: Harald Freudenberger Date: Fri Aug 6 12:02:00 2021 +0200 s390/zcrypt: fix wrong offset index for APKA master key valid state [ Upstream commit 8617bb74006252cb2286008afe7d6575a6425857 ] Tests showed a mismatch between what the CCA tool reports about the APKA master key state and what's displayed by the zcrypt dd in sysfs. After some investigation, we found out that the documentation which was the source for the zcrypt dd implementation lacks the listing of 3 fields. So this patch now moves the evaluation of the APKA master key state to the correct offset. Signed-off-by: Harald Freudenberger Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin commit b4aa00bf8a4dec0f646bec2663f6910fffae6f44 Author: Vineeth Vijayan Date: Sun Apr 25 10:52:38 2021 +0200 s390/cio: add dev_busid sysfs entry for each subchannel [ Upstream commit d3683c055212bf910d4e318f7944910ce10dbee6 ] Introduce dev_busid, which exports the device-id associated with the io-subchannel (and message-subchannel). The dev_busid indicates that of the device which may be physically installed on the corrosponding subchannel. The dev_busid value "none" indicates that the subchannel is not valid, there is no I/O device currently associated with the subchannel. The dev_busid information would be helpful to write device-specific udev-rules associated with the subchannel. The dev_busid interface would be available even when the sch is not bound to any driver or if there is no operational device connected on it. Hence this attribute can be used to write udev-rules which are specific to the device associated with the subchannel. Signed-off-by: Vineeth Vijayan Reviewed-by: Peter Oberparleiter Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin commit d0831db736bb88ea60ac6982f1b5c355d861bd41 Author: Sebastian Krzyszkowiak Date: Mon Aug 16 18:50:14 2021 +0200 power: supply: max17042_battery: fix typo in MAx17042_TOFF [ Upstream commit ed0d0a0506025f06061325cedae1bbebd081620a ] Signed-off-by: Sebastian Krzyszkowiak Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 5d59f38c6ba546caca5e3ae815edd6bea4dae503 Author: Dmitry Osipenko Date: Sat Jul 31 20:38:38 2021 +0300 power: supply: smb347-charger: Add missing pin control activation [ Upstream commit efe2175478d5237949e33c84d9a722fc084b218c ] Pin control needs to be activated by setting the enable bit, otherwise hardware rejects all pin changes. Previously this stayed unnoticed on Nexus 7 because pin control was enabled by default after rebooting from downstream kernel, which uses driver that enables the bit and charger registers are non-volatile until power supply (battery) is disconnected. Configure the pin control enable bit. This fixes the potentially never-enabled charging on devices that use pin control. Signed-off-by: Dmitry Osipenko Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 10e759e350d7c5078cdd6497e410585434d02c22 Author: Amit Engel Date: Sun Aug 8 09:20:14 2021 +0300 nvmet: pass back cntlid on successful completion [ Upstream commit e804d5abe2d74cfe23f5f83be580d1cdc9307111 ] According to the NVMe specification, the response dword 0 value of the Connect command is based on status code: return cntlid for successful compeltion return IPO and IATTR for connect invalid parameters. Fix a missing error information for a zero sized queue, and return the cntlid also for I/O queue Connect commands. Signed-off-by: Amit Engel Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit ea4a353c0ef427b19389a5b4f503f8d89413ed3d Author: Ruozhu Li Date: Wed Jul 28 17:41:20 2021 +0800 nvme-rdma: don't update queue count when failing to set io queues [ Upstream commit 85032874f80ba17bf187de1d14d9603bf3f582b8 ] We update ctrl->queue_count and schedule another reconnect when io queue count is zero.But we will never try to create any io queue in next reco- nnection, because ctrl->queue_count already set to zero.We will end up having an admin-only session in Live state, which is exactly what we try to avoid in the original patch. Update ctrl->queue_count after queue_count zero checking to fix it. Signed-off-by: Ruozhu Li Reviewed-by: Sagi Grimberg Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 5d0f0c3bbe9926e373329a6fe142f5edcf59e102 Author: Ruozhu Li Date: Sat Aug 7 11:50:23 2021 +0800 nvme-tcp: don't update queue count when failing to set io queues [ Upstream commit 664227fde63844d69e9ec9e90a8a7801e6ff072d ] We update ctrl->queue_count and schedule another reconnect when io queue count is zero.But we will never try to create any io queue in next reco- nnection, because ctrl->queue_count already set to zero.We will end up having an admin-only session in Live state, which is exactly what we try to avoid in the original patch. Update ctrl->queue_count after queue_count zero checking to fix it. Signed-off-by: Ruozhu Li Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 591f69d7c415a64f96df6de9a674aaead355de21 Author: Chunguang Xu Date: Mon Aug 2 11:51:56 2021 +0800 blk-throtl: optimize IOPS throttle for large IO scenarios [ Upstream commit 4f1e9630afe6332de7286820fedd019f19eac057 ] After patch 54efd50 (block: make generic_make_request handle arbitrarily sized bios), the IO through io-throttle may be larger, and these IOs may be further split into more small IOs. However, IOPS throttle does not seem to be aware of this change, which makes the calculation of IOPS of large IOs incomplete, resulting in disk-side IOPS that does not meet expectations. Maybe we should fix this problem. We can reproduce it by set max_sectors_kb of disk to 128, set blkio.write_iops_throttle to 100, run a dd instance inside blkio and use iostat to watch IOPS: dd if=/dev/zero of=/dev/sdb bs=1M count=1000 oflag=direct As a result, without this change the average IOPS is 1995, with this change the IOPS is 98. Signed-off-by: Chunguang Xu Acked-by: Tejun Heo Link: https://lore.kernel.org/r/65869aaad05475797d63b4c3fed4f529febe3c26.1627876014.git.brookxu@tencent.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit cf13537be54c6ea49f208668f5f8b8bda3edd28e Author: Christoph Hellwig Date: Mon Aug 9 08:40:26 2021 +0200 bcache: add proper error unwinding in bcache_device_init [ Upstream commit 224b0683228c5f332f9cee615d85e75e9a347170 ] Except for the IDA none of the allocations in bcache_device_init is unwound on error, fix that. Signed-off-by: Christoph Hellwig Acked-by: Coly Li Link: https://lore.kernel.org/r/20210809064028.1198327-7-hch@lst.de Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 48aa6e4e28c4b8d2dd8e5fdbb6ea0c6fd475909f Author: Pali Rohár Date: Sun Aug 8 18:24:37 2021 +0200 isofs: joliet: Fix iocharset=utf8 mount option [ Upstream commit 28ce50f8d96ec9035f60c9348294ea26b94db944 ] Currently iocharset=utf8 mount option is broken. To use UTF-8 as iocharset, it is required to use utf8 mount option. Fix iocharset=utf8 mount option to use be equivalent to the utf8 mount option. If UTF-8 as iocharset is used then s_nls_iocharset is set to NULL. So simplify code around, remove s_utf8 field as to distinguish between UTF-8 and non-UTF-8 it is needed just to check if s_nls_iocharset is set to NULL or not. Link: https://lore.kernel.org/r/20210808162453.1653-5-pali@kernel.org Signed-off-by: Pali Rohár Signed-off-by: Jan Kara Signed-off-by: Sasha Levin commit 940ac461323e6011fe5cdc83b5dce2764eef8780 Author: Pali Rohár Date: Sun Aug 8 18:24:36 2021 +0200 udf: Fix iocharset=utf8 mount option [ Upstream commit b645333443712d2613e4e863f81090d5dc509657 ] Currently iocharset=utf8 mount option is broken. To use UTF-8 as iocharset, it is required to use utf8 mount option. Fix iocharset=utf8 mount option to use be equivalent to the utf8 mount option. If UTF-8 as iocharset is used then s_nls_map is set to NULL. So simplify code around, remove UDF_FLAG_NLS_MAP and UDF_FLAG_UTF8 flags as to distinguish between UTF-8 and non-UTF-8 it is needed just to check if s_nls_map set to NULL or not. Link: https://lore.kernel.org/r/20210808162453.1653-4-pali@kernel.org Signed-off-by: Pali Rohár Signed-off-by: Jan Kara Signed-off-by: Sasha Levin commit 4cf1551af31d1c55d17485de6c973f1479a6b166 Author: Jan Kara Date: Mon May 3 11:39:03 2021 +0200 udf: Check LVID earlier [ Upstream commit 781d2a9a2fc7d0be53a072794dc03ef6de770f3d ] We were checking validity of LVID entries only when getting implementation use information from LVID in udf_sb_lvidiu(). However if the LVID is suitably corrupted, it can cause problems also to code such as udf_count_free() which doesn't use udf_sb_lvidiu(). So check validity of LVID already when loading it from the disk and just disable LVID altogether when it is not valid. Reported-by: syzbot+7fbfe5fed73ebb675748@syzkaller.appspotmail.com Signed-off-by: Jan Kara Signed-off-by: Sasha Levin commit 3d12ccecfa316730abaf0a930711ea5cce4fe87f Author: Thomas Gleixner Date: Tue Jul 13 15:39:48 2021 +0200 hrtimer: Ensure timerfd notification for HIGHRES=n [ Upstream commit 8c3b5e6ec0fee18bc2ce38d1dfe913413205f908 ] If high resolution timers are disabled the timerfd notification about a clock was set event is not happening for all cases which use clock_was_set_delayed() because that's a NOP for HIGHRES=n, which is wrong. Make clock_was_set_delayed() unconditially available to fix that. Signed-off-by: Thomas Gleixner Link: https://lore.kernel.org/r/20210713135158.196661266@linutronix.de Signed-off-by: Sasha Levin commit aadfa1d6ca5f02e7b5177e516b290a3ae38b1c66 Author: Thomas Gleixner Date: Tue Jul 13 15:39:46 2021 +0200 hrtimer: Avoid double reprogramming in __hrtimer_start_range_ns() [ Upstream commit 627ef5ae2df8eeccb20d5af0e4cfa4df9e61ed28 ] If __hrtimer_start_range_ns() is invoked with an already armed hrtimer then the timer has to be canceled first and then added back. If the timer is the first expiring timer then on removal the clockevent device is reprogrammed to the next expiring timer to avoid that the pending expiry fires needlessly. If the new expiry time ends up to be the first expiry again then the clock event device has to reprogrammed again. Avoid this by checking whether the timer is the first to expire and in that case, keep the timer on the current CPU and delay the reprogramming up to the point where the timer has been enqueued again. Reported-by: Lorenzo Colitti Signed-off-by: Thomas Gleixner Link: https://lore.kernel.org/r/20210713135157.873137732@linutronix.de Signed-off-by: Sasha Levin commit 13ccaef77ee86047033c50bf59cb19e0dda3aa97 Author: Frederic Weisbecker Date: Mon Jul 26 14:55:10 2021 +0200 posix-cpu-timers: Force next expiration recalc after itimer reset [ Upstream commit 406dd42bd1ba0c01babf9cde169bb319e52f6147 ] When an itimer deactivates a previously armed expiration, it simply doesn't do anything. As a result the process wide cputime counter keeps running and the tick dependency stays set until it reaches the old ghost expiration value. This can be reproduced with the following snippet: void trigger_process_counter(void) { struct itimerval n = {}; n.it_value.tv_sec = 100; setitimer(ITIMER_VIRTUAL, &n, NULL); n.it_value.tv_sec = 0; setitimer(ITIMER_VIRTUAL, &n, NULL); } Fix this with resetting the relevant base expiration. This is similar to disarming a timer. Signed-off-by: Frederic Weisbecker Signed-off-by: Thomas Gleixner Acked-by: Peter Zijlstra (Intel) Link: https://lore.kernel.org/r/20210726125513.271824-4-frederic@kernel.org Signed-off-by: Sasha Levin commit 8a6c5eec811c1013001c8dc9874bf647b3c4ec36 Author: Smita Koralahalli Date: Mon Jun 28 12:27:40 2021 -0500 EDAC/mce_amd: Do not load edac_mce_amd module on guests [ Upstream commit 767f4b620edadac579c9b8b6660761d4285fa6f9 ] Hypervisors likely do not expose the SMCA feature to the guest and loading this module leads to false warnings. This module should not be loaded in guests to begin with, but people tend to do so, especially when testing kernels in VMs. And then they complain about those false warnings. Do the practical thing and do not load this module when running as a guest to avoid all that complaining. [ bp: Rewrite commit message. ] Suggested-by: Borislav Petkov Signed-off-by: Smita Koralahalli Signed-off-by: Borislav Petkov Reviewed-by: Yazen Ghannam Tested-by: Kim Phillips Link: https://lkml.kernel.org/r/20210628172740.245689-1-Smita.KoralahalliChannabasappa@amd.com Signed-off-by: Sasha Levin commit 4b680b3fc6f319860652532084b35b11d3868008 Author: Sergey Senozhatsky Date: Sat May 22 00:56:23 2021 +0900 rcu/tree: Handle VM stoppage in stall detection [ Upstream commit ccfc9dd6914feaa9a81f10f9cce56eb0f7712264 ] The soft watchdog timer function checks if a virtual machine was suspended and hence what looks like a lockup in fact is a false positive. This is what kvm_check_and_clear_guest_paused() does: it tests guest PVCLOCK_GUEST_STOPPED (which is set by the host) and if it's set then we need to touch all watchdogs and bail out. Watchdog timer function runs from IRQ, so PVCLOCK_GUEST_STOPPED check works fine. There is, however, one more watchdog that runs from IRQ, so watchdog timer fn races with it, and that watchdog is not aware of PVCLOCK_GUEST_STOPPED - RCU stall detector. apic_timer_interrupt() smp_apic_timer_interrupt() hrtimer_interrupt() __hrtimer_run_queues() tick_sched_timer() tick_sched_handle() update_process_times() rcu_sched_clock_irq() This triggers RCU stalls on our devices during VM resume. If tick_sched_handle()->rcu_sched_clock_irq() runs on a VCPU before watchdog_timer_fn()->kvm_check_and_clear_guest_paused() then there is nothing on this VCPU that touches watchdogs and RCU reads stale gp stall timestamp and new jiffies value, which makes it think that RCU has stalled. Make RCU stall watchdog aware of PVCLOCK_GUEST_STOPPED and don't report RCU stalls when we resume the VM. Signed-off-by: Sergey Senozhatsky Signed-off-by: Signed-off-by: Paul E. McKenney Signed-off-by: Sasha Levin commit 1cc05d71f04da3efdc944d6870232ae06455249d Author: Dietmar Eggemann Date: Wed Aug 4 15:59:25 2021 +0200 sched/deadline: Fix missing clock update in migrate_task_rq_dl() [ Upstream commit b4da13aa28d4fd0071247b7b41c579ee8a86c81a ] A missing clock update is causing the following warning: rq->clock_update_flags < RQCF_ACT_SKIP WARNING: CPU: 112 PID: 2041 at kernel/sched/sched.h:1453 sub_running_bw.isra.0+0x190/0x1a0 ... CPU: 112 PID: 2041 Comm: sugov:112 Tainted: G W 5.14.0-rc1 #1 Hardware name: WIWYNN Mt.Jade Server System B81.030Z1.0007/Mt.Jade Motherboard, BIOS 1.6.20210526 (SCP: 1.06.20210526) 2021/05/26 ... Call trace: sub_running_bw.isra.0+0x190/0x1a0 migrate_task_rq_dl+0xf8/0x1e0 set_task_cpu+0xa8/0x1f0 try_to_wake_up+0x150/0x3d4 wake_up_q+0x64/0xc0 __up_write+0xd0/0x1c0 up_write+0x4c/0x2b0 cppc_set_perf+0x120/0x2d0 cppc_cpufreq_set_target+0xe0/0x1a4 [cppc_cpufreq] __cpufreq_driver_target+0x74/0x140 sugov_work+0x64/0x80 kthread_worker_fn+0xe0/0x230 kthread+0x138/0x140 ret_from_fork+0x10/0x18 The task causing this is the `cppc_fie` DL task introduced by commit 1eb5dde674f5 ("cpufreq: CPPC: Add support for frequency invariance"). With CONFIG_ACPI_CPPC_CPUFREQ_FIE=y and schedutil cpufreq governor on slow-switching system (like on this Ampere Altra WIWYNN Mt. Jade Arm Server): DL task `curr=sugov:112` lets `p=cppc_fie` migrate and since the latter is in `non_contending` state, migrate_task_rq_dl() calls sub_running_bw()->__sub_running_bw()->cpufreq_update_util()-> rq_clock()->assert_clock_updated() on p. Fix this by updating the clock for a non_contending task in migrate_task_rq_dl() before calling sub_running_bw(). Reported-by: Bruno Goncalves Signed-off-by: Dietmar Eggemann Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Daniel Bristot de Oliveira Acked-by: Juri Lelli Link: https://lore.kernel.org/r/20210804135925.3734605-1-dietmar.eggemann@arm.com Signed-off-by: Sasha Levin commit 104adbffbe4c62c89f396bb6d37c0c6099b75879 Author: Tony Lindgren Date: Tue Jul 27 13:23:34 2021 +0300 crypto: omap-sham - clear dma flags only after omap_sham_update_dma_stop() [ Upstream commit fe28140b3393b0ba1eb95cc109f974a7e58b26fd ] We should not clear FLAGS_DMA_ACTIVE before omap_sham_update_dma_stop() is done calling dma_unmap_sg(). We already clear FLAGS_DMA_ACTIVE at the end of omap_sham_update_dma_stop(). The early clearing of FLAGS_DMA_ACTIVE is not causing issues as we do not need to defer anything based on FLAGS_DMA_ACTIVE currently. So this can be applied as clean-up. Cc: Lokesh Vutla Cc: Tero Kristo Signed-off-by: Tony Lindgren Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit ce7f2b516c77d1c2bab66635d45f7b534033e5b5 Author: Hans de Goede Date: Sun Aug 1 15:30:59 2021 +0200 power: supply: axp288_fuel_gauge: Report register-address on readb / writeb errors [ Upstream commit caa534c3ba40c6e8352b42cbbbca9ba481814ac8 ] When fuel_gauge_reg_readb()/_writeb() fails, report which register we were trying to read / write when the error happened. Also reword the message a bit: - Drop the axp288 prefix, dev_err() already prints this - Switch from telegram / abbreviated style to a normal sentence, aligning the message with those from fuel_gauge_read_*bit_word() Signed-off-by: Hans de Goede Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 3ebd7b38415e49080c1591b7ca141f87a81bdbe5 Author: Quentin Perret Date: Tue Jul 27 11:11:01 2021 +0100 sched/deadline: Fix reset_on_fork reporting of DL tasks [ Upstream commit f95091536f78971b269ec321b057b8d630b0ad8a ] It is possible for sched_getattr() to incorrectly report the state of the reset_on_fork flag when called on a deadline task. Indeed, if the flag was set on a deadline task using sched_setattr() with flags (SCHED_FLAG_RESET_ON_FORK | SCHED_FLAG_KEEP_PARAMS), then p->sched_reset_on_fork will be set, but __setscheduler() will bail out early, which means that the dl_se->flags will not get updated by __setscheduler_params()->__setparam_dl(). Consequently, if sched_getattr() is then called on the task, __getparam_dl() will override kattr.sched_flags with the now out-of-date copy in dl_se->flags and report the stale value to userspace. To fix this, make sure to only copy the flags that are relevant to sched_deadline to and from the dl_se->flags field. Signed-off-by: Quentin Perret Signed-off-by: Peter Zijlstra (Intel) Link: https://lore.kernel.org/r/20210727101103.2729607-2-qperret@google.com Signed-off-by: Sasha Levin commit 8c4d94db5acd99b5d64d0116fc12276266ee5be0 Author: Sean Anderson Date: Thu Jul 1 14:56:37 2021 -0400 crypto: mxs-dcp - Check for DMA mapping errors [ Upstream commit df6313d707e575a679ada3313358289af24454c0 ] After calling dma_map_single(), we must also call dma_mapping_error(). This fixes the following warning when compiling with CONFIG_DMA_API_DEBUG: [ 311.241478] WARNING: CPU: 0 PID: 428 at kernel/dma/debug.c:1027 check_unmap+0x79c/0x96c [ 311.249547] DMA-API: mxs-dcp 2280000.crypto: device driver failed to check map error[device address=0x00000000860cb080] [size=32 bytes] [mapped as single] Signed-off-by: Sean Anderson Reviewed-by: Richard Weinberger Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 7bb6302e9d0966d9467785e8cc4d3baa0321168d Author: Dmitry Osipenko Date: Mon Jul 5 23:12:11 2021 +0300 regulator: tps65910: Silence deferred probe error [ Upstream commit e301df76472cc929fa62d923bc3892931f7ad71d ] The TPS65910 regulator now gets a deferred probe until supply regulator is registered. Silence noisy error message about the deferred probe. Reported-by: Matt Merhar # Ouya T30 Tested-by: Matt Merhar # Ouya T30 Signed-off-by: Dmitry Osipenko Link: https://lore.kernel.org/r/20210705201211.16082-1-digetx@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit a85985099644700f365743986eb7f24f83c7cad6 Author: Jeongtae Park Date: Thu Jul 1 23:26:30 2021 +0900 regmap: fix the offset of register error log [ Upstream commit 1852f5ed358147095297a09cc3c6f160208a676d ] This patch fixes the offset of register error log by using regmap_get_offset(). Signed-off-by: Jeongtae Park Link: https://lore.kernel.org/r/20210701142630.44936-1-jeongtae.park@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 97bc540bfb61aa75af5eb60436763991067c8cf6 Author: Peter Zijlstra Date: Wed Jun 30 17:35:18 2021 +0200 locking/mutex: Fix HANDOFF condition [ Upstream commit 048661a1f963e9517630f080687d48af79ed784c ] Yanfei reported that setting HANDOFF should not depend on recomputing @first, only on @first state. Which would then give: if (ww_ctx || !first) first = __mutex_waiter_is_first(lock, &waiter); if (first) __mutex_set_flag(lock, MUTEX_FLAG_HANDOFF); But because 'ww_ctx || !first' is basically 'always' and the test for first is relatively cheap, omit that first branch entirely. Reported-by: Yanfei Xu Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Waiman Long Reviewed-by: Yanfei Xu Link: https://lore.kernel.org/r/20210630154114.896786297@infradead.org Signed-off-by: Sasha Levin