On 01/08/2018 05:00 PM, Lars-Peter Clausen wrote: > 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(). Even with the dummy driver I'm not able to reproduce it. wait_for_avail() gets called, thread goes to sleep and a Ctrl+C wakes it up with signal_pending() set and it exits the syscall. _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
