diff options
author | Takashi Iwai <tiwai@suse.de> | 2016-04-01 13:28:16 +0300 |
---|---|---|
committer | Jiri Slaby <jslaby@suse.cz> | 2016-04-20 09:40:09 +0300 |
commit | 415ab75664a7aa63fe8520e9500f6759f01a3daf (patch) | |
tree | 9de394a96deae5f48d1709036a65936b23c31356 /mm | |
parent | 168d26de82bf018acec1768ddf1f818e434d00be (diff) | |
download | linux-415ab75664a7aa63fe8520e9500f6759f01a3daf.tar.xz |
ALSA: timer: Use mod_timer() for rearming the system timer
commit 4a07083ed613644c96c34a7dd2853dc5d7c70902 upstream.
ALSA system timer backend stops the timer via del_timer() without sync
and leaves del_timer_sync() at the close instead. This is because of
the restriction by the design of ALSA timer: namely, the stop callback
may be called from the timer handler, and calling the sync shall lead
to a hangup. However, this also triggers a kernel BUG() when the
timer is rearmed immediately after stopping without sync:
kernel BUG at kernel/time/timer.c:966!
Call Trace:
<IRQ>
[<ffffffff8239c94e>] snd_timer_s_start+0x13e/0x1a0
[<ffffffff8239e1f4>] snd_timer_interrupt+0x504/0xec0
[<ffffffff8122fca0>] ? debug_check_no_locks_freed+0x290/0x290
[<ffffffff8239ec64>] snd_timer_s_function+0xb4/0x120
[<ffffffff81296b72>] call_timer_fn+0x162/0x520
[<ffffffff81296add>] ? call_timer_fn+0xcd/0x520
[<ffffffff8239ebb0>] ? snd_timer_interrupt+0xec0/0xec0
....
It's the place where add_timer() checks the pending timer. It's clear
that this may happen after the immediate restart without sync in our
cases.
So, the workaround here is just to use mod_timer() instead of
add_timer(). This looks like a band-aid fix, but it's a right move,
as snd_timer_interrupt() takes care of the continuous rearm of timer.
Reported-by: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Diffstat (limited to 'mm')
0 files changed, 0 insertions, 0 deletions