linux-ext4 - Re: [PATCH REBASED 0/7] ext4: Cleanup data=journal writeback path

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: <20230228135854.ky2zpwal7trz6yg3@quack3>
Date:   Tue, 28 Feb 2023 14:58:54 +0100
From:   Jan Kara <jack@...e.cz>
To:     Theodore Ts'o <tytso@....edu>
Cc:     Ext4 Developers List <linux-ext4@...r.kernel.org>
Subject: Re: [PATCH REBASED 0/7] ext4: Cleanup data=journal writeback path

Hi Ted!

On Tue 28-02-23 00:13:12, Theodore Ts'o wrote:
> This is Jan's data=journal cleanup patch series, previously submitted
> here[1] rebased on top of Linus's patches to address merge conflicts
> with mm-stable, per this discussion[2].
> 
> [1] https://lore.kernel.org/r/20230111152736.9608-1-jack@suse.cz
> [2] https://lore.kernel.org/r/Y/k4Jvph15ugcY54@mit.edu
> 
> While retesting this patch series, I've noticed a potential regression
> which doesn't trigger before applying the last patch in this series
> (Convert data=journal writeback to use ext4_writepages), but which
> triggers a WARNING in generic/390 about half the time.  I've gone back
> and retested, and this was happening before the rebase.
> 
> Jan, could you take a look and (1) let me know what you think about my
> patch conflict resolutions and (2) what you think about this warning
> which is occasionally triggered by generic/390?  Many thanks!

I went through the patches and they look good to me. I have a side note
that obviously the code isn't quite going to work for folios larger than 1
page but for 1 page folios we should be fine.

Regarding the warning somehow there are dirty pages left after the
procedures freeze_super() goes through to flush all dirty data. That is not
too surprising since in data=journal mode pages get (as a surprise to
freezing code) dirtied when transaction commits. I thought we have this
covered by jbd2_journal_flush() call in ext4_freeze() but maybe there are
some stranded PageDirty bits left? It needs more debugging...

								Honza
-- 
Jan Kara <jack@...e.com>
SUSE Labs, CR