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: <20230308163706.t5izn75mhoflxa73@quack3>
Date:   Wed, 8 Mar 2023 17:37:06 +0100
From:   Jan Kara <jack@...e.cz>
To:     Theodore Ts'o <tytso@....edu>
Cc:     Jan Kara <jack@...e.cz>,
        Ext4 Developers List <linux-ext4@...r.kernel.org>
Subject: Re: [PATCH REBASED 0/7] ext4: Cleanup data=journal writeback path

On Fri 03-03-23 11:38:06, Jan Kara wrote:
> On Fri 03-03-23 10:29:39, Jan Kara wrote:
> > On Thu 02-03-23 08:37:35, Theodore Ts'o wrote:
> > > 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?
> > 
> > As we discussed in the meeting, I'll have a look into the failure. For now
> > I'd keep patches on hold as it is not urgent patchset.
> 
> FWIW I'm able to reproduce the issue and also as I'm looking into the
> freeze to it was always there in principle. But my patches likely made it
> much more probable. I'll have a look what I can do...

So in the end this was mostly a cosmetic issue (jbd2 checkpointing code
leaving dirty bits on pages whose buffer heads were already written). Patch
submitted.

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