Date:   Fri, 16 Dec 2022 16:48:34 +0100
From:   Aleksandr Nogikh <nogikh@...gle.com>
To:     Al Viro <viro@...iv.linux.org.uk>
Cc:     Marco Elver <elver@...gle.com>, "Theodore Ts'o" <tytso@....edu>,
        Hillf Danton <hdanton@...a.com>,
        Matthew Wilcox <willy@...radead.org>,
        syzbot <syzbot+919c5a9be8433b8bf201@...kaller.appspotmail.com>,
        linux-kernel@...r.kernel.org, linux-mm@...ck.org,
        syzkaller-bugs@...glegroups.com
Subject: Re: [syzbot] WARNING in do_mkdirat

On Tue, Dec 13, 2022 at 2:44 AM Al Viro <viro@...iv.linux.org.uk> wrote:
>
> On Mon, Dec 12, 2022 at 08:29:10PM +0100, Marco Elver wrote:
>
> > > > Given the call trace above, how do you know the ntfs3 guys should be also
> > > > Cced in addition to AV? What if it would take more than three months for
> > > > syzbot to learn the skills in your mind?
>
> Depends.  If you really are talking about the *BOT* learning to do
> that on its own, it certainly would take more than 3 months; strong AI
> is hard.  If, OTOH, it is not an AI research project and intervention of
> somebody capable of passing the Turing test does not violate the purity
> of experiment...  Surely converting "if it mounts an image as filesystem
> of type $T, grep the tree for "MODULE_ALIAS_FS($T)" and treat that
> as if a function from the resulting file had been found in stack trace"
> into something usable for the bot should not take more than 3 months,
> should it?
>
> If expressing that rule really takes "more than three months", I would
> suggest that something is very wrong with the bot architecture...
>
> > Teaching a bot the pattern matching skills of a human is non-trivial.
> > The current design will likely do the simplest thing: regex match
> > reproducers and map a match to some kernel source dir, for which the
> > maintainers are Cc'd. If you have better suggestions on how to
> > mechanize subsystem selection based on a reproducer, please shout.
>
> Er...  Yes?  Look, it's really that simple -
> for i in `sed -ne 's/.*syz_mount_image$\([_[:alnum:]]*\).*/\1/p' <$REPRO`; do
>         git grep -l "MODULE_ALIAS_FS(\"$i\")"
> done | sort | uniq
> gets you the list of files.  No, I'm not suggesting to go for that kind
> of shell use, but it's clearly doable with regex and search over the source
> for fixed strings.  Unless something's drastically wrong with the way the
> bot is written, it should be capable of something as basic as that...
>
> If it can't do that kind of mapping, precalculating it for given tree is
> also not hard:
> git grep 'MODULE_ALIAS_FS("'|sed -ne 's/\(.*\):.*MODULE_ALIAS_FS("\([_[:alnum:]]*\)".*/syz_mount_image$\2:\1/p'
> will yield lines like
> syz_mount_image$ext2:fs/ext2/super.c
> syz_mount_image$ext2:fs/ext4/super.c
> syz_mount_image$ext3:fs/ext4/super.c
> syz_mount_image$ext4:fs/ext4/super.c
> etc.  Surely turning *that* into whatever form the bot wants can't
> be terribly hard? [*]
>
> All of that assumes that pattern-matching in syzkaller reproducer is
> expressible; if "we must do everything by call trace alone" is
> a real limitation, we are SOL; stack trace simply doesn't have
> that information.  Is there such an architectural limitation?

Thanks for the feedback, and we regret the inconvenience this may have caused.

We've deployed a simple short term solution to the immediate issue:
syzbot will extract the involved filesystems from reproducers and use
this information to construct the email subject line and Cc the
related people/mailing lists. This should take effect starting next
week.

That being said, in response to the original feedback we have already
been planning comprehensive improvements to the subsystem selection
process that will support more than just filesystems. But
unfortunately, this is going to take longer to become available.

--
Aleksandr

>
> [*] depending upon config, ext2 could be mounted by ext2.ko and ext4.ko;
> both have the same maillist for bug reports, so this ambiguity doesn't
> matter - either match would do.

Powered by blists - more mailing lists