linux-kernel - truncatat? was, 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: <20251110094829.GA24081@lst.de>
Date: Mon, 10 Nov 2025 10:48:29 +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,
	linux-api@...r.kernel.org, libc-alpha@...rceware.org
Subject: truncatat? was, Re: [RFC] xfs: fake fallocate success for always
 CoW inodes

On Mon, Nov 10, 2025 at 10:31:40AM +0100, Christoph Hellwig wrote:
> 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.

The usual way to pass extra flags was the flats at for the *at syscalls.
truncate doesn't have that, and I wonder if there would be uses for
that?  Because if so that feels like the right way to add that feature.
OTOH a quick internet search only pointed to a single question about it,
which was related to other confusion in the use of (f)truncate.

While adding a new system call can be rather cumbersome, the advantage
would be that we could implement the "only increase file size" flag
in common code and it would work on all file systems for kernels that
support the system call.