On Thu, Dec 30, 2021 at 1:35 AM Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > > On Mon, Dec 27, 2021 at 05:12:41PM +0800, Xie Yongji wrote: > > The rescuer thread might take over the works queued on > > the workqueue when the worker thread creation timed out. > > If this happens, we have no chance to create multiple > > recv threads which causes I/O hung on this nbd device. > > If a workqueue is used there aren't really 'receive threads'. > What is the deadlock here? We might have multiple recv works, and those recv works won't quit unless the socket is closed. If the rescuer thread takes over those works, only the first recv work can run. The I/O needed to be handled in other recv works would be hung since no thread can handle them. In that case, we can see below stacks in rescuer thread: __schedule schedule scheule_timeout unix_stream_read_generic unix_stream_recvmsg sock_xmit nbd_read_stat recv_work process_one_work rescuer_thread kthread ret_from_fork Thanks, Yongji