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

[Lars-Peter Clausen]

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.