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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 14 Jan 2009 16:54:30 -0500
From:	Theodore Tso <tytso@....EDU>
To:	Alex Buell <alex.buell@...ted.org.uk>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: 2.6.27 BUG at fs/inode.c:263 with ext4

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/