From: "Theodore Ts'o" <tytso@mit.edu>
To: Dmitry Vyukov <dvyukov@google.com>
Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
syzbot <syzbot+1505c80c74256c6118a5@syzkaller.appspotmail.com>,
syzkaller-bugs <syzkaller-bugs@googlegroups.com>,
Al Viro <viro@zeniv.linux.org.uk>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: INFO: rcu detected stall in sys_sendfile64 (2)
Date: Wed, 13 Mar 2019 12:37:01 -0400 [thread overview]
Message-ID: <20190313163701.GE672@mit.edu> (raw)
In-Reply-To: <CACT4Y+ZQD=raWY4Tp8nrUcpAAbwRt0D3sH65KrTP+JURtQ3n-Q@mail.gmail.com>
On Wed, Mar 13, 2019 at 07:43:38AM +0100, Dmitry Vyukov wrote:
> It would be more useful to accept patches that make syzkaller create
> better reproducers from these people. Manual work is not scalable. We
> would need 10 reproducers per day for a dozen of OSes (incl some
> private kernels/branches). Anybody is free to run syzkaller manually
> and do full manual (perfect) reporting. But for us it become clear
> very early that it won't work. Then see above, while that human is
> sleeping/on weekend/vacation, syzbot will already bisect own
> reproducer. Adding manual reproducer later won't help in any way.
> syzkaller already does lots of smart work for reproducers. Let's not
> give up on the last mile and switch back to all manual work.
I suspect a scalable solution that would significantly improve things
is one where Syzbot tries N times for a "good" result to make sure
it's not a flaky pass. N could either be hard-coded to some value
like 8 or 10, or Syzbot could experimentally try to figure out how
reliable the reproducer happens to be, and figure out what an ideal
"N" value should be for a particular reproducer.
- Ted
next prev parent reply other threads:[~2019-03-13 16:37 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-19 11:32 INFO: rcu detected stall in sys_sendfile64 (2) syzbot
2019-01-19 11:41 ` Dmitry Vyukov
2019-01-19 13:00 ` Tetsuo Handa
2019-03-12 3:59 ` syzbot
2019-03-12 4:08 ` Al Viro
2019-03-12 8:00 ` Jani Nikula
2019-03-12 8:00 ` Jani Nikula
2019-03-12 14:29 ` Tetsuo Handa
2019-03-12 14:29 ` Tetsuo Handa
2019-03-12 17:15 ` Dmitry Vyukov
2019-03-12 21:11 ` Tetsuo Handa
2019-03-13 6:43 ` Dmitry Vyukov
2019-03-13 16:37 ` Theodore Ts'o [this message]
2019-03-13 16:56 ` Dmitry Vyukov
2019-03-13 23:40 ` Eric Biggers
2019-03-14 10:52 ` Tetsuo Handa
2019-03-20 12:49 ` Dmitry Vyukov
2019-03-20 13:45 ` Dmitry Vyukov
2019-03-12 17:10 ` Dmitry Vyukov
2019-03-12 17:10 ` Dmitry Vyukov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190313163701.GE672@mit.edu \
--to=tytso@mit.edu \
--cc=dvyukov@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=penguin-kernel@i-love.sakura.ne.jp \
--cc=syzbot+1505c80c74256c6118a5@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.com \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.