aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2021-10-19ALSA: usb-audio: Fix microphone sound on Jieli webcam.Marco Giunta2-0/+14
When a Jieli Technology USB Webcam is connected, the video part works well, but the mic sound is speeded up. On dmesg there are messages about different rates from the runtime rates, warnings about volume resolution and lastly, the log is filled, every 5 seconds, with retire_capture_urb error messages. The mic works only when ep packet size is set to wMaxPacketSize (normal sound and no more retire_capture_urb error messages). Skipping reading sample rate, fixes the messages about different rates and forcing a volume resolution, fixes warnings about volume range. I have arbitrarily choosed the value (16): I read in a comment that there should be no more than 255 levels, so 4096 (max volume) / 16 = 0-255. Signed-off-by: Marco Giunta <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]>
2021-10-18audit: fix possible null-pointer dereference in audit_filter_rulesGaosheng Cui1-1/+1
Fix possible null-pointer dereference in audit_filter_rules. audit_filter_rules() error: we previously assumed 'ctx' could be null Cc: [email protected] Fixes: bf361231c295 ("audit: add saddr_fam filter field") Reported-by: kernel test robot <[email protected]> Reported-by: Dan Carpenter <[email protected]> Signed-off-by: Gaosheng Cui <[email protected]> Signed-off-by: Paul Moore <[email protected]>
2021-10-18tracing: Have all levels of checks prevent recursionSteven Rostedt (VMware)2-42/+11
While writing an email explaining the "bit = 0" logic for a discussion on making ftrace_test_recursion_trylock() disable preemption, I discovered a path that makes the "not do the logic if bit is zero" unsafe. The recursion logic is done in hot paths like the function tracer. Thus, any code executed causes noticeable overhead. Thus, tricks are done to try to limit the amount of code executed. This included the recursion testing logic. Having recursion testing is important, as there are many paths that can end up in an infinite recursion cycle when tracing every function in the kernel. Thus protection is needed to prevent that from happening. Because it is OK to recurse due to different running context levels (e.g. an interrupt preempts a trace, and then a trace occurs in the interrupt handler), a set of bits are used to know which context one is in (normal, softirq, irq and NMI). If a recursion occurs in the same level, it is prevented*. Then there are infrastructure levels of recursion as well. When more than one callback is attached to the same function to trace, it calls a loop function to iterate over all the callbacks. Both the callbacks and the loop function have recursion protection. The callbacks use the "ftrace_test_recursion_trylock()" which has a "function" set of context bits to test, and the loop function calls the internal trace_test_and_set_recursion() directly, with an "internal" set of bits. If an architecture does not implement all the features supported by ftrace then the callbacks are never called directly, and the loop function is called instead, which will implement the features of ftrace. Since both the loop function and the callbacks do recursion protection, it was seemed unnecessary to do it in both locations. Thus, a trick was made to have the internal set of recursion bits at a more significant bit location than the function bits. Then, if any of the higher bits were set, the logic of the function bits could be skipped, as any new recursion would first have to go through the loop function. This is true for architectures that do not support all the ftrace features, because all functions being traced must first go through the loop function before going to the callbacks. But this is not true for architectures that support all the ftrace features. That's because the loop function could be called due to two callbacks attached to the same function, but then a recursion function inside the callback could be called that does not share any other callback, and it will be called directly. i.e. traced_function_1: [ more than one callback tracing it ] call loop_func loop_func: trace_recursion set internal bit call callback callback: trace_recursion [ skipped because internal bit is set, return 0 ] call traced_function_2 traced_function_2: [ only traced by above callback ] call callback callback: trace_recursion [ skipped because internal bit is set, return 0 ] call traced_function_2 [ wash, rinse, repeat, BOOM! out of shampoo! ] Thus, the "bit == 0 skip" trick is not safe, unless the loop function is call for all functions. Since we want to encourage architectures to implement all ftrace features, having them slow down due to this extra logic may encourage the maintainers to update to the latest ftrace features. And because this logic is only safe for them, remove it completely. [*] There is on layer of recursion that is allowed, and that is to allow for the transition between interrupt context (normal -> softirq -> irq -> NMI), because a trace may occur before the context update is visible to the trace recursion logic. Link: https://lore.kernel.org/all/[email protected]/ Link: https://lkml.kernel.org/r/[email protected] Cc: Linus Torvalds <[email protected]> Cc: Petr Mladek <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: "James E.J. Bottomley" <[email protected]> Cc: Helge Deller <[email protected]> Cc: Michael Ellerman <[email protected]> Cc: Benjamin Herrenschmidt <[email protected]> Cc: Paul Mackerras <[email protected]> Cc: Paul Walmsley <[email protected]> Cc: Palmer Dabbelt <[email protected]> Cc: Albert Ou <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: "H. Peter Anvin" <[email protected]> Cc: Josh Poimboeuf <[email protected]> Cc: Jiri Kosina <[email protected]> Cc: Miroslav Benes <[email protected]> Cc: Joe Lawrence <[email protected]> Cc: Colin Ian King <[email protected]> Cc: Masami Hiramatsu <[email protected]> Cc: "Peter Zijlstra (Intel)" <[email protected]> Cc: Nicholas Piggin <[email protected]> Cc: Jisheng Zhang <[email protected]> Cc: =?utf-8?b?546L6LSH?= <[email protected]> Cc: Guo Ren <[email protected]> Cc: [email protected] Fixes: edc15cafcbfa3 ("tracing: Avoid unnecessary multiple recursion checks") Signed-off-by: Steven Rostedt (VMware) <[email protected]>
2021-10-18nfp: bpf: silence bitwise vs. logical OR warningNathan Chancellor1-2/+2
A new warning in clang points out two places in this driver where boolean expressions are being used with a bitwise OR instead of a logical one: drivers/net/ethernet/netronome/nfp/nfp_asm.c:199:20: error: use of bitwise '|' with boolean operands [-Werror,-Wbitwise-instead-of-logical] reg->src_lmextn = swreg_lmextn(lreg) | swreg_lmextn(rreg); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ || drivers/net/ethernet/netronome/nfp/nfp_asm.c:199:20: note: cast one or both operands to int to silence this warning drivers/net/ethernet/netronome/nfp/nfp_asm.c:280:20: error: use of bitwise '|' with boolean operands [-Werror,-Wbitwise-instead-of-logical] reg->src_lmextn = swreg_lmextn(lreg) | swreg_lmextn(rreg); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ || drivers/net/ethernet/netronome/nfp/nfp_asm.c:280:20: note: cast one or both operands to int to silence this warning 2 errors generated. The motivation for the warning is that logical operations short circuit while bitwise operations do not. In this case, it does not seem like short circuiting is harmful so implement the suggested fix of changing to a logical operation to fix the warning. Link: https://github.com/ClangBuiltLinux/linux/issues/1479 Reported-by: Nick Desaulniers <[email protected]> Signed-off-by: Nathan Chancellor <[email protected]> Reviewed-by: Nick Desaulniers <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2021-10-18drm/msm/devfreq: Restrict idle clamping to a618 for nowRob Clark3-1/+13
Until we better understand the stability issues caused by frequent frequency changes, lets limit them to a618. Signed-off-by: Rob Clark <[email protected]> Tested-by: John Stultz <[email protected]> Tested-by: Caleb Connolly <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Rob Clark <[email protected]>
2021-10-18ucounts: Fix signal ucount refcountingEric W. Biederman3-19/+57
In commit fda31c50292a ("signal: avoid double atomic counter increments for user accounting") Linus made a clever optimization to how rlimits and the struct user_struct. Unfortunately that optimization does not work in the obvious way when moved to nested rlimits. The problem is that the last decrement of the per user namespace per user sigpending counter might also be the last decrement of the sigpending counter in the parent user namespace as well. Which means that simply freeing the leaf ucount in __free_sigqueue is not enough. Maintain the optimization and handle the tricky cases by introducing inc_rlimit_get_ucounts and dec_rlimit_put_ucounts. By moving the entire optimization into functions that perform all of the work it becomes possible to ensure that every level is handled properly. The new function inc_rlimit_get_ucounts returns 0 on failure to increment the ucount. This is different than inc_rlimit_ucounts which increments the ucounts and returns LONG_MAX if the ucount counter has exceeded it's maximum or it wrapped (to indicate the counter needs to decremented). I wish we had a single user to account all pending signals to across all of the threads of a process so this complexity was not necessary Cc: [email protected] Fixes: d64696905554 ("Reimplement RLIMIT_SIGPENDING on top of ucounts") v1: https://lkml.kernel.org/r/87mtnavszx.fsf_-_@disp2133 Link: https://lkml.kernel.org/r/87fssytizw.fsf_-_@disp2133 Reviewed-by: Alexey Gladkov <[email protected]> Tested-by: Rune Kleveland <[email protected]> Tested-by: Yu Zhao <[email protected]> Tested-by: Jordan Glover <[email protected]> Signed-off-by: "Eric W. Biederman" <[email protected]>
2021-10-18KVM: SEV-ES: reduce ghcb_sa_len to 32 bitsPaolo Bonzini1-1/+1
The size of the GHCB scratch area is limited to 16 KiB (GHCB_SCRATCH_AREA_LIMIT), so there is no need for it to be a u64. This fixes a build error on 32-bit systems: i686-linux-gnu-ld: arch/x86/kvm/svm/sev.o: in function `sev_es_string_io: sev.c:(.text+0x110f): undefined reference to `__udivdi3' Cc: [email protected] Fixes: 019057bd73d1 ("KVM: SEV-ES: fix length of string I/O") Reported-by: Naresh Kamboju <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
2021-10-18KVM: VMX: Remove redundant handling of bus lock vmexitHao Xiang1-6/+9
Hardware may or may not set exit_reason.bus_lock_detected on BUS_LOCK VM-Exits. Dealing with KVM_RUN_X86_BUS_LOCK in handle_bus_lock_vmexit could be redundant when exit_reason.basic is EXIT_REASON_BUS_LOCK. We can remove redundant handling of bus lock vmexit. Unconditionally Set exit_reason.bus_lock_detected in handle_bus_lock_vmexit(), and deal with KVM_RUN_X86_BUS_LOCK only in vmx_handle_exit(). Signed-off-by: Hao Xiang <[email protected]> Message-Id: <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
2021-10-18KVM: kvm_stat: do not show halt_wait_nsChristian Borntraeger1-1/+1
Similar to commit 111d0bda8eeb ("tools/kvm_stat: Exempt time-based counters"), we should not show timer values in kvm_stat. Remove the new halt_wait_ns. Fixes: 87bcc5fa092f ("KVM: stats: Add halt_wait_ns stats for all architectures") Cc: Jing Zhang <[email protected]> Cc: Stefan Raspl <[email protected]> Signed-off-by: Christian Borntraeger <[email protected]> Reviewed-by: Stefan Raspl <[email protected]> Message-Id: <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
2021-10-18KVM: x86: WARN if APIC HW/SW disable static keys are non-zero on unloadSean Christopherson1-0/+2
WARN if the static keys used to track if any vCPU has disabled its APIC are left elevated at module exit. Unlike the underflow case, nothing in the static key infrastructure will complain if a key is left elevated, and because an elevated key only affects performance, nothing in KVM will fail if either key is improperly incremented. Signed-off-by: Sean Christopherson <[email protected]> Message-Id: <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
2021-10-18Revert "KVM: x86: Open code necessary bits of kvm_lapic_set_base() at vCPU ↵Sean Christopherson1-7/+11
RESET" Revert a change to open code bits of kvm_lapic_set_base() when emulating APIC RESET to fix an apic_hw_disabled underflow bug due to arch.apic_base and apic_hw_disabled being unsyncrhonized when the APIC is created. If kvm_arch_vcpu_create() fails after creating the APIC, kvm_free_lapic() will see the initialized-to-zero vcpu->arch.apic_base and decrement apic_hw_disabled without KVM ever having incremented apic_hw_disabled. Using kvm_lapic_set_base() in kvm_lapic_reset() is also desirable for a potential future where KVM supports RESET outside of vCPU creation, in which case all the side effects of kvm_lapic_set_base() are needed, e.g. to handle the transition from x2APIC => xAPIC. Alternatively, KVM could temporarily increment apic_hw_disabled (and call kvm_lapic_set_base() at RESET), but that's a waste of cycles and would impact the performance of other vCPUs and VMs. The other subtle side effect is that updating the xAPIC ID needs to be done at RESET regardless of whether the APIC was previously enabled, i.e. kvm_lapic_reset() needs an explicit call to kvm_apic_set_xapic_id() regardless of whether or not kvm_lapic_set_base() also performs the update. That makes stuffing the enable bit at vCPU creation slightly more palatable, as doing so affects only the apic_hw_disabled key. Opportunistically tweak the comment to explicitly call out the connection between vcpu->arch.apic_base and apic_hw_disabled, and add a comment to call out the need to always do kvm_apic_set_xapic_id() at RESET. Underflow scenario: kvm_vm_ioctl() { kvm_vm_ioctl_create_vcpu() { kvm_arch_vcpu_create() { if (something_went_wrong) goto fail_free_lapic; /* vcpu->arch.apic_base is initialized when something_went_wrong is false. */ kvm_vcpu_reset() { kvm_lapic_reset(struct kvm_vcpu *vcpu, bool init_event) { vcpu->arch.apic_base = APIC_DEFAULT_PHYS_BASE | MSR_IA32_APICBASE_ENABLE; } } return 0; fail_free_lapic: kvm_free_lapic() { /* vcpu->arch.apic_base is not yet initialized when something_went_wrong is true. */ if (!(vcpu->arch.apic_base & MSR_IA32_APICBASE_ENABLE)) static_branch_slow_dec_deferred(&apic_hw_disabled); // <= underflow bug. } return r; } } } This (mostly) reverts commit 421221234ada41b4a9f0beeb08e30b07388bd4bd. Fixes: 421221234ada ("KVM: x86: Open code necessary bits of kvm_lapic_set_base() at vCPU RESET") Reported-by: [email protected] Debugged-by: Tetsuo Handa <[email protected]> Signed-off-by: Sean Christopherson <[email protected]> Message-Id: <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
2021-10-18KVM: SEV-ES: Set guest_state_protected after VMSA updatePeter Gonda1-1/+6
The refactoring in commit bb18a6777465 ("KVM: SEV: Acquire vcpu mutex when updating VMSA") left behind the assignment to svm->vcpu.arch.guest_state_protected; add it back. Signed-off-by: Peter Gonda <[email protected]> [Delta between v2 and v3 of Peter's patch, which had already been committed; the commit message is my own. - Paolo] Fixes: bb18a6777465 ("KVM: SEV: Acquire vcpu mutex when updating VMSA") Signed-off-by: Paolo Bonzini <[email protected]>
2021-10-18KVM: X86: fix lazy allocation of rmapsPaolo Bonzini1-1/+2
If allocation of rmaps fails, but some of the pointers have already been written, those pointers can be cleaned up when the memslot is freed, or even reused later for another attempt at allocating the rmaps. Therefore there is no need to WARN, as done for example in memslot_rmap_alloc, but the allocation *must* be skipped lest KVM will overwrite the previous pointer and will indeed leak memory. Signed-off-by: Paolo Bonzini <[email protected]>
2021-10-18NIOS2: irqflags: rename a redefined register nameRandy Dunlap2-3/+3
Both arch/nios2/ and drivers/mmc/host/tmio_mmc.c define a macro with the name "CTL_STATUS". Change the one in arch/nios2/ to be "CTL_FSTATUS" (flags status) to eliminate the build warning. In file included from ../drivers/mmc/host/tmio_mmc.c:22: drivers/mmc/host/tmio_mmc.h:31: warning: "CTL_STATUS" redefined 31 | #define CTL_STATUS 0x1c arch/nios2/include/asm/registers.h:14: note: this is the location of the previous definition 14 | #define CTL_STATUS 0 Fixes: b31ebd8055ea ("nios2: Nios2 registers") Signed-off-by: Randy Dunlap <[email protected]> Cc: Dinh Nguyen <[email protected]> Signed-off-by: Dinh Nguyen <[email protected]>
2021-10-18selftests/tls: add SM4 algorithm dependency for tls selftestsTianjia Zhang1-0/+1
Kernel TLS test has added SM4 GCM/CCM algorithm support, but SM4 algorithm is not compiled by default, this patch add SM4 config dependency. Reported-by: Hangbin Liu <[email protected]> Reported-by: kernel test robot <[email protected]> Signed-off-by: Tianjia Zhang <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2021-10-18mctp: Be explicit about struct sockaddr_mctp paddingJeremy Kerr1-0/+2
We currently have some implicit padding in struct sockaddr_mctp. This patch makes this padding explicit, and ensures we have consistent layout on platforms with <32bit alignmnent. Fixes: 60fc63981693 ("mctp: Add sockaddr_mctp to uapi") Signed-off-by: Jeremy Kerr <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2021-10-18mctp: unify sockaddr_mctp typesJeremy Kerr3-8/+9
Use the more precise __kernel_sa_family_t for smctp_family, to match struct sockaddr. Also, use an unsigned int for the network member; negative networks don't make much sense. We're already using unsigned for mctp_dev and mctp_skb_cb, but need to change mctp_sock to suit. Fixes: 60fc63981693 ("mctp: Add sockaddr_mctp to uapi") Signed-off-by: Jeremy Kerr <[email protected]> Acked-by: Eugene Syromiatnikov <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2021-10-18cavium: Return negative value when pci_alloc_irq_vectors() failsZheyu Ma1-1/+1
During the process of driver probing, the probe function should return < 0 for failure, otherwise, the kernel will treat value > 0 as success. Signed-off-by: Zheyu Ma <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2021-10-18net: mscc: ocelot: Add of_node_put() before gotoWan Jiabing1-0/+1
Fix following coccicheck warning: ./drivers/net/ethernet/mscc/ocelot_vsc7514.c:946:1-33: WARNING: Function for_each_available_child_of_node should have of_node_put() before goto. Early exits from for_each_available_child_of_node should decrement the node reference counter. Signed-off-by: Wan Jiabing <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2021-10-18net: sparx5: Add of_node_put() before gotoWan Jiabing1-0/+1
Fix following coccicheck warning: ./drivers/net/ethernet/microchip/sparx5/s4parx5_main.c:723:1-33: WARNING: Function for_each_available_child_of_node should have of_node_put() before goto Early exits from for_each_available_child_of_node should decrement the node reference counter. Signed-off-by: Wan Jiabing <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2021-10-18net/sched: act_ct: Fix byte count on fragmented packetsPaul Blakey1-1/+1
First fragmented packets (frag offset = 0) byte len is zeroed when stolen by ip_defrag(). And since act_ct update the stats only afterwards (at end of execute), bytes aren't correctly accounted for such packets. To fix this, move stats update to start of action execute. Fixes: b57dc7c13ea9 ("net/sched: Introduce action ct") Signed-off-by: Paul Blakey <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2021-10-18net: dsa: mt7530: correct ds->num_portsDENG Qingfang1-7/+1
Setting ds->num_ports to DSA_MAX_PORTS made DSA core allocate unnecessary dsa_port's and call mt7530_port_disable for non-existent ports. Set it to MT7530_NUM_PORTS to fix that, and dsa_is_user_port check in port_enable/disable is no longer required. Cc: [email protected] Signed-off-by: DENG Qingfang <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2021-10-18net: dsa: lantiq_gswip: fix register definitionAleksander Jan Bajkowski1-1/+1
I compared the register definitions with the D-Link DWR-966 GPL sources and found that the PUAFD field definition was incorrect. This definition is unused and causes no issues. Fixes: 14fceff4771e ("net: dsa: Add Lantiq / Intel DSA driver for vrx200") Signed-off-by: Aleksander Jan Bajkowski <[email protected]> Acked-by: Hauke Mehrtens <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2021-10-18Merge tag 'linux-can-fixes-for-5.15-20211017' of ↵David S. Miller8-42/+79
git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can Marc Kleine-Budde says: ==================== pull-request: can 2021-10-17 this is a pull request of 11 patches for net/master. The first 4 patches are by Ziyang Xuan and Zhang Changzhong and fix 1 use after free and 3 standard conformance problems in the j1939 CAN stack. The next 2 patches are by Ziyang Xuan and fix 2 concurrency problems in the ISOTP CAN stack. Yoshihiro Shimoda's patch for the rcar_can fix suspend/resume on not running CAN interfaces. Aswath Govindraju's patch for the m_can driver fixes access for MMIO devices. Zheyu Ma contributes a patch for the peak_pci driver to fix a use after free. Stephane Grosjean's 2 patches fix CAN error state handling in the peak_usb driver. ==================== Signed-off-by: David S. Miller <[email protected]>
2021-10-18hamradio: baycom_epp: fix build for UMLRandy Dunlap1-3/+3
On i386, the baycom_epp driver wants to inspect X86 CPU features (TSC) and then act on that data, but that info is not available when running on UML, so prevent that test and do the default action. Prevents this build error on UML + i386: ../drivers/net/hamradio/baycom_epp.c: In function ‘epp_bh’: ../drivers/net/hamradio/baycom_epp.c:630:6: error: implicit declaration of function ‘boot_cpu_has’; did you mean ‘get_cpu_mask’? [-Werror=implicit-function-declaration] if (boot_cpu_has(X86_FEATURE_TSC)) \ ^ ../drivers/net/hamradio/baycom_epp.c:658:2: note: in expansion of macro ‘GETTICK’ GETTICK(time1); Fixes: 68f5d3f3b654 ("um: add PCI over virtio emulation driver") Signed-off-by: Randy Dunlap <[email protected]> Cc: [email protected] Cc: Jeff Dike <[email protected]> Cc: Richard Weinberger <[email protected]> Cc: Anton Ivanov <[email protected]> Cc: "David S. Miller" <[email protected]> Cc: Jakub Kicinski <[email protected]> Cc: Thomas Sailer <[email protected]> Cc: [email protected] Signed-off-by: David S. Miller <[email protected]>
2021-10-18dma-debug: teach add_dma_entry() about DMA_ATTR_SKIP_CPU_SYNCHamza Mahfooz3-24/+36
Mapping something twice should be possible as long as, DMA_ATTR_SKIP_CPU_SYNC is passed to the strictly speaking second relevant mapping operation (that attempts to map the same thing). So, don't issue a warning if the specified condition is met in add_dma_entry(). Signed-off-by: Hamza Mahfooz <[email protected]> Signed-off-by: Christoph Hellwig <[email protected]>
2021-10-17Linux 5.15-rc6Linus Torvalds1-1/+1
2021-10-17Merge tag 'libata-5.15-rc6' of ↵Linus Torvalds2-6/+5
git://git.kernel.org/pub/scm/linux/kernel/git/dlemoal/libata Pull libata fixes from Damien Le Moal: "Two fixes for this cycle: - Fix a null pointer dereference in ahci-platform driver (from Hai) - Fix uninitialized variables in pata_legacy driver (from Dan)" * tag 'libata-5.15-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/dlemoal/libata: ata: ahci_platform: fix null-ptr-deref in ahci_platform_enable_regulators() pata_legacy: fix a couple uninitialized variable bugs
2021-10-17Merge tag 'block-5.15-2021-10-17' of git://git.kernel.dk/linux-blockLinus Torvalds13-120/+171
Pull block fixes from Jens Axboe: "Bigger than usual for this point in time, the majority is fixing some issues around BDI lifetimes with the move from the request_queue to the disk in this release. In detail: - Series on draining fs IO for del_gendisk() (Christoph) - NVMe pull request via Christoph: - fix the abort command id (Keith Busch) - nvme: fix per-namespace chardev deletion (Adam Manzanares) - brd locking scope fix (Tetsuo) - BFQ fix (Paolo)" * tag 'block-5.15-2021-10-17' of git://git.kernel.dk/linux-block: block, bfq: reset last_bfqq_created on group change block: warn when putting the final reference on a registered disk brd: reduce the brd_devices_mutex scope kyber: avoid q->disk dereferences in trace points block: keep q_usage_counter in atomic mode after del_gendisk block: drain file system I/O on del_gendisk block: split bio_queue_enter from blk_queue_enter block: factor out a blk_try_enter_queue helper block: call submit_bio_checks under q_usage_counter nvme: fix per-namespace chardev deletion block/rnbd-clt-sysfs: fix a couple uninitialized variable bugs nvme-pci: Fix abort command id
2021-10-17Merge tag 'io_uring-5.15-2021-10-17' of git://git.kernel.dk/linux-blockLinus Torvalds1-1/+1
Pull io_uring fix from Jens Axboe: "Just a single fix for a wrong condition for grabbing a lock, a regression in this merge window" * tag 'io_uring-5.15-2021-10-17' of git://git.kernel.dk/linux-block: io_uring: fix wrong condition to grab uring lock
2021-10-17Merge tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhostLinus Torvalds4-37/+23
Pull virtio fixes from Michael Tsirkin: "Fixes up some issues in rc5" * tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost: vhost-vdpa: Fix the wrong input in config_cb VDUSE: fix documentation underline warning Revert "virtio-blk: Add validation for block size in config space" vhost_vdpa: unset vq irq before freeing irq virtio: write back F_VERSION_1 before validate
2021-10-17Merge tag 'powerpc-5.15-4' of ↵Linus Torvalds2-12/+19
git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux Pull powerpc fixes from Michael Ellerman: - Fix a bug where guests on P9 with interrupts passed through could get stuck in synchronize_irq(). - Fix a bug in KVM on P8 where secondary threads entering a guest would write outside their allocated stack. - Fix a bug in KVM on P8 where secondary threads could confuse the host offline code and cause the guest or host to crash. Thanks to Cédric Le Goater. * tag 'powerpc-5.15-4' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux: KVM: PPC: Book3S HV: Make idle_kvm_start_guest() return 0 if it went to guest KVM: PPC: Book3S HV: Fix stack handling in idle_kvm_start_guest() powerpc/xive: Discard disabled interrupts in get_irqchip_state()
2021-10-17Merge tag 'objtool_urgent_for_v5.15_rc6' of ↵Linus Torvalds1-31/+25
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull objtool fixes from Borislav Petkov: - Update section headers before the respective relocations to not trigger a safety check in elftoolchain's implementation of libelf - Do not add garbage data to the .rela.orc_unwind_ip section * tag 'objtool_urgent_for_v5.15_rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: objtool: Update section header before relocations objtool: Check for gelf_update_rel[a] failures
2021-10-17Merge tag 'edac_urgent_for_v5.15_rc6' of ↵Linus Torvalds1-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras Pull EDAC fix from Borislav Petkov: - Log the "correct" uncorrectable error count in the armada_xp driver * tag 'edac_urgent_for_v5.15_rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras: EDAC/armada-xp: Fix output of uncorrectable error counter
2021-10-17Merge tag 'perf_urgent_for_v5.15_rc6' of ↵Linus Torvalds1-0/+1
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull perf fix from Borislav Petkov: - Add Sapphire Rapids to the list of CPUs supporting the SMI count MSR * tag 'perf_urgent_for_v5.15_rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: perf/x86/msr: Add Sapphire Rapids CPU support
2021-10-17Merge tag 'efi-urgent-for-v5.15' of ↵Linus Torvalds3-4/+4
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull EFI fixes from Borislav Petkov: "Forwarded from Ard Biesheuvel through the tip tree. Ard will send stuff directly in the near future. Low priority fixes but fixes nonetheless: - update stub diagnostic print that is no longer accurate - avoid statically allocated buffer for CPER error record decoding - avoid sleeping on the efi_runtime semaphore when calling the ResetSystem EFI runtime service" * tag 'efi-urgent-for-v5.15' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: efi: Change down_interruptible() in virt_efi_reset_system() to down_trylock() efi/cper: use stack buffer for error record decoding efi/libstub: Simplify "Exiting bootservices" message
2021-10-17Merge tag 'x86_urgent_for_v5.15_rc6' of ↵Linus Torvalds2-2/+1
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 fixes from Borislav Petkov: - Do not enable AMD memory encryption in Kconfig by default due to shortcomings of some platforms, leading to boot failures. - Mask out invalid bits in the MXCSR for 32-bit kernels again because Thomas and I don't know how to mask out bits properly. Third time's the charm. * tag 'x86_urgent_for_v5.15_rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/fpu: Mask out the invalid MXCSR bits properly x86/Kconfig: Do not enable AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT automatically
2021-10-17Merge tag 'driver-core-5.15-rc6' of ↵Linus Torvalds11-24/+50
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core Pull driver core fixes from Greg KH: "Here are some small driver core fixes for 5.15-rc6, all of which have been in linux-next for a while with no reported issues. They include: - kernfs negative dentry bugfix - simple pm bus fixes to resolve reported issues" * tag 'driver-core-5.15-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: drivers: bus: Delete CONFIG_SIMPLE_PM_BUS drivers: bus: simple-pm-bus: Add support for probing simple bus only devices driver core: Reject pointless SYNC_STATE_ONLY device links kernfs: don't create a negative dentry if inactive node exists
2021-10-17Merge tag 'char-misc-5.15-rc6' of ↵Linus Torvalds14-25/+73
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc Pull char/misc driver fixes from Greg KH: "Here are some small char/misc driver fixes for 5.15-rc6 for reported issues that include: - habanalabs driver fixes - mei driver fixes and new ids - fpga new device ids - MAINTAINER file updates for fpga subsystem - spi module id table additions and fixes - fastrpc locking fixes - nvmem driver fix All of these have been in linux-next for a while with no reported issues" * tag 'char-misc-5.15-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: eeprom: 93xx46: fix MODULE_DEVICE_TABLE nvmem: Fix shift-out-of-bound (UBSAN) with byte size cells mei: hbm: drop hbm responses on early shutdown mei: me: add Ice Lake-N device id. eeprom: 93xx46: Add SPI device ID table eeprom: at25: Add SPI ID table misc: HI6421V600_IRQ should depend on HAS_IOMEM misc: fastrpc: Add missing lock before accessing find_vma() cb710: avoid NULL pointer subtraction misc: gehc: Add SPI ID table MAINTAINERS: Drop outdated FPGA Manager website MAINTAINERS: Add Hao and Yilun as maintainers habanalabs: fix resetting args in wait for CS IOCTL fpga: ice40-spi: Add SPI device ID table
2021-10-17Merge tag 'staging-5.15-rc6' of ↵Linus Torvalds16-18/+52
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging Pull staging and IIO driver fixes from Greg KH: "Here are a number of small IIO and staging driver fixes for 5.15-rc6. They include: - vc04_services bugfix for reported problem - r8188eu array underflow fix - iio driver fixes for a lot of tiny reported issues. All of these have been in linux-next for a while with no reported issues" * tag 'staging-5.15-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging: staging: r8188eu: prevent array underflow in rtw_hal_update_ra_mask() staging: vc04_services: shut up out-of-range warning iio: light: opt3001: Fixed timeout error when 0 lux iio: adis16480: fix devices that do not support sleep mode iio: mtk-auxadc: fix case IIO_CHAN_INFO_PROCESSED iio: adis16475: fix deadlock on frequency set iio: ssp_sensors: add more range checking in ssp_parse_dataframe() iio: ssp_sensors: fix error code in ssp_print_mcu_debug() iio: adc: ad7793: Fix IRQ flag iio: adc: ad7780: Fix IRQ flag iio: adc: ad7192: Add IRQ flag iio: adc: aspeed: set driver data when adc probe. iio: adc: rzg2l_adc: add missing clk_disable_unprepare() in rzg2l_adc_pm_runtime_resume() iio: adc: max1027: Fix the number of max1X31 channels iio: adc: max1027: Fix wrong shift with 12-bit devices iio: adc128s052: Fix the error handling path of 'adc128_probe()' iio: adc: rzg2l_adc: Fix -EBUSY timeout error return iio: accel: fxls8962af: return IRQ_HANDLED when fifo is flushed iio: dac: ti-dac5571: fix an error code in probe()
2021-10-17Merge tag 'tty-5.15-rc6' of ↵Linus Torvalds1-2/+6
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty Pull serial driver fix from Greg KH: "Here is a single 8250 Kconfig fix for 5.15-rc6 that resolves a regression that showed up in 5.15-rc1. It has been in linux-next for a while with no reported issues" * tag 'tty-5.15-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty: serial: 8250: allow disabling of Freescale 16550 compile test
2021-10-17Merge tag 'usb-5.15-rc6' of ↵Linus Torvalds8-22/+70
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb Pull USB fixes from Greg KH: "Here are some small USB fixes that resolve a number of tiny issues. They include: - new USB serial driver ids - xhci driver fixes for a bunch of issues - musb error path fixes. All of these have been in linux-next for a while with no reported issues" * tag 'usb-5.15-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: usb: musb: dsps: Fix the probe error path xhci: Enable trust tx length quirk for Fresco FL11 USB controller xhci: Fix command ring pointer corruption while aborting a command USB: xhci: dbc: fix tty registration race xhci: add quirk for host controllers that don't update endpoint DCS xhci: guard accesses to ep_state in xhci_endpoint_reset() USB: serial: qcserial: add EM9191 QDL support USB: serial: option: add Quectel EC200S-CN module support USB: serial: option: add prod. id for Quectel EG91 USB: serial: option: add Telit LE910Cx composition 0x1204
2021-10-17Merge branch 'for-linus' of ↵Linus Torvalds4-34/+68
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input Pull input fixes from Dmitry Torokhov: - a new product ID for the xpad joystick driver - fixes to resistive-adc-touch and snvs_pwrkey drivers - a change to touchscreen helpers to make clang happier * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input: Input: touchscreen - avoid bitwise vs logical OR warning Input: xpad - add support for another USB ID of Nacon GC-100 Input: resistive-adc-touch - fix division by zero error on z1 == 0 Input: snvs_pwrkey - add clk handling
2021-10-18netfilter: ebtables: allocate chainstack on CPU local nodesDavidlohr Bueso1-1/+3
Keep the per-CPU memory allocated for chainstacks local. Signed-off-by: Davidlohr Bueso <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]>
2021-10-17can: peak_usb: pcan_usb_fd_decode_status(): remove unnecessary test on the ↵Stephane Grosjean1-2/+1
nullity of a pointer Since alloc_can_err_skb() puts NULL in cf in the case when skb cannot be allocated and can_change_state() handles the case when cf is NULL, the test on the nullity of skb is now unnecessary. Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Stephane Grosjean <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]>
2021-10-17can: peak_usb: pcan_usb_fd_decode_status(): fix back to ERROR_ACTIVE state ↵Stephane Grosjean1-3/+2
notification This corrects the lack of notification of a return to ERROR_ACTIVE state for USB - CANFD devices from PEAK-System. Fixes: 0a25e1f4f185 ("can: peak_usb: add support for PEAK new CANFD USB adapters") Link: https://lore.kernel.org/all/[email protected] Cc: [email protected] Signed-off-by: Stephane Grosjean <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]>
2021-10-17can: peak_pci: peak_pci_remove(): fix UAFZheyu Ma1-5/+4
When remove the module peek_pci, referencing 'chan' again after releasing 'dev' will cause UAF. Fix this by releasing 'dev' later. The following log reveals it: [ 35.961814 ] BUG: KASAN: use-after-free in peak_pci_remove+0x16f/0x270 [peak_pci] [ 35.963414 ] Read of size 8 at addr ffff888136998ee8 by task modprobe/5537 [ 35.965513 ] Call Trace: [ 35.965718 ] dump_stack_lvl+0xa8/0xd1 [ 35.966028 ] print_address_description+0x87/0x3b0 [ 35.966420 ] kasan_report+0x172/0x1c0 [ 35.966725 ] ? peak_pci_remove+0x16f/0x270 [peak_pci] [ 35.967137 ] ? trace_irq_enable_rcuidle+0x10/0x170 [ 35.967529 ] ? peak_pci_remove+0x16f/0x270 [peak_pci] [ 35.967945 ] __asan_report_load8_noabort+0x14/0x20 [ 35.968346 ] peak_pci_remove+0x16f/0x270 [peak_pci] [ 35.968752 ] pci_device_remove+0xa9/0x250 Fixes: e6d9c80b7ca1 ("can: peak_pci: add support of some new PEAK-System PCI cards") Link: https://lore.kernel.org/all/[email protected] Cc: [email protected] Signed-off-by: Zheyu Ma <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]>
2021-10-17can: m_can: fix iomap_read_fifo() and iomap_write_fifo()Aswath Govindraju1-2/+12
The read and writes from the fifo are from a buffer, with various fields and data at predefined offsets. So, they should not be done to the same address(or port) in case of val_count greater than 1. Therefore, fix this by using iowrite32()/ioread32() instead of ioread32_rep()/iowrite32_rep(). Also, the write into FIFO must be performed with an offset from the message ram base address. Therefore, fix the base address to mram_base. Fixes: e39381770ec9 ("can: m_can: Disable IRQs on FIFO bus errors") Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Aswath Govindraju <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]>
2021-10-17can: rcar_can: fix suspend/resumeYoshihiro Shimoda1-8/+12
If the driver was not opened, rcar_can_suspend() should not call clk_disable() because the clock was not enabled. Fixes: fd1159318e55 ("can: add Renesas R-Car CAN driver") Link: https://lore.kernel.org/all/[email protected] Cc: [email protected] Signed-off-by: Yoshihiro Shimoda <[email protected]> Tested-by: Ayumi Nakamichi <[email protected]> Reviewed-by: Ulrich Hecht <[email protected]> Tested-by: Biju Das <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]>
2021-10-17block, bfq: reset last_bfqq_created on group changePaolo Valente1-0/+6
Since commit 430a67f9d616 ("block, bfq: merge bursts of newly-created queues"), BFQ maintains a per-group pointer to the last bfq_queue created. If such a queue, say bfqq, happens to move to a different group, then bfqq is no more a valid last bfq_queue created for its previous group. That pointer must then be cleared. Not resetting such a pointer may also cause UAF, if bfqq happens to also be freed after being moved to a different group. This commit performs this missing reset. As such it fixes commit 430a67f9d616 ("block, bfq: merge bursts of newly-created queues"). Such a missing reset is most likely the cause of the crash reported in [1]. With some analysis, we found that this crash was due to the above UAF. And such UAF did go away with this commit applied [1]. Anyway, before this commit, that crash happened to be triggered in conjunction with commit 2d52c58b9c9b ("block, bfq: honor already-setup queue merges"). The latter was then reverted by commit ebc69e897e17 ("Revert "block, bfq: honor already-setup queue merges""). Yet commit 2d52c58b9c9b ("block, bfq: honor already-setup queue merges") contains no error related with the above UAF, and can then be restored. [1] https://bugzilla.kernel.org/show_bug.cgi?id=214503 Fixes: 430a67f9d616 ("block, bfq: merge bursts of newly-created queues") Tested-by: Grzegorz Kowal <[email protected]> Signed-off-by: Paolo Valente <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]>