linux-kernel - RE: [RFC][PATCHSET] iov

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: <7591552a5ec5469d8a084c47f370ac03@AcuMS.aculab.com>
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)