RE: [RFC][PATCHSET] iov_iter work

[David Laight]

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)