Takashi Iwai 00a399cad1 ALSA: pcm: Revert capture stream behavior change in blocking mode ... In the commit 62ba568f7a ("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 e190161f96 ("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: 62ba568f7a ("ALSA: pcm: Return 0 when size < start_threshold in capture") Fixes: e190161f96 ("ALSA: pcm: Fix tight loop of OSS capture stream") Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>		2019-02-08 16:54:31 +01:00
..
oss
seq
compress_offload.c
control_compat.c
control.c
ctljack.c
device.c
hrtimer.c
hwdep_compat.c
hwdep.c
info_oss.c
info.c
init.c
isadma.c
jack.c
Kconfig
Makefile
memalloc.c
memory.c
misc.c
pcm_compat.c
pcm_dmaengine.c
pcm_drm_eld.c
pcm_iec958.c
pcm_lib.c	ALSA: pcm: Revert capture stream behavior change in blocking mode	2019-02-08 16:54:31 +01:00
pcm_local.h
pcm_memory.c
pcm_misc.c
pcm_native.c
pcm_param_trace.h
pcm_timer.c
pcm_trace.h
pcm.c
rawmidi_compat.c
rawmidi.c
seq_device.c
sgbuf.c
sound_oss.c
sound.c
timer_compat.c
timer.c
vmaster.c