Re: 2.6.27 BUG at fs/inode.c:263 with ext4

From: Theodore Tso
Date: Wed Jan 14 2009 - 16:56:53 EST


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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/