Re: [PATCH] process_vm_{read,write}v(3): initial man pages

On Tue, 20 Mar 2012 19:27:31 +1300
"Michael Kerrisk (man-pages)" [off-list ref] wrote:

On Tue, Mar 20, 2012 at 1:50 PM, Mike Frysinger [off-list ref]
wrote:

quoted

On Monday 19 March 2012 16:45:41 Michael Kerrisk (man-pages) wrote:

quoted

A quick question about one piece:

quoted

+The count values might be individually capped according to
\fIUIO_MAXIOV\fP. +If the Linux kernel is capped at smaller
values, the C library will take care +of emulating the limit it
exposes (if it is bigger) so the user only needs to +care about
that (what the C library defines).

I don't see anything in glibc that does this. Have I missed
something?

i think you're correct.  the code in glibc atm is merely a
syscall().  i think the idea was to have the C library guarantee
that and if moving forward the kernel changes, the C library would
update by adding a wrapper.  maybe just drop this sentence until
that day comes ?

So, does the kernel currently impose a limit on the size of the iovec?
It wasn't immediately clear to me from a quick scan of the source.

The code calls rw_copy_check_uvector which does check that the iovecs
are smaller than UIO_MAXIOV.

Note that the following bit is not strictly true:
  "So if the counts are too big, or the vectors invalid, or the
  addresses refer to regions that are inaccessible, none of the
  previous vectors will be processed and an +error will be returned
  immediately."

Whilst the code does check that memory regions in the process calling
the system calls are accessible before any work is done, it does not
check the memory regions in the remote process until just before doing
the read/write. So in that case you can end up with a partial
read/write if one of the iovec elements for the remote process points
to an invalid memory region. No further read/writes will be attempted
after this point though.

Regards,

Chris
-- 
cyeoh-hXjcm30GF6XQT0dZR+AlfA@public.gmane.org

--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html