From: Dave Chinner <david@fromorbit.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
Al Viro <viro@zeniv.linux.org.uk>,
linux-next@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
Christoph Hellwig <hch@lst.de>, Jens Axboe <axboe@kernel.dk>,
Jan Kara <jack@suse.cz>
Subject: Re: linux-next: OOPS at boot time
Date: Wed, 21 Jul 2010 15:20:07 +1000 [thread overview]
Message-ID: <20100721052007.GT32635@dastard> (raw)
In-Reply-To: <20100720174424.12a4bf64.akpm@linux-foundation.org>
On Tue, Jul 20, 2010 at 05:44:24PM -0700, Andrew Morton wrote:
> On Wed, 21 Jul 2010 08:45:25 +1000 Dave Chinner <david@fromorbit.com> wrote:
> > On Tue, Jul 20, 2010 at 03:36:56AM -0700, Andrew Morton wrote:
> > > On Tue, 20 Jul 2010 16:41:45 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > > > Has anyone seen this or something similar?
> > >
> > > I get it all the time. See the thread "Subject: Re: linux-next: Tree for
> > > July 7".
> >
> > Yet nobody else seems to be able to reproduce it. Given that powerPC
> > is good at triggering reace conditions, maybe there is one that
> > only you are unlucky eough to trigger.
> >
> > Rather than just commenting out the BUG_ON() and ignoring the
> > problem, can you print out the inode state (and enough information
> > to identify the filesystem the inode belongs to) before triggering
> > the BUG_ON() so we can get some idea of how this is triggering?
>
> Already did. ext3. I_DIRTY_SYNC, I_DIRTY_DATASYNC and I_DIRTY_PAGES
> are set (i_state=0x67).
>
> A bit of poking around indicates that these inodes always have zero
> attached pages,
They should, because by the time that bug fires they should have had
all their pages stripped away.
> and they were dirtied within dquot_free_space().
AFAICT dquot_free_space() is called deep in the guts of
ext3_truncate() via dquot_free_block(), which is called directly
before end_writeback(). That should overwrite any state changes made
inside ext3_truncate. I wonder if iput_final() is racing with
something else here?
> This isn't necessarily a problem in the quota code (setting aside the
> question: why the heck does dquot_free_space() set I_DIRTY_PAGES??).
> If the vfs is asked to kill off a dirty inode, it should at least clean
> the thing first.
>
> I dunno. That fs/inode.c patch series from Viro looks fishy. I guess
> I get to bisect it tomorrow.
I suspect that is the only way to get to the bottom of this, short
of a reliable reproducer being discovered. I'm still trying to
reproduce it - I've even turned quota on - but I'm not having any
more luck than over the weekend, though...
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2010-07-21 5:20 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 [this message]
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
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=20100721052007.GT32635@dastard \
--to=david@fromorbit.com \
--cc=akpm@linux-foundation.org \
--cc=axboe@kernel.dk \
--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 \
--cc=viro@zeniv.linux.org.uk \
/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.