pread.2, read.2, readv.2, sendfile.2, write.2: Clarify that Linux limits transfers to a maximum of 0x7ffff000 bytes

See https://bugs.debian.org/629994 and
https://bugs.debian.org/630029.

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

man2/pread.2

@@ -85,6 +85,12 @@ and
 .BR pwrite ()
 returns the number of bytes written.
 
+Note that is not an error for a successful call to transfer fewer bytes
+than requested (see
+.BR read (2)
+and
+.BR write (2)).
+
 On error, \-1 is returned and
 .I errno
 is set to indicate the cause of the error.

man2/read.2

@@ -87,6 +87,8 @@ available right now (maybe because we were close to end-of-file, or
 because we are reading from a pipe, or from a terminal), or because
 .BR read ()
 was interrupted by a signal.
+See also NOTES.
+
 On error, \-1 is returned, and
 .I errno
 is set appropriately.
@@ -178,6 +180,14 @@ or to return the number of bytes already read.
 .SH CONFORMING TO
 SVr4, 4.3BSD, POSIX.1-2001.
 .SH NOTES
+On Linux,
+.BR read ()
+(and similar system calls) will transfer at most
+0x7ffff000 (2,147,479,552) bytes,
+returning the number of bytes actually transferred.
+.\" commit e28cc71572da38a5a12c1cfe4d7032017adccf69
+(This is true on both 32-bit and 64-bit systems.)
+
 On NFS filesystems, reading small amounts of data will update the
 timestamp only the first time, subsequent calls may not do so.
 This is caused

man2/readv.2

@@ -184,6 +184,13 @@ return the number of bytes read;
 and
 .BR pwritev ()
 return the number of bytes written.
+
+Note that is not an error for a successful call to transfer fewer bytes
+than requested (see
+.BR read (2)
+and
+.BR write (2)).
+
 On error, \-1 is returned, and \fIerrno\fP is set appropriately.
 .SH ERRORS
 The errors are as given for

man2/sendfile.2

@@ -113,6 +113,7 @@ Note that a successful call to
 .BR sendfile ()
 may write fewer bytes than requested;
 the caller should be prepared to retry the call if there were unsent bytes.
+See also NOTES.
 
 On error, \-1 is returned, and
 .I errno
@@ -166,6 +167,12 @@ Other UNIX systems implement
 with different semantics and prototypes.
 It should not be used in portable programs.
 .SH NOTES
+.BR sendfile ()
+will transfer at most 0x7ffff000 (2,147,479,552) bytes,
+returning the number of bytes actually transferred.
+.\" commit e28cc71572da38a5a12c1cfe4d7032017adccf69
+(This is true on both 32-bit and 64-bit systems.)
+
 If you plan to use
 .BR sendfile ()
 for sending files to a TCP socket, but need

man2/write.2

@@ -89,6 +89,10 @@ Note that not all filesystems are POSIX conforming.
 .SH RETURN VALUE
 On success, the number of bytes written is returned (zero indicates
 nothing was written).
+It is not an error if this number is smaller than the number of bytes
+requested; this may happen for example because the disk device was filled.
+See also NOTES.
+
 On error, \-1 is returned, and \fIerrno\fP is set
 appropriately.
 
@@ -217,6 +221,14 @@ then the call fails with the error
 .BR EINTR ;
 if it is interrupted after at least one byte has been written,
 the call succeeds, and returns the number of bytes written.
+
+On Linux,
+.BR read ()
+(and similar system calls) will transfer at most
+0x7ffff000 (2,147,479,552) bytes,
+returning the number of bytes actually transferred.
+.\" commit e28cc71572da38a5a12c1cfe4d7032017adccf69
+(This is true on both 32-bit and 64-bit systems.)
 .SH BUGS
 According to POSIX.1-2008/SUSv4 Section XSI 2.9.7
 ("Thread Interactions with Regular File Operations"):