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  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 11 Jan 2021 00:18:05 +0000
From:   Matthew Wilcox <>
To:     Mikulas Patocka <>
Cc:     Al Viro <>,
        Andrew Morton <>,
        Dan Williams <>,
        Vishal Verma <>,
        Dave Jiang <>,
        Ira Weiny <>, Jan Kara <>,
        Steven Whitehouse <>,
        Eric Sandeen <>,
        Dave Chinner <>,
        Theodore Ts'o <>,
        Wang Jianchao <>,
        "Kani, Toshi" <>,
        "Norton, Scott J" <>,
        "Tadakamadla, Rajesh" <>,,,
Subject: Re: Expense of read_iter

On Sun, Jan 10, 2021 at 04:19:15PM -0500, Mikulas Patocka wrote:
> I put counters into vfs_read and vfs_readv.
> After a fresh boot of the virtual machine, the counters show "13385 4". 
> After a kernel compilation they show "4475220 8".
> So, the readv path is almost unused.
> My reasoning was that we should optimize for the "read" path and glue the 
> "readv" path on the top of that. Currently, the kernel is doing the 
> opposite - optimizing for "readv" and glueing "read" on the top of it.

But it's not about optimising for read vs readv.  read_iter handles
a host of other cases, such as pread(), preadv(), AIO reads, splice,
and reads to in-kernel buffers.

Some device drivers abused read() vs readv() to actually return different
information, depending which you called.  That's why there's now a
prohibition against both.

So let's figure out how to make iter_read() perform well for sys_read().

Powered by blists - more mailing lists