[alsa-devel] [PATCH 0/2] PCM OSS fixes

[Takashi Iwai]

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 at google.com and
> >>>>  001a1147e1988b160a05620552eb at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: config-syz-4.15
Type: application/octet-stream
Size: 121743 bytes
Desc: not available
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20180109/82e8cd95/attachment-0001.obj>