linux-kernel - Re: [PATCH v2 2/7] iomap: Add zero unwritten mappings dio support

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: <20250108012636.GE1306365@frogsfrogsfrogs>
Date: Tue, 7 Jan 2025 17:26:36 -0800
From: "Darrick J. Wong" <djwong@...nel.org>
To: John Garry <john.g.garry@...cle.com>
Cc: Christoph Hellwig <hch@....de>, brauner@...nel.org, cem@...nel.org,
	dchinner@...hat.com, 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 v2 2/7] iomap: Add zero unwritten mappings dio support

On Wed, Dec 18, 2024 at 11:15:42AM +0000, John Garry wrote:
> On 17/12/2024 07:08, Christoph Hellwig wrote:
> > On Fri, Dec 13, 2024 at 04:56:38PM -0800, Darrick J. Wong wrote:
> > > > > "If you receive -EBADMAP, then call fallocate(FALLOC_FL_MAKE_OVERWRITE)
> > > > > to force all the mappings to pure overwrites."
> > > > 
> > > > Ewwwwwwwwwwwwwwwwwwwww.
> > > > 
> > > > That's not a sane API in any way.
> > > 
> > > Oh I know, I'd much rather stick to the view that block untorn writes
> > > are a means for programs that only ever do IO in large(ish) blocks to
> > > take advantage of a hardware feature that also wants those large
> > > blocks.
> > 
> > I (vaguely) agree ith that.
> > 
> > > And only if the file mapping is in the correct state, and the
> > > program is willing to *maintain* them in the correct state to get the
> > > better performance.
> > 
> > I kinda agree with that, but the maintain is a bit hard as general
> > rule of thumb as file mappings can change behind the applications
> > back.  So building interfaces around the concept that there are
> > entirely stable mappings seems like a bad idea.
> 
> I tend to agree.

As long as it's a general rule that file mappings can change even after
whatever prep work an application tries to do, we're never going to have
an easy time enabling any of these fancy direct-to-storage tricks like
cpu loads and stores to pmem, or this block-untorn writes stuff.

> > 
> > > I don't want xfs to grow code to write zeroes to
> > > mapped blocks just so it can then write-untorn to the same blocks.
> > 
> > Agreed.
> > 
> 
> So if we want to allow large writes over mixed extents, how to handle?
> 
> Note that some time ago we also discussed that we don't want to have a
> single bio covering mixed extents as we cannot atomically convert all
> unwritten extents to mapped.

>From https://lore.kernel.org/linux-xfs/Z3wbqlfoZjisbe1x@infradead.org/ :

"I think we should wire it up as a new FALLOC_FL_WRITE_ZEROES mode,
document very vigorously that it exists to facilitate pure overwrites
(specifically that it returns EOPNOTSUPP for always-cow files), and not
add more ioctls."

If we added this new fallocate mode to set up written mappings, would it
be enough to write in the programming manuals that applications should
use it to prepare a file for block-untorn writes?  Perhaps we should
change the errno code to EMEDIUMTYPE for the mixed mappings case.

Alternately, maybe we /should/ let programs open a lease-fd on a file
range, do their untorn writes through the lease fd, and if another
thread does something to break the lease, then the lease fd returns EIO
until you close it.

<shrug> any thoughts?

--D

> Thanks,
> John
> 
> 
> 
>