[lkml]   [2018]   [Jan]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 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 .
> > 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.

 \ /
  Last update: 2018-01-15 14:57    [W:0.057 / U:0.984 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site