This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 4/4] Remove broken posix_fallocate, posix_falllocate64 fallback code [BZ#15661]
- From: Florian Weimer <fweimer at redhat dot com>
- To: Roland McGrath <roland at hack dot frob dot com>, Rich Felker <dalias at libc dot org>
- Cc: Paul Eggert <eggert at cs dot ucla dot edu>, libc-alpha at sourceware dot org
- Date: Thu, 07 May 2015 21:05:33 +0200
- Subject: Re: [PATCH 4/4] Remove broken posix_fallocate, posix_falllocate64 fallback code [BZ#15661]
- Authentication-results: sourceware.org; auth=none
- References: <20150424134516 dot 6795441F484D0 at oldenburg dot str dot redhat dot com> <554927F9 dot 7080509 at redhat dot com> <5549C097 dot 50505 at redhat dot com> <554A9A46 dot 2050806 at cs dot ucla dot edu> <20150506233055 dot GQ17573 at brightrain dot aerifal dot cx> <20150507181942 dot E71202C3B93 at topped-with-meat dot com>
On 05/07/2015 08:19 PM, Roland McGrath wrote:
>> If I'm not mistaken ftruncate could still reduce the file size if it
>> races with another operation that would extend the file. This is also
>> a data loss bug.
>
> I concur.
It happens with length == 0. We could error out with EINVAL instead of
calling ftruncate.
Daniel Berrange pointed me to these bugs:
https://sourceware.org/bugzilla/show_bug.cgi?id=17322
https://bugzilla.redhat.com/show_bug.cgi?id=1140250
https://bugzilla.redhat.com/show_bug.cgi?id=1077068
This suggests that people actually rely on the current allocation
behavior. Combined with my previous analysis that applications will
start to fail if we remove the fallback and return EINVAL, I now think
we need to keep the allocation loop.
I don't like this situation. It's a strong argument against providing
approximate user-space emulation (setxid is another example, I'm sure
there are others). These experiences may be relevant to the getrandom
debate.
I'm working on a patch with a few minor fixes to posix_fallocate and an
update to the manual. I don't think we can do better at present,
unfortunately.
--
Florian Weimer / Red Hat Product Security