Hello. https://syzkaller.appspot.com/text?tag=CrashReport&x=154869fd080000 suggests that p9_client_rpc() is trapped at infinite retry loop ---------- again: /* Wait for the response */ err = wait_event_killable(req->wq, req->status >= REQ_STATUS_RCVD); /* Make sure our req is coherent with regard to updates in other * threads - echoes to wmb() in the callback */ smp_rmb(); if (err == -ERESTARTSYS && c->status == Connected && type == P9_TFLUSH) { sigpending = 1; clear_thread_flag(TIF_SIGPENDING); goto again; } ---------- which I guess that net/9p/trans_fd.c is failing to call p9_client_cb() in order to update req->status and wake up req->wq. But why does p9 think that Flush operation worth retrying forever? The peer side should be able to detect close of file descriptor on local side due to process termination via SIGKILL, and the peer side should be able to perform appropriate recovery operation even if local side cannot receive response for Flush operation. Thus, why not to give up upon SIGKILL? On 2018/07/10 19:30, syzbot wrote: > Hello, > > syzbot found the following crash on: > > HEAD commit: d00d6d9a339d Add linux-next specific files for 20180709 > git tree: linux-next > console output: https://syzkaller.appspot.com/x/log.txt?x=111179b2400000 > kernel config: https://syzkaller.appspot.com/x/.config?x=94fe2b586beccacd > dashboard link: https://syzkaller.appspot.com/bug?extid=2349f5067b1772c1d8a5 > compiler: gcc (GCC) 8.0.1 20180413 (experimental) > syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=174329b2400000 > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=11229044400000 > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > Reported-by: syzbot+2349f5067b1772c1d8a5@xxxxxxxxxxxxxxxxxxxxxxxxx >
