linux-ext4 - Re: LBS support for EXT4

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: <c3ywjnnpfefledcl27qoqvwi4ew7fkrpmneddbxtquazraocrv@5e6l3t5oqap4>
Date: Wed, 25 Jun 2025 13:13:11 +0200
From: "Pankaj Raghav (Samsung)" <kernel@...kajraghav.com>
To: Theodore Ts'o <tytso@....edu>
Cc: Jan Kara <jack@...e.cz>, Luis Chamberlain <mcgrof@...nel.org>, 
	Pankaj Raghav <p.raghav@...sung.com>, linux-ext4@...r.kernel.org, Zhang Yi <yi.zhang@...weicloud.com>, 
	Baokun Li <libaokun1@...wei.com>
Subject: Re: LBS support for EXT4

Thanks for the reply, Ted.

On Mon, Jun 23, 2025 at 10:17:53AM -0400, Theodore Ts'o wrote:
> If you want to review and test the ext4/iomap changes, that would be
> great.  Be aware, though, that there are some features of ext4
> (example: data journalling, fscrypt, fsverity, etc.) that the current
> iomap buffered I/O code may not support today.  The alternatives are
> to keep the existing ext4 code paths for those file system features,
> or to try to add that functionality into iomap.  There are of course
> tradeoffs to both alternatives; one might result in more code that we
> have to maintain; the other might require a lot more work.
> 
> It _might_ be less effort to add LBS support to native ext4 code.  I
> think the main thing is to make sure that we always we use a large
> folio and not fall back to a sub-blocksize set of pages.  So again,
> it's all about tradeoffs and what you consider to be the highest
> priority.

@Baokun are your LBS patches based on the native ext4 code or on top of
Zhang's iomap patches.

> 
> For myself, my primary concern is to keep the code maintainable and to
> not result in any test regressions.  If your goal is to get more file
> systems to use iomap for buffered I/O, that might be different than
> those who are aiming to get performance or improved hardware support
> ASAP as your higher priority.  I will say that in the ideal world, we
> would eventually migrate to use the iomap code for buffered I/O for at
> least the most common case.  But if we end up having an intermediate
> way station where we have large folio support for LBS before we get to
> that desired end state, I'm open to that, so long as the code stays
> maintainable and bug-free(tm).   :-)
> 

This makes sense. Thanks, Ted.

-- 
Pankaj Raghav