[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#629994: marked as done (linux-image-2.6.39-1-amd64: sendfile returns early without user-visible reason)

Your message dated Fri, 10 Jun 2011 14:43:14 +0100
with message-id <1307713394.22348.597.camel@localhost>
and subject line Re: Bug#629994: linux-image-2.6.39-1-amd64: sendfile returns early without user-visible reason
has caused the Debian Bug report #629994,
regarding linux-image-2.6.39-1-amd64: sendfile returns early without user-visible reason
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
629994: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=629994
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: linux-2.6
Version: 2.6.39-1+b1
Severity: normal


In 2.6.39 (and maybe some earlier versions= of Linux, sendfile supports
file->file copies.

Unfortunately, it doesn't handle files near 2GB size correctly and returns
early. For example, here is a call that tries to copy a >3GB file:

[pid  8171] sendfile(18, 17, [0], 3569424384)    = 2147479552

Linux always seems to stop copying at 0x7FFFF000 bytes, without apparent
reason (such as disk full or another error). This happens with a 64 bit
kernel btw., so this is not a 32 bit issue either.

This causes many programs to report a "short write", as this is an error
condition with similar syscalls on files (such as write(2)).

I think sendfile should either not attempt to copy files, or copy the
requested number of bytes unless an error occurs (such as disk full or a
read error). Otherwise programs always need to retry with another syscall,
to see if sendfile returned "just so" or there was an actual problem.

-- Package-specific info:
** Version:
Linux version 2.6.39-1-amd64 (Debian 2.6.39-1) (buildd_amd64-brahms@buildd.debian.org) (gcc version 4.4.6 (Debian 4.4.6-3) ) #1 SMP Tue May 24 14:34:19 UTC 2011

** Tainted: PMO (4113)
 * Proprietary module has been loaded.
 * System experienced a machine check exception.
 * Out-of-tree module has been loaded.

-- System Information:
Debian Release: 6.0.1
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.39-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages linux-image-2.6.39-1-amd64 depends on:
ii  debconf [debconf-2.0]         1.5.36.1   Debian configuration management sy
ii  initramfs-tools [linux-initra 0.99       tools for generating an initramfs
ii  linux-base                    3          Linux image base package
ii  module-init-tools             3.12-1     tools for managing Linux kernel mo

Versions of packages linux-image-2.6.39-1-amd64 recommends:
ii  firmware-linux-free           3          Binary firmware for various driver

Versions of packages linux-image-2.6.39-1-amd64 suggests:
ii  grub-pc                 1.98+20100804-14 GRand Unified Bootloader, version 
ii  lilo                    1:22.8-10        LInux LOader - The Classic OS load
pn  linux-doc-2.6.39        <none>           (no description available)

Versions of packages linux-image-2.6.39-1-amd64 is related to:
ii  firmware-bnx2                 0.28       Binary firmware for Broadcom NetXt
pn  firmware-bnx2x                <none>     (no description available)
pn  firmware-ipw2x00              <none>     (no description available)
pn  firmware-ivtv                 <none>     (no description available)
pn  firmware-iwlwifi              <none>     (no description available)
pn  firmware-linux                <none>     (no description available)
pn  firmware-linux-nonfree        <none>     (no description available)
pn  firmware-qlogic               <none>     (no description available)
pn  firmware-ralink               <none>     (no description available)
pn  xen-hypervisor                <none>     (no description available)

-- debconf information:
  linux-image-2.6.39-1-amd64/prerm/removing-running-kernel-2.6.39-1-amd64: true
* linux-image-2.6.39-1-amd64/postinst/missing-firmware-2.6.39-1-amd64:
  linux-image-2.6.39-1-amd64/postinst/ignoring-ramdisk:
  linux-image-2.6.39-1-amd64/postinst/depmod-error-initrd-2.6.39-1-amd64: false

--- End Message ---
--- Begin Message --- 
On Fri, 2011-06-10 at 07:19 +0200, Marc Lehmann wrote:
> Package: linux-2.6
> Version: 2.6.39-1+b1
> Severity: normal
> 
> 
> In 2.6.39 (and maybe some earlier versions= of Linux, sendfile supports
> file->file copies.
> 
> Unfortunately, it doesn't handle files near 2GB size correctly and returns
> early.
[...]

This was a deliberate change made some time ago to avoid possible
internal overflows.

> I think sendfile should either not attempt to copy files, or copy the
> requested number of bytes unless an error occurs (such as disk full or a
> read error). Otherwise programs always need to retry with another syscall,
> to see if sendfile returned "just so" or there was an actual problem.
[...]

Unix read/write calls have always worked that way.

Ben.

-- 
Ben Hutchings
For every action, there is an equal and opposite criticism. - Harrison

Attachment: signature.asc
Description: This is a digitally signed message part


--- End Message ---
Reply to: