From: Artem Bityutskiy <dedekind1@gmail.com>
To: Jan Kara <jack@suse.cz>
Cc: Ted Tso <tytso@mit.edu>,
Ext4 Mailing List <linux-ext4@vger.kernel.org>,
Linux FS Maling List <linux-fsdevel@vger.kernel.org>,
Linux Kernel Maling List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v1 0/9] do not use s_dirt in ext4
Date: Fri, 30 Mar 2012 18:43:15 +0300 [thread overview]
Message-ID: <1333122195.5440.60.camel@sauron.fi.intel.com> (raw)
In-Reply-To: <20120330153530.GH5587@quack.suse.cz>
[-- Attachment #1: Type: text/plain, Size: 2028 bytes --]
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.
Any hints how to properly report an ext4 bug?
--
Best Regards,
Artem Bityutskiy
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2012-03-30 15:40 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-20 14:41 [PATCH v1 0/9] do not use s_dirt in ext4 Artem Bityutskiy
2012-03-20 14:41 ` [PATCH v1 1/9] ext4: do not mark superblock as dirty unnecessarily Artem Bityutskiy
2012-03-22 9:58 ` Jan Kara
2012-03-20 14:41 ` [PATCH v1 2/9] ext4: write superblock only once on unmount Artem Bityutskiy
2012-03-22 9:59 ` Jan Kara
2012-03-20 14:41 ` [PATCH v1 3/9] ext4: remove useless s_dirt assignment Artem Bityutskiy
2012-03-22 10:02 ` Jan Kara
2012-03-20 14:41 ` [PATCH v1 4/9] mm: export dirty_writeback_interval Artem Bityutskiy
2012-03-20 14:41 ` [PATCH v1 5/9] VFS: remove unused superblock helpers Artem Bityutskiy
2012-03-20 14:41 ` [PATCH v1 6/9] ext4: introduce __ext4_mark_super_dirty Artem Bityutskiy
2012-03-20 14:41 ` [PATCH v1 7/9] ext4: stop using VFS for dirty superblock management Artem Bityutskiy
2012-03-21 8:26 ` Artem Bityutskiy
2012-03-20 14:41 ` [PATCH v1 8/9] ext4: small cleanup in ext4_commit_super Artem Bityutskiy
2012-03-22 10:11 ` Jan Kara
2012-03-20 14:41 ` [PATCH v1 9/9] ext4: introduce own superblock dirty flag Artem Bityutskiy
2012-03-22 9:53 ` [PATCH v1 0/9] do not use s_dirt in ext4 Jan Kara
2012-03-22 10:05 ` Artem Bityutskiy
2012-03-22 10:33 ` Jan Kara
2012-03-22 11:25 ` Artem Bityutskiy
2012-03-22 13:42 ` Jan Kara
2012-03-22 13:59 ` Artem Bityutskiy
2012-03-27 13:29 ` Artem Bityutskiy
2012-03-27 20:14 ` Jan Kara
2012-03-28 8:44 ` Artem Bityutskiy
2012-03-28 10:15 ` Jan Kara
2012-03-30 15:23 ` Artem Bityutskiy
2012-03-30 15:35 ` Jan Kara
2012-03-30 15:43 ` Artem Bityutskiy [this message]
2012-03-31 11:49 ` Jan Kara
2012-04-02 13:46 ` Artem Bityutskiy
2012-03-31 12:25 ` Artem Bityutskiy
2012-03-22 13:35 ` Ted Ts'o
2012-03-22 13:56 ` Artem Bityutskiy
2012-03-22 15:06 ` Ted Ts'o
2012-03-23 8:55 ` Artem Bityutskiy
2012-03-23 14:23 ` Ted Ts'o
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1333122195.5440.60.camel@sauron.fi.intel.com \
--to=dedekind1@gmail.com \
--cc=jack@suse.cz \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).