Re: INFO: task hung in filemap_fault

[Dmitry Vyukov]

On Mon, Jan 15, 2018 at 11:44 AM, Tetsuo Handa
<penguin-kernel@xxxxxxxxxxxxxxxxxxx> wrote:
> Dmitry Vyukov wrote:
>> On Mon, Jan 8, 2018 at 11:48 AM, Tetsuo Handa
>> <penguin-kernel@xxxxxxxxxxxxxxxxxxx> wrote:
>> > Dmitry Vyukov wrote:
>> >> >> Hi Tetsuo,
>> >> >>
>> >> >> syzbot always re-runs the same workload on a new machine. If it
>> >> >> manages to reproduce the problem, it provides a reproducer. In this
>> >> >> case it didn't.
>> >> >
>> >> > Even if it did not manage to reproduce the problem, showing raw.log in
>> >> > C format is helpful for me. For example,
>> >> >
>> >> >   ioctl$LOOP_CHANGE_FD(r3, 0x4c00, r1)
>> >> >
>> >> > is confusing. 0x4c00 is not LOOP_CHANGE_FD but LOOP_SET_FD.
>> >> > If the message were
>> >> >
>> >> >   ioctl(r3, 0x4c00, r1)
>> >> >
>> >> > more people will be able to read what the program tried to do.
>> >> > There are many operations done on loop devices, but are too hard
>> >> > for me to pick up only loop related actions.
>> >>
>> >>
>> >> Hi Tetsuo,
>> >>
>> >> The main purpose of this format is different, this is a complete
>> >> representation of programs that allows replaying them using syzkaller
>> >> tools.
>> >
>> > What is ioctl$LOOP_CHANGE_FD(r3, 0x4c00, r1) ?
>> > 0x4c00 is LOOP_SET_FD. Why LOOP_CHANGE_FD is there?
>>
>>
>> In short, it specifies exact discrimination of the syscall which
>> affects parsing of the rest of the arguments. For some syscalls
>> (ioctl/setsockopt/sendmsg) kernel has hundreds of different
>> discriminations with radically different arguments.
>> Now if you are asking why the discrimination is LOOP_CHANGE_FD, but
>> the actual command is LOOP_SET_FD, that's because this is a fuzzer,
>> it's sole purpose is to mess things in unexpected ways.
>
> ??? I can't catch what you want to say.
>
> I understand that a fuzzer intentionally tests various cases.
> My question is simple. Why don't you use actual command name like
> ioctl$LOOP_SET_FD(r3, 0x4c00, r1) ?
> Writing like ioctl$LOOP_CHANGE_FD is confusing. I consider it as a bug.

To answer this I need to dive a bit into syzkaller internals.
There are 2 main operations with programs: generation and mutations.
During these operations consts specified in syscall discriminations
always match (we don't get LOOP_CHANGE_FD which is actually
LOOP_SET_FD). However, there are some additional operations, in
particular argument changes based on intercepted comparison arguments
in kernel code. Say, we execute LOOP_CHANGE_FD and collect all
comparison arguments and then alter syscall arguments that match one
argument to another argument. That's when we can get discrimination X
which is actually discrimination Y. There is bunch of open questions
associated with this process. First of which is -- should we ever
mutate arguments that are specified as const in a discrimination.
Mutating consts is useful, because that's what allows fuzzer to get to
all of these undescribed ioctls/setsockopts/netlink messages/network
packet protocols, etc. But then, should we also change the
discrimination? What to do if 2 disciminations have completely
different arguments, which are not possible to translate? What if we
don't have a discrimination for the new value at all? What if we have
a partial const match for 2 discriminations, but no exact match for
any discrimination. Also note that it's usually more complex than this
ioctl change because consts can be buried deep into sendmsg's data.
Even in this case, the actual ioctl depends on the file type, but we
can as well have an unknown fd type, so even when we do
ioctl$LOOP_SET_FD(r3, 0x4c00, r1), that's not necessasry LOOP_SET_FD.