linux-ext4 - Re: [PATCH 0/19 v3] ext4: Fix transaction overflow due to revoke descriptors

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: <20191024151216.GQ31271@quack2.suse.cz>
Date:   Thu, 24 Oct 2019 17:12:16 +0200
From:   Jan Kara <jack@...e.cz>
To:     "Theodore Y. Ts'o" <tytso@....edu>
Cc:     Jan Kara <jack@...e.cz>, linux-ext4@...r.kernel.org
Subject: Re: [PATCH 0/19 v3] ext4: Fix transaction overflow due to revoke
 descriptors

On Thu 24-10-19 15:09:08, Jan Kara wrote:
> On Sat 19-10-19 15:19:33, Theodore Y. Ts'o wrote:
> > Hi Jan,
> > 
> > I've tried applying this patch set against 5.4-rc3, and I'm finding a
> > easily reproducible failure using:
> > 
> > 	kvm-xfstests -c ext3conv ext4/039
> > 
> > It is the BUG_ON in fs/jbd2/commit.c, around line 570:
> > 
> > 	J_ASSERT(commit_transaction->t_nr_buffers <=
> > 		 atomic_read(&commit_transaction->t_outstanding_credits));
> > 
> > The failure (with the obvious debugging printk added) is:
> > 
> > ext4/039		[15:13:16][    6.747101] run fstests ext4/039 at 2019-10
> > -19 15:13:16
> > [    7.018766] Mounted ext4 file system at /vdc supports timestamps until 2038 (
> > 0x7fffffff)
> > [    8.227631] JBD2: t_nr_buffers 226, t_outstanding_credits=223
> > [    8.229215] ------------[ cut here ]------------
> > [    8.230249] kernel BUG at fs/jbd2/commit.c:573!
> >      	       ...
> > 
> > The full log is attached (although the stack trace isn't terribly
> > interesting, since this is being run out of kjournald2).
> 
> Thanks! Somehow this escaped my testing although I thought I have run ext3
> configuration... Anyway we are reserving too few space in this case - with
> some debugging added:
> 
> [   80.296029] t_buffers: 222, t_outstanding_credits: 219,
> t_revoke_written: 23, t_revoke_reserved: 12, t_revoke_records_written
> 11432, t_revoke_records_reserved 11432, revokes_per_block: 1020
> 
> Which is really puzzling because it would suggest that revokes_per_block is
> actually wrong. Digging more into this.

Yeah, ext4 was updating journal features in this case but
j_revoke_records_per_block didn't get properly updated. Fixed now.

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