On 03/02/2021 01:48, Jens Axboe wrote: > On 2/2/21 5:04 PM, Pavel Begunkov wrote: >> On 02/02/2021 19:52, Hao Xu wrote: >>> This might happen if we do epoll_wait on a uring fd while reading/writing >>> the former epoll fd in a sqe in the former uring instance. >>> So let's don't flush cqring overflow list when we fail to get the uring >>> lock. This leads to less accuracy, but is still ok. >> >> if (io_cqring_events(ctx) || test_bit(0, &ctx->cq_check_overflow)) >> mask |= EPOLLIN | EPOLLRDNORM; >> >> Instead of flushing. It'd make sense if we define poll as "there might >> be something, go do your peek/wait with overflow checks". Jens, is that >> documented anywhere? > > Nope - I actually think that the approach chosen here is pretty good, > it'll force the app to actually check and hence do what it needs to do. Do you mean that good is this 2-liner? I pretty like it... unless there is a userspace app that would be broken with the change... -- Pavel Begunkov