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

Lars-Peter Clausen lars at metafoo.de
Mon Jan 8 17:00:08 CET 2018


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().

This might not be OSS specific and maybe it is possible to trigger it from
ALSA as well.


More information about the Alsa-devel mailing list