[Bug libc/15661] posix_fallocate fallback code buggy and dangerous

["carlos at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

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

Carlos O'Donell <carlos at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |carlos at redhat dot com

--- Comment #7 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to Rich Felker from comment #0)
> When the fallocate syscall returns EOPNOTSUPP, glibc tries to emulate it via
> checking the file size and, if the file size needs to be extended, writing a
> single zero byte at the location that should be the new last byte of the
> file, via pwrite. This approach is broken for two reasons:
> 
> 1. For files opened in O_APPEND mode, pwrite will simply write at the
> current position, extending the file by 1 byte rather than the correct
> amount.

This is a real bug.

> 2. Checking the size then writing at a location past the end of the file
> involves a race condition that could lead to data corruption. If the file is
> extended by another thread or process after the size is checked but before
> pwrite is called, pwrite may overwrite data rather than writing to a new
> location past the end of the file.

Given that posix_fallocate is not listed in POSIX section 2.9.7 "Thread
Interactions with Regular File Operations" the call is not required to be
atomic with respect to any other operation. Therefore it is the responsibility
of the "other thread" to synchronize the file operations with the thread
calling posix_fallocate to ensure posix_fallocate has returned.

Does that justify keeping the fallback code?

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