linux-kernel - Re: 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: <lhu5xbiyzq4.fsf@oldenburg.str.redhat.com>
Date: Mon, 10 Nov 2025 11:00:03 +0100
From: Florian Weimer <fweimer@...hat.com>
To: Christoph Hellwig <hch@....de>
Cc: 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: Re: truncatat? was, Re: [RFC] xfs: fake fallocate success for
 always CoW inodes

* Christoph Hellwig:

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

There are some references to ftruncateat:

  <https://codesearch.debian.net/search?q=ftruncateat&literal=1>

I don't have a particularly strong opinion on the choice of interface.
I can't find anything in the Austin Group tracker that suggests that
they are considering standardizing ftruncateat without a flags argument.

Thanks,
Florian