it seems to be that read event doesn't work properly, but I'm not sure
if it is related to what Pavel mentioned
poll<link>accept works but not poll<link>read -> cqe still receives
poll event but no read event, however I received a read event after
the third request via telnet

I just tested https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git/commit/?h=io_uring-5.9&id=d4e7cd36a90e38e0276d6ce0c20f5ccef17ec38c
and
https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git/commit/?h=io_uring-5.9&id=227c0c9673d86732995474d277f84e08ee763e46
(but it works on Linux 5.7)


On Sat, 15 Aug 2020 at 18:50, Pavel Begunkov <asml.silence@gmail.com> wrote:
>
> On 15/08/2020 18:12, Jens Axboe wrote:
> > On 8/15/20 12:45 AM, Pavel Begunkov wrote:
> >> On 13/08/2020 02:32, Jens Axboe wrote:
> >>> On 8/12/20 12:28 PM, Pavel Begunkov wrote:
> >>>> On 12/08/2020 21:22, Pavel Begunkov wrote:
> >>>>> On 12/08/2020 21:20, Pavel Begunkov wrote:
> >>>>>> On 12/08/2020 21:05, Jens Axboe wrote:
> >>>>>>> On 8/12/20 11:58 AM, Josef wrote:
> >>>>>>>> Hi,
> >>>>>>>>
> >>>>>>>> I have a weird issue on kernel 5.8.0/5.8.1, SIGINT even SIGKILL
> >>>>>>>> doesn't work to kill this process(always state D or D+), literally I
> >>>>>>>> have to terminate my VM because even the kernel can't kill the process
> >>>>>>>> and no issue on 5.7.12-201, however if IOSQE_IO_LINK is not set, it
> >>>>>>>> works
> >>>>>>>>
> >>>>>>>> I've attached a file to reproduce it
> >>>>>>>> or here
> >>>>>>>> https://gist.github.com/1Jo1/15cb3c63439d0c08e3589cfa98418b2c
> >>>>>>>
> >>>>>>> Thanks, I'll take a look at this. It's stuck in uninterruptible
> >>>>>>> state, which is why you can't kill it.
> >>>>>>
> >>>>>> It looks like one of the hangs I've been talking about a few days ago,
> >>>>>> an accept is inflight but can't be found by cancel_files() because it's
> >>>>>> in a link.
> >>>>>
> >>>>> BTW, I described it a month ago, there were more details.
> >>>>
> >>>> https://lore.kernel.org/io-uring/34eb5e5a-8d37-0cae-be6c-c6ac4d85b5d4@gmail.com
> >>>
> >>> Yeah I think you're right. How about something like the below? That'll
> >>> potentially cancel more than just the one we're looking for, but seems
> >>> kind of silly to only cancel from the file table holding request and to
> >>> the end.
> >>
> >> The bug is not poll/t-out related, IIRC my test reproduces it with
> >> read(pipe)->open(). See the previously sent link.
> >
> > Right, but in this context for poll, I just mean any request that has a
> > poll handler armed. Not necessarily only a pure poll. The patch should
> > fix your case, too.
>
> Ok. I was thinking about sleeping in io_read(), etc. from io-wq context.
> That should have the same effect.
>
> >
> >> As mentioned, I'm going to patch that up, if you won't beat me on that.
> >
> > Please test and send a fix if you find something! I'm going to ship what
> > I have this weekend, but we can always add a fix on top if we need
> > anything.
>
> Sure
>
> --
> Pavel Begunkov

--
Josef Grieb