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]

Date:   Thu, 24 Oct 2019 15:09:08 +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 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.

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