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, 8 Jun 2021 14:43:28 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Al Viro' <viro@...iv.linux.org.uk>,
        Linus Torvalds <torvalds@...ux-foundation.org>
CC:     "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        David Sterba <dsterba@...e.com>,
        Miklos Szeredi <miklos@...redi.hu>,
        Anton Altaparmakov <anton@...era.com>,
        David Howells <dhowells@...hat.com>,
        Matthew Wilcox <willy@...radead.org>,
        Pavel Begunkov <asml.silence@...il.com>
Subject: RE: [RFC][PATCHSET] iov_iter work

My 'brain farts' :-)

I've looked as at iterate_all_kinds() and my brain melted.

Certainly optimising for 'copy all the data' seems right.
There are also hot code paths where a vector length of 1
is very common (eg sendmsg).

Do I remember the code incrementing iter->iov as it
progresses down the list of buffers?
That is probably rather more dangerous than keeping
the buffer index.
If the buffer index is kept then 'backing up' and
setting a fixed offset become much safer - if slower
in unusual cases.

The short iov_cache[] used for iovec could be put inside
the iov_iter structure (perhaps a special extended structure).
I think everything allocates both (typically on stack)
at exactly the same time.
This definitely neatens up all the callers.
(I've had a patch for it - except io-uring.)

I wonder if long iovec could read the ptr:length
from userspace as the copy progresses?
(To save the malloc/free.)
ISTR the total length is needed up front - so that
would need to be a separate loop.
This might be problematic for architectures that have
directional and ranged user access enables.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ