[Bug libc/14565] New: Unnecessary failure case in sysdeps/posix/writev.c, etc.

[Bug libc/14565] New: Unnecessary failure case in sysdeps/posix/writev.c, etc.

[bugdal at aerifal dot cx]

http://sourceware.org/bugzilla/show_bug.cgi?id=14565

             Bug #: 14565
           Summary: Unnecessary failure case in sysdeps/posix/writev.c,
                    etc.
           Product: glibc
           Version: unspecified
            Status: NEW
          Severity: minor
          Priority: P2
         Component: libc
        AssignedTo: unassigned@sourceware.org
        ReportedBy: bugdal@aerifal.cx
                CC: drepper.fsp@gmail.com
    Classification: Unclassified


The atomic writev emulation in sysdeps/posix/writev.c (and likewise readv)
depends on being able to obtain a potentially-large buffer via malloc, and
fails when memory is unavailable. It would be much nicer to have an automatic
buffer of size PIPE_BUF for use when malloc fails, and simply write at most
PIPE_BUF bytes in that case. This is permitted behavior, per POSIX; writes on
non-pipes are not required to be atomic, and writes on pipes need only be
atomic if the size to be written is bounded by PIPE_BUF. Aside from that case,
"short writes" (and likewise, for readv, "short reads") are permitted, and it's
the caller's responsibility to resubmit the rest if desired.

I have no idea if this code is actually used anywhere, but it would be nice to
fix it anyway, and it could be useful to people porting to obscure systems
(especially if the same code is used in newlib..?)

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/14565] Unnecessary failure case in sysdeps/posix/writev.c, etc.

[joseph at codesourcery dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=14565

--- Comment #1 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2012-09-09 22:19:06 UTC ---
FWIW:

/* Pessimistically assume that 2.6.18 introduced real handling of
   large numbers of requests to readv and writev and that we don't
   need a fallback.  It likely worked for much longer.  */
#if __LINUX_KERNEL_VERSION >= 0x020612
# define __ASSUME_COMPLETE_READV_WRITEV 1
#endif

It would be nice if someone figured out just when this went into the 
kernel - if it was actually 2.6.16 or before, then this replacement code 
isn't actually needed for Linux any more.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/14565] Unnecessary failure case in sysdeps/posix/writev.c, etc.

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=14565

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |fweimer at redhat dot com
         Resolution|---                         |FIXED
              Flags|                            |security-

--- Comment #2 from Florian Weimer <fweimer at redhat dot com> ---
This has been addressed indirectly by requiring a minimum kernel version of
2.6.16, starting with glibc 2.17.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/14565] Unnecessary failure case in sysdeps/posix/writev.c, etc.

[jsm28 at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=14565

Joseph Myers <jsm28 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |---

--- Comment #3 from Joseph Myers <jsm28 at gcc dot gnu.org> ---
This is still an issue with the fallback code present in the glibc source tree
(maybe used on Hurd?), although the problem code won't be used on Linux.

(The relevant Linux kernel support was actually added between 2.0 and 2.2.)

-- 
You are receiving this mail because:
You are on the CC list for the bug.