On Sat, Jan 19, 2019 at 2:10 PM Tetsuo Handa
[off-list ref] wrote:

On 2019/01/19 21:16, Dmitry Vyukov wrote:

quoted

quoted

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