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]
Message-ID: <ebc2efdb-4e7f-0db9-ef04-c02aac0b08b1@kernel.dk>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ