On Mon, Nov 20, 2017 at 1:47 PM, Dmitry Vyukov <dvyukov@xxxxxxxxxx> 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). > > Re CONFIG_SND_DEBUG=y, should we enable it permanently in syzbot configs? > 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). > 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? FYI, we are also rolling out syzbot feature that allows testing of custom patches (but only on the exact reproducer, not general fuzzing): https://github.com/google/syzkaller/blob/master/docs/syzbot.md#communication-with-syzbot As far as I understand this was not applicable in this particular case, but if you need it in future, give it a try. _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
