linux-kernel - Re: [PATCH] char/mem: only use {read,write}_iter, not the old {read,write} functions

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: <f35d7a15-0cbf-1663-15af-eae37a90d0ff@kernel.dk>
Date:   Fri, 20 May 2022 09:11:39 -0600
From:   Jens Axboe <axboe@...nel.dk>
To:     Al Viro <viro@...iv.linux.org.uk>,
        "Jason A. Donenfeld" <Jason@...c4.com>
Cc:     gregkh@...uxfoundation.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] char/mem: only use {read,write}_iter, not the old
 {read,write} functions

On 5/20/22 9:09 AM, Al Viro wrote:
> On Fri, May 20, 2022 at 03:50:30PM +0200, Jason A. Donenfeld wrote:
>> Currently mem.c implements both the {read,write}_iter functions and the
>> {read,write} functions. But with {read,write} going away at some point
>> in the future,
> 
> Not likely to happen, unfortunately.
> 
>> and most kernel code made to prefer {read,write}_iter,
>> there's no point in keeping around the old code.
> 
> Profile and you'll see ;-/

Weren't you working on bits to get us to performance parity there?
What's the status of that?

It really is an unfortunate situation we're currently in with two
methods for either read or write, with one being greatly preferred as we
can pass in non-file associated state (like IOCB_NOWAIT, etc) but the
older variant being a bit faster. It lives us in a bad place, imho.

-- 
Jens Axboe