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

[Mike Frysinger <vapier-aBrp7R+bbdUdnm+yROfE0A@public.gmane.org>]

[-- Attachment #1: Type: Text/Plain, Size: 1414 bytes --]

On Tuesday 20 March 2012 02:27:31 Michael Kerrisk (man-pages) wrote:
> On Tue, Mar 20, 2012 at 1:50 PM, Mike Frysinger <vapier-aBrp7R+bbdUdnm+yROfE0A@public.gmane.org> wrote:
> > On Monday 19 March 2012 16:45:41 Michael Kerrisk (man-pages) wrote:
> >> A quick question about one piece:
> >> > +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.

yes.  process_vm_{read,write}v() in mm/process_vm_access.c calls 
process_vm_rw() which calls rw_copy_check_uvector() in fs/read_write.c and one 
of the first things it does:
    if (nr_segs > UIO_MAXIOV) {
        ret = -EINVAL;
        goto out;
    }
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]