Bug 14565

Summary: Unnecessary failure case in sysdeps/posix/writev.c, etc.
Product: glibc Reporter: Rich Felker <bugdal>
Component: libcAssignee: Not yet assigned to anyone <unassigned>
Status: REOPENED ---    
Severity: minor CC: drepper.fsp, fweimer
Priority: P2 Flags: fweimer: security-
Version: unspecified   
Target Milestone: ---   
Host: Target:
Build: Last reconfirmed:

Description Rich Felker 2012-09-09 19:05:17 UTC 
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..?)
Comment 1 jsm-csl@polyomino.org.uk 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.
Comment 2 Florian Weimer 2014-06-17 04:39:37 UTC 
This has been addressed indirectly by requiring a minimum kernel version of 2.6.16, starting with glibc 2.17.
Comment 3 Joseph Myers 2014-06-17 11:45:40 UTC 
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.)