linux-kernel - Re: [PATCH 1/4] iomap: Lift blocksize restriction on atomic writes

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: <Z5FdfFZWwlKGaVUD@dread.disaster.area>
Date: Thu, 23 Jan 2025 08:05:00 +1100
From: Dave Chinner <david@...morbit.com>
To: "Darrick J. Wong" <djwong@...nel.org>
Cc: John Garry <john.g.garry@...cle.com>, brauner@...nel.org,
	cem@...nel.org, dchinner@...hat.com, hch@....de,
	ritesh.list@...il.com, linux-xfs@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	martin.petersen@...cle.com
Subject: Re: [PATCH 1/4] iomap: Lift blocksize restriction on atomic writes

On Tue, Jan 14, 2025 at 03:57:26PM -0800, Darrick J. Wong wrote:
> On Tue, Jan 14, 2025 at 03:41:13PM +1100, Dave Chinner wrote:
> > On Wed, Dec 11, 2024 at 05:34:33PM -0800, Darrick J. Wong wrote:
> > > On Fri, Dec 06, 2024 at 08:15:05AM +1100, Dave Chinner wrote:
> > > > On Thu, Dec 05, 2024 at 10:52:50AM +0000, John Garry wrote:
> Tricky questions: How do we avoid collisions between overlapping writes?
> I guess we find a free file range at the top of the file that is long
> enough to stage the write, and put it there?  And purge it later?

Use xfs_bmap_last_offset() to find the last used block in the file,
locate the block we are operating on beyond that. If done under the
ILOCK_EXCL, then this can't race against other attempts to create
a post-EOF extent for an atomic write swap, and it's safe against
other atomic writes in progress.

i.e. we don't really need anything special to create a temporary
post-EOF extent.

> Also, does this imply that the maximum file size is less than the usual
> 8EB?

Maybe. Depends on implementation details, I think.

I think The BMBT on-disk record format can handle offsets beyond
8EiB, so the question remains how we stage the data for the IO into
that extent before we swap it over. The mapping tree index is
actually unsigned, we are limited to 8EiB by loff_t being signed,
not by XFS or the mapping tree being unable to index beyond 8EiB
safely...

> (There's also the question about how to do this with buffered writes,
> but I guess we could skip that for now.)

yup, that's kinda what I meant by "implementation details"...

-Dave.
-- 
Dave Chinner
david@...morbit.com