linux-kernel - Re: [PATCH V2] io_uring: introduce inline reqs for IORING_SETUP

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:   Tue, 9 Apr 2019 02:37:17 -0700
From:   Christoph Hellwig <hch@...radead.org>
To:     Jianchao Wang <jianchao.w.wang@...cle.com>
Cc:     axboe@...nel.dk, viro@...iv.linux.org.uk,
        linux-block@...r.kernel.org, linux-fsdevel@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH V2] io_uring: introduce inline reqs for
 IORING_SETUP_IOPOLL

On Tue, Apr 09, 2019 at 01:21:54PM +0800, Jianchao Wang wrote:
> For the IORING_SETUP_IOPOLL case, all of the submission and
> completion are handled under ctx->uring_lock or in SQ poll thread
> context, so io_get_req and io_put_req has been serialized well.
> The only exception is the asynchronous workqueue context where could
> free the io_kiocb for error. To overcome this, we allocate a new
> io_kiocb and free the previous inlined one.
> 
> Based on this, we introduce the preallocated reqs list per ctx and
> needn't to provide any lock to serialize the updating of list. The
> performacne benefits from this. The test result of following fio
> command

I really don't like the idea of exposing this to userspace.  Is
there any good reason to not simply always allocate inline request
up to a certain ring size?