On Mon, 20 Nov 2017 13:47:28 +0100, Dmitry Vyukov wrote:
On Wed, Nov 1, 2017 at 8:49 PM, Takashi Iwai tiwai@suse.de 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@syzkaller.appspotmail.com 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.
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.
Thanks!
Takashi