Re: [PATCH 4/4] Remove broken posix_fallocate, posix_falllocate64 fallback code [BZ#15661]

[Florian Weimer <fweimer at redhat dot com>]

On 05/26/2015 05:13 PM, Rich Felker wrote:
> On Tue, May 26, 2015 at 11:12:15AM +0200, Florian Weimer wrote:
>> On 05/22/2015 12:18 PM, Mark Wielaard wrote:
>>> On Mon, 2015-05-18 at 12:43 +0200, Florian Weimer wrote:
>>>> Another very recent example is here:
>>>>
>>>> https://lists.fedorahosted.org/pipermail/elfutils-devel/2015-May/004868.html
>>>>
>>>>> 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 should point out that the above patch isn't in elfutils yet. It is
>>> waiting on how this discussion turns out.
>>>
>>> At the moment we simply use ftruncate. The problem that is solved by
>>> using posix_fallocate is that we are about the write to the memory of an
>>> mmapped file. Since ftruncate doesn't guarantee that the backing store
>>> is really there we risk getting a SIGBUS if the disk is full and we
>>> write to a memory area that hasn't been allocated yet. Since this is in
>>> library code, we cannot simply catch the SIGBUS. And we cannot use
>>> fallocate since that doesn't guarantee that the backing store is really
>>> allocated since it depends on whether the underlying file system support
>>> fallocate.
>>
>> posix_fallocate does not guarantee this, either.  See my patch with the
>> documentation update.  Compression, COW, thin provision all can result
>> in ENOSPC.
> 
> These are all buggy, non-conforming implementations.

It's a trade-off.  A malloc with over-commitment is buggy and
non-conforming as well, but it allows you to run more applications at
the same time, actually eliminating failure scenarios.

The same thing is true for posix_fallocate.  You can at least make sure
that quota and file-system-level limits are not in the way.  And if you
want pure fallocate, that's still available.

> That doesn't mean
> users can't use them, but when applications malfunction, it's because
> they're using a low-quality, wrong implementation, not because the
> application has a bug. When the implementation intentionally cuts
> corners on correctness, it's not the application's job to make up for
> it.

I think this isn't really helpful.  There is a need for storage
allocation, and there is empirical evidence that a userspace allocation
loop is worthwhile.  If the kernel does not provide proper fallocate
support, it does not matter from the user perspective if it's in libc or
in the application.  I'd rather provide the best possible implementation
in glibc.

-- 
Florian Weimer / Red Hat Product Security