diff options
author | Takashi Iwai <tiwai@suse.de> | 2019-02-06 07:30:44 +0100 |
---|---|---|
committer | Takashi Iwai <tiwai@suse.de> | 2019-02-08 16:54:31 +0100 |
commit | 00a399cad1a063e7665f06b6497a807db20441fd (patch) | |
tree | 8f2a341d6882481c2cccc2523912e06f7cba65ec /MAINTAINERS | |
parent | 0a5cf9e88b5178d15f00f3cf35081841d80403cd (diff) |
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>
Diffstat (limited to 'MAINTAINERS')
0 files changed, 0 insertions, 0 deletions