In the commit 62ba568f ("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 e190161f ("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: 62ba568f ("ALSA: pcm: Return 0 when size < start_threshold in capture")
Fixes: e190161f ("ALSA: pcm: Fix tight loop of OSS capture stream")
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>