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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20251110093140.GA22674@lst.de>
Date: Mon, 10 Nov 2025 10:31:40 +0100
From: Christoph Hellwig <hch@....de>
To: Florian Weimer <fw@...eb.enyo.de>
Cc: Christoph Hellwig <hch@....de>, 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

On Sat, Nov 08, 2025 at 01:30:18PM +0100, Florian Weimer wrote:
> 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.

That's a weird use of posix_fallocate, but if an interface to increase
the file without the chance of reducing it is useful that's for
sure something we could add.

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

fallocate seems like an odd interface choice for that, but given that
(f)truncate doesn't have a flags argument that might still be the
least unexpected version.

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

What do you think "to be used with mmap" flag could be useful for
in the file system?  For file systems mmap I/O isn't very different
from other use cases.