Re: INFO: task hung in filemap_fault

[Dmitry Vyukov]

On Mon, Jan 1, 2018 at 4:27 PM, Tetsuo Handa
<penguin-kernel@xxxxxxxxxxxxxxxxxxx> wrote:
> I suggest syzbot to try linux.git before reporting bugs in linux-next.git.
> You know there are many duplicates caused by an invalid free in pcrypt.
> Soft lockups in ioctl(LOOP_SET_FD) are
>
>         /* Avoid recursion */
>         f = file;
>         while (is_loop_device(f)) {
>                 struct loop_device *l;
>
>                 if (f->f_mapping->host->i_bdev == bdev)
>                         goto out_putf;
>
>                 l = f->f_mapping->host->i_bdev->bd_disk->private_data;
>                 if (l->lo_state == Lo_unbound) {
>                         error = -EINVAL;
>                         goto out_putf;
>                 }
>                 f = l->lo_backing_file;
>         }
>
> loop which means that something (maybe memory corruption) is forming circular
> chain, and there seems to be some encryption related parameters/values in
> raw.log file. It is nice to retest a kernel without encryption related things
> and/or a kernel without known encryption related bugs.


Hi Tetsuo,

Let's forget about the single crypto bug. We can't build the system
that handles hundreds of bugs around that single bug which is fixed at
this point. What is the general improvement you are proposing?

Note that some bugs are only in linux.git, some are only in
linux-next.git, some are only in net, kvm, etc, or maybe in some
combination of these. And we generally don't know where a bug is
present and where it is not. We can try to do some assumption _if_ the
bug has a reproducer, but even then most kernel bugs are due to races
and can't be reproduced with 100% probability, or it can't be just
that the same bug can be reproduced on a different tree but requires a
slightly different reproducer. So any such assumptions won't be 100%
reliable, and any flaw in information syzbot provides usually provokes
lots of very negative reaction from kernel developers.