Re: INFO: task hung in filemap_fault

[Dmitry Vyukov]

On Mon, Jan 15, 2018 at 3:25 PM, Tetsuo Handa
<penguin-kernel@xxxxxxxxxxxxxxxxxxx> wrote:
> Dmitry Vyukov wrote:
>> >> I am not completely following. You previously mentioned raw.log, which
>> >> is a collection of multiple programs, but now you seem to be talking
>> >> about a single reproducer. When syzbot manages to reproduce the bug
>> >> only with syzkaller program but not with a corresponding C program, it
>> >> provides only syzkaller program. It such case it can sense to convert.
>> >> But the case you pointed to actually contains C program. So there is
>> >> no need to do the conversion at all... What am I missing?
>> >>
>> >
>> > raw.log is not readable for me.
>> > I want to see C program even if syzbot did not manage to reproduce the bug.
>> > If C program is available, everyone can try reproducing the bug with manually
>> > trimmed C program.
>>
>> If it did not manage to reproduce the bug, there is no C program.
>> There is no program at all.
>>
>
> What!? Then, what does raw.log contain? I want to read raw.log as C program.


raw.log is not a _program_, it's hundreds of separate programs that
were executed before the crash. It's also very compressed
representation as compared to equivalent C programs. For example for
this program:

mmap(&(0x7f0000000000/0xfff000)=nil, 0xfff000, 0x3, 0x32,
0xffffffffffffffff, 0x0)
r0 = socket$nl_generic(0x10, 0x3, 0x10)
sendmsg$nl_generic(r0,
&(0x7f0000b3e000-0x38)={&(0x7f0000d4a000-0xc)={0x10, 0x0, 0x0, 0x0},
0xc, &(0x7f0000007000)={&(0x7f0000f7c000-0x15c)={0x24, 0x1c, 0x109,
0xffffffffffffffff, 0xffffffffffffffff, {0x4, 0x0, 0x0},
[@nested={0x10, 0x9, [@typed={0xc, 0x0, @u32=0x0}]}]}, 0x24}, 0x1,
0x0, 0x0, 0x0}, 0x0)

you can get up to this amount of C code:
https://gist.githubusercontent.com/dvyukov/eeaeb4e4ac45c3a251f72098c9295bf9/raw/700cd583507eca90711ba11b42e406f317553371/gistfile1.txt

that is, 700 lines of C source for 3 line program. So instead of a 1MB
file that will be 100MB, and then it probably should be a gzip archive
with hundreds of separate C files. There are people on this list
complaining even about 200K of attachments. I don't see that this will
be better and well accepted.