linux-kernel - Driver snd-hrtimer - causing system freeze with Rosegarden

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:	Wed, 09 Dec 2009 20:10:14 +0100
From:	wzab <wzab@....pw.edu.pl>
To:	linux-kernel@...r.kernel.org
CC:	"Zabolotny, Wojciech" <wzab@....pw.edu.pl>
Subject: Driver snd-hrtimer - causing system freeze with Rosegarden 

When I try to use the "HR timer" as a MIDI sequencer timer in the
Rosegarden (http://www.rosegardenmusic.com) application, the system
freezes. Another people also reported similar problems with other
sequencer - OpenOctave (
https://linuxmusicians.com/viewtopic.php?f=27&p=8917 )

I have tested the problem on two SMP machines with diffrent kernels
(2.6.30, 2.6.31.6, 2.6.32).
The problem seems to be associated with the "snd-hrtimer" module.
I've tried to run the application vie remote X session, while having the
text console active.
Before the machine froze, the following messages have been displayed in
the console:

System 1 (Intel(R) Pentium(R) 4 CPU 2.80GHz HT)

hrtimer: interrupt too slow, forcing clock min delta to 3568 ns

System 2 (Intel(R) Core(TM)2 CPU         T5500  @ 1.66GHz)
hrtimer: interrupt too slow, forcing clock min delta to 11103 ns
CE: hpet increasing min_delta_ns to 15000 nsec
CE: hpet increasing min_delta_ns to 22500 nsec
CE: hpet increasing min_delta_ns to 33750 nsec

Analyzing the problem, I had an idea, that maybe the snd-hrtimer should
be rewritten to call
the callback via tasklet (I attach my patch only as an ilustration, my
code doesn't work either),
 however then I got the message "BUG: scheduling while atomic" or
something like this
 from the snd_hrtimer_stop function called from _snd_timer_stop.
Therefore I've tried to investigate the snd_hrtimer_stop more thoroughly.

Looking further into the code, I have found, that snd_hrtimer_stop may
be called
from the callback routine (e.g.:
http://lxr.linux.no/linux+v2.6.32/sound/core/timer.c#L709 or
http://lxr.linux.no/linux+v2.6.32/sound/core/timer.c#L719 )

It seems to me, that calling hrtimer_cancel (in the original code),
which waits for the handler to finish,
from that handler  may lock the machine...
(snd_hrtimer_callback calls the snd_timer_interrupt:
http://lxr.linux.no/linux+v2.6.32/sound/core/hrtimer.c#L47
which in turn calls snd_hrtimer_stop (as above) which calls hrtimer_cancel).

Unfortunately currently I have no idea how to fix this problem. Maybe
snd_hrtimer_stop shouldn't try to cancel the timer,
instead setting a flag causing callback to return immediately without
rearming of the timer?

-- 
Best regards,
Wojtek Zabolotny
wzab@....pw.edu.pl

View attachment "hrtimer.patch" of type "text/x-patch" (1964 bytes)