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: <aQjzwh3iAQREjndH@kbusch-mbp>
Date: Mon, 3 Nov 2025 11:26:10 -0700
From: Keith Busch <kbusch@...nel.org>
To: Eric Biggers <ebiggers@...nel.org>
Cc: Christoph Hellwig <hch@....de>, Carlos Llamas <cmllamas@...gle.com>,
	Keith Busch <kbusch@...a.com>, linux-block@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, linux-xfs@...r.kernel.org,
	linux-ext4@...r.kernel.org, axboe@...nel.dk,
	Hannes Reinecke <hare@...e.de>,
	"Martin K. Petersen" <martin.petersen@...cle.com>
Subject: Re: [PATCHv4 5/8] iomap: simplify direct io validity check

On Mon, Nov 03, 2025 at 10:10:31AM -0800, Eric Biggers wrote:
> On Fri, Oct 31, 2025 at 10:18:20AM +0100, Christoph Hellwig wrote:
> > 
> > xfstests just started exercising this and we're getting lots of interesting
> > reports (for the non-fscrypt case).
> 
> Great to hear that it's starting to be tested.  But it's concerning that
> it's just happening now, 3 years after the patches went in, and is also
> still finding lots of bugs.  It's hard for me to understand how it was
> ready, or even useful, in the first place.

I've been using these memory alignment capabilities in production for
quite some time without issue on real hardware, and it's proven very
useful at reducing memory and cpu utilization because that's really how
the data alignment comes into the services responisble for running the
disk io, and the alignment is outside the service's control.

Christoph is testing different use cases with check summing and finding
much of the infrastructure wasn't ready to accept the more arbitrary
memory offsets and lengths.

Finding it now is more of an indication that those two use cases haven't
overlapped.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ