Messages in this thread |  | | | Date | Wed, 19 May 2004 08:50:36 -0400 | | From | Jakub Jelinek <> | | Subject | Re: sendfile -EOVERFLOW on AMD64 |
| |
On Wed, May 19, 2004 at 02:44:27PM +0200, Andi Kleen wrote: > > (note error is int, not ssize_t), but I don't see anything obvious > > for other filesystems. > > sendfile64 on 32bit hosts seems to be quite fishy too. > > It works with ssize_t, which is 32bit only, but there are no checks > that the transfered file is not >4GB. It would just wrap in this case. > It would be better to add such checks for 32bit hosts to sendfile64. > > Or am I missing something?
The userland prototypes are: extern ssize_t sendfile (int __out_fd, int __in_fd, off_t *__offset, size_t __count) __THROW; extern ssize_t sendfile64 (int __out_fd, int __in_fd, __off64_t *__offset, size_t __count) __THROW; Thus you really cannot transfer more than 4G-1 bytes in one call on 32-bit arches. Actually, already any counts >= 2GB-1 might be problematic, but we are there on the same boat as with e.g. read(2). For read, POSIX says: "If the value of nbyte is greater than {SSIZE_MAX}, the result is implementation-defined." so portable programs really shouldn't try to transfer more than that in one go but the kernel certainly should try to handle sizes up to SIZE_MAX-4096 or something like that. Jakub - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |