kernel.git/sound/core/pcm_lib.c, branch linux-3.2.y

ALSA: pcm: Remove yet superfluous WARN_ON()

2018-03-03T15:50:58Z

commit 23b19b7b50fe1867da8d431eea9cd3e4b6328c2c upstream. muldiv32() contains a snd_BUG_ON() (which is morphed as WARN_ON() with debug option) for checking the case of 0 / 0. This would be helpful if this happens only as a logical error; however, since the hw refine is performed with any data set provided by user, the inconsistent values that can trigger such a condition might be passed easily. Actually, syzbot caught this by passing some zero'ed old hw_params ioctl. So, having snd_BUG_ON() there is simply superfluous and rather harmful to give unnecessary confusions. Let's get rid of it. Reported-by: syzbot+7e6ee55011deeebce15d@syzkaller.appspotmail.com Signed-off-by: Takashi Iwai Signed-off-by: Ben Hutchings

ALSA: pcm: Remove incorrect snd_BUG_ON() usages

2018-03-03T15:50:53Z

commit fe08f34d066f4404934a509b6806db1a4f700c86 upstream. syzkaller triggered kernel warnings through PCM OSS emulation at closing a stream: WARNING: CPU: 0 PID: 3502 at sound/core/pcm_lib.c:1635 snd_pcm_hw_param_first+0x289/0x690 sound/core/pcm_lib.c:1635 Call Trace: .... snd_pcm_hw_param_near.constprop.27+0x78d/0x9a0 sound/core/oss/pcm_oss.c:457 snd_pcm_oss_change_params+0x17d3/0x3720 sound/core/oss/pcm_oss.c:969 snd_pcm_oss_make_ready+0xaa/0x130 sound/core/oss/pcm_oss.c:1128 snd_pcm_oss_sync+0x257/0x830 sound/core/oss/pcm_oss.c:1638 snd_pcm_oss_release+0x20b/0x280 sound/core/oss/pcm_oss.c:2431 __fput+0x327/0x7e0 fs/file_table.c:210 .... This happens while it tries to open and set up the aloop device concurrently. The warning above (invoked from snd_BUG_ON() macro) is to detect the unexpected logical error where snd_pcm_hw_refine() call shouldn't fail. The theory is true for the case where the hw_params config rules are static. But for an aloop device, the hw_params rule condition does vary dynamically depending on the connected target; when another device is opened and changes the parameters, the device connected in another side is also affected, and it caused the error from snd_pcm_hw_refine(). That is, the simplest "solution" for this is to remove the incorrect assumption of static rules, and treat such an error as a normal error path. As there are a couple of other places using snd_BUG_ON() incorrectly, this patch removes these spurious snd_BUG_ON() calls. Reported-by: syzbot+6f11c7e2a1b91d466432@syzkaller.appspotmail.com Signed-off-by: Takashi Iwai Signed-off-by: Ben Hutchings

ALSA: pcm : Call kill_fasync() in stream lock

2017-02-23T03:51:06Z

commit 3aa02cb664c5fb1042958c8d1aa8c35055a2ebc4 upstream. Currently kill_fasync() is called outside the stream lock in snd_pcm_period_elapsed(). This is potentially racy, since the stream may get released even during the irq handler is running. Although snd_pcm_release_substream() calls snd_pcm_drop(), this doesn't guarantee that the irq handler finishes, thus the kill_fasync() call outside the stream spin lock may be invoked after the substream is detached, as recently reported by KASAN. As a quick workaround, move kill_fasync() call inside the stream lock. The fasync is rarely used interface, so this shouldn't have a big impact from the performance POV. Ideally, we should implement some sync mechanism for the proper finish of stream and irq handler. But this oneliner should suffice for most cases, so far. Reported-by: Baozeng Ding Signed-off-by: Takashi Iwai [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings

ALSA: pcm: fix fifo_size frame calculation

2014-11-05T20:27:45Z

commit a9960e6a293e6fc3ed414643bb4e4106272e4d0a upstream. The calculated frame size was wrong because snd_pcm_format_physical_width() actually returns the number of bits, not bytes. Use snd_pcm_format_size() instead, which not only returns bytes, but also simplifies the calculation. Fixes: 8bea869c5e56 ("ALSA: PCM midlevel: improve fifo_size handling") Signed-off-by: Clemens Ladisch Signed-off-by: Takashi Iwai Signed-off-by: Ben Hutchings

ALSA: Add SNDRV_PCM_STATE_PAUSED case in wait_for_avail function

2014-02-15T19:20:14Z

commit ed697e1aaf7237b1a62af39f64463b05c262808d upstream. When the process is sleeping at the SNDRV_PCM_STATE_PAUSED state from the wait_for_avail function, the sleep process will be woken by timeout(10 seconds). Even if the sleep process wake up by timeout, by this patch, the process will continue with sleep and wait for the other state. Signed-off-by: JongHo Kim Signed-off-by: Takashi Iwai Signed-off-by: Ben Hutchings

sound: Add export.h for THIS_MODULE/EXPORT_SYMBOL where needed

2011-10-31T23:31:22Z

These aren't modules, but they do make use of these macros, so they will need export.h to get that definition. Previously, they got it via the implicit module.h inclusion. Signed-off-by: Paul Gortmaker

ALSA: pcm: add snd_pcm_hw_rule_noresample()

2011-09-20T06:56:45Z

Add a helper function to allow drivers to disable hardware resampling when the application has specified the SNDRV_PCM_HW_PARAMS_NORESAMPLE flag. Signed-off-by: Clemens Ladisch Signed-off-by: Takashi Iwai

ALSA: pcm - fix race condition in wait_for_avail()

2011-09-15T07:03:16Z

wait_for_avail() in pcm_lib.c has a race in it (observed in practice by an Intel validation group). The function is supposed to return once space in the buffer has become available, or if some timeout happens. The entity that creates space (irq handler of sound driver and some such) will do a wake up on a waitqueue that this function registers for. However there are two races in the existing code 1) If space became available between the caller noticing there was no space and this function actually sleeping, the wakeup is missed and the timeout condition will happen instead 2) If a wakeup happened but not sufficient space became available, the code will loop again and wait for more space. However, if the second wake comes in prior to hitting the schedule_timeout_interruptible(), it will be missed, and potentially you'll wait out until the timeout happens. The fix consists of using more careful setting of the current state (so that if a wakeup happens in the main loop window, the schedule_timeout() falls through) and by checking for available space prior to going into the schedule_timeout() loop, but after being on the waitqueue and having the state set to interruptible. [tiwai: the following changes have been added to Arjan's original patch: - merged akpm's fix for waitqueue adding order into a single patch - reduction of duplicated code of avail check ] Signed-off-by: Arjan van de Ven Signed-off-by: Andrew Morton Cc: Signed-off-by: Takashi Iwai

ALSA: Make snd_pcm_debug_name usable outside pcm_lib

2011-07-24T11:34:32Z

Formatting a PCM name is useful for module debug too. Add snd_prefix when making function public. [minor coding-style fixes by tiwai] Signed-off-by: Eliot Blennerhassett Signed-off-by: Takashi Iwai

ALSA: PCM - Don't check DMA time-out too shortly

2011-05-26T06:09:38Z

When the PCM period size is set larger than 10 seconds, currently the PCM core may abort the operation with DMA-error due to the fixed timeout for 10 seconds. A similar problem is seen in the drain operation that has a fixed timeout of 10 seconds, too. This patch fixes the timeout length depending on the period size and rate, also including the consideration of no_period_wakeup flag. Reported-by: Raymond Yau Signed-off-by: Takashi Iwai