Bug 14565 - Unnecessary failure case in sysdeps/posix/writev.c, etc.
Summary: Unnecessary failure case in sysdeps/posix/writev.c, etc.
Alias: None
Product: glibc
Classification: Unclassified
Component: libc (show other bugs)
Version: unspecified
: P2 minor
Target Milestone: ---
Assignee: Not yet assigned to anyone
Depends on:
Reported: 2012-09-09 19:05 UTC by Rich Felker
Modified: 2014-06-17 11:45 UTC (History)
2 users (show)

See Also:
Last reconfirmed:
fweimer: security-


Note You need to log in before you can comment on or make changes to this bug.
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 joseph@codesourcery.com 2012-09-09 22:19:06 UTC

/* 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

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.)