On Wed, 20 Apr 2016 10:08:55 +0200, Takashi Iwai wrote:
On Wed, 20 Apr 2016 09:56:04 +0200, Dmitry Vyukov wrote:
On Sun, Apr 3, 2016 at 8:33 AM, Takashi Iwai tiwai@suse.de wrote:
It is not easily reproducible. I've hit several times while running fuzzer for a week. Here is one of the logs for the record: https://gist.githubusercontent.com/dvyukov/c84798ee55721563ecb537c4d51dc9f5/...
There are a few more fixes in sound/core/timer.c since 4.5, and they possibly already cover this.
Please let me know if this is still seen on the upcoming 4.6-rc2.
Hi Takashi,
I've updated fuzzer to 05cf8077e54b20dddb756eaa26f3aeb5c38dd3cf (Apr
- yesterday. Let's see if it still happens.
Out of curiosity, how was the bug found?
Well, I'm not entirely sure whether they really cover. It's just a hope, as these are patches to close some possible races :)
9984d1b5835ca29fc7025186a891ee7398d21cc7 ALSA: timer: Protect the whole snd_timer_close() with open race f65e0d299807d8a11812845c972493c3f9a18e10 ALSA: timer: Call notifier in the same spinlock 4a07083ed613644c96c34a7dd2853dc5d7c70902 ALSA: timer: Use mod_timer() for rearming the system timer
Hi Takashi,
I've hit it again on 806fdcce017dc98c4dbf8ed001750a0d7d2bb0af (Apr 14), all 3 commits are already in my tree.
[ 343.222218] ------------[ cut here ]------------ [ 343.222218] WARNING: CPU: 3 PID: 7040 at kernel/time/hrtimer.c:837 hrtimer_forward+0x26a/0x3e0
This is a different warning. The previous was use-after-free, and this is a warning about re-arming the queued hrtimer. Maybe there is a slightly remaining race about hrtimer_start() and the interrupt handler in snd-hrtimer.
Could you check whether two patches below help anything? This should harden against the race between hrtimer callback and another start/stop calls.
Takashi