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: <ZACmnwm9in84kbOB@mit.edu>
Date:   Thu, 2 Mar 2023 08:37:35 -0500
From:   "Theodore Ts'o" <tytso@....edu>
To:     Jan Kara <jack@...e.cz>
Cc:     Ext4 Developers List <linux-ext4@...r.kernel.org>
Subject: Re: [PATCH REBASED 0/7] ext4: Cleanup data=journal writeback path

On Tue, Feb 28, 2023 at 02:58:54PM +0100, Jan Kara wrote:
> 
> 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...

So the question I have is whether this is a bug that was always there,
or perhaps code changes affected the timing, so that it was much more
likely to happen (although in my testing it's still only triggering
about 50% of the time).

This warning can mean that data can be lost, especially if someone was
doing hibernation, right?  We can discuss this at today's ext4 video
conference, but I'm inclined to wait until the next merge cycle for
this patch series until we can figure out what's going on.  Jan, what
do you think?

	     	     	       	      - Ted