linux-ext4 - Re: [PATCH v1 0/9] do not use s

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: <20120331114926.GA4569@quack.suse.cz>
Date:	Sat, 31 Mar 2012 13:49:26 +0200
From:	Jan Kara <jack@...e.cz>
To:	Artem Bityutskiy <dedekind1@...il.com>
Cc:	Jan Kara <jack@...e.cz>, Ted Tso <tytso@....edu>,
	Ext4 Mailing List <linux-ext4@...r.kernel.org>,
	Linux FS Maling List <linux-fsdevel@...r.kernel.org>,
	Linux Kernel Maling List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v1 0/9] do not use s_dirt in ext4

On Fri 30-03-12 18:43:15, Artem Bityutskiy wrote:
> On Fri, 2012-03-30 at 17:35 +0200, Jan Kara wrote:
> > > [23500.239442]  [<ffffffff811ab59d>] write_dirty_buffer+0x4d/0x80
> > > [23500.239442]  [<ffffffff8123be1d>] __flush_batch+0x4d/0xa0
> > > [23500.239442]  [<ffffffff8123c605>] jbd2_log_do_checkpoint+0xf5/0x4f0
> > > [23500.239442]  [<ffffffff8123ca89>] __jbd2_log_wait_for_space+0x89/0x190
> > > [23500.239442]  [<ffffffff81237a98>] start_this_handle+0x3a8/0x4e0
> > > [23500.239442]  [<ffffffff810799e0>] ? remove_wait_queue+0x50/0x50
> > > [23500.239442]  [<ffffffff81237c93>] jbd2__journal_start+0xc3/0x100
> > > [23500.239442]  [<ffffffff81237ce3>] jbd2_journal_start+0x13/0x20
> > > [23500.239442]  [<ffffffff8121743f>] ext4_journal_start_sb+0x7f/0x1d0
> > > [23500.239442]  [<ffffffff81224a24>] ? ext4_fallocate+0x1a4/0x530
> > > [23500.239442]  [<ffffffff811f64c5>] ? ext4_meta_trans_blocks+0xa5/0xb0
> > > [23500.239442]  [<ffffffff81224a24>] ext4_fallocate+0x1a4/0x530
> > > [23500.239442]  [<ffffffff8117a092>] do_fallocate+0xf2/0x160
> > > [23500.239442]  [<ffffffff8117a14b>] sys_fallocate+0x4b/0x70
> > > [23500.239442]  [<ffffffff815e6d69>] system_call_fastpath+0x16/0x1b
> > > [23500.239442] Code: ee 44 89 e7 e8 35 1f 0f 00 49 8b 5d 18 4c 89 ef e8 19 4e 00 00 48 83 c4 08 c1 e3 18 c1 fb 1f 83 e3 a1 89 d8 5b 41 5c 41 5d 5d c3 <0f> 0b 0f 0b 0f 0b 0f 0b 0f 0b 66 0f 1f 84 00 00 00 00 00 55 48 
> > > [23500.239442] RIP  [<ffffffff811a9add>] submit_bh+0x10d/0x120
> > > [23500.239442]  RSP <ffff880273a41b58>
> > > [23500.261657] ---[ end trace 3db7a7a7ae953551 ]---
> >   Hmm, looks like we tried to checkpoint BH_Unwritten buffer. That looks
> > like a bug in fallocate() support. Not really related but definitely worth
> > reporting.
> 
> Well, I ran vanilla the tests in vanilla 3.3 overnight, they were fine.
> But may be I was lucky. I'll try to run the tests with vanilla kernel
> some more. I mean, it would make more sense to report something against
> vanilla 3.3, not a patched 3.3.
  That's true. Frankly I think you were lucky with hitting the bug with
patched kernel rather than not hitting it with vanilla :). What test did
you run exactly?

> Any hints how to properly report an ext4 bug?
  Hmm, like any other. Report what load did you run, what kernel, and the
oops... And send the report to linux-ext4@...r.kernel.org.
								Honza

-- 
Jan Kara <jack@...e.cz>
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html