From: Theodore Tso <tytso@MIT.EDU>
To: Alex Buell <alex.buell@munted.org.uk>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: 2.6.27 BUG at fs/inode.c:263 with ext4
Date: Wed, 14 Jan 2009 16:54:30 -0500 [thread overview]
Message-ID: <20090114215430.GK6222@mit.edu> (raw)
In-Reply-To: <20090114210143.39e27168@lithium.local.net>
On Wed, Jan 14, 2009 at 09:01:43PM +0000, Alex Buell wrote:
> I've been testing ext4 with some spare disks, tonight I created an
> ext4fs on a USB 60GB hard disk, and backed up my /home partition
> onto it with rsync.
>
> After umounting the device, and switching off the USB connection I
> got the following in my /var/log/messages.
>
> What would this suggest? I'd be happy to supply further information
> if required.
Can you reproduce this error?
The BUG is coming from fs/inode.c: 263, which in my kernel is this:
void clear_inode(struct inode *inode)
{
might_sleep();
invalidate_inode_buffers(inode);
BUG_ON(inode->i_data.nrpages); <--------------------
BUG_ON(!(inode->i_state & I_FREEING));
BUG_ON(inode->i_state & I_CLEAR);
inode_sync_wait(inode);
DQUOT_DROP(inode);
... and it's apparently coming from udevd when it deletes the device
node from /dev, which looks like is a tempfs filesystem. That would
explain the call stack, which shows that clear_inode() was apparently
called from shmem_delete_inode():
> Jan 14 20:50:00 lithium [<c0157c55>] shmem_delete_inode+0x0/0xae
> Jan 14 20:50:00 lithium [<c016b6e3>] generic_delete_inode+0x91/0xf9
> Jan 14 20:50:00 lithium [<c016ae1d>] iput+0x48/0x4a
> Jan 14 20:50:00 lithium [<c0163a44>] do_unlinkat+0xb0/0x11f
> Jan 14 20:50:00 lithium [<c0112ace>] do_page_fault+0x23c/0x54a
> Jan 14 20:50:00 lithium [<c0102cb1>] sysenter_do_call+0x12/0x25
That would imply that there were pages from the block device still in
the page cache, which I suspect means they were left over from mke2fs
or fsck, or some other program directly accessing the block device
directly. I wonder if this BUG can be triggered if a process has an
open file descriptor on the device at the time when it's powered off,
or pulled from the system?
Some details about how reliably you can reproduce this BUG would be
greatly appreciated.
- Ted
next prev parent reply other threads:[~2009-01-14 21:56 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-14 21:01 2.6.27 BUG at fs/inode.c:263 with ext4 Alex Buell
2009-01-14 21:54 ` Theodore Tso [this message]
2009-01-15 0:02 ` Alex Buell
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=20090114215430.GK6222@mit.edu \
--to=tytso@mit.edu \
--cc=alex.buell@munted.org.uk \
--cc=linux-kernel@vger.kernel.org \
/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