linux-kernel - Re: [PATCH liburing v2 0/1] test: add epoll test case

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 31 Jan 2020 08:39:46 -0700
From:   Jens Axboe <axboe@...nel.dk>
To:     Stefano Garzarella <sgarzare@...hat.com>
Cc:     linux-kernel@...r.kernel.org, io-uring@...r.kernel.org
Subject: Re: [PATCH liburing v2 0/1] test: add epoll test case

On 1/31/20 7:29 AM, Stefano Garzarella wrote:
> Hi Jens,
> this is a v2 of the epoll test.
> 
> v1 -> v2:
>     - if IORING_FEAT_NODROP is not available, avoid to overflow the CQ
>     - add 2 new tests to test epoll with IORING_FEAT_NODROP
>     - cleanups
> 
> There are 4 sub-tests:
>     1. test_epoll
>     2. test_epoll_sqpoll
>     3. test_epoll_nodrop
>     4. test_epoll_sqpoll_nodrop
> 
> In the first 2 tests, I try to avoid to queue more requests than we have room
> for in the CQ ring. These work fine, I have no faults.

Thanks!

> In the tests 3 and 4, if IORING_FEAT_NODROP is supported, I try to submit as
> much as I can until I get a -EBUSY, but they often fail in this way:
> the submitter manages to submit everything, the receiver receives all the
> submitted bytes, but the cleaner loses completion events (I also tried to put a
> timeout to epoll_wait() in the cleaner to be sure that it is not related to the
> patch that I send some weeks ago, but the situation doesn't change, it's like
> there is still overflow in the CQ).
> 
> Next week I'll try to investigate better which is the problem.

Does it change if you have an io_uring_enter() with GETEVENTS set? I wonder if
you just pruned the CQ ring but didn't flush the internal side.

> I hope my test make sense, otherwise let me know what is wrong.

I'll take a look...

> Anyway, when I was exploring the library, I had a doubt:
> - in the __io_uring_get_cqe() should we call sys_io_uring_enter() also if
>   submit and wait_nr are zero, but IORING_SQ_NEED_WAKEUP is set in the
>   sq.kflags?

It's a submission side thing, the completion side shouldn't care. That
flag is only relevant if you're submitting IO with SQPOLL. Then it tells
you that the thread needs to get woken up, which you need io_uring_enter()
to do. But for just reaping completions and not needing to submit
anything new, we don't care if the thread is sleeping.

-- 
Jens Axboe