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@xxxxxxxxxx> 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:
signature.asc
Description: This is a digitally signed message part.
