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.
