aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2021-04-17Merge branch 'akpm' (patches from Andrew)Linus Torvalds25-59/+66
Merge misc fixes from Andrew Morton: "12 patches. Subsystems affected by this patch series: mm (documentation, kasan, and pagemap), csky, ia64, gcov, and lib" * emailed patches from Andrew Morton <[email protected]>: lib: remove "expecting prototype" kernel-doc warnings gcov: clang: fix clang-11+ build mm: ptdump: fix build failure mm/mapping_dirty_helpers: guard hugepage pud's usage ia64: tools: remove duplicate definition of ia64_mf() on ia64 ia64: tools: remove inclusion of ia64-specific version of errno.h header ia64: fix discontig.c section mismatches ia64: remove duplicate entries in generic_defconfig csky: change a Kconfig symbol name to fix e1000 build error kasan: remove redundant config option kasan: fix hwasan build for gcc mm: eliminate "expecting prototype" kernel-doc warnings
2021-04-17ALSA: usb-audio: Add support for many Roland devices' implicit feedback quirksLucas Endres1-0/+59
It makes USB audio capture and playback possible and pristine on my Roland INTEGRA-7, Boutique D-05, and R-26, along with many more I've encountered people having had issues with over the last decade or so. Signed-off-by: Lucas Endres <[email protected]> Link: https://lore.kernel.org/r/CAOsVg8rA61B=005_VyUwpw3piVwA7Bo5fs1GYEB054efyzGjLw@mail.gmail.com Signed-off-by: Takashi Iwai <[email protected]>
2021-04-16cxl/mem: Fix memory device capacity probingDan Williams1-2/+5
The CXL Identify Memory Device output payload emits capacity in 256MB units. The driver is treating the capacity field as bytes. This was missed because QEMU reports bytes when it should report bytes / 256MB. Fixes: 8adaf747c9f0 ("cxl/mem: Find device capabilities") Reviewed-by: Vishal Verma <[email protected]> Cc: Ben Widawsky <[email protected]> Link: https://lore.kernel.org/r/161862021044.3259705.7008520073059739760.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Dan Williams <[email protected]>
2021-04-16netlink: don't call ->netlink_bind with table lock heldFlorian Westphal1-2/+2
When I added support to allow generic netlink multicast groups to be restricted to subscribers with CAP_NET_ADMIN I was unaware that a genl_bind implementation already existed in the past. It was reverted due to ABBA deadlock: 1. ->netlink_bind gets called with the table lock held. 2. genetlink bind callback is invoked, it grabs the genl lock. But when a new genl subsystem is (un)registered, these two locks are taken in reverse order. One solution would be to revert again and add a comment in genl referring 1e82a62fec613, "genetlink: remove genl_bind"). This would need a second change in mptcp to not expose the raw token value anymore, e.g. by hashing the token with a secret key so userspace can still associate subflow events with the correct mptcp connection. However, Paolo Abeni reminded me to double-check why the netlink table is locked in the first place. I can't find one. netlink_bind() is already called without this lock when userspace joins a group via NETLINK_ADD_MEMBERSHIP setsockopt. Same holds for the netlink_unbind operation. Digging through the history, commit f773608026ee1 ("netlink: access nlk groups safely in netlink bind and getname") expanded the lock scope. commit 3a20773beeeeade ("net: netlink: cap max groups which will be considered in netlink_bind()") ... removed the nlk->ngroups access that the lock scope extension was all about. Reduce the lock scope again and always call ->netlink_bind without the table lock. The Fixes tag should be vs. the patch mentioned in the link below, but that one got squash-merged into the patch that came earlier in the series. Fixes: 4d54cc32112d8d ("mptcp: avoid lock_fast usage in accept path") Link: https://lore.kernel.org/mptcp/[email protected]/T/#u Cc: Cong Wang <[email protected]> Cc: Xin Long <[email protected]> Cc: Johannes Berg <[email protected]> Cc: Sean Tranchetti <[email protected]> Cc: Paolo Abeni <[email protected]> Cc: Pablo Neira Ayuso <[email protected]> Signed-off-by: Florian Westphal <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2021-04-16Merge tag 'io_uring-5.12-2021-04-16' of git://git.kernel.dk/linux-blockLinus Torvalds1-2/+5
Pull io_uring fix from Jens Axboe: "Fix for a potential hang at exit with SQPOLL from Pavel" * tag 'io_uring-5.12-2021-04-16' of git://git.kernel.dk/linux-block: io_uring: fix early sqd_list removal sqpoll hangs
2021-04-16lib: remove "expecting prototype" kernel-doc warningsRandy Dunlap4-10/+12
Fix various kernel-doc warnings in lib/ due to missing or erroneous function names. Add kernel-doc for some function parameters that was missing. Use kernel-doc "Return:" notation in earlycpio.c. Quietens the following warnings: lib/earlycpio.c:61: warning: expecting prototype for cpio_data find_cpio_data(). Prototype was for find_cpio_data() instead lib/lru_cache.c:640: warning: expecting prototype for lc_dump(). Prototype was for lc_seq_dump_details() instead lru_cache.c:90: warning: Function parameter or member 'cache' not described in 'lc_create' lib/parman.c:368: warning: expecting prototype for parman_item_del(). Prototype was for parman_item_remove() instead parman.c:309: warning: Excess function parameter 'prority' description in 'parman_prio_init' lib/radix-tree.c:703: warning: expecting prototype for __radix_tree_insert(). Prototype was for radix_tree_insert() instead radix-tree.c:180: warning: Excess function parameter 'addr' description in 'radix_tree_find_next_bit' radix-tree.c:180: warning: Excess function parameter 'size' description in 'radix_tree_find_next_bit' radix-tree.c:931: warning: Function parameter or member 'iter' not described in 'radix_tree_iter_replace' Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Randy Dunlap <[email protected]> Cc: Philipp Reisner <[email protected]> Cc: Lars Ellenberg <[email protected]> Cc: Jiri Pirko <[email protected]> Cc: Matthew Wilcox <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2021-04-16gcov: clang: fix clang-11+ buildJohannes Berg1-1/+1
With clang-11+, the code is broken due to my kvmalloc() conversion (which predated the clang-11 support code) leaving one vmalloc() in place. Fix that. Link: https://lkml.kernel.org/r/20210412214210.6e1ecca9cdc5.I24459763acf0591d5e6b31c7e3a59890d802f79c@changeid Signed-off-by: Johannes Berg <[email protected]> Reviewed-by: Nick Desaulniers <[email protected]> Tested-by: Nick Desaulniers <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2021-04-16mm: ptdump: fix build failureChristophe Leroy1-1/+1
READ_ONCE() cannot be used for reading PTEs. Use ptep_get() instead, to avoid the following errors: CC mm/ptdump.o In file included from <command-line>: mm/ptdump.c: In function 'ptdump_pte_entry': include/linux/compiler_types.h:320:38: error: call to '__compiletime_assert_207' declared with attribute error: Unsupported access size for {READ,WRITE}_ONCE(). 320 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) | ^ include/linux/compiler_types.h:301:4: note: in definition of macro '__compiletime_assert' 301 | prefix ## suffix(); \ | ^~~~~~ include/linux/compiler_types.h:320:2: note: in expansion of macro '_compiletime_assert' 320 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) | ^~~~~~~~~~~~~~~~~~~ include/asm-generic/rwonce.h:36:2: note: in expansion of macro 'compiletime_assert' 36 | compiletime_assert(__native_word(t) || sizeof(t) == sizeof(long long), \ | ^~~~~~~~~~~~~~~~~~ include/asm-generic/rwonce.h:49:2: note: in expansion of macro 'compiletime_assert_rwonce_type' 49 | compiletime_assert_rwonce_type(x); \ | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ mm/ptdump.c:114:14: note: in expansion of macro 'READ_ONCE' 114 | pte_t val = READ_ONCE(*pte); | ^~~~~~~~~ make[2]: *** [mm/ptdump.o] Error 1 See commit 481e980a7c19 ("mm: Allow arches to provide ptep_get()") and commit c0e1c8c22beb ("powerpc/8xx: Provide ptep_get() with 16k pages") for details. Link: https://lkml.kernel.org/r/912b349e2bcaa88939904815ca0af945740c6bd4.1618478922.git.christophe.leroy@csgroup.eu Fixes: 30d621f6723b ("mm: add generic ptdump") Signed-off-by: Christophe Leroy <[email protected]> Cc: Steven Price <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2021-04-16mm/mapping_dirty_helpers: guard hugepage pud's usageZack Rusin1-0/+2
Mapping dirty helpers have, so far, been only used on X86, but a port of vmwgfx to ARM64 exposed a problem which results in a compilation error on ARM64 systems: mm/mapping_dirty_helpers.c: In function `wp_clean_pud_entry': mm/mapping_dirty_helpers.c:172:32: error: implicit declaration of function `pud_dirty'; did you mean `pmd_dirty'? [-Werror=implicit-function-declaration] This is due to the fact that mapping_dirty_helpers code assumes that pud_dirty is always defined, which is not the case for architectures that don't define CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD. ARM64 arch is a little inconsistent when it comes to PUD hugepage helpers, e.g. it defines pud_young but not pud_dirty but regardless of that the core kernel code shouldn't assume that any of the PUD hugepage helpers are available unless CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD is defined. This prevents compilation errors whenever one of the drivers is ported to new architectures. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Zack Rusin <[email protected]> Reviewed-by: Thomas Hellstrm (Intel) <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2021-04-16ia64: tools: remove duplicate definition of ia64_mf() on ia64John Paul Adrian Glaubitz1-3/+0
The ia64_mf() macro defined in tools/arch/ia64/include/asm/barrier.h is already defined in <asm/gcc_intrin.h> on ia64 which causes libbpf failing to build: CC /usr/src/linux/tools/bpf/bpftool//libbpf/staticobjs/libbpf.o In file included from /usr/src/linux/tools/include/asm/barrier.h:24, from /usr/src/linux/tools/include/linux/ring_buffer.h:4, from libbpf.c:37: /usr/src/linux/tools/include/asm/../../arch/ia64/include/asm/barrier.h:43: error: "ia64_mf" redefined [-Werror] 43 | #define ia64_mf() asm volatile ("mf" ::: "memory") | In file included from /usr/include/ia64-linux-gnu/asm/intrinsics.h:20, from /usr/include/ia64-linux-gnu/asm/swab.h:11, from /usr/include/linux/swab.h:8, from /usr/include/linux/byteorder/little_endian.h:13, from /usr/include/ia64-linux-gnu/asm/byteorder.h:5, from /usr/src/linux/tools/include/uapi/linux/perf_event.h:20, from libbpf.c:36: /usr/include/ia64-linux-gnu/asm/gcc_intrin.h:382: note: this is the location of the previous definition 382 | #define ia64_mf() __asm__ volatile ("mf" ::: "memory") | cc1: all warnings being treated as errors Thus, remove the definition from tools/arch/ia64/include/asm/barrier.h. Signed-off-by: John Paul Adrian Glaubitz <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2021-04-16ia64: tools: remove inclusion of ia64-specific version of errno.h headerJohn Paul Adrian Glaubitz1-2/+0
There is no longer an ia64-specific version of the errno.h header below arch/ia64/include/uapi/asm/, so trying to build tools/bpf fails with: CC /usr/src/linux/tools/bpf/bpftool/btf_dumper.o In file included from /usr/src/linux/tools/include/linux/err.h:8, from btf_dumper.c:11: /usr/src/linux/tools/include/uapi/asm/errno.h:13:10: fatal error: ../../../arch/ia64/include/uapi/asm/errno.h: No such file or directory 13 | #include "../../../arch/ia64/include/uapi/asm/errno.h" | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ compilation terminated. Thus, just remove the inclusion of the ia64-specific errno.h so that the build will use the generic errno.h header on this target which was used there anyway as the ia64-specific errno.h was just a wrapper for the generic header. Fixes: c25f867ddd00 ("ia64: remove unneeded uapi asm-generic wrappers") Signed-off-by: John Paul Adrian Glaubitz <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2021-04-16ia64: fix discontig.c section mismatchesRandy Dunlap1-3/+3
Fix IA64 discontig.c Section mismatch warnings. When CONFIG_SPARSEMEM=y and CONFIG_MEMORY_HOTPLUG=y, the functions computer_pernodesize() and scatter_node_data() should not be marked as __meminit because they are needed after init, on any memory hotplug event. Also, early_nr_cpus_node() is called by compute_pernodesize(), so early_nr_cpus_node() cannot be __meminit either. WARNING: modpost: vmlinux.o(.text.unlikely+0x1612): Section mismatch in reference from the function arch_alloc_nodedata() to the function .meminit.text:compute_pernodesize() The function arch_alloc_nodedata() references the function __meminit compute_pernodesize(). This is often because arch_alloc_nodedata lacks a __meminit annotation or the annotation of compute_pernodesize is wrong. WARNING: modpost: vmlinux.o(.text.unlikely+0x1692): Section mismatch in reference from the function arch_refresh_nodedata() to the function .meminit.text:scatter_node_data() The function arch_refresh_nodedata() references the function __meminit scatter_node_data(). This is often because arch_refresh_nodedata lacks a __meminit annotation or the annotation of scatter_node_data is wrong. WARNING: modpost: vmlinux.o(.text.unlikely+0x1502): Section mismatch in reference from the function compute_pernodesize() to the function .meminit.text:early_nr_cpus_node() The function compute_pernodesize() references the function __meminit early_nr_cpus_node(). This is often because compute_pernodesize lacks a __meminit annotation or the annotation of early_nr_cpus_node is wrong. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Randy Dunlap <[email protected]> Cc: Mike Rapoport <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2021-04-16ia64: remove duplicate entries in generic_defconfigRandy Dunlap1-2/+0
Fix ia64 generic_defconfig duplicate entries, as warned by: arch/ia64/configs/generic_defconfig: warning: override: reassigning to symbol ATA: => 58 arch/ia64/configs/generic_defconfig: warning: override: reassigning to symbol ATA_PIIX: => 59 These 2 symbols still have the same value as in the removed lines. Link: https://lkml.kernel.org/r/[email protected] Fixes: c331649e6371 ("ia64: Use libata instead of the legacy ide driver in defconfigs") Signed-off-by: Randy Dunlap <[email protected]> Reported-by: Geert Uytterhoeven <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Cc: Tony Luck <[email protected]> Cc: Fenghua Yu <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2021-04-16csky: change a Kconfig symbol name to fix e1000 build errorRandy Dunlap2-2/+2
e1000's #define of CONFIG_RAM_BASE conflicts with a Kconfig symbol in arch/csky/Kconfig. The symbol in e1000 has been around longer, so change arch/csky/ to use DRAM_BASE instead of RAM_BASE to remove the conflict. (although e1000 is also a 2-line change) Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Randy Dunlap <[email protected]> Reported-by: kernel test robot <[email protected]> Acked-by: Guo Ren <[email protected]> Cc: Jesse Brandeburg <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2021-04-16kasan: remove redundant config optionWalter Wu9-17/+18
CONFIG_KASAN_STACK and CONFIG_KASAN_STACK_ENABLE both enable KASAN stack instrumentation, but we should only need one config, so that we remove CONFIG_KASAN_STACK_ENABLE and make CONFIG_KASAN_STACK workable. see [1]. When enable KASAN stack instrumentation, then for gcc we could do no prompt and default value y, and for clang prompt and default value n. This patch fixes the following compilation warning: include/linux/kasan.h:333:30: warning: 'CONFIG_KASAN_STACK' is not defined, evaluates to 0 [-Wundef] [[email protected]: fix merge snafu] Link: https://bugzilla.kernel.org/show_bug.cgi?id=210221 [1] Link: https://lkml.kernel.org/r/[email protected] Fixes: d9b571c885a8 ("kasan: fix KASAN_STACK dependency for HW_TAGS") Signed-off-by: Walter Wu <[email protected]> Suggested-by: Dmitry Vyukov <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Acked-by: Arnd Bergmann <[email protected]> Reviewed-by: Andrey Konovalov <[email protected]> Cc: Andrey Ryabinin <[email protected]> Cc: Dmitry Vyukov <[email protected]> Cc: Alexander Potapenko <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2021-04-16kasan: fix hwasan build for gccArnd Bergmann1-6/+6
gcc-11 adds support for -fsanitize=kernel-hwaddress, so it becomes possible to enable CONFIG_KASAN_SW_TAGS. Unfortunately this fails to build at the moment, because the corresponding command line arguments use llvm specific syntax. Change it to use the cc-param macro instead, which works on both clang and gcc. [[email protected]: fixup for "kasan: fix hwasan build for gcc"] Link: https://lkml.kernel.org/r/YHQZVfVVLE/[email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: Marco Elver <[email protected]> Reviewed-by: Marco Elver <[email protected]> Acked-by: Andrey Konovalov <[email protected]> Cc: Masahiro Yamada <[email protected]> Cc: Michal Marek <[email protected]> Cc: Andrey Ryabinin <[email protected]> Cc: Nathan Chancellor <[email protected]> Cc: Nick Desaulniers <[email protected]> Cc: Alexander Potapenko <[email protected]> Cc: Dmitry Vyukov <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2021-04-16mm: eliminate "expecting prototype" kernel-doc warningsRandy Dunlap3-13/+22
Fix stray kernel-doc warnings in mm/ due to mis-typed or missing function names. Quietens these kernel-doc warnings: mm/mmu_gather.c:264: warning: expecting prototype for tlb_gather_mmu(). Prototype was for __tlb_gather_mmu() instead mm/oom_kill.c:180: warning: expecting prototype for Check whether unreclaimable slab amount is greater than(). Prototype was for should_dump_unreclaim_slab() instead mm/shuffle.c:155: warning: expecting prototype for shuffle_free_memory(). Prototype was for __shuffle_free_memory() instead Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Randy Dunlap <[email protected]> Reviewed-by: Matthew Wilcox (Oracle) <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2021-04-16Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpfDavid S. Miller8-111/+175
Daniel Borkmann says: ==================== pull-request: bpf 2021-04-17 The following pull-request contains BPF updates for your *net* tree. We've added 10 non-merge commits during the last 9 day(s) which contain a total of 8 files changed, 175 insertions(+), 111 deletions(-). The main changes are: 1) Fix a potential NULL pointer dereference in libbpf's xsk umem handling, from Ciara Loftus. 2) Mitigate a speculative oob read of up to map value size by tightening the masking window, from Daniel Borkmann. ==================== Signed-off-by: David S. Miller <[email protected]>
2021-04-16MAINTAINERS: update my emailLijun Pan1-1/+1
Update my email and change myself to Reviewer. Signed-off-by: Lijun Pan <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2021-04-16bpf: Update selftests to reflect new error statesDaniel Borkmann6-35/+16
Update various selftest error messages: * The 'Rx tried to sub from different maps, paths, or prohibited types' is reworked into more specific/differentiated error messages for better guidance. * The change into 'value -4294967168 makes map_value pointer be out of bounds' is due to moving the mixed bounds check into the speculation handling and thus occuring slightly later than above mentioned sanity check. * The change into 'math between map_value pointer and register with unbounded min value' is similarly due to register sanity check coming before the mixed bounds check. * The case of 'map access: known scalar += value_ptr from different maps' now loads fine given masks are the same from the different paths (despite max map value size being different). Signed-off-by: Daniel Borkmann <[email protected]> Reviewed-by: John Fastabend <[email protected]> Acked-by: Alexei Starovoitov <[email protected]>
2021-04-16bpf: Tighten speculative pointer arithmetic maskDaniel Borkmann1-29/+44
This work tightens the offset mask we use for unprivileged pointer arithmetic in order to mitigate a corner case reported by Piotr and Benedict where in the speculative domain it is possible to advance, for example, the map value pointer by up to value_size-1 out-of-bounds in order to leak kernel memory via side-channel to user space. Before this change, the computed ptr_limit for retrieve_ptr_limit() helper represents largest valid distance when moving pointer to the right or left which is then fed as aux->alu_limit to generate masking instructions against the offset register. After the change, the derived aux->alu_limit represents the largest potential value of the offset register which we mask against which is just a narrower subset of the former limit. For minimal complexity, we call sanitize_ptr_alu() from 2 observation points in adjust_ptr_min_max_vals(), that is, before and after the simulated alu operation. In the first step, we retieve the alu_state and alu_limit before the operation as well as we branch-off a verifier path and push it to the verification stack as we did before which checks the dst_reg under truncation, in other words, when the speculative domain would attempt to move the pointer out-of-bounds. In the second step, we retrieve the new alu_limit and calculate the absolute distance between both. Moreover, we commit the alu_state and final alu_limit via update_alu_sanitation_state() to the env's instruction aux data, and bail out from there if there is a mismatch due to coming from different verification paths with different states. Reported-by: Piotr Krysiuk <[email protected]> Reported-by: Benedict Schlueter <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Reviewed-by: John Fastabend <[email protected]> Acked-by: Alexei Starovoitov <[email protected]> Tested-by: Benedict Schlueter <[email protected]>
2021-04-16bpf: Move sanitize_val_alu out of op switchDaniel Borkmann1-6/+11
Add a small sanitize_needed() helper function and move sanitize_val_alu() out of the main opcode switch. In upcoming work, we'll move sanitize_ptr_alu() as well out of its opcode switch so this helps to streamline both. Signed-off-by: Daniel Borkmann <[email protected]> Reviewed-by: John Fastabend <[email protected]> Acked-by: Alexei Starovoitov <[email protected]>
2021-04-16bpf: Refactor and streamline bounds check into helperDaniel Borkmann1-16/+33
Move the bounds check in adjust_ptr_min_max_vals() into a small helper named sanitize_check_bounds() in order to simplify the former a bit. Signed-off-by: Daniel Borkmann <[email protected]> Reviewed-by: John Fastabend <[email protected]> Acked-by: Alexei Starovoitov <[email protected]>
2021-04-16bpf: Improve verifier error messages for usersDaniel Borkmann1-23/+63
Consolidate all error handling and provide more user-friendly error messages from sanitize_ptr_alu() and sanitize_val_alu(). Signed-off-by: Daniel Borkmann <[email protected]> Reviewed-by: John Fastabend <[email protected]> Acked-by: Alexei Starovoitov <[email protected]>
2021-04-16bpf: Rework ptr_limit into alu_limit and add common error pathDaniel Borkmann1-8/+13
Small refactor with no semantic changes in order to consolidate the max ptr_limit boundary check. Signed-off-by: Daniel Borkmann <[email protected]> Reviewed-by: John Fastabend <[email protected]> Acked-by: Alexei Starovoitov <[email protected]>
2021-04-16bpf: Ensure off_reg has no mixed signed bounds for all typesDaniel Borkmann1-10/+9
The mixed signed bounds check really belongs into retrieve_ptr_limit() instead of outside of it in adjust_ptr_min_max_vals(). The reason is that this check is not tied to PTR_TO_MAP_VALUE only, but to all pointer types that we handle in retrieve_ptr_limit() and given errors from the latter propagate back to adjust_ptr_min_max_vals() and lead to rejection of the program, it's a better place to reside to avoid anything slipping through for future types. The reason why we must reject such off_reg is that we otherwise would not be able to derive a mask, see details in 9d7eceede769 ("bpf: restrict unknown scalars of mixed signed bounds for unprivileged"). Signed-off-by: Daniel Borkmann <[email protected]> Reviewed-by: John Fastabend <[email protected]> Acked-by: Alexei Starovoitov <[email protected]>
2021-04-16bpf: Move off_reg into sanitize_ptr_aluDaniel Borkmann1-4/+5
Small refactor to drag off_reg into sanitize_ptr_alu(), so we later on can use off_reg for generalizing some of the checks for all pointer types. Signed-off-by: Daniel Borkmann <[email protected]> Reviewed-by: John Fastabend <[email protected]> Acked-by: Alexei Starovoitov <[email protected]>
2021-04-16bpf: Use correct permission flag for mixed signed bounds arithmeticDaniel Borkmann1-1/+1
We forbid adding unknown scalars with mixed signed bounds due to the spectre v1 masking mitigation. Hence this also needs bypass_spec_v1 flag instead of allow_ptr_leaks. Fixes: 2c78ee898d8f ("bpf: Implement CAP_BPF") Signed-off-by: Daniel Borkmann <[email protected]> Reviewed-by: John Fastabend <[email protected]> Acked-by: Alexei Starovoitov <[email protected]>
2021-04-16ASoC: mt6359: Drop ASoC mt6359 ASoC accdet jack documentRob Herring1-164/+0
This reverts commit e61c589587c772c5f672b22683c3e0b38be20702. The binding document has lots of schema errors and there's been no effort to fix them, so let's remove it. Cc: Argus Lin <[email protected]> Cc: Mark Brown <[email protected]> Cc: Liam Girdwood <[email protected]> Cc: Matthias Brugger <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Signed-off-by: Rob Herring <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2021-04-16Merge tag 'riscv-for-linus-5.12-rc8' of ↵Linus Torvalds5-2/+16
git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux Pull RISC-V fixes from Palmer Dabbelt: "A handful of fixes: - a fix to properly select SPARSEMEM_STATIC on rv32 - a few fixes to kprobes I don't generally like sending stuff this late, but these all seem pretty safe" * tag 'riscv-for-linus-5.12-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux: riscv: keep interrupts disabled for BREAKPOINT exception riscv: kprobes/ftrace: Add recursion protection to the ftrace callback riscv: add do_page_fault and do_trap_break into the kprobes blacklist riscv: Fix spelling mistake "SPARSEMEM" to "SPARSMEM"
2021-04-16Merge tag 'arm64-fixes' of ↵Linus Torvalds1-4/+4
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux Pull arm64 fix from Catalin Marinas: "Fix kernel compilation when using the LLVM integrated assembly. A recent commit (2decad92f473, "arm64: mte: Ensure TIF_MTE_ASYNC_FAULT is set atomically") broke the kernel build when using the LLVM integrated assembly (only noticeable with clang-12 as MTE is not supported by earlier versions and the code in question not compiled). The Fixes: tag in the commit refers to the original patch introducing subsections for the alternative code sequences" * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: arm64: alternatives: Move length validation in alternative_{insn, endif}
2021-04-16ASoC: rt715: remove kcontrols which no longer be usedJack Yu2-68/+36
Using new kcontrols "Capture Switch" and "Capture Volume" instead, remove kcontrols which no longer be used. Signed-off-by: Jack Yu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2021-04-16ASoC: rt715: add main capture switch and main capture volumeJack Yu2-0/+258
Add main capture switch and main capture volume control. Main capture control has its own channel value respectivelly. Signed-off-by: Jack Yu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2021-04-16ASoC: rt715: modification for code simplicityJack Yu1-4/+4
Modification for code simplicity. Signed-off-by: Jack Yu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2021-04-16Merge series "ASoC: Intel: add new TGL/ADL configurations" from Pierre-Louis ↵Mark Brown2-0/+234
Bossart <[email protected]>: Very little code but quite a few descriptors to add TigerLake (TGL) /AlderLake (ADL) ACPI match tables for I2S and SoundWire devices, new dailinks for Bluetooth offload. Some day this will be read from platform firmware. Also clarify how microphones are handled for SoundWire devices, and create modules to avoid linking the same code multiple times. Pierre-Louis Bossart (5): ASoC: Intel: soc-acpi: add ADL SoundWire base configurations ASoC: Intel: soc-acpi: add ADL jack-less SoundWire configurations ASoC: Intel: sof_sdw: add mutual exclusion between PCH DMIC and RT715 ASoC: Intel: boards: handle hda-dsp-common as a module ASoC: Intel: boards: create sof-maxim-common module Vamshi Krishna Gopal (3): ASoC: Intel: soc-acpi: add entries for i2s machines in ADL match table ASoC: Intel: sof_sdw: add quirk for new ADL-P Rvp ASoC: Intel: boards: add support for adl boards in sof-rt5682 Yong Zhi (1): ASoC: Intel: Boards: tgl_max98373: Add BT offload support sound/soc/intel/boards/Kconfig | 18 ++ sound/soc/intel/boards/Makefile | 28 +- sound/soc/intel/boards/bxt_da7219_max98357a.c | 1 + sound/soc/intel/boards/bxt_rt298.c | 1 + sound/soc/intel/boards/cml_rt1011_rt5682.c | 1 + sound/soc/intel/boards/ehl_rt5660.c | 1 + sound/soc/intel/boards/glk_rt5682_max98357a.c | 1 + sound/soc/intel/boards/hda_dsp_common.c | 5 + sound/soc/intel/boards/skl_hda_dsp_generic.c | 1 + sound/soc/intel/boards/sof_da7219_max98373.c | 1 + sound/soc/intel/boards/sof_maxim_common.c | 24 +- sound/soc/intel/boards/sof_maxim_common.h | 6 +- sound/soc/intel/boards/sof_pcm512x.c | 1 + sound/soc/intel/boards/sof_rt5682.c | 67 ++++- sound/soc/intel/boards/sof_sdw.c | 32 ++- sound/soc/intel/boards/sof_sdw_common.h | 1 + sound/soc/intel/boards/sof_sdw_max98373.c | 4 +- .../intel/common/soc-acpi-intel-adl-match.c | 249 ++++++++++++++++++ 18 files changed, 415 insertions(+), 27 deletions(-) -- 2.25.1
2021-04-16Merge series "ASoC: soc-pcm: ignore dummy-DAI at soc_pcm_params_symmetry()" ↵Mark Brown4-7/+16
from Kuninori Morimoto <[email protected]>: Hi Mark I noticed if we have... 1) Sound Card used DPCM 2) It exchanges rate to 48kHz by using .be_hw_params_fixup() 3) Codec had symmetric_rate = 1 We will get below error. I didn't confirm, but maybe same things happen if it exchanged channels/sample_bits. # aplay 44100.wav # aplay 44100.wav => [kernel] be.ak4613-hifi: ASoC: unmatched rate symmetry: snd-soc-dummy-dai:44100 - soc_pcm_params_symmetry:48000 [kernel] be.ak4613-hifi: ASoC: hw_params BE failed -22 [kernel] fe.rsnd-dai.0: ASoC: hw_params BE failed -22 aplay: set_params:1407: Unable to install hw params: ACCESS: RW_INTERLEAVED FORMAT: S16_LE SUBFORMAT: STD SAMPLE_BITS: 16 FRAME_BITS: 32 CHANNELS: 2 RATE: 44100 PERIOD_TIME: (23219 23220) PERIOD_SIZE: 1024 PERIOD_BYTES: 4096 PERIODS: 4 BUFFER_TIME: (92879 92880) BUFFER_SIZE: 4096 BUFFER_BYTES: 16384 TICK_TIME: 0 This patch-set solves this issue. patch 1) - 3) are just cleanup patches. 4) is fot this issue. Link: https://lore.kernel.org/r/[email protected] Kuninori Morimoto (4): ASoC: soc-pcm: don't use "name" on __soc_pcm_params_symmetry() macro ASoC: soc-pcm: indicate DAI name if soc_pcm_params_symmetry() failed ASoC: soc-utils: add snd_soc_component_is_dummy() ASoC: soc-pcm: ignore dummy-DAI at soc_pcm_params_symmetry() include/sound/soc-component.h | 1 + sound/soc/soc-core.c | 2 +- sound/soc/soc-pcm.c | 14 ++++++++------ sound/soc/soc-utils.c | 6 ++++++ 4 files changed, 16 insertions(+), 7 deletions(-) -- 2.25.1
2021-04-16ASoC: simple-card-utils: Increase maximum number of links to 128Thierry Reding3-5/+7
On Tegra186 and later, the number of links can go up to 72, so bump the maximum number of links to the next power of two (128). Fixes: f2138aed231c ("ASoC: simple-card-utils: enable flexible CPU/Codec/Platform") Signed-off-by: Thierry Reding <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Jon Hunter <[email protected]> Tested-by: Jon Hunter <[email protected]> Signed-off-by: Mark Brown <[email protected]>
2021-04-16ASoC: simple-card-utils: Propagate errors on too many linksThierry Reding2-15/+21
The DAI counting code doesn't propagate errors when the number of maximum links is exceeded, which causes subsequent initialization code to continue to run and that eventually leads to memory corruption with the code trying to access memory that is out of bounds. Fix this by propagating errors when the maximum number of links is reached, which ensures that the driver fails to load and prevents the memory corruption. Fixes: f2138aed231c ("ASoC: simple-card-utils: enable flexible CPU/Codec/Platform") Signed-off-by: Thierry Reding <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Jon Hunter <[email protected]> Tested-by: Jon Hunter <[email protected]> Signed-off-by: Mark Brown <[email protected]>
2021-04-16Merge tag 'drm-fixes-2021-04-16' of git://anongit.freedesktop.org/drm/drmLinus Torvalds3-5/+4
Pull drm fixes from Daniel Vetter: "I pinged the usual suspects, only intel fixes pending" * tag 'drm-fixes-2021-04-16' of git://anongit.freedesktop.org/drm/drm: drm/i915/display/vlv_dsi: Do not skip panel_pwr_cycle_delay when disabling the panel drm/i915: Don't zero out the Y plane's watermarks drm/i915/dpcd_bl: Don't try vesa interface unless specified by VBT
2021-04-16ALSA: hda/hdmi: fix race in handling acomp ELD notification at resumeKai Vehmanen1-2/+2
When snd-hda-codec-hdmi is used with ASoC HDA controller like SOF (acomp used for ELD notifications), display connection change done during suspend, can be lost due to following sequence of events: 1. system in S3 suspend 2. DP/HDMI receiver connected 3. system resumed 4. HDA controller resumed, but card->deferred_resume_work not complete 5. acomp eld_notify callback 6. eld_notify ignored as power state is not CTL_POWER_D0 7. HDA resume deferred work completed, power state set to CTL_POWER_D0 This results in losing the notification, and the jack state reported to user-space is not correct. The check on step 6 was added in commit 8ae743e82f0b ("ALSA: hda - Skip ELD notification during system suspend"). It would seem with the deferred resume logic in ASoC core, this check is not safe. Fix the issue by modifying the check to use "dev.power.power_state.event" instead of ALSA specific card power state variable. BugLink: https://github.com/thesofproject/linux/issues/2825 Suggested-by: Takashi Iwai <[email protected]> Signed-off-by: Kai Vehmanen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]>
2021-04-16ASoC: soc-pcm: ignore dummy-DAI at soc_pcm_params_symmetry()Kuninori Morimoto1-1/+2
soc_pcm_params_symmetry() checks CPU / Codec symmetry. Unfortunately there was bug on it (= A) which didn't check Codec. But is back by (B). A: v5.7: commit c840f7698d26 ("ASoC: soc-pcm: Merge for_each_rtd_cpu/codec_dais()") B: v5.12: commit 3a9067211122 ("ASoC: soc-pcm: cleanup soc_pcm_params_symmetry()") In total, old - v5.6 (= Generation-1): symmetric_rate : DAI_Link / CPU / Codec symmetric_channels : DAI_Link / CPU / Codec symmetric_sample_bits : DAI_Link / CPU / Codec v5.7 - v5.11 (= Generation-2): (= because of bug by (A)) symmetric_rate : DAI_Link / CPU symmetric_channels : DAI_Link / CPU / Codec symmetric_sample_bits : DAI_Link / CPU / Codec v5.12 - (= Generation-3): (= back by (B)) symmetric_rate : DAI_Link / CPU / Codec symmetric_channels : DAI_Link / CPU / Codec symmetric_sample_bits : DAI_Link / CPU / Codec OTOH, we can use DPCM which is configured by FE / BE. Both FE / BE uses dummy-DAI. FE: CPU <-> dummy-DAI BE: dummy-DAI <-> Codec One note is that we can use .be_hw_params_fixup in DPCM case. This means BE settings might be fixuped/updated by FE. This feature is used for example on MIXer case. It can be happen not only for rate, but for channels/sample_bits too. Because of these reasons, below issue happen on Generation-1 / Generation-3, if... 1) Sound Card used DPCM 2) It exchanges rate to 48kHz by using .be_hw_params_fixup() 3) Codec had symmetric_rate = 1 I didn't confirm, but maybe same things happen if it exchanged channels/sample_bits at Generation-1/2/3 too. # aplay 44100.wav # aplay 44100.wav => [kernel] be.ak4613-hifi: ASoC: unmatched rate symmetry: snd-soc-dummy-dai:44100 - soc_pcm_params_symmetry:48000 [kernel] be.ak4613-hifi: ASoC: hw_params BE failed -22 [kernel] fe.rsnd-dai.0: ASoC: hw_params BE failed -22 aplay: set_params:1407: Unable to install hw params: ACCESS: RW_INTERLEAVED FORMAT: S16_LE SUBFORMAT: STD SAMPLE_BITS: 16 FRAME_BITS: 32 CHANNELS: 2 RATE: 44100 PERIOD_TIME: (23219 23220) PERIOD_SIZE: 1024 PERIOD_BYTES: 4096 PERIODS: 4 BUFFER_TIME: (92879 92880) BUFFER_SIZE: 4096 BUFFER_BYTES: 16384 TICK_TIME: 0 soc_pcm_params_symmetry() checks by below if (symmetry) for_each_rtd_cpu_dais(rtd, i, cpu_dai) if (cpu_dai->xxx && cpu_dai->xxx != d.xxx) { dev_err(rtd->dev, "..."); return -EINVAL; } Because of above reason 3) (= Codec had symmetric_rate = 1) BE can't ignore "if (symmetric)". At 1st aplay, soc_pcm_params_symmetry() ignores it, because dummy-DAI->rate is 0. After this check, each DAI sets/keep settings. In above sample case, BE gets 48000 and FE gets 44100, and it happen BE -> FE order. Because DPCM is sharing *same* dummy-DAI, dummy-DAI sets as 48000 by BE, and is overwrote by 44100 by FE. This settings never be cleaned (= a) after 1st aplay, because dummy-DAI is used from FE/BE, never be last user (b). static int soc_pcm_hw_clean(...) { ... for_each_rtd_dais(rtd, i, dai) { ... (b) if (snd_soc_dai_active(dai) == 1) (a) soc_pcm_set_dai_params(dai, NULL); ... } ... } At 2nd aplay, BE gets 48000 but dummy-DAI is keeping 44100, soc_pcm_params_symmetry() checks will fail. To solve this issue, this patch ignores dummy-DAI at soc_pcm_params_symmetry() Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Kuninori Morimoto <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2021-04-16ASoC: soc-utils: add snd_soc_component_is_dummy()Kuninori Morimoto3-1/+8
There is snd_soc_dai_is_dummy(), but not for component. This patch adds it. Signed-off-by: Kuninori Morimoto <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2021-04-16ASoC: soc-pcm: indicate DAI name if soc_pcm_params_symmetry() failedKuninori Morimoto1-2/+3
It indicates unmatched symmetry value, but not indicates on which DAI. This patch indicates it. Signed-off-by: Kuninori Morimoto <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2021-04-16ASoC: soc-pcm: don't use "name" on __soc_pcm_params_symmetry() macroKuninori Morimoto1-5/+5
__soc_pcm_params_symmetry() macro is using "name" as parameter which will be exchanged to rate/channles/sample_bit, like below dai->name => dai->rate dai->name => dai->channels dai->name => dai->sample_bit But, dai itself has "name". This means 1) It is very confusable naming 2) It can't use dai->name This patch use "xxx" instead of "name" Signed-off-by: Kuninori Morimoto <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2021-04-16ASoC: core: Don't set platform name when of_node is setDaniel Baluta1-1/+5
A DAI link has 3 components: * CPU * platform * codec(s) A component is specified via: * name * of_node * dai_name In order to avoid confusion when building a sound card we disallow matching by both name and of_node (1). soc_check_tplg_fes allows overriding certain BE links by overriding BE link name. This doesn't work well if BE link was specified via DT, because we end up with a link with both name and of_node specified which is conflicting with (1). In order to fix this we need to: * override of_node if component was specified via DT * override name, otherwise. Signed-off-by: Daniel Baluta <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2021-04-16ASoC: Intel: sof_sdw: add quirk for new ADL-P RvpVamshi Krishna Gopal1-0/+11
Add quirks for jack detection, rt711 DAI and DMIC Reviewed-by: Bard Liao <[email protected]> Reviewed-by: Kai Vehmanen <[email protected]> Signed-off-by: Vamshi Krishna Gopal <[email protected]> Signed-off-by: Pierre-Louis Bossart <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2021-04-16ASoC: Intel: soc-acpi: add ADL jack-less SoundWire configurationsPierre-Louis Bossart1-0/+38
Add one configuration with no RT711. Signed-off-by: Pierre-Louis Bossart <[email protected]> Reviewed-by: Rander Wang <[email protected]> Reviewed-by: Libin Yang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2021-04-16ASoC: Intel: soc-acpi: add ADL SoundWire base configurationsPierre-Louis Bossart1-0/+185
Add configurations ported over from TGL. The topology names need to include link information given all the hardware permutations. Signed-off-by: Pierre-Louis Bossart <[email protected]> Reviewed-by: Rander Wang <[email protected]> Reviewed-by: Libin Yang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2021-04-16ALSA: hda/realtek: fix mute/micmute LEDs for HP ProBook 445 G7Jonas Witschel1-0/+25
The HP ProBook 445 G7 (17T32ES) uses ALC236. Like ALC236_FIXUP_HP_GPIO_LED, COEF index 0x34 bit 5 is used to control the playback mute LED, but the microphone mute LED is controlled using pin VREF instead of a COEF index. AlsaInfo: https://alsa-project.org/db/?f=0d3f4d1af39cc359f9fea9b550727ee87e5cf45a Signed-off-by: Jonas Witschel <[email protected]> Cc: <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]>
2021-04-16ALSA: hda/realtek: Add quirk for Lenovo Ideapad S740Takashi Iwai2-0/+503
Lenovo Ideapad S740 requires quite a few COEF setups to make its speakers working. The verb table was provided from Ryan Prescott as the result of investigation via qemu: https://github.com/ryanprescott/realtek-verb-tools/wiki/How-to-sniff-verbs-from-a-Windows-sound-driver BugLink: https://github.com/thesofproject/linux/issues/2748 Tested-by: Ryan Prescott <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]>