On Mon, 08 Jan 2018 20:21:00 +0100, Lars-Peter Clausen wrote:
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@google.com and 001a1147e1988b160a05620552eb@google.com)
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.
Is the machine too fast? But mine isn't that slow, either.
FWIW, below is the kconfig I'm using. I ran KVM with -smp 2.
Takashi