linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dmitry Vyukov <dvyukov@google.com>
To: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Cc: Eric Biggers <ebiggers@kernel.org>,
	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, 20 Mar 2019 13:49:44 +0100	[thread overview]
Message-ID: <CACT4Y+ZR=GoC6eNkgu4mVzDK9ad_J3DT3ThsUBj_PFK3q5tRag@mail.gmail.com> (raw)
In-Reply-To: <f3e25790-4edd-9e77-f656-e41d7a992945@i-love.sakura.ne.jp>

On Thu, Mar 14, 2019 at 11:52 AM Tetsuo Handa
<penguin-kernel@i-love.sakura.ne.jp> wrote:
>
> On 2019/03/14 8:40, Eric Biggers wrote:
> > On Wed, Mar 13, 2019 at 07:43:38AM +0100, 'Dmitry Vyukov' via syzkaller-bugs wrote:
> >>> Also, humans can sometimes find more simpler C reproducers from syzbot provided
> >>> reproducers. It would be nice if syzbot can accept and use a user defined C
> >>> reproducer for testing.
> >>
> >> 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.
> >>
> >
> > Well, it's very tough and not many people are familiar with the syzkaller
> > codebase, let alone have time to contribute.
>
> Right. I don't read/write go programs. I don't have access to environments
> for running syzbot. But instead I try to write kernel patches.
>
> Also, although anybody is free to do full manual (perfect) reporting,
> I can't afford checking such reports posted to e.g. LKML. I can afford
> checking only https://syzkaller.appspot.com/ .
>
> I have seen a Japanese article which explains how to run syzbot. But I felt that
> that article lacks what to do if syzbot found a bug. If people found a crash
> by running syzbot in their environments, it would be nice if they can export
> the report and import it to https://syzkaller.appspot.com/ (i.e. dashboard
> acts as if a bugzilla).
>
> >                                               But having simplified a lot of
> > the syzkaller reproducers manually, the main things I do are:
>
> Yes. I'm doing similar things. Other things not listed here are:
>
>   Try to remove syscall() which passes EOF as fd argument, for it should be
>   unrelated to the problem unless such call affects subtle timing.
>
>   Try to remove code for testing fuse / tun etc. if the problem seems to be
>   unrelated to fuse / tun etc.
>
> syzbot gets pleased with finding one C reproducer, but I wish that syzbot
> continues trying to find smaller C reproducers by e.g. eliminating unrelated
> calls.
>
> >
> > - Replace bare system calls with proper C library calls.  For example:
> >
> >       #include <sys/syscall.h>
> >
> >       syscall(__NR_socket, 0xa, 6, 0);
> >
> >     becomes:
> >
> >       #include <sys/socket.h>
> >
> >         socket(AF_INET, SOCK_DCCP, 0);
>
> Yes. It would be nice if C reproducers are provided using symbols. I run
> syzbot provided C reproducers under strace because strace gives me more hints
> about symbols and structures.


I will answer re reproducers first.

Thanks for the suggestions, I've filed
https://github.com/google/syzkaller/issues/1070 for this. Lots of them
are implementable within the current framework. Things on kernel
mailing lists (suggestions, bug reports, patches) get lost very
quickly.

As far as I see most of them are related to cosmetics (not saying that
it's not useful, but just won't affect bisection results).
From my experience the most powerful simplifications are possible only
when I have already root caused the bug and understand its mechanics.
Then it's possible to reorder syscalls, remove all/most of threading,
etc. But in that case bisection is not so useful already.

Some of them can alter the load on kernel (e.g. using libc structs and
syscall wrappers) which can lead to triggering of a different bug...

  reply	other threads:[~2019-03-20 12:49 UTC|newest]

Thread overview: 17+ 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 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
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 [this message]
2019-03-20 13:45                 ` 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='CACT4Y+ZR=GoC6eNkgu4mVzDK9ad_J3DT3ThsUBj_PFK3q5tRag@mail.gmail.com' \
    --to=dvyukov@google.com \
    --cc=ebiggers@kernel.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).