linux-kernel - Re: INFO: task hung in filemap

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <201801152256.HDH17623.tSJHFLFOFMVOQO@I-love.SAKURA.ne.jp>
Date:   Mon, 15 Jan 2018 22:56:42 +0900
From:   Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
To:     dvyukov@...gle.com
Cc:     bot+980f5e5fc060c37505bd65abb49a963518b269d9@...kaller.appspotmail.com,
        ak@...ux.intel.com, akpm@...ux-foundation.org, jack@...e.cz,
        jlayton@...hat.com, linux-kernel@...r.kernel.org,
        linux-mm@...ck.org, mgorman@...hsingularity.net, mingo@...nel.org,
        npiggin@...il.com, rgoldwyn@...e.com,
        syzkaller-bugs@...glegroups.com, axboe@...nel.dk,
        tom.leiming@...il.com, hare@...e.de, osandov@...com, shli@...com
Subject: Re: INFO: task hung in filemap_fault

Dmitry Vyukov wrote:
> > No problem. In the "tty: User triggerable soft lockup." case, I manually
> > trimmed the reproducer at https://marc.info/?l=linux-mm&m=151368630414963 .
> > That is,
> >
> >  (1) Can the problem be reproduced even if setup_tun(0, true); is commented out?
> >
> >  (2) Can the problem be reproduced even if NONFAILING(A = B); is replaced with
> >      plain A = B; assignment?
> >
> >  (3) Can the problem be reproduced even if install_segv_handler(); is commented
> >      out?
> >
> >  (4) Can the problem be reproduced even if some syscalls (e.g. __NR_memfd_create,
> >      __NR_getsockopt, __NR_perf_event_open) are replaced with no-op?
> >
> > and so on. Then, I finally reached a reproducer which I sent, and the bug was fixed.
> >
> > What is important is that everyone can try simplifying the reproducer written
> > in plain C in order to narrow down the culprit. Providing a (e.g.) CGI service
> > which generates plain C reproducer like gistfile1.txt will be helpful to me.
> 
> 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.