netdev - Re: [PATCHv2 00/12] iov_iter: replace import_single

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>] [day] [month] [year] [list]

Message-ID: <f9ca2051-741b-e4bb-74c5-178778c788df@kernel.dk>
Date:   Sun, 8 Jan 2023 20:51:43 -0700
From:   Jens Axboe <axboe@...nel.dk>
To:     Keith Busch <kbusch@...a.com>, linux-kernel@...r.kernel.org,
        Alexander Viro <viro@...iv.linux.org.uk>
Cc:     linux-aio@...ck.org, linux-fsdevel@...r.kernel.org, hch@....de,
        io-uring@...r.kernel.org, Pavel Begunkov <asml.silence@...il.com>,
        Eric Dumazet <edumazet@...gle.com>,
        Steven Rostedt <rostedt@...dmis.org>, davem@...emloft.net,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        David Howells <dhowells@...hat.com>,
        Jarkko Sakkinen <jarkko@...nel.org>,
        Paul Moore <paul@...l-moore.com>, keyrings@...r.kernel.org,
        linux-security-module@...r.kernel.org,
        linux-trace-kernel@...r.kernel.org, linux-block@...r.kernel.org,
        netdev@...r.kernel.org, Keith Busch <kbusch@...nel.org>
Subject: Re: [PATCHv2 00/12] iov_iter: replace import_single_range with ubuf

On 1/5/23 12:07 PM, Keith Busch wrote:
> From: Keith Busch <kbusch@...nel.org>
> 
> ITER_UBUF is a more efficient representation when using single vector
> buffers, providing small optimizations over ITER_IOVEC. This series
> introduces a helper to set these up, and replaces all applicable users
> of import_single_range with the new helper. And since there are no
> single range users left after this change, the helper is no longer
> needed.
> 
> As noted in v1(*), there are some fundamental differences to how io_uring
> compares to read/write/readv/writev. There are only the two affected
> file_operations, and they already do not work with io_uring due to their
> diverging semantics for vectored vs non-vectored read/write. Therefore,
> this series having io_uring prefer ubuf iov_iter isn't introducing new
> breakage.

Pondering how to stage this, both for later upstream but also for
testing. Would probably make the best sense to stage 1-5 separately,
and then just punt the remaining ones to the appropriate subsystems.
And then 12/12 can go in when they have all been applied.

-- 
Jens Axboe