Re: BUG: unable to handle kernel paging request in snd_seq_oss_readq_puts

[Dmitry Vyukov]

On Mon, Nov 20, 2017 at 2:21 PM, Takashi Iwai <tiwai@xxxxxxx> wrote:
> On Mon, 20 Nov 2017 13:47:28 +0100,
> Dmitry Vyukov wrote:
>>
>> On Wed, Nov 1, 2017 at 8:49 PM, Takashi Iwai <tiwai@xxxxxxx> wrote:
>> > On Wed, 01 Nov 2017 19:39:46 +0100,
>> > Dmitry Vyukov wrote:
>> >>
>> >> On Wed, Nov 1, 2017 at 9:38 PM, syzbot
>> >> <bot+31681772ec7a18dde8d3f8caf475f361a89b9514@xxxxxxxxxxxxxxxxxxxxxxxxx>
>> >> wrote:
>> >> > Hello,
>> >> >
>> >> > syzkaller hit the following crash on
>> >> > fc2e8b1a47c14b22c33eb087fca0db58e1f4ed0e
>> >> > git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
>> >> > compiler: gcc (GCC) 7.1.1 20170620
>> >> > .config is attached
>> >> > Raw console output is attached.
>> >> > C reproducer is attached
>> >> > syzkaller reproducer is attached. See https://goo.gl/kgGztJ
>> >> > for information about syzkaller reproducers
>> >>
>> >> This also happened on more recent commits, including upstream
>> >> 9c323bff13f92832e03657cabdd70d731408d621 (Oct 20):
>> >
>> > Could you try the patch below with CONFIG_SND_DEBUG=y and see whether
>> > it catches any bad calls?  It's already in for-next branch for 4.15.
>>
>>
>> Hi Takashi,
>>
>> Unfortunately it's not possible to test custom patches in syzbot infrastructure.
>> We've experimented with applying a bunch of custom patches in the past
>> and it lead to unrecoverable mess. We were not able to communicate
>> precise state of code with reports, we were not able to provide
>> meaningful report with line numbers that matter (not possible to
>> understand what exactly line caused a bug), developers could
>> (rightfully) suspect that some bugs might be caused the unknown set of
>> private patches, random subset of patches won't apply and that set
>> changes over time and depends on order in which we apply patches, etc.
>> It's also not possible to dedicate a syzkaller instance with a bunch
>> of attached machines for this. First, it will require lots of
>> resources (your request is not unique). Then, whenever we test kernel
>> we get dozens of bugs. What should we do with these bugs? We don't
>> know which are related to your patch and which are not. We can't
>> report them upstream (see above). Basically you would need to go
>> through these dozens of bugs after testing and do something with each
>> of them, but I don't think you want to.
>>
>> But we are happy to test whatever is in upstream tree (this patch already is).
>
> The bug turned out to be a different issue as the suggested patch may
> fix, and I believe we already address it by the upstream commit
> 132d358b183ac6ad8b3fea32ad5e0663456d18d1
>     ALSA: seq: Fix OSS sysex delivery in OSS emulation
>
> I thought I submitted the fix line, but it might be to another syzbot
> report or I did wrong.

Yes, you submitted the fix line above.
syzbot already detected that the fix reached all of tested branches
for this bug.


>> Re CONFIG_SND_DEBUG=y, should we enable it permanently in syzbot configs?
>
> Yes, it's worth to have CONFIG_SND_DEBUG=y in fuzzer.
>
>> From our point of view, the more debug configs are enabled, the more
>> bugs we find, the better. There just must be somebody who will then
>> fix problems uncovered by the config (either bugs of config false
>> positives).
>
> In the case of CONFIG_SND_DEBUG, it gives more debug hints by adding
> WARN_ON(), but the code behavior is almost same.
>
>> If you will take a look on the config attached to the first mail, do
>> you see anything else to fix there re sound? Maybe turn off some
>> deprecated configs that nobody uses for a long time? Or enable some
>> new configs?
>
> CONFIG_SND_DYNAMIC_MINORS=y is recommended for modern systems, too.

I've enabled CONFIG_SND_DEBUG and CONFIG_SND_DYNAMIC_MINORS in syzbot configs.