All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Vyukov <dvyukov@google.com>
To: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Cc: syzbot <syzbot+ea7d9cb314b4ab49a18a@syzkaller.appspotmail.com>,
	David Miller <davem@davemloft.net>,
	Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>,
	LKML <linux-kernel@vger.kernel.org>,
	netdev <netdev@vger.kernel.org>,
	syzkaller-bugs <syzkaller-bugs@googlegroups.com>,
	Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>,
	Linux-MM <linux-mm@kvack.org>, Shakeel Butt <shakeelb@google.com>,
	syzkaller <syzkaller@googlegroups.com>
Subject: Re: INFO: rcu detected stall in ndisc_alloc_skb
Date: Sun, 20 Jan 2019 14:30:29 +0100	[thread overview]
Message-ID: <CACT4Y+b=5_p=eTgKobApkZZTAVeRxrn3dEempFHampFjrGX0Pw@mail.gmail.com> (raw)
In-Reply-To: <d90cc533-607e-fe40-9b02-a6cac7b7b534@i-love.sakura.ne.jp>

On Sat, Jan 19, 2019 at 2:10 PM Tetsuo Handa
<penguin-kernel@i-love.sakura.ne.jp> wrote:
>
> On 2019/01/19 21:16, Dmitry Vyukov wrote:
> >> The question for me is, whether sysbot can detect hash collision with different
> >> syz-program lines before writing the hash value to /dev/kmsg, and retry by modifying
> >> syz-program lines in order to get a new hash value until collision is avoided.
> >> If it is difficult, simpler choice like current Unix time and PID could be used
> >> instead...
> >
> > Hummm, say, if you run syz-manager locally and report a bug, where
> > will the webserver and database that allows to download all satellite
> > info work? How long you need to keep this info and provide the web
> > service? You will also need to pay and maintain the server for... how
> > long? I don't see how this can work and how we can ask people to do
> > this. This frankly looks like overly complex solution to a problem
> > were simpler solutions will work. Keeping all info in a self-contained
> > file looks like the only option to make it work reliably.
> > It's also not possible to attribute kernel output to individual programs.
>
> The first messages I want to look at is kernel output. Then, I look at
> syz-program lines as needed. But current "a self-contained file" is
> hard to find kernel output.

I think everybody looks at kernel crash first, that's why we provide
kernel crash inline in the email so it's super easy to find. One does
not need to look at console output at all to read the crash message.
Console output is meant for more complex cases when a developer needs
to extract some long tail of custom information. We don't know what
exactly information a developer is looking for and it is different in
each case, so it's not possible to optimize for this. We preserve
console output intact to not destroy some potentially important
information. Say, if we start reordering messages, we lose timing
information and timing/interleaving information is important in some
cases.

> Even if we keep both kernel output and
> syz-program lines in a single file, we can improve readability by
> splitting into kernel output section and syz-program section.
>
>   # Kernel output section start
>   [$(uptime)][$(caller_info)] executing program #0123456789abcdef0123456789abcdef
>   [$(uptime)][$(caller_info)] $(kernel_messages_caused_by_0123456789abcdef0123456789abcdef_are_here)
>   [$(uptime)][$(caller_info)] executing program #456789abcdef0123456789abcdef0123
>   [$(uptime)][$(caller_info)] $(kernel_messages_caused_by_456789abcdef0123456789abcdef0123_and_0123456789abcdef0123456789abcdef_are_here)
>   [$(uptime)][$(caller_info)] executing program #89abcdef0123456789abcdef01234567
>   [$(uptime)][$(caller_info)] $(kernel_messages_caused_by_89abcdef0123456789abcdef01234567_456789abcdef0123456789abcdef0123_and_0123456789abcdef0123456789abcdef_are_here)
>   [$(uptime)][$(caller_info)] BUG: unable to handle kernel paging request at $(address)
>   [$(uptime)][$(caller_info)] CPU: $(cpu) PID: $(pid) Comm: syz#89abcdef0123 Not tainted $(version) #$(build)
>   [$(uptime)][$(caller_info)] $(backtrace_of_caller_info_is_here)
>   [$(uptime)][$(caller_info)] Kernel panic - not syncing: Fatal exception
>   # Kernel output section end
>   # syzbot code section start
>   Program for #0123456789abcdef0123456789abcdef
>   $(program_lines_for_0123456789abcdef0123456789abcdef_is_here)
>   Program for #456789abcdef0123456789abcdef0123
>   $(program_lines_for_456789abcdef0123456789abcdef0123_is_here)
>   Program for #89abcdef0123456789abcdef01234567
>   $(program_lines_for_89abcdef0123456789abcdef01234567_is_here)
>   # syzbot code section end
>

  reply	other threads:[~2019-01-20 13:30 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-31  7:42 syzbot
2018-12-31  7:49 ` Dmitry Vyukov
2018-12-31  7:49   ` Dmitry Vyukov
2018-12-31  8:17   ` Tetsuo Handa
2018-12-31  8:24     ` Dmitry Vyukov
2018-12-31  8:24       ` Dmitry Vyukov
2019-01-02 17:06       ` Tetsuo Handa
2019-01-05 10:49         ` Tetsuo Handa
2019-01-06 13:24           ` Dmitry Vyukov
2019-01-06 13:24             ` Dmitry Vyukov
2019-01-06 13:47             ` Tetsuo Handa
2019-01-07 11:12               ` Dmitry Vyukov
2019-01-07 11:12                 ` Dmitry Vyukov
2019-01-18  5:20                 ` Tetsuo Handa
2019-01-19 12:16                   ` Dmitry Vyukov
2019-01-19 12:16                     ` Dmitry Vyukov
2019-01-19 13:10                     ` Tetsuo Handa
2019-01-20 13:30                       ` Dmitry Vyukov [this message]
2019-01-20 13:30                         ` Dmitry Vyukov
2019-01-20 14:24                         ` Tetsuo Handa

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+b=5_p=eTgKobApkZZTAVeRxrn3dEempFHampFjrGX0Pw@mail.gmail.com' \
    --to=dvyukov@google.com \
    --cc=davem@davemloft.net \
    --cc=kuznet@ms2.inr.ac.ru \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=netdev@vger.kernel.org \
    --cc=penguin-kernel@i-love.sakura.ne.jp \
    --cc=shakeelb@google.com \
    --cc=syzbot+ea7d9cb314b4ab49a18a@syzkaller.appspotmail.com \
    --cc=syzkaller-bugs@googlegroups.com \
    --cc=syzkaller@googlegroups.com \
    --cc=yoshfuji@linux-ipv6.org \
    --subject='Re: INFO: rcu detected stall in ndisc_alloc_skb' \
    /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

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.