From: Al Viro <viro@ZenIV.linux.org.uk>
To: Jan Kara <jack@suse.cz>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
Andrew Morton <akpm@linux-foundation.org>,
Dave Chinner <david@fromorbit.com>,
linux-next@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
Christoph Hellwig <hch@lst.de>, Jens Axboe <axboe@kernel.dk>
Subject: Re: linux-next: OOPS at boot time
Date: Wed, 21 Jul 2010 18:49:52 +0100 [thread overview]
Message-ID: <20100721174952.GT31073@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20100721121116.GD3447@quack.suse.cz>
On Wed, Jul 21, 2010 at 02:11:17PM +0200, Jan Kara wrote:
> Thanks for bisecting this. The patch series indeed seems to uncover
> some discrepancies.
> Ext3 has always dirtied inode in it's ->delete_inode method (via quota
> code). But previously clear_inode() just overwrote the state with I_CLEAR
> and thus we never saw the BUG_ON. After Al's patches, i_state is set in
> end_writeback() which happens earlier. In particular it happens before
> ext3_free_inode() which dirties the inode through quota code while freeing
> xattrs - they are accounted in i_blocks, so i_blocks are updated during
> freeing and inode is dirtied.
> Actually, ext3_mark_inode_dirty() called during each mark_inode_dirty()
> call writes the inode state to the journal so the dirty flag in the inode
> state is in fact stale and overwriting it with I_CLEAR never mattered. In
> this sense, the BUG_ON triggered is a false positive. But I believe this is
> a separate story.
> I'm not sure how to really fix this. It seems a bit premature to me to
> mark inode as I_CLEAR before the filesystem is actually done with it. So
> maybe the line
> inode->i_state = I_FREEING | I_CLEAR;
> should be moved to evict() fuction?
Nope. I_CLEAR is "no async calls from vfs anymore; it's under complete
fs control and is about to die now".
In any case, I'll post a dumb replacement for ext3 after I verify it on
the laptop I have with me. Should be in an hour or so (the damn thing is
_slow_).
next prev parent reply other threads:[~2010-07-21 17:50 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-20 6:41 linux-next: OOPS at boot time Stephen Rothwell
2010-07-20 9:12 ` Milton Miller
2010-07-20 10:36 ` Andrew Morton
2010-07-20 22:45 ` Dave Chinner
2010-07-21 0:44 ` Andrew Morton
2010-07-21 5:20 ` Dave Chinner
2010-07-21 7:29 ` Andrew Morton
2010-07-21 7:48 ` Stephen Rothwell
2010-07-21 12:11 ` Jan Kara
2010-07-21 17:49 ` Al Viro [this message]
2010-07-21 21:40 ` Al Viro
2010-07-23 10:04 ` Jan Kara
2010-07-24 12:27 ` Al Viro
2010-07-21 23:19 ` Dave Chinner
2010-07-21 12:19 ` Jan Kara
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=20100721174952.GT31073@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=akpm@linux-foundation.org \
--cc=axboe@kernel.dk \
--cc=david@fromorbit.com \
--cc=hch@lst.de \
--cc=jack@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=sfr@canb.auug.org.au \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.