On Mon, 06 Jun 2016 18:29:25 +0200, Dmitry Vyukov wrote:
On Mon, Jun 6, 2016 at 4:11 PM, Takashi Iwai tiwai@suse.de wrote:
On Sat, 04 Jun 2016 20:27:50 +0200, Dmitry Vyukov wrote:
On Sat, Jun 4, 2016 at 8:00 PM, Dmitry Vyukov dvyukov@google.com wrote:
Hello,
The following program triggers use-after-free:
Forget to mention that you need to run it in a tight parallel loop. It takes around 5 minutes to reproduce for me.
Hmm, this again is a bug that is difficult to trigger... At least, I couldn't reproduce locally. How many processes are you running with stress program?
I use a VM with 4 cores and use 20 parallel test processes.
It seems that there is nothing more than opening /dev/audio and does some mmap in the job. Is there any other relevant thing there?
I think poll with timeout is related. It is poll who sets hrtimer, right?
If it's about snd-dummy driver, hrtimer is created at open, and started/stopped at PCM trigger, and removed at close.
Is there any good way to decode which syscalls are executed in the test code?
Takashi
Also, this assumes that the first sound card is Dummy driver, right? Check /proc/asound/cards.
# cat /proc/asound/cards 0 [Dummy ]: Dummy - Dummy Dummy 1 1 [Loopback ]: Loopback - Loopback Loopback 1 2 [VirMIDI ]: VirMIDI - VirMIDI Virtual MIDI Card 1 3 [pcsp ]: PC-Speaker - pcsp Internal PC-Speaker at port 0x61 4 [Intel ]: HDA-Intel - HDA Intel HDA Intel at 0xfebf0000 irq 24
If it's about snd-dummy driver, one blind shot would be a patch like below. But even if it would fix, it doesn't explain why it's triggered in that way...
thanks,
Takashi
diff --git a/sound/drivers/dummy.c b/sound/drivers/dummy.c index c0f8f613f1f1..172dacd925f5 100644 --- a/sound/drivers/dummy.c +++ b/sound/drivers/dummy.c @@ -420,6 +420,7 @@ static int dummy_hrtimer_stop(struct snd_pcm_substream *substream)
static inline void dummy_hrtimer_sync(struct dummy_hrtimer_pcm *dpcm) {
hrtimer_cancel(&dpcm->timer); tasklet_kill(&dpcm->tasklet);}