From: Jakub Jelinek <jakub@redhat.com>
To: Andi Kleen <ak@muc.de>
Cc: Jan Kasprzak <kas@informatics.muni.cz>,
linux-kernel@vger.kernel.org, akpm@osdl.org
Subject: Re: sendfile -EOVERFLOW on AMD64
Date: Wed, 19 May 2004 08:50:36 -0400 [thread overview]
Message-ID: <20040519125036.GM30909@devserv.devel.redhat.com> (raw)
In-Reply-To: <20040519124427.GA68902@colin2.muc.de>
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
next prev parent reply other threads:[~2004-05-19 12:51 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1XuW9-3G0-23@gated-at.bofh.it>
2004-05-19 9:29 ` sendfile -EOVERFLOW on AMD64 Andi Kleen
2004-05-19 10:38 ` Jan Kasprzak
2004-05-19 10:58 ` Jakub Jelinek
2004-05-19 11:01 ` Jan Kasprzak
2004-05-19 11:22 ` Nathan Scott
2004-05-19 11:13 ` Nathan Scott
2004-05-19 12:44 ` Andi Kleen
2004-05-19 12:50 ` Jakub Jelinek [this message]
2004-05-19 12:57 ` Andi Kleen
2004-05-19 19:48 ` Jan Kasprzak
2004-05-19 8:44 Jan Kasprzak
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040519125036.GM30909@devserv.devel.redhat.com \
--to=jakub@redhat.com \
--cc=ak@muc.de \
--cc=akpm@osdl.org \
--cc=kas@informatics.muni.cz \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.