summaryrefslogtreecommitdiff
path: root/sound/core
AgeCommit message (Collapse)Author
2021-12-22ALSA: rawmidi - fix the uninitalized user_pversionJaroslav Kysela
The user_pversion was uninitialized for the user space file structure in the open function, because the file private structure use kmalloc for the allocation. The kernel ALSA sequencer code clears the file structure, so no additional fixes are required. Cc: stable@kernel.org Cc: broonie@kernel.org BugLink: https://github.com/alsa-project/alsa-lib/issues/178 Fixes: 09d23174402d ("ALSA: rawmidi: introduce SNDRV_RAWMIDI_IOCTL_USER_PVERSION") Reported-by: syzbot+88412ee8811832b00dbe@syzkaller.appspotmail.com Signed-off-by: Jaroslav Kysela <perex@perex.cz> Link: https://lore.kernel.org/r/20211218123925.2583847-1-perex@perex.cz Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-12-13ALSA: jack: Check the return value of kstrdup()Xiaoke Wang
kstrdup() can return NULL, it is better to check the return value of it. Signed-off-by: Xiaoke Wang <xkernel.wang@foxmail.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/tencent_094816F3522E0DC704056C789352EBBF0606@qq.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-12-02ALSA: ctl: Fix copy of updated id with element read/writeAlan Young
When control_compat.c:copy_ctl_value_to_user() is used, by ctl_elem_read_user() & ctl_elem_write_user(), it must also copy back the snd_ctl_elem_id value that may have been updated (filled in) by the call to snd_ctl_elem_read/snd_ctl_elem_write(). This matches the functionality provided by snd_ctl_elem_read_user() and snd_ctl_elem_write_user(), via snd_ctl_build_ioff(). Without this, and without making additional calls to snd_ctl_info() which are unnecessary when using the non-compat calls, a userspace application will not know the numid value for the element and consequently will not be able to use the poll/read interface on the control file to determine which elements have updates. Signed-off-by: Alan Young <consult.awy@gmail.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20211202150607.543389-1-consult.awy@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-12-02ALSA: pcm: oss: Handle missing errors in snd_pcm_oss_change_params*()Takashi Iwai
A couple of calls in snd_pcm_oss_change_params_locked() ignore the possible errors. Catch those errors and abort the operation for avoiding further problems. Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20211201073606.11660-4-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-12-02ALSA: pcm: oss: Limit the period size to 16MBTakashi Iwai
Set the practical limit to the period size (the fragment shift in OSS) instead of a full 31bit; a too large value could lead to the exhaust of memory as we allocate temporary buffers of the period size, too. As of this patch, we set to 16MB limit, which should cover all use cases. Reported-by: syzbot+bb348e9f9a954d42746f@syzkaller.appspotmail.com Reported-by: Bixuan Cui <cuibixuan@linux.alibaba.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/1638270978-42412-1-git-send-email-cuibixuan@linux.alibaba.com Link: https://lore.kernel.org/r/20211201073606.11660-3-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-12-02ALSA: pcm: oss: Fix negative period/buffer sizesTakashi Iwai
The period size calculation in OSS layer may receive a negative value as an error, but the code there assumes only the positive values and handle them with size_t. Due to that, a too big value may be passed to the lower layers. This patch changes the code to handle with ssize_t and adds the proper error checks appropriately. Reported-by: syzbot+bb348e9f9a954d42746f@syzkaller.appspotmail.com Reported-by: Bixuan Cui <cuibixuan@linux.alibaba.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/1638270978-42412-1-git-send-email-cuibixuan@linux.alibaba.com Link: https://lore.kernel.org/r/20211201073606.11660-2-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-11-10ALSA: memalloc: Remove a stale commentTakashi Iwai
The comment about the reused vmalloc helpers is no longer valid after the recent change for the noncontig allocator. Drop the stale comment. Fixes: ad4f93ca4138 ("ALSA: memalloc: Use proper SG helpers for noncontig allocations") Link: https://lore.kernel.org/r/20211110063100.21359-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-11-09ALSA: memalloc: Use proper SG helpers for noncontig allocationsTakashi Iwai
The recently introduced non-contiguous page allocation support helpers are using the simplified code to calculate the page and DMA address based on the vmalloc helpers, but this isn't quite right as the vmap is valid only for the direct DMA. This patch corrects those accessors to use the proper SG helpers instead. Fixes: a25684a95646 ("ALSA: memalloc: Support for non-contiguous page allocation") Tested-by: Alex Xu (Hello71) <alex_y_xu@yahoo.ca> Link: https://lore.kernel.org/r/20211108151059.31898-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-11-07ALSA: PCM: Fix NULL dereference at mmap checksTakashi Iwai
The recent refactoring of mmap handling caused Oops on some devices that don't use the standard memory allocations. This patch addresses it by allowing snd_dma_buffer_mmap() helper to receive the NULL pointer dmab argument (and return an error appropriately). Fixes: a202bd1ad86d ("ALSA: core: Move mmap handler into memalloc ops") Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20211107163911.13534-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-11-05ALSA: timer: Unconditionally unlink slave instances, tooTakashi Iwai
Like the previous fix (commit c0317c0e8709 "ALSA: timer: Fix use-after-free problem"), we have to unlink slave timer instances immediately at snd_timer_stop(), too. Otherwise it may leave a stale entry in the list if the slave instance is freed before actually running. Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20211105091517.21733-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-11-05ALSA: memalloc: Catch call with NULL snd_dma_buffer pointerTakashi Iwai
Although we've covered all calls with NULL dma buffer pointer, so far, there may be still some else in the wild. For catching such a case more easily, add a WARN_ON_ONCE() in snd_dma_get_ops(). Fixes: 37af81c5998f ("ALSA: core: Abstract memory alloc helpers") Link: https://lore.kernel.org/r/20211105102103.28148-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-11-04Revert "ALSA: memalloc: Convert x86 SG-buffer handling with non-contiguous type"Takashi Iwai
This reverts commit 2d9ea39917a4e4293bc2caea902c7059a330b611. We've got a regression report showing that the audio got broken the device over AMD IOMMU. The conversion assumed the wrong pointer / page mapping for the indirect mapping case, and we need to correct this urgently, so let's revert it for now. Fixes: 2d9ea39917a4 ("ALSA: memalloc: Convert x86 SG-buffer handling with non-contiguous type") Reported-and-tested-by: Alex Xu (Hello71) <alex_y_xu@yahoo.ca> Link: https://lore.kernel.org/r/20211104180846.16340-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-11-03ALSA: timer: Fix use-after-free problemWang Wensheng
When the timer instance was add into ack_list but was not currently in process, the user could stop it via snd_timer_stop1() without delete it from the ack_list. Then the user could free the timer instance and when it was actually processed UAF occurred. This issue could be reproduced via testcase snd_timer01 in ltp - running several instances of that testcase at the same time. What I actually met was that the ack_list of the timer broken and the kernel went into deadloop with irqoff. That could be detected by hardlockup detector on board or when we run it on qemu, we could use gdb to dump the ack_list when the console has no response. To fix this issue, we delete the timer instance from ack_list and active_list unconditionally in snd_timer_stop1(). Signed-off-by: Wang Wensheng <wangwensheng4@huawei.com> Suggested-by: Takashi Iwai <tiwai@suse.de> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20211103033517.80531-1-wangwensheng4@huawei.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-11-01Merge branch 'for-next' into for-linusTakashi Iwai
Merge 5.16-devel branch for upstreaming Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-10-26ALSA: mixer: fix deadlock in snd_mixer_oss_set_volumePavel Skripkin
In commit 411cef6adfb3 ("ALSA: mixer: oss: Fix racy access to slots") added mutex protection in snd_mixer_oss_set_volume(). Second mutex_lock() in same function looks like typo, fix it. Reported-by: syzbot+ace149a75a9a0a399ac7@syzkaller.appspotmail.com Fixes: 411cef6adfb3 ("ALSA: mixer: oss: Fix racy access to slots") Cc: <stable@vger.kernel.org> Signed-off-by: Pavel Skripkin <paskripkin@gmail.com> Link: https://lore.kernel.org/r/20211024140315.16704-1-paskripkin@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-10-21ALSA: mixer: oss: Fix racy access to slotsTakashi Iwai
The OSS mixer can reassign the mapping slots dynamically via proc file. Although the addition and deletion of those slots are protected by mixer->reg_mutex, the access to slots aren't, hence this may cause UAF when the slots in use are deleted concurrently. This patch applies the mixer->reg_mutex in all appropriate code paths (i.e. the ioctl functions) that may access slots. Reported-by: syzbot+9988f17cf72a1045a189@syzkaller.appspotmail.com Reviewed-by: Jaroslav Kysela <perex@perex.cz> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/00000000000036adc005ceca9175@google.com Link: https://lore.kernel.org/r/20211020164846.922-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-10-19ALSA: memalloc: Fix a typo in snd_dma_buffer_sync() descriptionTakashi Iwai
It caused a warning for kernel-doc build. Fixes: a25684a95646 ("ALSA: memalloc: Support for non-contiguous page allocation") Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Link: https://lore.kernel.org/r/20211019165402.4fa82c38@canb.auug.org.au Link: https://lore.kernel.org/r/20211019060536.26089-2-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-10-18ALSA: memalloc: Convert x86 SG-buffer handling with non-contiguous typeTakashi Iwai
We've had an x86-specific SG-buffer handling code, but now it can be merged gracefully with the standard non-contiguous DMA pages. After the migration, SNDRV_DMA_TYPE_DMA_SG becomes identical with SNDRV_DMA_TYPE_NONCONTIG on x86, while others still fall back to SNDRV_DMA_TYPE_DEV. The remaining problem is about the SG-buffer with WC pages: the DMA core stuff on x86 doesn't treat it well, so we still need some special handling to manipulate the page attribute manually. The mmap handler for SNDRV_DMA_TYPE_DEV_SG_WC still returns -ENOENT intentionally for the fallback to the default handler. Link: https://lore.kernel.org/r/20211017074859.24112-4-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-10-18ALSA: memalloc: Support for non-coherent page allocationTakashi Iwai
Following to the addition of non-contiguous pages, this patch adds the new contiguous non-coherent page allocation to the standard memalloc helper. Like the previous non-contig type, this non-coherent type is also directional and requires the explicit sync, too. Hence the driver using this type of buffer may need to set SNDRV_PCM_INFO_EXPLICIT_SYNC flag to the PCM hardware.info as well, unless it's set up in the managed mode. Link: https://lore.kernel.org/r/20211017074859.24112-3-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-10-18ALSA: memalloc: Support for non-contiguous page allocationTakashi Iwai
This patch adds the support for allocation of non-contiguous DMA pages in the common memalloc helper. It's another SG-buffer type, but unlike the existing one, this is directional and requires the explicit sync / invalidation of dirty pages on non-coherent architectures. For this enhancement, the following points are changed: - snd_dma_device stores the DMA direction. - snd_dma_device stores need_sync flag indicating whether the explicit sync is required or not. - A new variant of helper functions, snd_dma_alloc_dir_pages() and *_all() are introduced; the old snd_dma_alloc_pages() and *_all() kept as just wrappers with DMA_BIDIRECTIONAL. - A new helper snd_dma_buffer_sync() is introduced; this gets called in the appropriate places. - A new allocation type, SNDRV_DMA_TYPE_NONCONTIG, is introduced. When the driver allocates pages with this new type, and it may require the SNDRV_PCM_INFO_EXPLICIT_SYNC flag set to the PCM hardware.info for taking the full control of PCM applptr and hwptr changes (that implies disabling the mmap of control/status data). When the buffer allocation is managed by snd_pcm_set_managed_buffer(), this flag is automatically set depending on the result of dma_need_sync() internally. Otherwise, if the buffer is managed manually, the driver has to set the flag explicitly, too. The explicit sync between CPU and device for non-coherent memory is performed at the points before and after read/write transfer as well as the applptr/hwptr syncptr ioctl. In the case of mmap mode, user-space is supposed to call the syncptr ioctl with the hwptr flag to update and fetch the status at first; this corresponds to CPU-sync. Then user-space advances the applptr via syncptr ioctl again with applptr flag, and this corresponds to the device sync with flushing. Other than the DMA direction and the explicit sync, the usage of this new buffer type is almost equivalent with the existing SNDRV_DMA_TYPE_DEV_SG; you can get the page and the address via snd_sgbuf_get_page() and snd_sgbuf_get_addr(), also calculate the continuous pages via snd_sgbuf_get_chunk_size(). For those SG-page handling, the non-contig type shares the same ops with the vmalloc handler. As we do always vmap the SG pages at first, the actual address can be deduced from the vmapped address easily without iterating the SG-list. Link: https://lore.kernel.org/r/20211017074859.24112-2-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-10-17ALSA: ISA: not for M68KRandy Dunlap
On m68k, compiling drivers under SND_ISA causes build errors: ../sound/core/isadma.c: In function 'snd_dma_program': ../sound/core/isadma.c:33:17: error: implicit declaration of function 'claim_dma_lock' [-Werror=implicit-function-declaration] 33 | flags = claim_dma_lock(); | ^~~~~~~~~~~~~~ ../sound/core/isadma.c:41:9: error: implicit declaration of function 'release_dma_lock' [-Werror=implicit-function-declaration] 41 | release_dma_lock(flags); | ^~~~~~~~~~~~~~~~ ../sound/isa/sb/sb16_main.c: In function 'snd_sb16_playback_prepare': ../sound/isa/sb/sb16_main.c:253:72: error: 'DMA_AUTOINIT' undeclared (first use in this function) 253 | snd_dma_program(dma, runtime->dma_addr, size, DMA_MODE_WRITE | DMA_AUTOINIT); | ^~~~~~~~~~~~ ../sound/isa/sb/sb16_main.c:253:72: note: each undeclared identifier is reported only once for each function it appears in ../sound/isa/sb/sb16_main.c: In function 'snd_sb16_capture_prepare': ../sound/isa/sb/sb16_main.c:322:71: error: 'DMA_AUTOINIT' undeclared (first use in this function) 322 | snd_dma_program(dma, runtime->dma_addr, size, DMA_MODE_READ | DMA_AUTOINIT); | ^~~~~~~~~~~~ and more... Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: Jaroslav Kysela <perex@perex.cz> Cc: Takashi Iwai <tiwai@suse.com> Cc: alsa-devel@alsa-project.org Cc: linux-m68k@lists.linux-m68k.org Cc: Geert Uytterhoeven <geert@linux-m68k.org> Link: https://lore.kernel.org/r/20211016062602.3588-1-rdunlap@infradead.org Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-10-14ALSA: pcm: Unify snd_pcm_delay() and snd_pcm_hwsync()Takashi Iwai
Both snd_pcm_delay() and snd_pcm_hwsync() do the almost same thing. The only difference is that the former calculate the delay, so unify them as a code cleanup, and treat NULL delay argument only for hwsync operation. Also, the patch does a slight code refactoring in snd_pcm_delay(). The initialization of the delay value is done in the caller side now. Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20211014145323.26506-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-10-14Merge branch 'for-linus' into for-nextTakashi Iwai
A back-merge of 5.15 branch into 5.16-devel branch for further development of USB and ALSA core stuff that depends on 5.15 fixes. Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-10-11ALSA: pcm: Workaround for a wrong offset in SYNC_PTR compat ioctlTakashi Iwai
Michael Forney reported an incorrect padding type that was defined in the commit 80fe7430c708 ("ALSA: add new 32-bit layout for snd_pcm_mmap_status/control") for PCM control mmap data. His analysis is correct, and this caused the misplacements of PCM control data on 32bit arch and 32bit compat mode. The bug is that the __pad2 definition in __snd_pcm_mmap_control64 struct was wrongly with __pad_before_uframe, which should have been __pad_after_uframe instead. This struct is used in SYNC_PTR ioctl and control mmap. Basically this bug leads to two problems: - The offset of avail_min field becomes wrong, it's placed right after appl_ptr without padding on little-endian - When appl_ptr and avail_min are read as 64bit values in kernel side, the values become either zero or corrupted (mixed up) One good news is that, because both user-space and kernel misunderstand the wrong offset, at least, 32bit application running on 32bit kernel works as is. Also, 64bit applications are unaffected because the padding size is zero. The remaining problem is the 32bit compat mode; as mentioned in the above, avail_min is placed right after appl_ptr on little-endian archs, 64bit kernel reads bogus values for appl_ptr updates, which may lead to streaming bugs like jumping, XRUN or whatever unexpected. (However, we haven't heard any serious bug reports due to this over years, so practically seen, it's fairly safe to assume that the impact by this bug is limited.) Ideally speaking, we should correct the wrong mmap status control definition. But this would cause again incompatibility with the existing binaries, and fixing it (e.g. by renumbering ioctls) would be really messy. So, as of this patch, we only correct the behavior of 32bit compat mode and keep the rest as is. Namely, the SYNC_PTR ioctl is now handled differently in compat mode to read/write the 32bit values at the right offsets. The control mmap of 32bit apps on 64bit kernels has been already disabled (which is likely rather an overlook, but this worked fine at this time :), so covering SYNC_PTR ioctl should suffice as a fallback. Fixes: 80fe7430c708 ("ALSA: add new 32-bit layout for snd_pcm_mmap_status/control") Reported-by: Michael Forney <mforney@mforney.org> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Cc: <stable@vger.kernel.org> Cc: Rich Felker <dalias@libc.org> Link: https://lore.kernel.org/r/29QBMJU8DE71E.2YZSH8IHT5HMH@mforney.org Link: https://lore.kernel.org/r/20211010075546.23220-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-10-07ALSA: pcm: Add more disconnection checks at file opsTakashi Iwai
In the case of hot-disconnection of a PCM device, all file operations except for close should be rejected. This patch adds more sanity checks in the file operation code paths. Link: https://lore.kernel.org/r/20211006142214.3089-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-09-30ALSA: seq: Fix a potential UAF by wrong private_free call orderTakashi Iwai
John Keeping reported and posted a patch for a potential UAF in rawmidi sequencer destruction: the snd_rawmidi_dev_seq_free() may be called after the associated rawmidi object got already freed. After a deeper look, it turned out that the bug is rather the incorrect private_free call order for a snd_seq_device. The snd_seq_device private_free gets called at the release callback of the sequencer device object, while this was rather expected to be executed at the snd_device call chains that runs at the beginning of the whole card-free procedure. It's been broken since the rewrite of sequencer-device binding (although it hasn't surfaced because the sequencer device release happens usually right along with the card device release). This patch corrects the private_free call to be done in the right place, at snd_seq_device_dev_free(). Fixes: 7c37ae5c625a ("ALSA: seq: Rewrite sequencer device binding with standard bus") Reported-and-tested-by: John Keeping <john@metanate.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20210930114114.8645-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-09-23ALSA: rawmidi: introduce SNDRV_RAWMIDI_IOCTL_USER_PVERSIONJaroslav Kysela
The new framing mode causes the user space regression, because the alsa-lib code does not initialize the reserved space in the params structure when the device is opened. This change adds SNDRV_RAWMIDI_IOCTL_USER_PVERSION like we do for the PCM interface for the protocol acknowledgment. Cc: David Henningsson <coding@diwic.se> Cc: <stable@vger.kernel.org> Fixes: 08fdced60ca0 ("ALSA: rawmidi: Add framing mode") BugLink: https://github.com/alsa-project/alsa-lib/issues/178 Signed-off-by: Jaroslav Kysela <perex@perex.cz> Link: https://lore.kernel.org/r/20210920171850.154186-1-perex@perex.cz Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-09-03Merge tag 'kbuild-v5.15' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild Pull Kbuild updates from Masahiro Yamada: - Add -s option (strict mode) to merge_config.sh to make it fail when any symbol is redefined. - Show a warning if a different compiler is used for building external modules. - Infer --target from ARCH for CC=clang to let you cross-compile the kernel without CROSS_COMPILE. - Make the integrated assembler default (LLVM_IAS=1) for CC=clang. - Add <linux/stdarg.h> to the kernel source instead of borrowing <stdarg.h> from the compiler. - Add Nick Desaulniers as a Kbuild reviewer. - Drop stale cc-option tests. - Fix the combination of CONFIG_TRIM_UNUSED_KSYMS and CONFIG_LTO_CLANG to handle symbols in inline assembly. - Show a warning if 'FORCE' is missing for if_changed rules. - Various cleanups * tag 'kbuild-v5.15' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: (39 commits) kbuild: redo fake deps at include/ksym/*.h kbuild: clean up objtool_args slightly modpost: get the *.mod file path more simply checkkconfigsymbols.py: Fix the '--ignore' option kbuild: merge vmlinux_link() between ARCH=um and other architectures kbuild: do not remove 'linux' link in scripts/link-vmlinux.sh kbuild: merge vmlinux_link() between the ordinary link and Clang LTO kbuild: remove stale *.symversions kbuild: remove unused quiet_cmd_update_lto_symversions gen_compile_commands: extract compiler command from a series of commands x86: remove cc-option-yn test for -mtune= arc: replace cc-option-yn uses with cc-option s390: replace cc-option-yn uses with cc-option ia64: move core-y in arch/ia64/Makefile to arch/ia64/Kbuild sparc: move the install rule to arch/sparc/Makefile security: remove unneeded subdir-$(CONFIG_...) kbuild: sh: remove unused install script kbuild: Fix 'no symbols' warning when CONFIG_TRIM_UNUSD_KSYMS=y kbuild: Switch to 'f' variants of integrated assembler flag kbuild: Shuffle blank line to improve comment meaning ...
2021-08-30Merge branch 'for-linus' into for-nextTakashi Iwai
2021-08-27ALSA: pcm: fix divide error in snd_pcm_lib_ioctlZubin Mithra
Syzkaller reported a divide error in snd_pcm_lib_ioctl. fifo_size is of type snd_pcm_uframes_t(unsigned long). If frame_size is 0x100000000, the error occurs. Fixes: a9960e6a293e ("ALSA: pcm: fix fifo_size frame calculation") Signed-off-by: Zubin Mithra <zsm@chromium.org> Reviewed-by: Guenter Roeck <groeck@chromium.org> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20210827153735.789452-1-zsm@chromium.org Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-08-19isystem: trim/fixup stdarg.h and other headersAlexey Dobriyan
Delete/fixup few includes in anticipation of global -isystem compile option removal. Note: crypto/aegis128-neon-inner.c keeps <stddef.h> due to redefinition of uintptr_t error (one definition comes from <stddef.h>, another from <linux/types.h>). Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2021-08-14ALSA: pcm: Add SNDRV_PCM_INFO_EXPLICIT_SYNC flagTakashi Iwai
ALSA PCM core has an optimized way to communicate with user-space for its control and status data via mmap on the supported architectures like x86. Depending on the situation, however, we'd rather want to enforce user-space notifying the applptr or hwptr change explicitly via ioctl. For example, the upcoming non-contig and non-coherent buffer handling would need an explicit sync, and this needs to catch the applptr and hwptr changes. Also, ASoC SOF driver will have the SPIB support that has the similar requirement for the explicit control of the applptr and hwptr. This patch adds the new PCM hardware info flag, SNDRV_PCM_INFO_EXPLICIT_SYNC. When this flag is set, PCM core disables both the control and the status mmap, which enforces user-space to update via SYNC_PTR ioctl. In that way, drivers can catch the applptr and hwptr update and apply the sync operation if needed. Link: https://lore.kernel.org/r/20210812113818.6479-1-tiwai@suse.de Link: https://lore.kernel.org/r/20210610205326.1176400-1-pierre-louis.bossart@linux.intel.com Link: https://lore.kernel.org/r/20210813082142.5375-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-08-13ALSA: memalloc: Count continuous pages in vmalloc buffer handlerTakashi Iwai
This is an enhancement for the SG-style page handling in vmalloc buffer handler to calculate the continuous pages. When snd_sgbuf_get_chunk_size() is called for a vmalloc buffer, currently we return only the size that fits into a single page. However, this API call is rather supposed for obtaining the continuous pages and most of vmalloc or noncontig buffers do have lots of continuous pages indeed. So, in this patch, the callback now calculates the possibly continuous pages up to the given size limit. Note that the end address in the function is calculated from the last byte, hence it's one byte shorter. This is because ofs + size can be above the actual buffer size boundary. Until now, this feature isn't really used, but it'll become useful in a later patch that adds the non-contiguous buffer type that shares the same callback function as vmalloc. Link: https://lore.kernel.org/r/20210812113818.6479-1-tiwai@suse.de Link: https://lore.kernel.org/r/20210813081645.4680-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-08-13ALSA: core: control_led: use strscpy instead of strlcpyPierre-Louis Bossart
strlcpy is deprecated, use its safe replacement Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Bard Liao <bard.liao@intel.com> Reviewed-by: Paul Olaru <paul.olaru@oss.nxp.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Link: https://lore.kernel.org/r/20210812225904.171529-2-pierre-louis.bossart@linux.intel.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-08-09ALSA: pcm: Check mmap capability of runtime dma buffer at firstTakashi Iwai
Currently we check only the substream->dma_buffer as the preset of the buffer configuration for verifying the availability of mmap. But a few drivers rather set up the buffer in the own way without the standard buffer preallocation using substream->dma_buffer, and they miss the proper checks. (Now it's working more or less fine as most of them are running only on x86). Actually, they may set up the runtime dma_buffer (referred via snd_pcm_get_dma_buf()) at the open callback, though. That is, this could have been used as the primary source. This patch changes the hw_support_mmap() function to check the runtime dma buffer at first. It's usually NULL with the standard buffer preallocation, and in that case, we continue checking substream->dma_buffer as fallback. Link: https://lore.kernel.org/r/20210809071829.22238-2-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-08-09Merge branch 'for-linus' into for-nextTakashi Iwai
2021-08-09ALSA: pcm: Fix mmap breakage without explicit buffer setupTakashi Iwai
The recent fix c4824ae7db41 ("ALSA: pcm: Fix mmap capability check") restricts the mmap capability only to the drivers that properly set up the buffers, but it caused a regression for a few drivers that manage the buffer on its own way. For those with UNKNOWN buffer type (i.e. the uninitialized / unused substream->dma_buffer), just assume that the driver handles the mmap properly and blindly trust the hardware info bit. Fixes: c4824ae7db41 ("ALSA: pcm: Fix mmap capability check") Reported-and-tested-by: Jeff Woods <jwoods@fnordco.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/s5him0gpghv.wl-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-08-08ALSA: memalloc: Fix mmap of SG-buffer with WC pagesTakashi Iwai
The code refactoring to move the WC page handling into the common memalloc layer caused a breakage for HD-audio HDMI. I overlooked that the driver is using the SG-buffer, which isn't covered by the patch. This patch adds the mmap workaround for WC pages to SG-buffer handler. A caveat is that it falls back to the default handler by returning an error after setting the pgprot, so it won't work in all cases but merely for PCM (which is currently the only use case). Fixes: 623c10108338 ("ALSA: memalloc: Fix pgprot for WC mmap on x86") Reported-and-tested-by: Andy Lavr <andy.lavr@gmail.com> Link: https://lore.kernel.org/r/20210808080034.20337-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-08-04ALSA: memalloc: Store snd_dma_buffer.addr for continuous pages, tooTakashi Iwai
In the recent fix commit eda80d7c9c4d ("ALSA: memalloc: Fix regression with SNDRV_DMA_TYPE_CONTINUOUS"), we replaced the pfn argument of the remap_page_pfn() call from the uninitialized dmab->addr. It was the right fix, but it'd be more generic if we actually initialize dmab->area for SNDRV_DMA_TYPE_CONTINOUS, too. e.g. the field is used in the common snd_sgbuf_get_addr(), too. This patch adds the initialization of addr field and does revert of the previous change to refer to it again in the mmap call. Link: https://lore.kernel.org/r/20210804074125.8170-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-08-04ALSA: memalloc: Fix pgprot for WC mmap on x86Takashi Iwai
We have a special handling of WC pages on x86, and it's currently specific to HD-audio. The last forgotten piece was the pgprot setup for the mmap with WC pages. This patch moves the pgprot setup for WC pages from HD-audio-specific mmap callback to the common helper code. It allows us to remove the superfluous mmap callback in HD-audio and its prepare_mmap redirection. Link: https://lore.kernel.org/r/20210804061329.29265-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-08-04ALSA: memalloc: Support WC allocation on all architecturesTakashi Iwai
There are the generic DMA API calls for allocating and managing the pages with the write-combined attribute. Let's use them for all architectures but x86; x86 still needs the special handling to override the page attributes. Acked-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20210802072815.13551-5-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-08-04ALSA: pcm: Allow exact buffer preallocationTakashi Iwai
A few drivers want to have rather the exact buffer preallocation at the driver probe time and keep using it for the whole operations without allowing dynamic buffer allocation. For satisfying the demands, this patch extends the managed buffer allocation API slightly. Namely, when 0 is passed to max argument of the allocation helper functions snd_pcm_set_managed_buffer*(), it treats as if the fixed size allocation of the given size. If the pre-allocation fails in this mode, the function returns now -ENOMEM. Otherwise, i.e. max argument is non-zero, the function never returns -ENOMEM but tries to fall back to the smaller chunks and allows the dynamic allocation later -- which is still the default behavior until now. For more intuitive use, also two new helpers are added for handling the fixed size buffer allocation, too: snd_pcm_set_fixed_buffer() and snd_pcm_set_fixed_buffer_all(). Acked-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20210802072815.13551-4-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-08-04ALSA: memalloc: Correctly name as WCTakashi Iwai
SNDRV_DMA_TYPE_DEV_UC and SNDRV_DMA_TYPE_DEV_UC_SG are incorrectly named as if they were for the uncached memory, while actually we set the pages as write-combined. Rename them to reflect the right attribute. Acked-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20210802072815.13551-3-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-08-04ALSA: memalloc: Minor refactoringTakashi Iwai
Return the pointer directly from alloc ops instead of setting dmab->area at each place. It simplifies the code a bit. Acked-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20210802072815.13551-2-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-08-03ALSA: seq: Fix racy deletion of subscriberTakashi Iwai
It turned out that the current implementation of the port subscription is racy. The subscription contains two linked lists, and we have to add to or delete from both lists. Since both connection and disconnection procedures perform the same order for those two lists (i.e. src list, then dest list), when a deletion happens during a connection procedure, the src list may be deleted before the dest list addition completes, and this may lead to a use-after-free or an Oops, even though the access to both lists are protected via mutex. The simple workaround for this race is to change the access order for the disconnection, namely, dest list, then src list. This assures that the connection has been established when disconnecting, and also the concurrent deletion can be avoided. Reported-and-tested-by: folkert <folkert@vanheusden.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20210801182754.GP890690@belle.intranet.vanheusden.com Link: https://lore.kernel.org/r/20210803114312.2536-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-08-02Merge branch 'for-linus' into for-nextTakashi Iwai
2021-08-02ALSA: memalloc: Fix regression with SNDRV_DMA_TYPE_CONTINUOUSTakashi Iwai
The recent code refactoring made the mmap of continuous pages to be done via the own helper snd_dma_continuous_mmap() with remap_pfn_range(). There I overlooked that dmab->addr isn't set for the allocation with SNDRV_DMA_TYPE_CONTINUOUS. This resulted always in an error at mmap with this buffer type on the system such as Intel SST Baytrail driver. This patch fixes the regression by passing the correct address. Fixes: 30b7ba6972d5 ("ALSA: core: Add continuous and vmalloc mmap ops") Reported-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/8d6674da-7d7b-803e-acc9-7de6cb1223fa@redhat.com Link: https://lore.kernel.org/r/20210801113801.31290-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-07-31ALSA: core: Fix double calls of snd_card_free() via devresTakashi Iwai
At the transition to the devres-managed card release, we've put the check of double-free at trigger_card_release(). But this wasn't enough, as the code path calls snd_card_free() again, and it would lead to the doubly snd_card_free() calls. Actually the v1 patch was correct to handle this, but I forgot that corner case and moved the check to the more obvious place as I thought it's clearer. But, as usual, devils live in details. This patch corrects the check of the double-free to the right place, with a bit more comments. Fixes: e8ad415b7a55 ("ALSA: core: Add managed card creation") Link: https://lore.kernel.org/r/20210731083446.26680-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-07-30ALSA: pcm - fix mmap capability check for the snd-dummy driverJaroslav Kysela
The snd-dummy driver (fake_buffer configuration) uses the ops->page callback for the mmap operations. Allow mmap for this case, too. Cc: <stable@vger.kernel.org> Fixes: c4824ae7db41 ("ALSA: pcm: Fix mmap capability check") Signed-off-by: Jaroslav Kysela <perex@perex.cz> Link: https://lore.kernel.org/r/20210730090254.612478-1-perex@perex.cz Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-07-27ALSA: seq: Fix comments of wrong client number for MIDI PassthroughTakashi Iwai
MIDI Passthrough sequencer client is assigned always to the fixed number 14, while it's wrongly documented in the comments as if 62, which was an old number that was used during development. Fix all those numbers. Link: https://lore.kernel.org/r/20210727105232.7321-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>