ALSA: pcm: Revert capture stream behavior change in blocking mode
authorTakashi Iwai <tiwai@suse.de>
Wed, 6 Feb 2019 06:30:44 +0000 (07:30 +0100)
committerTakashi Iwai <tiwai@suse.de>
Fri, 8 Feb 2019 15:54:31 +0000 (16:54 +0100)
commit00a399cad1a063e7665f06b6497a807db20441fd
tree8f2a341d6882481c2cccc2523912e06f7cba65ec
parent0a5cf9e88b5178d15f00f3cf35081841d80403cd
ALSA: pcm: Revert capture stream behavior change in blocking mode

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>
sound/core/pcm_lib.c