aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-04-20bpf, selftests: Add test for BPF_STX BPF_B storing R10Luke Nelson1-0/+40
This patch adds a test to test_verifier that writes the lower 8 bits of R10 (aka FP) using BPF_B to an array map and reads the result back. The expected behavior is that the result should be the same as first copying R10 to R9, and then storing / loading the lower 8 bits of R9. This test catches a bug that was present in the x86-64 JIT that caused an incorrect encoding for BPF_STX BPF_B when the source operand is R10. Signed-off-by: Xi Wang <[email protected]> Signed-off-by: Luke Nelson <[email protected]> Signed-off-by: Alexei Starovoitov <[email protected]> Link: https://lore.kernel.org/bpf/[email protected]
2020-04-20bpf, x86: Fix encoding for lower 8-bit registers in BPF_STX BPF_BLuke Nelson1-3/+15
This patch fixes an encoding bug in emit_stx for BPF_B when the source register is BPF_REG_FP. The current implementation for BPF_STX BPF_B in emit_stx saves one REX byte when the operands can be encoded using Mod-R/M alone. The lower 8 bits of registers %rax, %rbx, %rcx, and %rdx can be accessed without using a REX prefix via %al, %bl, %cl, and %dl, respectively. Other registers, (e.g., %rsi, %rdi, %rbp, %rsp) require a REX prefix to use their 8-bit equivalents (%sil, %dil, %bpl, %spl). The current code checks if the source for BPF_STX BPF_B is BPF_REG_1 or BPF_REG_2 (which map to %rdi and %rsi), in which case it emits the required REX prefix. However, it misses the case when the source is BPF_REG_FP (mapped to %rbp). The result is that BPF_STX BPF_B with BPF_REG_FP as the source operand will read from register %ch instead of the correct %bpl. This patch fixes the problem by fixing and refactoring the check on which registers need the extra REX byte. Since no BPF registers map to %rsp, there is no need to handle %spl. Fixes: 622582786c9e0 ("net: filter: x86: internal BPF JIT") Signed-off-by: Xi Wang <[email protected]> Signed-off-by: Luke Nelson <[email protected]> Signed-off-by: Alexei Starovoitov <[email protected]> Link: https://lore.kernel.org/bpf/[email protected]
2020-04-20bpf: Fix handling of XADD on BTF memoryJann Horn1-1/+1
check_xadd() can cause check_ptr_to_btf_access() to be executed with atype==BPF_READ and value_regno==-1 (meaning "just check whether the access is okay, don't tell me what type it will result in"). Handle that case properly and skip writing type information, instead of indexing into the registers at index -1 and writing into out-of-bounds memory. Note that at least at the moment, you can't actually write through a BTF pointer, so check_xadd() will reject the program after calling check_ptr_to_btf_access with atype==BPF_WRITE; but that's after the verifier has already corrupted memory. This patch assumes that BTF pointers are not available in unprivileged programs. Fixes: 9e15db66136a ("bpf: Implement accurate raw_tp context access via BTF") Signed-off-by: Jann Horn <[email protected]> Signed-off-by: Alexei Starovoitov <[email protected]> Link: https://lore.kernel.org/bpf/[email protected]
2020-04-20bpf: Forbid XADD on spilled pointers for unprivileged usersJann Horn2-9/+20
When check_xadd() verifies an XADD operation on a pointer to a stack slot containing a spilled pointer, check_stack_read() verifies that the read, which is part of XADD, is valid. However, since the placeholder value -1 is passed as `value_regno`, check_stack_read() can only return a binary decision and can't return the type of the value that was read. The intent here is to verify whether the value read from the stack slot may be used as a SCALAR_VALUE; but since check_stack_read() doesn't check the type, and the type information is lost when check_stack_read() returns, this is not enforced, and a malicious user can abuse XADD to leak spilled kernel pointers. Fix it by letting check_stack_read() verify that the value is usable as a SCALAR_VALUE if no type information is passed to the caller. To be able to use __is_pointer_value() in check_stack_read(), move it up. Fix up the expected unprivileged error message for a BPF selftest that, until now, assumed that unprivileged users can use XADD on stack-spilled pointers. This also gives us a test for the behavior introduced in this patch for free. In theory, this could also be fixed by forbidding XADD on stack spills entirely, since XADD is a locked operation (for operations on memory with concurrency) and there can't be any concurrency on the BPF stack; but Alexei has said that he wants to keep XADD on stack slots working to avoid changes to the test suite [1]. The following BPF program demonstrates how to leak a BPF map pointer as an unprivileged user using this bug: // r7 = map_pointer BPF_LD_MAP_FD(BPF_REG_7, small_map), // r8 = launder(map_pointer) BPF_STX_MEM(BPF_DW, BPF_REG_FP, BPF_REG_7, -8), BPF_MOV64_IMM(BPF_REG_1, 0), ((struct bpf_insn) { .code = BPF_STX | BPF_DW | BPF_XADD, .dst_reg = BPF_REG_FP, .src_reg = BPF_REG_1, .off = -8 }), BPF_LDX_MEM(BPF_DW, BPF_REG_8, BPF_REG_FP, -8), // store r8 into map BPF_MOV64_REG(BPF_REG_ARG1, BPF_REG_7), BPF_MOV64_REG(BPF_REG_ARG2, BPF_REG_FP), BPF_ALU64_IMM(BPF_ADD, BPF_REG_ARG2, -4), BPF_ST_MEM(BPF_W, BPF_REG_ARG2, 0, 0), BPF_EMIT_CALL(BPF_FUNC_map_lookup_elem), BPF_JMP_IMM(BPF_JNE, BPF_REG_0, 0, 1), BPF_EXIT_INSN(), BPF_STX_MEM(BPF_DW, BPF_REG_0, BPF_REG_8, 0), BPF_MOV64_IMM(BPF_REG_0, 0), BPF_EXIT_INSN() [1] https://lore.kernel.org/bpf/[email protected]/ Fixes: 17a5267067f3 ("bpf: verifier (add verifier core)") Signed-off-by: Jann Horn <[email protected]> Signed-off-by: Alexei Starovoitov <[email protected]> Link: https://lore.kernel.org/bpf/[email protected]
2020-04-20cpumap: Avoid warning when CONFIG_DEBUG_PER_CPU_MAPS is enabledToke Høiland-Jørgensen1-1/+1
When the kernel is built with CONFIG_DEBUG_PER_CPU_MAPS, the cpumap code can trigger a spurious warning if CONFIG_CPUMASK_OFFSTACK is also set. This happens because in this configuration, NR_CPUS can be larger than nr_cpumask_bits, so the initial check in cpu_map_alloc() is not sufficient to guard against hitting the warning in cpumask_check(). Fix this by explicitly checking the supplied key against the nr_cpumask_bits variable before calling cpu_possible(). Fixes: 6710e1126934 ("bpf: introduce new bpf cpu map type BPF_MAP_TYPE_CPUMAP") Reported-by: Xiumei Mu <[email protected]> Signed-off-by: Toke Høiland-Jørgensen <[email protected]> Signed-off-by: Alexei Starovoitov <[email protected]> Tested-by: Xiumei Mu <[email protected]> Acked-by: Jesper Dangaard Brouer <[email protected]> Acked-by: Song Liu <[email protected]> Link: https://lore.kernel.org/bpf/[email protected]
2020-04-21KVM: PPC: Book3S HV: Handle non-present PTEs in page fault functionsPaul Mackerras2-8/+10
Since cd758a9b57ee "KVM: PPC: Book3S HV: Use __gfn_to_pfn_memslot in HPT page fault handler", it's been possible in fairly rare circumstances to load a non-present PTE in kvmppc_book3s_hv_page_fault() when running a guest on a POWER8 host. Because that case wasn't checked for, we could misinterpret the non-present PTE as being a cache-inhibited PTE. That could mismatch with the corresponding hash PTE, which would cause the function to fail with -EFAULT a little further down. That would propagate up to the KVM_RUN ioctl() generally causing the KVM userspace (usually qemu) to fall over. This addresses the problem by catching that case and returning to the guest instead. For completeness, this fixes the radix page fault handler in the same way. For radix this didn't cause any obvious misbehaviour, because we ended up putting the non-present PTE into the guest's partition-scoped page tables, leading immediately to another hypervisor data/instruction storage interrupt, which would go through the page fault path again and fix things up. Fixes: cd758a9b57ee "KVM: PPC: Book3S HV: Use __gfn_to_pfn_memslot in HPT page fault handler" Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1820402 Reported-by: David Gibson <[email protected]> Tested-by: David Gibson <[email protected]> Signed-off-by: Paul Mackerras <[email protected]>
2020-04-20Merge tag 'mlx5-fixes-2020-04-20' of ↵David S. Miller8-24/+40
git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux mlx5-fixes-2020-04-20 Signed-off-by: David S. Miller <[email protected]>
2020-04-20net/mlx5e: Get the latest values from counters in switchdev modeZhu Yanjun1-1/+6
In the switchdev mode, when running "cat /sys/class/net/NIC/statistics/tx_packets", the ppcnt register is accessed to get the latest values. But currently this command can not get the correct values from ppcnt. From firmware manual, before getting the 802_3 counters, the 802_3 data layout should be set to the ppcnt register. When the command "cat /sys/class/net/NIC/statistics/tx_packets" is run, before updating 802_3 data layout with ppcnt register, the monitor counters are tested. The test result will decide the 802_3 data layout is updated or not. Actually the monitor counters do not support to monitor rx/tx stats of 802_3 in switchdev mode. So the rx/tx counters change will not trigger monitor counters. So the 802_3 data layout will not be updated in ppcnt register. Finally this command can not get the latest values from ppcnt register with 802_3 data layout. Fixes: 5c7e8bbb0257 ("net/mlx5e: Use monitor counters for update stats") Signed-off-by: Zhu Yanjun <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2020-04-20net/mlx5: Kconfig: convert imply usage to weak dependencySaeed Mahameed1-4/+4
MLX5_CORE uses the 'imply' keyword to depend on VXLAN, PTP_1588_CLOCK, MLXFW and PCI_HYPERV_INTERFACE. This was useful to force vxlan, ptp, etc.. to be reachable to mlx5 regardless of their config states. Due to the changes in the cited commit below, the semantics of 'imply' was changed to not force any restriction on the implied config. As a result of this change, the compilation of MLX5_CORE=y and VXLAN=m would result in undefined references, as VXLAN now would stay as 'm'. To fix this we change MLX5_CORE to have a weak dependency on these modules/configs and make sure they are reachable, by adding: depend on symbol || !symbol. For example: VXLAN=m MLX5_CORE=y, this will force MLX5_CORE to m Fixes: def2fbffe62c ("kconfig: allow symbols implied by y to become m") Signed-off-by: Saeed Mahameed <[email protected]> Cc: Masahiro Yamada <[email protected]> Cc: Nicolas Pitre <[email protected]> Cc: Arnd Bergmann <[email protected]> Reported-by: Randy Dunlap <[email protected]>
2020-04-20net/mlx5e: Don't trigger IRQ multiple times on XSK wakeup to avoid WQ overrunsMaxim Mikityanskiy4-5/+15
XSK wakeup function triggers NAPI by posting a NOP WQE to a special XSK ICOSQ. When the application floods the driver with wakeup requests by calling sendto() in a certain pattern that ends up in mlx5e_trigger_irq, the XSK ICOSQ may overflow. Multiple NOPs are not required and won't accelerate the process, so avoid posting a second NOP if there is one already on the way. This way we also avoid increasing the queue size (which might not help anyway). Fixes: db05815b36cb ("net/mlx5e: Add XSK zero-copy support") Signed-off-by: Maxim Mikityanskiy <[email protected]> Reviewed-by: Tariq Toukan <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2020-04-20net/mlx5: CT: Change idr to xarray to protect parallel tuple id allocationPaul Blakey1-11/+12
After allowing parallel tuple insertion, we get the following trace: [ 5505.142249] ------------[ cut here ]------------ [ 5505.148155] WARNING: CPU: 21 PID: 13313 at lib/radix-tree.c:581 delete_node+0x16c/0x180 [ 5505.295553] CPU: 21 PID: 13313 Comm: kworker/u50:22 Tainted: G OE 5.6.0+ #78 [ 5505.304824] Hardware name: Supermicro Super Server/X10DRT-P, BIOS 2.0b 03/30/2017 [ 5505.313740] Workqueue: nf_flow_table_offload flow_offload_work_handler [nf_flow_table] [ 5505.323257] RIP: 0010:delete_node+0x16c/0x180 [ 5505.349862] RSP: 0018:ffffb19184eb7b30 EFLAGS: 00010282 [ 5505.356785] RAX: 0000000000000000 RBX: ffff904ac95b86d8 RCX: ffff904b6f938838 [ 5505.365190] RDX: 0000000000000000 RSI: ffff904ac954b908 RDI: ffff904ac954b920 [ 5505.373628] RBP: ffff904b4ac13060 R08: 0000000000000001 R09: 0000000000000000 [ 5505.382155] R10: 0000000000000000 R11: 0000000000000040 R12: 0000000000000000 [ 5505.390527] R13: ffffb19184eb7bfc R14: ffff904b6bef5800 R15: ffff90482c1203c0 [ 5505.399246] FS: 0000000000000000(0000) GS:ffff904c2fc80000(0000) knlGS:0000000000000000 [ 5505.408621] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 5505.415739] CR2: 00007f5d27006010 CR3: 0000000058c10006 CR4: 00000000001626e0 [ 5505.424547] Call Trace: [ 5505.428429] idr_alloc_u32+0x7b/0xc0 [ 5505.433803] mlx5_tc_ct_entry_add_rule+0xbf/0x950 [mlx5_core] [ 5505.441354] ? mlx5_fc_create+0x23c/0x370 [mlx5_core] [ 5505.448225] mlx5_tc_ct_block_flow_offload+0x874/0x10b0 [mlx5_core] [ 5505.456278] ? mlx5_tc_ct_block_flow_offload+0x63d/0x10b0 [mlx5_core] [ 5505.464532] nf_flow_offload_tuple.isra.21+0xc5/0x140 [nf_flow_table] [ 5505.472286] ? __kmalloc+0x217/0x2f0 [ 5505.477093] ? flow_rule_alloc+0x1c/0x30 [ 5505.482117] flow_offload_work_handler+0x1d0/0x290 [nf_flow_table] [ 5505.489674] ? process_one_work+0x17c/0x580 [ 5505.494922] process_one_work+0x202/0x580 [ 5505.500082] ? process_one_work+0x17c/0x580 [ 5505.505696] worker_thread+0x4c/0x3f0 [ 5505.510458] kthread+0x103/0x140 [ 5505.514989] ? process_one_work+0x580/0x580 [ 5505.520616] ? kthread_bind+0x10/0x10 [ 5505.525837] ret_from_fork+0x3a/0x50 [ 5505.570841] ---[ end trace 07995de9c56d6831 ]--- This happens from parallel deletes/adds to idr, as idr isn't protected. Fix that by using xarray as the tuple_ids allocator instead of idr. Fixes: 7da182a998d6 ("netfilter: flowtable: Use work entry per offload command") Reviewed-by: Roi Dayan <[email protected]> Signed-off-by: Paul Blakey <[email protected]> Reviewed-by: Oz Shlomo <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2020-04-20net/mlx5: Fix failing fw tracer allocation on s390Niklas Schnelle1-3/+3
On s390 FORCE_MAX_ZONEORDER is 9 instead of 11, thus a larger kzalloc() allocation as done for the firmware tracer will always fail. Looking at mlx5_fw_tracer_save_trace(), it is actually the driver itself that copies the debug data into the trace array and there is no need for the allocation to be contiguous in physical memory. We can therefor use kvzalloc() instead of kzalloc() and get rid of the large contiguous allcoation. Fixes: f53aaa31cce7 ("net/mlx5: FW tracer, implement tracer logic") Signed-off-by: Niklas Schnelle <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2020-04-20kvm: Disable objtool frame pointer checking for vmenter.SJosh Poimboeuf1-0/+4
Frame pointers are completely broken by vmenter.S because it clobbers RBP: arch/x86/kvm/svm/vmenter.o: warning: objtool: __svm_vcpu_run()+0xe4: BP used as a scratch register That's unavoidable, so just skip checking that file when frame pointers are configured in. On the other hand, ORC can handle that code just fine, so leave objtool enabled in the !FRAME_POINTER case. Reported-by: Randy Dunlap <[email protected]> Signed-off-by: Josh Poimboeuf <[email protected]> Message-Id: <01fae42917bacad18be8d2cbc771353da6603473.1587398610.git.jpoimboe@redhat.com> Tested-by: Randy Dunlap <[email protected]> # build-tested Fixes: 199cd1d7b534 ("KVM: SVM: Split svm_vcpu_run inline assembly to separate file") Signed-off-by: Paolo Bonzini <[email protected]>
2020-04-20audit: check the length of userspace generated audit recordsPaul Moore1-0/+3
Commit 756125289285 ("audit: always check the netlink payload length in audit_receive_msg()") fixed a number of missing message length checks, but forgot to check the length of userspace generated audit records. The good news is that you need CAP_AUDIT_WRITE to submit userspace audit records, which is generally only given to trusted processes, so the impact should be limited. Cc: [email protected] Fixes: 756125289285 ("audit: always check the netlink payload length in audit_receive_msg()") Reported-by: [email protected] Signed-off-by: Paul Moore <[email protected]>
2020-04-21tpm/tpm_tis: Free IRQ if probing failsJarkko Sakkinen1-1/+7
Call disable_interrupts() if we have to revert to polling in order not to unnecessarily reserve the IRQ for the life-cycle of the driver. Cc: [email protected] # 4.5.x Reported-by: Hans de Goede <[email protected]> Fixes: e3837e74a06d ("tpm_tis: Refactor the interrupt setup") Signed-off-by: Jarkko Sakkinen <[email protected]>
2020-04-21tpm: fix wrong return value in tpm_pcr_extendTianjia Zhang1-1/+1
For the algorithm that does not match the bank, a positive value EINVAL is returned here. I think this is a typo error. It is necessary to return an error value. Cc: [email protected] # 5.4.x Fixes: 9f75c8224631 ("KEYS: trusted: correctly initialize digests and fix locking issue") Signed-off-by: Tianjia Zhang <[email protected]> Reviewed-by: Roberto Sassu <[email protected]> Reviewed-by: Jerry Snitselaar <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]>
2020-04-21tpm: ibmvtpm: retry on H_CLOSED in tpm_ibmvtpm_send()George Wilson1-63/+73
tpm_ibmvtpm_send() can fail during PowerVM Live Partition Mobility resume with an H_CLOSED return from ibmvtpm_send_crq(). The PAPR says, 'The "partner partition suspended" transport event disables the associated CRQ such that any H_SEND_CRQ hcall() to the associated CRQ returns H_Closed until the CRQ has been explicitly enabled using the H_ENABLE_CRQ hcall.' This patch adds a check in tpm_ibmvtpm_send() for an H_CLOSED return from ibmvtpm_send_crq() and in that case calls tpm_ibmvtpm_resume() and retries the ibmvtpm_send_crq() once. Cc: [email protected] # 3.7.x Fixes: 132f76294744 ("drivers/char/tpm: Add new device driver to support IBM vTPM") Reported-by: Linh Pham <[email protected]> Reviewed-by: Stefan Berger <[email protected]> Signed-off-by: George Wilson <[email protected]> Tested-by: Linh Pham <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]>
2020-04-21tpm: Export tpm2_get_cc_attrs_tbl for ibmvtpm driver as moduleStefan Berger1-0/+1
This patch fixes the following problem when the ibmvtpm driver is built as a module: ERROR: modpost: "tpm2_get_cc_attrs_tbl" [drivers/char/tpm/tpm_ibmvtpm.ko] undefined! make[1]: *** [scripts/Makefile.modpost:94: __modpost] Error 1 make: *** [Makefile:1298: modules] Error 2 Fixes: 18b3670d79ae ("tpm: ibmvtpm: Add support for TPM2") Signed-off-by: Stefan Berger <[email protected]> Reported-by: Sachin Sant <[email protected]> Tested-by: Sachin Sant <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]>
2020-04-20team: fix hang in team_mode_get()Taehee Yoo1-0/+4
When team mode is changed or set, the team_mode_get() is called to check whether the mode module is inserted or not. If the mode module is not inserted, it calls the request_module(). In the request_module(), it creates a child process, which is the "modprobe" process and waits for the done of the child process. At this point, the following locks were used. down_read(&cb_lock()); by genl_rcv() genl_lock(); by genl_rcv_msc() rtnl_lock(); by team_nl_cmd_options_set() mutex_lock(&team->lock); by team_nl_team_get() Concurrently, the team module could be removed by rmmod or "modprobe -r" The __exit function of team module is team_module_exit(), which calls team_nl_fini() and it tries to acquire following locks. down_write(&cb_lock); genl_lock(); Because of the genl_lock() and cb_lock, this process can't be finished earlier than request_module() routine. The problem secenario. CPU0 CPU1 team_mode_get request_module() modprobe -r team_mode_roundrobin team <--(B) modprobe team <--(A) team_mode_roundrobin By request_module(), the "modprobe team_mode_roundrobin" command will be executed. At this point, the modprobe process will decide that the team module should be inserted before team_mode_roundrobin. Because the team module is being removed. By the module infrastructure, the same module insert/remove operations can't be executed concurrently. So, (A) waits for (B) but (B) also waits for (A) because of locks. So that the hang occurs at this point. Test commands: while : do teamd -d & killall teamd & modprobe -rv team_mode_roundrobin & done The approach of this patch is to hold the reference count of the team module if the team module is compiled as a module. If the reference count of the team module is not zero while request_module() is being called, the team module will not be removed at that moment. So that the above scenario could not occur. Fixes: 3d249d4ca7d0 ("net: introduce ethernet teaming device") Signed-off-by: Taehee Yoo <[email protected]> Reviewed-by: Jiri Pirko <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-04-20Merge branch 'mptcp-fix-races-on-accept'David S. Miller3-33/+52
Paolo Abeni says: ==================== mptcp: fix races on accept() This series includes some fixes for accept() races which may cause inconsistent MPTCP socket status and oops. Please see the individual patches for the technical details. ==================== Signed-off-by: David S. Miller <[email protected]>
2020-04-20mptcp: drop req socket remote_key* fieldsPaolo Abeni3-17/+19
We don't need them, as we can use the current ingress opt data instead. Setting them in syn_recv_sock() may causes inconsistent mptcp socket status, as per previous commit. Fixes: cc7972ea1932 ("mptcp: parse and emit MP_CAPABLE option according to v1 spec") Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-04-20mptcp: avoid flipping mp_capable field in syn_recv_sock()Paolo Abeni1-16/+30
If multiple CPUs races on the same req_sock in syn_recv_sock(), flipping such field can cause inconsistent child socket status. When racing, the CPU losing the req ownership may still change the mptcp request socket mp_capable flag while the CPU owning the request is cloning the socket, leaving the child socket with 'is_mptcp' set but no 'mp_capable' flag. Such socket will stay with 'conn' field cleared, heading to oops in later mptcp callback. Address the issue tracking the fallback status in a local variable. Fixes: 58b09919626b ("mptcp: create msk early") Co-developed-by: Florian Westphal <[email protected]> Signed-off-by: Florian Westphal <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-04-20mptcp: handle mptcp listener destruction via rcuFlorian Westphal1-0/+3
Following splat can occur during self test: BUG: KASAN: use-after-free in subflow_data_ready+0x156/0x160 Read of size 8 at addr ffff888100c35c28 by task mptcp_connect/4808 subflow_data_ready+0x156/0x160 tcp_child_process+0x6a3/0xb30 tcp_v4_rcv+0x2231/0x3730 ip_protocol_deliver_rcu+0x5c/0x860 ip_local_deliver_finish+0x220/0x360 ip_local_deliver+0x1c8/0x4e0 ip_rcv_finish+0x1da/0x2f0 ip_rcv+0xd0/0x3c0 __netif_receive_skb_one_core+0xf5/0x160 __netif_receive_skb+0x27/0x1c0 process_backlog+0x21e/0x780 net_rx_action+0x35f/0xe90 do_softirq+0x4c/0x50 [..] This occurs when accessing subflow_ctx->conn. Problem is that tcp_child_process() calls listen sockets' sk_data_ready() notification, but it doesn't hold the listener lock. Another cpu calling close() on the listener will then cause transition of refcount to 0. Fixes: 58b09919626bf ("mptcp: create msk early") Signed-off-by: Florian Westphal <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-04-20cxgb4: fix large delays in PTP synchronizationRahul Lakkireddy2-21/+9
Fetching PTP sync information from mailbox is slow and can take up to 10 milliseconds. Reduce this unnecessary delay by directly reading the information from the corresponding registers. Fixes: 9c33e4208bce ("cxgb4: Add PTP Hardware Clock (PHC) support") Signed-off-by: Manoj Malviya <[email protected]> Signed-off-by: Rahul Lakkireddy <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-04-20Merge tag 'omap-for-v5.6/fixes-rc7-signed' of ↵Arnd Bergmann1-0/+5
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into arm/fixes Boot regression fix for N950/N9 We need to tag RNG as disabled for N950/N9 as it blocked by the secure mode. We have a similar change done for N900, but I missed adding it for N950/N9 with the recent RNG changes. * tag 'omap-for-v5.6/fixes-rc7-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap: ARM: dts: OMAP3: disable RNG on N950/N9 Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Arnd Bergmann <[email protected]>
2020-04-20net: stmmac: dwmac-meson8b: Add missing boundary to RGMII TX clock arrayMarc Zyngier1-0/+1
Running with KASAN on a VIM3L systems leads to the following splat when probing the Ethernet device: ================================================================== BUG: KASAN: global-out-of-bounds in _get_maxdiv+0x74/0xd8 Read of size 4 at addr ffffa000090615f4 by task systemd-udevd/139 CPU: 1 PID: 139 Comm: systemd-udevd Tainted: G E 5.7.0-rc1-00101-g8624b7577b9c #781 Hardware name: amlogic w400/w400, BIOS 2020.01-rc5 03/12/2020 Call trace: dump_backtrace+0x0/0x2a0 show_stack+0x20/0x30 dump_stack+0xec/0x148 print_address_description.isra.12+0x70/0x35c __kasan_report+0xfc/0x1d4 kasan_report+0x4c/0x68 __asan_load4+0x9c/0xd8 _get_maxdiv+0x74/0xd8 clk_divider_bestdiv+0x74/0x5e0 clk_divider_round_rate+0x80/0x1a8 clk_core_determine_round_nolock.part.9+0x9c/0xd0 clk_core_round_rate_nolock+0xf0/0x108 clk_hw_round_rate+0xac/0xf0 clk_factor_round_rate+0xb8/0xd0 clk_core_determine_round_nolock.part.9+0x9c/0xd0 clk_core_round_rate_nolock+0xf0/0x108 clk_core_round_rate_nolock+0xbc/0x108 clk_core_set_rate_nolock+0xc4/0x2e8 clk_set_rate+0x58/0xe0 meson8b_dwmac_probe+0x588/0x72c [dwmac_meson8b] platform_drv_probe+0x78/0xd8 really_probe+0x158/0x610 driver_probe_device+0x140/0x1b0 device_driver_attach+0xa4/0xb0 __driver_attach+0xcc/0x1c8 bus_for_each_dev+0xf4/0x168 driver_attach+0x3c/0x50 bus_add_driver+0x238/0x2e8 driver_register+0xc8/0x1e8 __platform_driver_register+0x88/0x98 meson8b_dwmac_driver_init+0x28/0x1000 [dwmac_meson8b] do_one_initcall+0xa8/0x328 do_init_module+0xe8/0x368 load_module+0x3300/0x36b0 __do_sys_finit_module+0x120/0x1a8 __arm64_sys_finit_module+0x4c/0x60 el0_svc_common.constprop.2+0xe4/0x268 do_el0_svc+0x98/0xa8 el0_svc+0x24/0x68 el0_sync_handler+0x12c/0x318 el0_sync+0x158/0x180 The buggy address belongs to the variable: div_table.63646+0x34/0xfffffffffffffa40 [dwmac_meson8b] Memory state around the buggy address: ffffa00009061480: fa fa fa fa 00 00 00 01 fa fa fa fa 00 00 00 00 ffffa00009061500: 05 fa fa fa fa fa fa fa 00 04 fa fa fa fa fa fa >ffffa00009061580: 00 03 fa fa fa fa fa fa 00 00 00 00 00 00 fa fa ^ ffffa00009061600: fa fa fa fa 00 01 fa fa fa fa fa fa 01 fa fa fa ffffa00009061680: fa fa fa fa 00 01 fa fa fa fa fa fa 04 fa fa fa ================================================================== Digging into this indeed shows that the clock divider array is lacking a final fence, and that the clock subsystems goes in the weeds. Oh well. Let's add the empty structure that indicates the end of the array. Fixes: bd6f48546b9c ("net: stmmac: dwmac-meson8b: Fix the RGMII TX delay on Meson8b/8m2 SoCs") Signed-off-by: Marc Zyngier <[email protected]> Cc: Martin Blumenstingl <[email protected]> Reviewed-by: Martin Blumenstingl <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-04-20ipv6: fix restrict IPV6_ADDRFORM operationJohn Haxby1-7/+6
Commit b6f6118901d1 ("ipv6: restrict IPV6_ADDRFORM operation") fixed a problem found by syzbot an unfortunate logic error meant that it also broke IPV6_ADDRFORM. Rearrange the checks so that the earlier test is just one of the series of checks made before moving the socket from IPv6 to IPv4. Fixes: b6f6118901d1 ("ipv6: restrict IPV6_ADDRFORM operation") Signed-off-by: John Haxby <[email protected]> Cc: [email protected] Signed-off-by: David S. Miller <[email protected]>
2020-04-20net: systemport: Omit superfluous error message in bcm_sysport_probe()Tang Bin1-1/+0
In the function bcm_sysport_probe(), when get irq failed, the function platform_get_irq() logs an error message, so remove redundant message here. Signed-off-by: Tang Bin <[email protected]> Acked-by: Florian Fainelli <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-04-20net: openvswitch: ovs_ct_exit to be done under ovs_lockTonghao Zhang2-2/+5
syzbot wrote: | ============================= | WARNING: suspicious RCU usage | 5.7.0-rc1+ #45 Not tainted | ----------------------------- | net/openvswitch/conntrack.c:1898 RCU-list traversed in non-reader section!! | | other info that might help us debug this: | rcu_scheduler_active = 2, debug_locks = 1 | ... | | stack backtrace: | Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-0-ga698c8995f-prebuilt.qemu.org 04/01/2014 | Workqueue: netns cleanup_net | Call Trace: | ... | ovs_ct_exit | ovs_exit_net | ops_exit_list.isra.7 | cleanup_net | process_one_work | worker_thread To avoid that warning, invoke the ovs_ct_exit under ovs_lock and add lockdep_ovsl_is_held as optional lockdep expression. Link: https://lore.kernel.org/lkml/[email protected] Fixes: 11efd5cb04a1 ("openvswitch: Support conntrack zone limit") Cc: Pravin B Shelar <[email protected]> Cc: Yi-Hung Wei <[email protected]> Reported-by: [email protected] Signed-off-by: Tonghao Zhang <[email protected]> Acked-by: Pravin B Shelar <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-04-20tty/sysrq: Export sysrq_mask(), sysrq_toggle_support()Dmitry Safonov1-0/+2
Build fix for serial_core being module: ERROR: modpost: "sysrq_toggle_support" [drivers/tty/serial/serial_core.ko] undefined! ERROR: modpost: "sysrq_mask" [drivers/tty/serial/serial_core.ko] undefined! Fixes: eaee41727e6d ("sysctl/sysrq: Remove __sysrq_enabled copy") Cc: Jiri Slaby <[email protected]> Reported-by: "kernelci.org bot" <[email protected]> Reported-by: Michael Ellerman <[email protected]> Reported-by: Stephen Rothwell <[email protected]> Signed-off-by: Dmitry Safonov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-04-20vdso/datapage: Use correct clock mode name in commentChristian Brauner1-2/+2
While the explanation for time namespace <-> vdso interactions is very helpful it uses the wrong name in the comment when describing the clock mode making grepping a bit annoying. This seems like an accidental oversight when moving from VCLOCK_TIMENS to VDSO_CLOCKMODE_TIMENS. It seems that 660fd04f9317 ("lib/vdso: Prepare for time namespace support") misspelled VCLOCK_TIMENS as VLOCK_TIMENS which explains why it got missed when VCLOCK_TIMENS became VDSO_CLOCKMODE_TIMENS in 2d6b01bd88cc ("lib/vdso: Move VCLOCK_TIMENS to vdso_clock_modes"). Update the comment to use VDSO_CLOCKMODE_TIMENS. Fixes: 660fd04f9317 ("lib/vdso: Prepare for time namespace support") Fixes: 2d6b01bd88cc ("lib/vdso: Move VCLOCK_TIMENS to vdso_clock_modes") Signed-off-by: Christian Brauner <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Acked-by: Andrei Vagin <[email protected]> Acked-by: Vincenzo Frascino <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2020-04-20drm/i915/dpcd_bl: Unbreak enable_dpcd_backlight modparamLyude Paul1-0/+1
Looks like I accidentally made it so you couldn't force DPCD backlight support on, whoops. Fix that. Signed-off-by: Lyude Paul <[email protected]> Fixes: 17f5d57915be ("drm/i915: Force DPCD backlight mode on X1 Extreme 2nd Gen 4K AMOLED panel") Cc: Adam Jackson <[email protected]> Cc: Jani Nikula <[email protected]> Cc: Joonas Lahtinen <[email protected]> Cc: "Ville Syrjälä" <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit d7fb38ae36a2dc97924b075ad1d1a88792777ea9) Signed-off-by: Rodrigo Vivi <[email protected]>
2020-04-20drm/i915: fix Sphinx build duplicate label warningJani Nikula1-2/+2
Fix the warning caused by enabling the autosectionlabel extension in the kernel Sphinx build: Documentation/gpu/i915.rst:610: WARNING: duplicate label gpu/i915:layout, other instance in Documentation/gpu/i915.rst The autosectionlabel extension adds labels to each section title for cross-referencing, but forbids identical section titles in a document. With kernel-doc, this includes sections titles in the included kernel-doc comments. In the warning message, Sphinx is unable to reference the labels in their true locations in the kernel-doc comments in source. In this case, there's "Layout" sections in both gt/intel_workarounds.c and i915_reg.h. Rename the section in the latter to "File Layout". Fixes: 58ad30cf91f0 ("docs: fix reference to core-api/namespaces.rst") Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 27be41de45a70fe1cb0ae1cbd2fd6da1ce3ffe9a) Signed-off-by: Rodrigo Vivi <[email protected]>
2020-04-20drm/i915/display: Load DP_TP_CTL/STATUS offset before use itJosé Roberto de Souza2-6/+13
Right now dp.regs.dp_tp_ctl/status are only set during the encoder pre_enable() hook, what is causing all reads and writes to those registers to go to offset 0x0 before pre_enable() is executed. So if i915 takes the BIOS state and don't do a modeset any following link retraing will fail. In the case that i915 needs to do a modeset, the DDI disable sequence will write to a wrong register not disabling DP 'Transport Enable' in DP_TP_CTL, making a HDMI modeset in the same port/transcoder to not light up the monitor. So here for GENs older than 12, that have those registers fixed at port offset range it is loading at encoder/port init while for GEN12 it will keep setting it at encoder pre_enable() and during HW state readout. Fixes: 4444df6e205b ("drm/i915/tgl: move DP_TP_* to transcoder") Cc: Matt Roper <[email protected]> Cc: Lucas De Marchi <[email protected]> Signed-off-by: José Roberto de Souza <[email protected]> Reviewed-by: Matt Roper <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit edcb9028d66b44d74ba4f8b9daa379b004dc1f85) Signed-off-by: Rodrigo Vivi <[email protected]>
2020-04-20drm/i915/tgl: TBT AUX should use TC power well opsMatt Roper1-6/+6
As on ICL, we want to use the Type-C aux handlers for the TBT aux wells to ensure the DP_AUX_CH_CTL_TBT_IO flag is set properly. Fixes: 656409bbaf87 ("drm/i915/tgl: Add power well support") Cc: José Roberto de Souza <[email protected]> Cc: Imre Deak <[email protected]> Signed-off-by: Matt Roper <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: José Roberto de Souza <[email protected]> (cherry picked from commit 3cbdb97564a39020262e62b655e788b63cf426cb) Signed-off-by: Rodrigo Vivi <[email protected]>
2020-04-20drm/i915: HDCP: fix Ri prime check done during link checkOliver Barta1-1/+2
The check was always succeeding even in case of a mismatch due to the HDCP_STATUS_ENC bit being set. Make sure both bits are actually set. Signed-off-by: Oliver Barta <[email protected]> Fixes: 2320175feb74 ("drm/i915: Implement HDCP for HDMI") Reviewed-by: Ramalingam C <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 3ffaf56e912e76cf09c560244c8804f9bebda8b1) Signed-off-by: Rodrigo Vivi <[email protected]>
2020-04-20drm/i915/gt: Update PMINTRMSK holding fwChris Wilson1-3/+6
If we use a non-forcewaked write to PMINTRMSK, it does not take effect until much later, if at all, causing a loss of RPS interrupts and no GPU reclocking, leaving the GPU running at the wrong frequency for long periods of time. Reported-by: Francisco Jerez <[email protected]> Suggested-by: Francisco Jerez <[email protected]> Fixes: 35cc7f32c298 ("drm/i915/gt: Use non-forcewake writes for RPS") Signed-off-by: Chris Wilson <[email protected]> Cc: Francisco Jerez <[email protected]> Cc: Mika Kuoppala <[email protected]> Cc: Andi Shyti <[email protected]> Reviewed-by: Mika Kuoppala <[email protected]> Reviewed-by: Andi Shyti <[email protected]> Reviewed-by: Francisco Jerez <[email protected]> Cc: <[email protected]> # v5.6+ Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit a080bd994c4023042a2b605c65fa10a25933f636) Signed-off-by: Rodrigo Vivi <[email protected]>
2020-04-20drm/i915/tgl: Add Wa_14010477008:tglMatt Roper2-5/+14
Media decompression support should not be advertised on any display planes for steppings A0-C0. Bspec: 53273 Fixes: 2dfbf9d2873a ("drm/i915/tgl: Gen-12 display can decompress surfaces compressed by the media engine") Cc: Matt Atwood <[email protected]> Signed-off-by: Matt Roper <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: José Roberto de Souza <[email protected]> (cherry picked from commit dbff5a8db9c630f61a892ab41a283445e01270f5) Signed-off-by: Rodrigo Vivi <[email protected]>
2020-04-20bdev: Reduce time holding bd_mutex in sync in blkdev_close()Douglas Anderson1-0/+10
While trying to "dd" to the block device for a USB stick, I encountered a hung task warning (blocked for > 120 seconds). I managed to come up with an easy way to reproduce this on my system (where /dev/sdb is the block device for my USB stick) with: while true; do dd if=/dev/zero of=/dev/sdb bs=4M; done With my reproduction here are the relevant bits from the hung task detector: INFO: task udevd:294 blocked for more than 122 seconds. ... udevd D 0 294 1 0x00400008 Call trace: ... mutex_lock_nested+0x40/0x50 __blkdev_get+0x7c/0x3d4 blkdev_get+0x118/0x138 blkdev_open+0x94/0xa8 do_dentry_open+0x268/0x3a0 vfs_open+0x34/0x40 path_openat+0x39c/0xdf4 do_filp_open+0x90/0x10c do_sys_open+0x150/0x3c8 ... ... Showing all locks held in the system: ... 1 lock held by dd/2798: #0: ffffff814ac1a3b8 (&bdev->bd_mutex){+.+.}, at: __blkdev_put+0x50/0x204 ... dd D 0 2798 2764 0x00400208 Call trace: ... schedule+0x8c/0xbc io_schedule+0x1c/0x40 wait_on_page_bit_common+0x238/0x338 __lock_page+0x5c/0x68 write_cache_pages+0x194/0x500 generic_writepages+0x64/0xa4 blkdev_writepages+0x24/0x30 do_writepages+0x48/0xa8 __filemap_fdatawrite_range+0xac/0xd8 filemap_write_and_wait+0x30/0x84 __blkdev_put+0x88/0x204 blkdev_put+0xc4/0xe4 blkdev_close+0x28/0x38 __fput+0xe0/0x238 ____fput+0x1c/0x28 task_work_run+0xb0/0xe4 do_notify_resume+0xfc0/0x14bc work_pending+0x8/0x14 The problem appears related to the fact that my USB disk is terribly slow and that I have a lot of RAM in my system to cache things. Specifically my writes seem to be happening at ~15 MB/s and I've got ~4 GB of RAM in my system that can be used for buffering. To write 4 GB of buffer to disk thus takes ~4000 MB / ~15 MB/s = ~267 seconds. The 267 second number is a problem because in __blkdev_put() we call sync_blockdev() while holding the bd_mutex. Any other callers who want the bd_mutex will be blocked for the whole time. The problem is made worse because I believe blkdev_put() specifically tells other tasks (namely udev) to go try to access the device at right around the same time we're going to hold the mutex for a long time. Putting some traces around this (after disabling the hung task detector), I could confirm: dd: 437.608600: __blkdev_put() right before sync_blockdev() for sdb udevd: 437.623901: blkdev_open() right before blkdev_get() for sdb dd: 661.468451: __blkdev_put() right after sync_blockdev() for sdb udevd: 663.820426: blkdev_open() right after blkdev_get() for sdb A simple fix for this is to realize that sync_blockdev() works fine if you're not holding the mutex. Also, it's not the end of the world if you sync a little early (though it can have performance impacts). Thus we can make a guess that we're going to need to do the sync and then do it without holding the mutex. We still do one last sync with the mutex but it should be much, much faster. With this, my hung task warnings for my test case are gone. Signed-off-by: Douglas Anderson <[email protected]> Reviewed-by: Guenter Roeck <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2020-04-20mei: me: fix irq number stored in hw structBenjamin Lee1-1/+2
Commit 261b3e1f2a01 ("mei: me: store irq number in the hw struct.") stores the irq number in the hw struct before MSI is enabled. This caused a regression for mei_me_synchronize_irq() waiting for the wrong irq number. On my laptop this causes a hang on shutdown. Fix the issue by storing the irq number after enabling MSI. Fixes: 261b3e1f2a01 ("mei: me: store irq number in the hw struct.") Signed-off-by: Benjamin Lee <[email protected]> Cc: stable <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-04-20ASoC: wm89xx: Add missing dependencyYueHaibing1-0/+3
sound/soc/codecs/wm8900.o: In function `wm8900_i2c_probe': wm8900.c:(.text+0xa36): undefined reference to `__devm_regmap_init_i2c' sound/soc/codecs/wm8900.o: In function `wm8900_modinit': wm8900.c:(.init.text+0xb): undefined reference to `i2c_register_driver' sound/soc/codecs/wm8900.o: In function `wm8900_exit': wm8900.c:(.exit.text+0x8): undefined reference to `i2c_del_driver' sound/soc/codecs/wm8988.o: In function `wm8988_i2c_probe': wm8988.c:(.text+0x857): undefined reference to `__devm_regmap_init_i2c' sound/soc/codecs/wm8988.o: In function `wm8988_modinit': wm8988.c:(.init.text+0xb): undefined reference to `i2c_register_driver' sound/soc/codecs/wm8988.o: In function `wm8988_exit': wm8988.c:(.exit.text+0x8): undefined reference to `i2c_del_driver' sound/soc/codecs/wm8995.o: In function `wm8995_i2c_probe': wm8995.c:(.text+0x1c4f): undefined reference to `__devm_regmap_init_i2c' sound/soc/codecs/wm8995.o: In function `wm8995_modinit': wm8995.c:(.init.text+0xb): undefined reference to `i2c_register_driver' sound/soc/codecs/wm8995.o: In function `wm8995_exit': wm8995.c:(.exit.text+0x8): undefined reference to `i2c_del_driver' Add SND_SOC_I2C_AND_SPI dependency to fix this. Fixes: ea00d95200d02ece ("ASoC: Use imply for SND_SOC_ALL_CODECS") Reported-by: Hulk Robot <[email protected]> Signed-off-by: YueHaibing <[email protected]> Acked-by: Charles Keepax <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2020-04-20vhost: disable for OABIMichael S. Tsirkin4-7/+16
vhost is currently broken on the some ARM configs. The reason is that the ring element addresses are passed between components with different alignments assumptions. Thus, if guest selects a pointer and host then gets and dereferences it, then alignment assumed by the host's compiler might be greater than the actual alignment of the pointer. compiler on the host from assuming pointer is aligned. This actually triggers on ARM with -mabi=apcs-gnu - which is a deprecated configuration. With this OABI, compiler assumes that all structures are 4 byte aligned - which is stronger than virtio guarantees for available and used rings, which are merely 2 bytes. Thus a guest without -mabi=apcs-gnu running on top of host with -mabi=apcs-gnu will be broken. The correct fix is to force alignment of structures - however that is an intrusive fix that's best deferred until the next release. We didn't previously support such ancient systems at all - this surfaced after vdpa support prompted removing dependency of vhost on VIRTULIZATION. So for now, let's just add something along the lines of depends on !ARM || AEABI to the virtio Kconfig declaration, and add a comment that it has to do with struct member alignment. Note: we can't make VHOST and VHOST_RING themselves have a dependency since these are selected. Add a new symbol for that. We should be able to drop this dependency down the road. Fixes: 20c384f1ea1a0bc7 ("vhost: refine vhost and vringh kconfig") Suggested-by: Ard Biesheuvel <[email protected]> Suggested-by: Richard Earnshaw <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]>
2020-04-20Merge series "ASoC: rsnd: multi-SSI setup fixes" from Matthias Blankertz ↵Mark Brown1-5/+14
<[email protected]>: Fix rsnd_dai_call() operations being performed twice for the master SSI in multi-SSI setups, and fix the rsnd_ssi_stop operation for multi-SSI setups. The only visible effect of these issues was some "status check failed" spam when the rsnd_ssi_stop was called, but overall the code is cleaner now, and some questionable writes to the SSICR register which did not lead to any observable misbehaviour but were contrary to the datasheet are fixed. Mark: The first patch kind of reverts my "ASoC: rsnd: Fix parent SSI start/stop in multi-SSI mode" from a few days ago and achieves the same effect in a simpler fashion, if you would prefer a clean patch series based on v5.6 drop me a note. Greetings, Matthias Matthias Blankertz (2): ASoC: rsnd: Don't treat master SSI in multi SSI setup as parent ASoC: rsnd: Fix "status check failed" spam for multi-SSI sound/soc/sh/rcar/ssi.c | 18 +++++++++++++----- 1 file changed, 13 insertions(+), 5 deletions(-) base-commit: 15a5760cb8b6d5c1ebbf1d2e1f0b77380ab68a82 -- 2.26.1
2020-04-20Merge series "ASoC: meson: fix codec-to-codec link setup" from Jerome Brunet ↵Mark Brown2-2/+6
<[email protected]>: This patchset fixes the problem reported by Marc in this thread [0] The problem was due to an error in the meson card drivers which had the "no_pcm" dai_link property set on codec-to-codec links [0]: https://lore.kernel.org/r/[email protected] Jerome Brunet (2): ASoC: meson: axg-card: fix codec-to-codec link setup ASoC: meson: gx-card: fix codec-to-codec link setup sound/soc/meson/axg-card.c | 4 +++- sound/soc/meson/gx-card.c | 4 +++- 2 files changed, 6 insertions(+), 2 deletions(-) -- 2.25.2
2020-04-20ASoC: dapm: fixup dapm kcontrol widgetGyeongtaek Lee1-3/+17
snd_soc_dapm_kcontrol widget which is created by autodisable control should contain correct on_val, mask and shift because it is set when the widget is powered and changed value is applied on registers by following code in dapm_seq_run_coalesced(). mask |= w->mask << w->shift; if (w->power) value |= w->on_val << w->shift; else value |= w->off_val << w->shift; Shift on the mask in dapm_kcontrol_data_alloc() is removed to prevent double shift. And, on_val in dapm_kcontrol_set_value() is modified to get correct value in the dapm_seq_run_coalesced(). Signed-off-by: Gyeongtaek Lee <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2020-04-20ASoC: rsnd: Fix "status check failed" spam for multi-SSIMatthias Blankertz1-1/+7
Fix the rsnd_ssi_stop function to skip disabling the individual SSIs of a multi-SSI setup, as the actual stop is performed by rsnd_ssiu_stop_gen2 - the same logic as in rsnd_ssi_start. The attempt to disable these SSIs was harmless, but caused a "status check failed" message to be printed for every SSI in the multi-SSI setup. The disabling of interrupts is still performed, as they are enabled for all SSIs in rsnd_ssi_init, but care is taken to not accidentally set the EN bit for an SSI where it was not set by rsnd_ssi_start. Signed-off-by: Matthias Blankertz <[email protected]> Acked-by: Kuninori Morimoto <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2020-04-20ASoC: rsnd: Don't treat master SSI in multi SSI setup as parentMatthias Blankertz1-4/+7
The master SSI of a multi-SSI setup was attached both to the RSND_MOD_SSI slot and the RSND_MOD_SSIP slot of the rsnd_dai_stream. This is not correct wrt. the meaning of being "parent" in the rest of the SSI code, where it seems to indicate an SSI that provides clock and word sync but is not transmitting/receiving audio data. Not treating the multi-SSI master as parent allows removal of various special cases to the rsnd_ssi_is_parent conditions introduced in commit a09fb3f28a60 ("ASoC: rsnd: Fix parent SSI start/stop in multi-SSI mode"). It also fixes the issue that operations performed via rsnd_dai_call() were performed twice for the master SSI. This caused some "status check failed" spam when stopping a multi-SSI stream as the driver attempted to stop the master SSI twice. Signed-off-by: Matthias Blankertz <[email protected]> Acked-by: Kuninori Morimoto <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2020-04-20ASoC: meson: gx-card: fix codec-to-codec link setupJerome Brunet1-1/+3
Since the addition of commit 9b5db059366a ("ASoC: soc-pcm: dpcm: Only allow playback/capture if supported"), meson-axg cards which have codec-to-codec links fail to init and Oops. Unable to handle kernel NULL pointer dereference at virtual address 0000000000000128 Internal error: Oops: 96000044 [#1] PREEMPT SMP CPU: 3 PID: 1582 Comm: arecord Not tainted 5.7.0-rc1 pc : invalidate_paths_ep+0x30/0xe0 lr : snd_soc_dapm_dai_get_connected_widgets+0x170/0x1a8 Call trace: invalidate_paths_ep+0x30/0xe0 snd_soc_dapm_dai_get_connected_widgets+0x170/0x1a8 dpcm_path_get+0x38/0xd0 dpcm_fe_dai_open+0x70/0x920 snd_pcm_open_substream+0x564/0x840 snd_pcm_open+0xfc/0x228 snd_pcm_capture_open+0x4c/0x78 snd_open+0xac/0x1a8 ... While this error was initially reported the axg-card type, it also applies to the gx-card type. While initiliazing the links, ASoC treats the codec-to-codec links of this card type as a DPCM backend. This error eventually leads to the Oops. Most of the card driver code is shared between DPCM backends and codec-to-codec links. The property "no_pcm" marking DCPM BE was left set on codec-to-codec links, leading to this problem. This commit fixes that. Fixes: e37a0c313a0f ("ASoC: meson: gx: add sound card support") Signed-off-by: Jerome Brunet <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2020-04-20ASoC: meson: axg-card: fix codec-to-codec link setupJerome Brunet1-1/+3
Since the addition of commit 9b5db059366a ("ASoC: soc-pcm: dpcm: Only allow playback/capture if supported"), meson-axg cards which have codec-to-codec links fail to init and Oops: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000128 Internal error: Oops: 96000044 [#1] PREEMPT SMP CPU: 3 PID: 1582 Comm: arecord Not tainted 5.7.0-rc1 pc : invalidate_paths_ep+0x30/0xe0 lr : snd_soc_dapm_dai_get_connected_widgets+0x170/0x1a8 Call trace: invalidate_paths_ep+0x30/0xe0 snd_soc_dapm_dai_get_connected_widgets+0x170/0x1a8 dpcm_path_get+0x38/0xd0 dpcm_fe_dai_open+0x70/0x920 snd_pcm_open_substream+0x564/0x840 snd_pcm_open+0xfc/0x228 snd_pcm_capture_open+0x4c/0x78 snd_open+0xac/0x1a8 ... While initiliazing the links, ASoC treats the codec-to-codec links of this card type as a DPCM backend. This error eventually leads to the Oops. Most of the card driver code is shared between DPCM backends and codec-to-codec links. The property "no_pcm" marking DCPM BE was left set on codec-to-codec links, leading to this problem. This commit fixes that. Fixes: 0a8f1117a680 ("ASoC: meson: axg-card: add basic codec-to-codec link support") Signed-off-by: Jerome Brunet <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2020-04-20Merge tag 'iio-fixes-for-5.7a' of ↵Greg Kroah-Hartman17-111/+400
git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus Jonathan writes: First set of IIO fixes for the 5.7 cycle. Includes one MAINTAINERS update to avoid people getting a lot of bounce messages and complaining about it. * MAINTAINERS - Drop Stefan Popa's Analog Devices email address in favour of Michael Hennerich. * core - Fix handling of dB sysfs inputs. - Drop a stray semi colon in macro definition. * ad5770r - Fix an off by one in chec on maximum number of channels. * ad7192 - Fix a null pointer de-reference due to the name previously being retrieved from the spi_get_device_id call which no longer works as the relevant table was removed. * ad7797 - Use correct attribute group. * counter/104-quad-8 - Add locks to prevent some race conditions. * inv-mpu6050 - Fix issues around suspend / resume clashing with runtime PM. * stm32-adc - Fix sleep in invalid context - Fix id relative path error in device tree binding doc. * st_lsm6dsx - Fix a read alignment issue on an untagged FIFO. - Handle odr for slave to properly compute the FIFO data layout / pattern. - Flush the HW FIFO before resettting the device to avoid a race on interrupt line 1. * st_sensors - Rely on ODR mask not ODR address to identify if the ODR can be set. Some devices have an ODR address of 0. * ti-ads8344 - Byte ordering was wrong - fix it. * xilinx-xadc - Fix inverted logic in powering down the second ADC. - Fix clearing interrupt when enabling the trigger. - Fix configuration of sequencer when in simultaneous sampling mode. - Limit initial sampling rate as done for runtime configured ones. * tag 'iio-fixes-for-5.7a' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio: MAINTAINERS: remove Stefan Popa's email iio: adc: ad7192: fix null pointer de-reference crash during probe iio: core: remove extra semi-colon from devm_iio_device_register() macro iio: adc: ti-ads8344: properly byte swap value iio: imu: inv_mpu6050: fix suspend/resume with runtime power iio: st_sensors: rely on odr mask to know if odr can be set iio: xilinx-xadc: Make sure not exceed maximum samplerate iio: xilinx-xadc: Fix sequencer configuration for aux channels in simultaneous mode iio: xilinx-xadc: Fix clearing interrupt when enabling trigger iio: xilinx-xadc: Fix ADC-B powerdown iio: dac: ad5770r: fix off-by-one check on maximum number of channels iio: imu: st_lsm6dsx: flush hw FIFO before resetting the device iio: core: Fix handling of 'dB' dt-bindings: iio: adc: stm32-adc: fix id relative path counter: 104-quad-8: Add lock guards - generic interface iio: imu: st_lsm6dsx: specify slave odr in slv_odr iio: imu: st_lsm6dsx: fix read misalignment on untagged FIFO iio: adc: stm32-adc: fix sleep in atomic context iio:ad7797: Use correct attribute_group
Powered by cgit, Gruvboxed by Blaster4385.