linux-kernel - Re: [RFC] xfs: fake fallocate success for always CoW inodes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <878qgg4sh1.fsf@mid.deneb.enyo.de>
Date: Sat, 08 Nov 2025 13:30:18 +0100
From: Florian Weimer <fw@...eb.enyo.de>
To: Christoph Hellwig <hch@....de>
Cc: Florian Weimer <fweimer@...hat.com>,  Matthew Wilcox
 <willy@...radead.org>,  Hans Holmberg <hans.holmberg@....com>,
  linux-xfs@...r.kernel.org,  Carlos Maiolino <cem@...nel.org>,  Dave
 Chinner <david@...morbit.com>,  "Darrick J . Wong" <djwong@...nel.org>,
  linux-fsdevel@...r.kernel.org,  linux-kernel@...r.kernel.org,
  libc-alpha@...rceware.org
Subject: Re: [RFC] xfs: fake fallocate success for always CoW inodes

* Christoph Hellwig:

> On Thu, Nov 06, 2025 at 05:31:28PM +0100, Florian Weimer wrote:
>> It's been a few years, I think, and maybe we should drop the allocation
>> logic from posix_fallocate in glibc?  Assuming that it's implemented
>> everywhere it makes sense?
>
> I really think it should go away.  If it turns out we find cases where
> it was useful we can try to implement a zeroing fallocate in the kernel
> for the file system where people want it.  gfs2 for example currently
> has such an implementation, and we could have somewhat generic library
> version of it.

Sorry, I remember now where this got stuck the last time.

This program:

#include <fcntl.h>
#include <stddef.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/mman.h>

int
main(void)
{
  FILE *fp = tmpfile();
  if (fp == NULL)
    abort();
  int fd = fileno(fp);
  posix_fallocate(fd, 0, 1);
  char *p = mmap(NULL, 1, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
  *p = 1;
}

should not crash even if the file system does not support fallocate.
I hope we can agree on that.  I expect avoiding SIGBUS errors because
of insufficient file size is a common use case for posix_fallocate.
This use is not really an optimization, it's required to get mmap
working properly.

If we can get an fallocate mode that we can use as a fallback to
increase the file size with a zero flag argument, we can definitely
use that in posix_fallocate (replacing the fallback path on kernels
that support it).  All local file systems should be able to implement
that (but perhaps not efficiently).  Basically, what we need here is a
non-destructive ftruncate.

Maybe add two flags, one for the ftruncate replacement, and one that
instructs the file system that the range will be used with mmap soon?
I expect this could be useful information to the file system.  We
wouldn't use it in posix_fallocate, but applications calling fallocate
directly might.

Christoph, is this something you could help with?