linux-kernel - Re: [PATCH] xfs: fix confused tracepoints in xfs_reflink_end_atomic

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] [day] [month] [year] [list]

Message-ID: <20251125021800.GA6061@frogsfrogsfrogs>
Date: Mon, 24 Nov 2025 18:18:00 -0800
From: "Darrick J. Wong" <djwong@...nel.org>
To: John Garry <john.g.garry@...cle.com>
Cc: Christoph Hellwig <hch@...radead.org>, alexjlzheng@...il.com,
	cem@...nel.org, linux-xfs@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Jinliang Zheng <alexjlzheng@...cent.com>,
	"Darrick J. Wong" <darrick.wong@...cle.com>
Subject: Re: [PATCH] xfs: fix confused tracepoints in
 xfs_reflink_end_atomic_cow()

On Mon, Nov 24, 2025 at 02:25:29PM +0000, John Garry wrote:
> On 24/11/2025 14:04, Christoph Hellwig wrote:
> > On Mon, Nov 24, 2025 at 10:57:24AM +0000, John Garry wrote:
> > > Commit d6f215f35963 might be able to explain that.
> > 
> > I don't think so.
> 
> I am just pointing out why it was changed to use a separate transaction per
> extent [and why the cow end handler for atomic writes is different].
> 
> > That commit splits up the operation so to avoid
> > doing the entire operation in a single transaction, and the rationale
> > for this is sound.  But the atomic work showed that it went to far,

It did go too far, because when d6f215f3596 was written we didn't have
these nice helpers that guestimate how many deferred remapping ops we
can attach to a single fresh transaction.

Nowadays we probably could speed up the non-atomic remapping path by
computing a safe batching factor and doing that much instead of only one
extent per transaction chain.  Stupidly hardcoding 16 would be enough to
achieve an order of magnitude improvement.

Nobody's complained about slow ioend performance enough to do that work
and then QA it though.  Remember, that d6f commit comes with the
following barb:

"Note that this can be reproduced after ~320 million fsx ops while
running generic/938 (long soak directio fsx exerciser):"

(generic/938 is now generic/521.)

--D

> > because we can still batch up a fair amount of conversions.  I think
> > the argument of allowing to batch up as many transactions as we allow
> > in an atomic write still makes perfect sense.
> > 
> 
> Sure, Darrick knows more about this than me (so I'll let him comment).
> 
>