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: <20250623141753.GA33354@mit.edu>
Date: Mon, 23 Jun 2025 10:17:53 -0400
From: "Theodore Ts'o" <tytso@....edu>
To: Pankaj Raghav <kernel@...kajraghav.com>
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

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.

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).   :-)

Cheers,

						- Ted