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: <20251110093701.GB22674@lst.de>
Date: Mon, 10 Nov 2025 10:37:01 +0100
From: Christoph Hellwig <hch@....de>
To: Dave Chinner <david@...morbit.com>
Cc: Florian Weimer <fw@...eb.enyo.de>, 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>,
	"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 Mon, Nov 10, 2025 at 09:15:50AM +1100, Dave Chinner wrote:
> On Sat, Nov 08, 2025 at 01:30:18PM +0100, Florian Weimer wrote:
> > * 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.
> 
> This is what the shiny new FALLOC_FL_WRITE_ZEROS command is supposed
> to provide. We don't have widepsread support in filesystems for it
> yet, though.

Not really.  FALLOC_FL_WRITE_ZEROS does hardware-offloaded zeroing.
I.e., it does the same think as the just write zeroes thing as the
current glibc fallback and is just as bad for the same reasons.  It
also is something that doesn't make any sense to support in a write
out of place file system.

> Failing to check the return value of a library call that documents
> EOPNOTSUPP as a valid error is a bug. IOWs, the above code *should*
> SIGBUS on the mmap access, because it failed to verify that the file
> extension operation actually worked.
> 
> I mean, if this was "ftruncate(1); mmap(); *p =1" and ftruncate()
> failed and so SIGBUS was delivered, there would be no doubt that
> this is an application bug. Why is should we treat errors returned
> by fallocate() and/or posix_fallocate() any different here?

I think what Florian wants (although I might be misunderstanding him)
is an interface that will increase the file size up to the passed in
size, but never reduce it and lose data.

> > 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
> 
> The fallocate() API already support that, in two different ways:
> FALLOC_FL_ZERO_RANGE and FALLOC_FL_WRITE_ZEROS. 

They are both quite different as they both zero the entire passed in
range, even if it already contains data, which is completely different
from the posix_fallocate or fallocate FALLOC_FL_ALLOCATE_RANGE semantics
that leave any existing data intact.