summaryrefslogtreecommitdiffstats
path: root/sound/core
Commit message (Collapse)AuthorAgeFilesLines
* ALSA: PCM: check if ops are defined before suspending PCMRanjani Sridharan2019-04-051-0/+8
| | | | | | | | | | | | | | | | | | | | | [ Upstream commit d9c0b2afe820fa3b3f8258a659daee2cc71ca3ef ] BE dai links only have internal PCM's and their substream ops may not be set. Suspending these PCM's will result in their ops->trigger() being invoked and cause a kernel oops. So skip suspending PCM's if their ops are NULL. [ NOTE: this change is required now for following the recent PCM core change to get rid of snd_pcm_suspend() call. Since DPCM BE takes the runtime carried from FE while keeping NULL ops, it can hit this bug. See details at: https://github.com/thesofproject/linux/pull/582 -- tiwai ] Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
* ALSA: pcm: Don't suspend stream in unrecoverable PCM stateTakashi Iwai2019-04-031-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 113ce08109f8e3b091399e7cc32486df1cff48e7 upstream. Currently PCM core sets each opened stream forcibly to SUSPENDED state via snd_pcm_suspend_all() call, and the user-space is responsible for re-triggering the resume manually either via snd_pcm_resume() or prepare call. The scheme works fine usually, but there are corner cases where the stream can't be resumed by that call: the streams still in OPEN state before finishing hw_params. When they are suspended, user-space cannot perform resume or prepare because they haven't been set up yet. The only possible recovery is to re-open the device, which isn't nice at all. Similarly, when a stream is in DISCONNECTED state, it makes no sense to change it to SUSPENDED state. Ditto for in SETUP state; which you can re-prepare directly. So, this patch addresses these issues by filtering the PCM streams to be suspended by checking the PCM state. When a stream is in either OPEN, SETUP or DISCONNECTED as well as already SUSPENDED, the suspend action is skipped. To be noted, this problem was originally reported for the PCM runtime PM on HD-audio. And, the runtime PM problem itself was already addressed (although not intended) by the code refactoring commits 3d21ef0b49f8 ("ALSA: pcm: Suspend streams globally via device type PM ops") and 17bc4815de58 ("ALSA: pci: Remove superfluous snd_pcm_suspend*() calls"). These commits eliminated the snd_pcm_suspend*() calls from the runtime PM suspend callback code path, hence the racy OPEN state won't appear while runtime PM. (FWIW, the race window is between snd_pcm_open_substream() and the first power up in azx_pcm_open().) Although the runtime PM issue was already "fixed", the same problem is still present for the system PM, hence this patch is still needed. And for stable trees, this patch alone should suffice for fixing the runtime PM problem, too. Reported-and-tested-by: Jon Hunter <jonathanh@nvidia.com> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* ALSA: pcm: Fix possible OOB access in PCM oss pluginsTakashi Iwai2019-04-031-21/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit ca0214ee2802dd47239a4e39fb21c5b00ef61b22 upstream. The PCM OSS emulation converts and transfers the data on the fly via "plugins". The data is converted over the dynamically allocated buffer for each plugin, and recently syzkaller caught OOB in this flow. Although the bisection by syzbot pointed out to the commit 65766ee0bf7f ("ALSA: oss: Use kvzalloc() for local buffer allocations"), this is merely a commit to replace vmalloc() with kvmalloc(), hence it can't be the cause. The further debug action revealed that this happens in the case where a slave PCM doesn't support only the stereo channels while the OSS stream is set up for a mono channel. Below is a brief explanation: At each OSS parameter change, the driver sets up the PCM hw_params again in snd_pcm_oss_change_params_lock(). This is also the place where plugins are created and local buffers are allocated. The problem is that the plugins are created before the final hw_params is determined. Namely, two snd_pcm_hw_param_near() calls for setting the period size and periods may influence on the final result of channels, rates, etc, too, while the current code has already created plugins beforehand with the premature values. So, the plugin believes that channels=1, while the actual I/O is with channels=2, which makes the driver reading/writing over the allocated buffer size. The fix is simply to move the plugin allocation code after the final hw_params call. Reported-by: syzbot+d4503ae45b65c5bc1194@syzkaller.appspotmail.com Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* ALSA: seq: oss: Fix Spectre v1 vulnerabilityGustavo A. R. Silva2019-04-031-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | commit c709f14f0616482b67f9fbcb965e1493a03ff30b upstream. dev is indirectly controlled by user-space, hence leading to a potential exploitation of the Spectre variant 1 vulnerability. This issue was detected with the help of Smatch: sound/core/seq/oss/seq_oss_synth.c:626 snd_seq_oss_synth_make_info() warn: potential spectre issue 'dp->synths' [w] (local cap) Fix this by sanitizing dev before using it to index dp->synths. Notice that given that speculation windows are large, the policy is to kill the speculation on the first load and not worry if it can be completed with a dependent load/store [1]. [1] https://lore.kernel.org/lkml/20180423164740.GY17484@dhcp22.suse.cz/ Cc: stable@vger.kernel.org Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* ALSA: rawmidi: Fix potential Spectre v1 vulnerabilityGustavo A. R. Silva2019-04-031-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | commit 2b1d9c8f87235f593826b9cf46ec10247741fff9 upstream. info->stream is indirectly controlled by user-space, hence leading to a potential exploitation of the Spectre variant 1 vulnerability. This issue was detected with the help of Smatch: sound/core/rawmidi.c:604 __snd_rawmidi_info_select() warn: potential spectre issue 'rmidi->streams' [r] (local cap) Fix this by sanitizing info->stream before using it to index rmidi->streams. Notice that given that speculation windows are large, the policy is to kill the speculation on the first load and not worry if it can be completed with a dependent load/store [1]. [1] https://lore.kernel.org/lkml/20180423164740.GY17484@dhcp22.suse.cz/ Cc: stable@vger.kernel.org Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* ALSA: pcm: Revert capture stream behavior change in blocking modeTakashi Iwai2019-02-081-16/+4
| | | | | | | | | | | | | | | | | | | | | | | | | In the commit 62ba568f7aef ("ALSA: pcm: Return 0 when size < start_threshold in capture"), we changed the behavior of __snd_pcm_lib_xfer() to return immediately with 0 when a capture stream has a high start_threshold. This was intended to be a correction of the behavior consistency and looked harmless, but this was the culprit of the recent breakage reported by syzkaller, which was fixed by the commit e190161f96b8 ("ALSA: pcm: Fix tight loop of OSS capture stream"). At the time for the OSS fix, I didn't touch the behavior for ALSA native API, as assuming that this behavior actually is good. But this turned out to be also broken actually for a similar deployment, e.g. one thread goes to a write loop in blocking mode while another thread controls the start/stop of the stream manually. Overall, the original commit is harmful, and it brings less merit to keep that behavior. Let's revert it. Fixes: 62ba568f7aef ("ALSA: pcm: Return 0 when size < start_threshold in capture") Fixes: e190161f96b8 ("ALSA: pcm: Fix tight loop of OSS capture stream") Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: pcm: Fix tight loop of OSS capture streamTakashi Iwai2019-01-251-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | When the trigger=off is passed for a PCM OSS stream, it sets the start_threshold of the given substream to the boundary size, so that it won't be automatically started. This can be problematic for a capture stream, unfortunately, as detected by syzkaller. The scenario is like the following: - In __snd_pcm_lib_xfer() that is invoked from snd_pcm_oss_read() loop, we have a check whether the stream was already started or the stream can be auto-started. - The function at this check returns 0 with trigger=off since we explicitly disable the auto-start. - The loop continues and repeats calling __snd_pcm_lib_xfer() tightly, which may lead to an RCU stall. This patch fixes the bug by simply allowing the wait for non-started stream in the case of OSS capture. For native usages, it's supposed to be done by the caller side (which is user-space), hence it returns zero like before. (In theory, __snd_pcm_lib_xfer() could wait even for the native API usage cases, too; but I'd like to stay in a safer side for not breaking the existing stuff for now.) Reported-by: syzbot+fbe0496f92a0ce7b786c@syzkaller.appspotmail.com Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* Merge tag 'asoc-fix-v5.0-rc2' of ↵Takashi Iwai2019-01-181-1/+2
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus ASoC: Fixes for v5.0 Quite a big batch of fixes here. There's a couple of things going on, the main one is that we found some issues with not deferring probe when we should, causing us to skip some driver initialization. The fixes for this then in turn exposed some issues with how we were searching for components which had previously gone unnoticed due to the original issue. There's also been the normal driver specific stuff and there's been what looks like several batches of automated scanning for issues which have generated quite a large set of smaller fixes for potential crashes and missed error handling.
| * ALSA: compress: prevent potential divide by zero bugsDan Carpenter2019-01-031-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The problem is seen in the q6asm_dai_compr_set_params() function: ret = q6asm_map_memory_regions(dir, prtd->audio_client, prtd->phys, (prtd->pcm_size / prtd->periods), ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ prtd->periods); In this code prtd->pcm_size is the buffer_size and prtd->periods comes from params->buffer.fragments. If we allow the number of fragments to be zero then it results in a divide by zero bug. One possible fix would be to use prtd->pcm_count directly instead of using the division to re-calculate it. But I decided that it doesn't really make sense to allow zero fragments. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Mark Brown <broonie@kernel.org>
* | Remove 'type' argument from access_ok() functionLinus Torvalds2019-01-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Nobody has actually used the type (VERIFY_READ vs VERIFY_WRITE) argument of the user address range verification function since we got rid of the old racy i386-only code to walk page tables by hand. It existed because the original 80386 would not honor the write protect bit when in kernel mode, so you had to do COW by hand before doing any user access. But we haven't supported that in a long time, and these days the 'type' argument is a purely historical artifact. A discussion about extending 'user_access_begin()' to do the range checking resulted this patch, because there is no way we're going to move the old VERIFY_xyz interface to that model. And it's best done at the end of the merge window when I've done most of my merges, so let's just get this done once and for all. This patch was mostly done with a sed-script, with manual fix-ups for the cases that weren't of the trivial 'access_ok(VERIFY_xyz' form. There were a couple of notable cases: - csky still had the old "verify_area()" name as an alias. - the iter_iov code had magical hardcoded knowledge of the actual values of VERIFY_{READ,WRITE} (not that they mattered, since nothing really used it) - microblaze used the type argument for a debug printout but other than those oddities this should be a total no-op patch. I tried to fix up all architectures, did fairly extensive grepping for access_ok() uses, and the changes are trivial, but I may have missed something. Any missed conversion should be trivially fixable, though. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* | Merge tag 'asoc-v4.21' of ↵Takashi Iwai2018-12-181-3/+15
|\ \ | |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-next ASoC: Updates for v4.21 Not much work on the core this time around but we've seen quite a bit of driver work, including on the generic DT drivers. There's also a large part of the diff from a merge of the DaVinci and OMAP directories, along with some active development there: - Preparatory work from Morimoto-san for merging the audio-graph and audio-graph-scu cards. - A merge of the TI OMAP and DaVinci directories, the OMAP product line has been merged into the DaVinci product line so there is now a lot of IP sharing which meant that the split directories just got in the way. This has pulled in a few architecture changes as well. - A big cleanup of the Maxim MAX9867 driver from Ladislav Michl. - Support for Asahi Kaesi AKM4118, AMD ACP3x, Intel platforms with RT5660, Meson AXG S/PDIF inputs, several Qualcomm IPs and Xilinx I2S controllers.
| * Merge branch 'asoc-4.21' into asoc-nextMark Brown2018-12-181-3/+15
| |\
| | * ALSA: compress: make use of runtime buffer for copySrinivas Kandagatla2018-12-141-3/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Default copy function uses kmalloc to allocate buffers, lets check if the runtime buffers are setup before making this allocations. This can be useful if the buffers are dma buffers. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Acked-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Mark Brown <broonie@kernel.org>
* | | ALSA: pcm: Fix potential Spectre v1 vulnerabilityGustavo A. R. Silva2018-12-131-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | stream is indirectly controlled by user-space, hence leading to a potential exploitation of the Spectre variant 1 vulnerability. This issue was detected with the help of Smatch: sound/core/pcm.c:140 snd_pcm_control_ioctl() warn: potential spectre issue 'pcm->streams' [r] (local cap) Fix this by sanitizing stream before using it to index pcm->streams Notice that given that speculation windows are large, the policy is to kill the speculation on the first load and not worry if it can be completed with a dependent load/store [1]. [1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2 Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Cc: stable@vger.kernel.org Signed-off-by: Takashi Iwai <tiwai@suse.de>
* | | Merge branch 'for-linus' into for-nextTakashi Iwai2018-12-071-6/+8
|\ \ \ | |/ / | | | | | | | | | | | | | | | Back-merge for applying the more HD-audio quirks on top of the latest code. Signed-off-by: Takashi Iwai <tiwai@suse.de>
| * | ALSA: pcm: Fix starvation on down_write_nonblock()Chanho Min2018-11-291-5/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 67ec1072b053 ("ALSA: pcm: Fix rwsem deadlock for non-atomic PCM stream") fixes deadlock for non-atomic PCM stream. But, This patch causes antother stuck. If writer is RT thread and reader is a normal thread, the reader thread will be difficult to get scheduled. It may not give chance to release readlocks and writer gets stuck for a long time if they are pinned to single cpu. The deadlock described in the previous commit is because the linux rwsem queues like a FIFO. So, we might need non-FIFO writelock, not non-block one. My suggestion is that the writer gives reader a chance to be scheduled by using the minimum msleep() instaed of spinning without blocking by writer. Also, The *_nonblock may be changed to *_nonfifo appropriately to this concept. In terms of performance, when trylock is failed, this minimum periodic msleep will have the same performance as the tick-based schedule()/wake_up_q(). [ Although this has a fairly high performance penalty, the relevant code path became already rare due to the previous commit ("ALSA: pcm: Call snd_pcm_unlink() conditionally at closing"). That is, now this unconditional msleep appears only when using linked streams, and this must be a rare case. So we accept this as a quick workaround until finding a more suitable one -- tiwai ] Fixes: 67ec1072b053 ("ALSA: pcm: Fix rwsem deadlock for non-atomic PCM stream") Suggested-by: Wonmin Jung <wonmin.jung@lge.com> Signed-off-by: Chanho Min <chanho.min@lge.com> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
| * | ALSA: pcm: Call snd_pcm_unlink() conditionally at closingTakashi Iwai2018-11-291-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently the PCM core calls snd_pcm_unlink() always unconditionally at closing a stream. However, since snd_pcm_unlink() invokes the global rwsem down, the lock can be easily contended. More badly, when a thread runs in a high priority RT-FIFO, it may stall at spinning. Basically the call of snd_pcm_unlink() is required only for the linked streams that are already rare occasion. For normal use cases, this code path is fairly superfluous. As an optimization (and also as a workaround for the RT problem above in normal situations without linked streams), this patch adds a check before calling snd_pcm_unlink() and calls it only when needed. Reported-by: Chanho Min <chanho.min@lge.com> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* | | ALSA: control: Consolidate helpers for adding and replacing ctl elementsTakashi Iwai2018-11-241-71/+52
|/ / | | | | | | | | | | | | | | | | | | | | | | Both snd_ctl_add() and snd_ctl_replace() process the things in a fairly similar way, and indeed the most of the codes can be unified. This patch is a refactoring to consolidate the both functions to call a single helper with an extra "mode" argument. There should be no functional difference, except for one additional sanity check applied now to snd_ctl_replace() (which was rather overlooking, IMO), too. Signed-off-by: Takashi Iwai <tiwai@suse.de>
* | ALSA: control: Fix race between adding and removing a user elementTakashi Iwai2018-11-241-35/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The procedure for adding a user control element has some window opened for race against the concurrent removal of a user element. This was caught by syzkaller, hitting a KASAN use-after-free error. This patch addresses the bug by wrapping the whole procedure to add a user control element with the card->controls_rwsem, instead of only around the increment of card->user_ctl_count. This required a slight code refactoring, too. The function snd_ctl_add() is split to two parts: a core function to add the control element and a part calling it. The former is called from the function for adding a user control element inside the controls_rwsem. One change to be noted is that snd_ctl_notify() for adding a control element gets called inside the controls_rwsem as well while it was called outside the rwsem. But this should be OK, as snd_ctl_notify() takes another (finer) rwlock instead of rwsem, and the call of snd_ctl_notify() inside rwsem is already done in another code path. Reported-by: syzbot+dc09047bce3820621ba2@syzkaller.appspotmail.com Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* | ALSA: oss: Use kvzalloc() for local buffer allocationsTakashi Iwai2018-11-092-6/+6
|/ | | | | | | | | | | | | | | | PCM OSS layer may allocate a few temporary buffers, one for the core read/write and another for the conversions via plugins. Currently both are allocated via vmalloc(). But as the allocation size is equivalent with the PCM period size, the required size might be quite small, depending on the application. This patch replaces these vmalloc() calls with kvzalloc() for covering small period sizes better. Also, we use "z"-alloc variant here for addressing the possible uninitialized access reported by syzkaller. Reported-by: syzbot+1cb36954e127c98dd037@syzkaller.appspotmail.com Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: seq: oss: Use the standard fall-through annotationTakashi Iwai2018-10-121-1/+1
| | | | | | | | As a preparatory patch for the upcoming -Wimplicit-fallthrough compiler checks, replace with the standard "fall through" annotation. Unfortunately gcc doesn't understand a chattier text. Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: memalloc: Add fall-through annotationTakashi Iwai2018-10-121-0/+1
| | | | | | | | | As a preparatory patch for the upcoming -Wimplicit-fallthrough compiler checks, add the "fall through" annotation in snd_dma_alloc_pages(). Note that this seems necessary to be put exactly before the next label, so it's outside the ifdef block. Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: rawmidi: A lightweight function to discard pending bytesTakashi Iwai2018-10-042-3/+23
| | | | | | | | | | For discarding the pending bytes on rawmidi, we process with a loop of snd_rawmidi_transmit() which is just a waste of CPU power. Implement a lightweight API function to discard the pending bytes and the proceed the ring buffer instantly, and use it instead of open codes. Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: pcm: Update hardware pointer before start captureRicardo Biehl Pasquali2018-09-101-3/+5
| | | | | | | | | This ensures the transfer loop won't waste a run to read the few frames (if any) between start and hw_ptr update. It will wait for the next interrupt with wait_for_avail(). Signed-off-by: Ricardo Biehl Pasquali <pasqualirb@gmail.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* Merge branch 'topic/pcm-indirect-fixes' into for-nextTakashi Iwai2018-09-041-2/+2
|\ | | | | | | Signed-off-by: Takashi Iwai <tiwai@suse.de>
| * ALSA: rawmidi: Initialize allocated buffersTakashi Iwai2018-09-031-2/+2
| | | | | | | | | | | | | | | | | | | | | | syzbot reported the uninitialized value exposure in certain situations using virmidi loop. It's likely a very small race at writing and reading, and the influence is almost negligible. But it's safer to paper over this just by replacing the existing kvmalloc() with kvzalloc(). Reported-by: syzbot+194dffdb8b22fc5d207a@syzkaller.appspotmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
* | ALSA: memalloc: Add non-cached buffer typeTakashi Iwai2018-08-282-2/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In some cases (mainly for x86), we need the DMA coherent buffer with non-cached pages. Although this has been done in each driver side like HD-audio and intel8x0, it can be done cleaner in the core memory allocator. This patch adds the new types, SNDRV_DMA_TYPE_DEV_UC and SNDRV_DMA_TYPE_DEV_UC_SG, for allocating such non-cached buffer pages. On non-x86 architectures, they work as same as the standard SNDRV_DMA_TYPE_DEV and *_SG. One additional change by this move is that we can assure to pass the non-cached pgprot to the vmapped buffer, too. It eventually fixes the case like non-snoop mode without mmap access on HD-audio. Signed-off-by: Takashi Iwai <tiwai@suse.de>
* | ALSA: memalloc: Simplify snd_malloc_dev_pages() callsTakashi Iwai2018-08-281-11/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | snd_malloc_dev_pages() and snd_free_dev_pages() are local functions and the parameters passed there are all contained in snd_dma_buffer object. As a code-simplification, pass snd_dma_buffer object and assign the address there like other allocators do (except for snd_malloc_pages() which is called from outside, hence we can't change easily). Only code refactoring, no functional changes. Signed-off-by: Takashi Iwai <tiwai@suse.de>
* | ALSA: memalloc: Don't align the size to power-of-twoTakashi Iwai2018-08-281-7/+2
| | | | | | | | | | | | | | | | The size passed to dma_alloc_coherent() doesn't have to be aligned with power-of-two, rather it should be the raw size. As a minor optimization, remove the size adjustment in the current code. Signed-off-by: Takashi Iwai <tiwai@suse.de>
* | ALSA: seq: Do error checks at creating system portsTakashi Iwai2018-08-281-3/+15
| | | | | | | | | | | | | | snd_seq_system_client_init() doesn't check the errors returned from its port creations. Let's do it properly and handle the error paths. Signed-off-by: Takashi Iwai <tiwai@suse.de>
* | ALSA: seq: add error check in snd_seq_system_client_init()Dan Carpenter2018-08-281-0/+4
| | | | | | | | | | | | | | | | Static checkers complain that snd_seq_create_kernel_client() can return -EBUSY here so we need to have some error handling. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* | ALSA: pcm: signedness bug in snd_pcm_plug_alloc()Dan Carpenter2018-08-271-2/+2
| | | | | | | | | | | | | | | | The "frames" variable is unsigned so the error handling doesn't work properly. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* | ALSA: pcm: Return 0 when size < start_threshold in captureRicardo Biehl Pasquali2018-08-271-4/+9
|/ | | | | | | | | In __snd_pcm_lib_xfer(), when capture, if state is PREPARED and size is less than start_threshold nothing can be done. As there is no error, 0 is returned. Signed-off-by: Ricardo Biehl Pasquali <pasqualirb@gmail.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: seq: virmidi: Fix discarding the unsubscribed outputTakashi Iwai2018-08-141-2/+3
| | | | | | | | | | | | | | | | The recent change to move the virmidi output processing to a work slightly modified the code to discard the unsubscribed outputs so that it works without a temporary buffer. However, this is actually buggy, and may spew a kernel warning due to the unexpected call of snd_rawmidi_transmit_ack(), as triggered by syzbot. This patch takes back to the original code in that part, use a temporary buffer and simply repeat snd_rawmidi_transmit(), in order to address the regression. Fixes: f7debfe54090 ("ALSA: seq: virmidi: Offload the output event processing") Reported-by: syzbot+ec5f605c91812d200367@syzkaller.appspotmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: seq_oss: Mark expected switch fall-throughGustavo A. R. Silva2018-08-041-1/+1
| | | | | | | | | | In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Warning level 2 was used: -Wimplicit-fallthrough=2 Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: seq: Mark expected switch fall-throughGustavo A. R. Silva2018-08-041-1/+1
| | | | | | | | | | | | In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Notice that in this particular case, I replaced the code comment with a proper "fall through" annotation, which is what GCC is expecting to find. Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: compress: Remove empty init and exitTakashi Iwai2018-08-031-12/+0
| | | | | | | | | | | | For a sake of code simplification, remove the init and the exit entries that do nothing. Notes for readers: actually it's OK to remove *both* init and exit, but not OK to remove the exit entry. By removing only the exit while keeping init, the module becomes permanently loaded; i.e. you cannot unload it any longer! Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: seq: Drop unused 64bit division macrosTakashi Iwai2018-08-011-24/+0
| | | | | | | The old ugly macros remained in the code without usage. Rip them off. Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: seq: Use no intrruptible mutex_lockTakashi Iwai2018-08-011-19/+7
| | | | | | | | All usages of mutex in ALSA sequencer core would take too long, hence we don't have to care about the user interruption that makes things complicated. Let's replace them with simpler mutex_lock(). Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: seq: Fix leftovers at probe error pathTakashi Iwai2018-08-016-36/+23
| | | | | | | | | | | | | | | | | | | | The sequencer core module doesn't call some destructors in the error path of the init code, which may leave some resources. This patch mainly fix these leaks by calling the destructors appropriately at alsa_seq_init(). Also the patch brings a few cleanups along with it, namely: - Expand the old "if ((err = xxx) < 0)" coding style - Get rid of empty seq_queue_init() and its caller - Change snd_seq_info_done() to void Last but not least, a couple of functions lose __exit annotation since they are called also in alsa_seq_init(). No functional changes but minor code cleanups. Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: seq: Remove dead codesTakashi Iwai2018-08-016-115/+0
| | | | | | | | There are a few functions that have been commented out for ages. And also there are functions that do nothing but placeholders. Let's kill them. Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: seq: Minor cleanup of MIDI event parser helpersTakashi Iwai2018-08-014-52/+20
| | | | | | | | | | | | | | snd_midi_event_encode_byte() can never fail, and it can return rather true/false. Change the return type to bool, adjust the argument to receive a MIDI byte as unsigned char, and adjust the comment accordingly. This allows callers to drop error checks, which simplifies the code. Meanwhile, snd_midi_event_encode() helper is used only in seq_midi.c, and it can be better folded into it. This will reduce the total amount of lines in the end. Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: pcm: Mark expected switch fall-throughGustavo A. R. Silva2018-08-011-0/+1
| | | | | | | | | In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Addresses-Coverity-ID: 1357375 ("Missing break in switch") Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: seq: virmidi: Use READ_ONCE/WRITE_ONCE() macrosTakashi Iwai2018-07-301-9/+5
| | | | | | | | The trigger flag in vmidi object can be referred in different contexts concurrently, hence it's better to be put with READ_ONCE() and WRITE_ONCE() macros to assure the accesses. Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: seq: virmidi: Offload the output event processingTakashi Iwai2018-07-301-54/+46
| | | | | | | | | | | | | | | | | | | | | | | | | The virmidi sequencer stuff tries to translate the rawmidi bytes to sequencer events and deliver the packets at trigger callback. The amount of the whole process of these translations and deliveries depends on the incoming rawmidi bytes, and we have no limit for that; this was the cause of a CPU soft lockup that had been reported and fixed recently. Although we've fixed the soft lockup by putting the temporary unlock and cond_resched(), it's rather a quick band aid. In this patch, meanwhile, the event parsing and delivery process is offloaded to a dedicated work, and the trigger callback just kicks it off. It has three merits, at least: - The processing is always done in a sleepable context, which can assure the event delivery with non-atomic flag without hackish is_atomic() usage. - Other relevant codes can be simplified, reducing the lines - It makes me happier Signed-off-by: Takashi Iwai <tiwai@suse.de>
* Merge branch 'for-linus' into topic/virmidiTakashi Iwai2018-07-294-8/+14
|\ | | | | | | | | | | | | Pull the latest ALSA sequencer fixes for the further development of virmidi. Signed-off-by: Takashi Iwai <tiwai@suse.de>
| * ALSA: virmidi: Fix too long output trigger loopTakashi Iwai2018-07-271-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The virmidi output trigger tries to parse the all available bytes and process sequencer events as much as possible. In a normal situation, this is supposed to be relatively short, but a program may give a huge buffer and it'll take a long time in a single spin lock, which may eventually lead to a soft lockup. This patch simply adds a workaround, a cond_resched() call in the loop if applicable. A better solution would be to move the event processor into a work, but let's put a duct-tape quickly at first. Reported-and-tested-by: Dae R. Jeong <threeearcat@gmail.com> Reported-by: syzbot+619d9f40141d826b097e@syzkaller.appspotmail.com Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
| * ALSA: seq: Fix poll() error returnTakashi Iwai2018-07-262-2/+2
| | | | | | | | | | | | | | | | | | | | | | The sanity checks in ALSA sequencer and OSS sequencer emulation codes return falsely -ENXIO from poll callback. They should be EPOLLERR instead. This was caught thanks to the recent change to the return value. Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
| * ALSA: memalloc: Don't exceed over the requested sizeTakashi Iwai2018-07-231-6/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | snd_dma_alloc_pages_fallback() tries to allocate pages again when the allocation fails with reduced size. But the first try actually *increases* the size to power-of-two, which may give back a larger chunk than the requested size. This confuses the callers, e.g. sgbuf assumes that the size is equal or less, and it may result in a bad loop due to the underflow and eventually lead to Oops. The code of this function seems incorrectly assuming the usage of get_order(). We need to decrease at first, then align to power-of-two. Reported-and-tested-by: he, bo <bo.he@intel.com> Reported-by: zhang jun <jun.zhang@intel.com> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* | ALSA: pcm: Fix sparse warning wrt PCM format typeTakashi Iwai2018-07-271-1/+1
| | | | | | | | | | | | | | | | | | | | The PCM format type is with __bitwise, hence it needs the explicit cast with __force. It's ugly, but there is a reason for that cost... This fixes the sparse warning: sound/core/oss/pcm_oss.c:1854:55: warning: incorrect type in argument 1 (different base types) Signed-off-by: Takashi Iwai <tiwai@suse.de>
OpenPOWER on IntegriCloud