Skip to content

Commit 4e7655f

Browse files
committed
ALSA: seq: Don't break snd_use_lock_sync() loop by timeout
The snd_use_lock_sync() (thus its implementation snd_use_lock_sync_helper()) has the 5 seconds timeout to break out of the sync loop. It was introduced from the beginning, just to be "safer", in terms of avoiding the stupid bugs. However, as Ben Hutchings suggested, this timeout rather introduces a potential leak or use-after-free that was apparently fixed by the commit 2d7d540 ("ALSA: seq: Fix race during FIFO resize"): for example, snd_seq_fifo_event_in() -> snd_seq_event_dup() -> copy_from_user() could block for a long time, and snd_use_lock_sync() goes timeout and still leaves the cell at releasing the pool. For fixing such a problem, we remove the break by the timeout while still keeping the warning. Suggested-by: Ben Hutchings <[email protected]> Cc: <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
1 parent 3d016d5 commit 4e7655f

File tree

1 file changed

+3
-6
lines changed

1 file changed

+3
-6
lines changed

sound/core/seq/seq_lock.c

Lines changed: 3 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -28,19 +28,16 @@
2828
/* wait until all locks are released */
2929
void snd_use_lock_sync_helper(snd_use_lock_t *lockp, const char *file, int line)
3030
{
31-
int max_count = 5 * HZ;
31+
int warn_count = 5 * HZ;
3232

3333
if (atomic_read(lockp) < 0) {
3434
pr_warn("ALSA: seq_lock: lock trouble [counter = %d] in %s:%d\n", atomic_read(lockp), file, line);
3535
return;
3636
}
3737
while (atomic_read(lockp) > 0) {
38-
if (max_count == 0) {
39-
pr_warn("ALSA: seq_lock: timeout [%d left] in %s:%d\n", atomic_read(lockp), file, line);
40-
break;
41-
}
38+
if (warn_count-- == 0)
39+
pr_warn("ALSA: seq_lock: waiting [%d left] in %s:%d\n", atomic_read(lockp), file, line);
4240
schedule_timeout_uninterruptible(1);
43-
max_count--;
4441
}
4542
}
4643

0 commit comments

Comments
 (0)