On 01/08/2018 04:40 PM, Takashi Iwai wrote: > On Mon, 08 Jan 2018 16:37:32 +0100, > Lars-Peter Clausen wrote: >> >> On 01/08/2018 04:05 PM, Takashi Iwai wrote: >>> On Mon, 08 Jan 2018 15:58:47 +0100, >>> Lars-Peter Clausen wrote: >>>> >>>> On 01/08/2018 03:25 PM, Takashi Iwai wrote: >>>>> Hi, >>>>> >>>>> this contains two fixes for PCM OSS bugs that have been triggered by >>>>> syzbot. These are simple and straightforward, and I'm going to queue >>>>> for 4.15-rc8. >>>> >>>> I tried to reproduce the issue as well with the reproducer generated by >>>> syzbot. But what syzbot reported was that the CPU didn't sleep for 140 >>>> seconds. But with a long write() we'll go to sleep in between frames. So >>>> when I tried the lockup detector never triggered. >>>> >>>> Were you able to reproduce the same CPU lockup as syzbot? >>> >>> Yes, I could reproduce RCU stalls with two reproducers >>> (001a113ece5c2b600d05620b097a@xxxxxxxxxx and >>> 001a1147e1988b160a05620552eb@xxxxxxxxxx) >>> >>> The patches seem curing them, so far, in combination with other >>> patches in for-linus branch of sound.git tree. >>> >> >> Hm, interesting. Are you using aloop for the backend or real hardware? > > The RCU stall happened also with dummy driver. Just feeding a GB of > chunk to /dev/audio and aborting the stream concurrently, then it > stalls at that point. Hm, does that mean that snd_pcm_playback_avail() is never 0 for the dummy driver? Usually we should catch the signal_pending() in wait_for_avail(). This might not be OSS specific and maybe it is possible to trigger it from ALSA as well. _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
