Re: kernel BUG at inode.c:889!

Re: kernel BUG at inode.c:889!

[Andreas Dilger]

I previously wrote:
> Below is a patch which should fix this.  It _should_ prevent you from
> mounting this filesystem in the first place, and should also stop the BUG
> in inode.c.  I'm not 100% sure of correctness, however:
> - is calling clear_inode() in these error cases OK?
> - is calling dput() the right thing to do for the root dentry?  This
>   is what kill_super() does when cleaning up the filesystem.
> 
> Cheers, Andreas
> ============================================================================
> --- fs/ext2/super.c.orig	Tue Jan 23 17:24:45 2001
> +++ fs/ext2/super.c	Wed Jan 31 12:27:25 2001
> @@ -628,13 +628,19 @@
>  	 */
>  	sb->s_op = &ext2_sops;
>  	sb->s_root = d_alloc_root(iget(sb, EXT2_ROOT_INO));
> -	if (!sb->s_root) {
> +	if (!sb->s_root || !S_ISDIR(sb->s_root->d_inode) ||

This should be !S_ISDIR(sb->s_root->d_inode->i_mode).

> +	    !sb->s_root->d_inode->i_blocks || !sb->s_root->d_inode->i_size) {
> +		if (sb->s_root) {
> +			dput(sb->s_root);
> +			sb->s_root = NULL;
> +			printk ("EXT2-fs: corrupt root inode, run e2fsck\n");
> +		} else
> +			printk ("EXT2-fs: get root inode failed\n");

Cheers, Andreas
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

kernel BUG at inode.c:889!

[Timo Jantunen]

Heip!


While I was looking unused partitions to be used for ReiserFS testing
(paranoia is a way of life when dealing with my data ;-), I did

mount /dev/hda5 /mnt/tmp

to a partition which I thought to be unused (just to be sure). This resulted
in a Really Weird(tm) /mnt/tmp _file_ which didn't have any permissions to
anyone. When checking kernel messages, I found "EXT2-fs warning: checktime
reached, running e2fsck is recommended" line. Then I tried to unmount the
partition. It checkfaulted. Messages had following entries.

---cut
Jan 31 19:46:30 limbo kernel: EXT2-fs error (device ide0(3,5)): free_inode: reserved inode or nonexistent inode
Jan 31 19:46:30 limbo kernel: kernel BUG at inode.c:889!
Jan 31 19:46:30 limbo kernel: invalid operand: 0000
Jan 31 19:46:30 limbo kernel: CPU:    0
Jan 31 19:46:30 limbo kernel: EIP:    0010:[iput+205/336]
Jan 31 19:46:30 limbo kernel: EFLAGS: 00010282
Jan 31 19:46:30 limbo kernel: eax: 0000001b   ebx: c7ce7180   ecx: cd536000   edx: c023a328
Jan 31 19:46:30 limbo kernel: esi: c023dde0   edi: c023dde0   ebp: c023de18   esp: c7c69f20
Jan 31 19:46:30 limbo kernel: ds: 0018   es: 0018   ss: 0018
Jan 31 19:46:30 limbo kernel: Process umount (pid: 1076, stackpage=c7c69000)
Jan 31 19:46:30 limbo kernel: Stack: c020954b c02095eb 00000379 c80b48c0 c7ce7180 c01413fe c7ce7180 cbb04e00
Jan 31 19:46:30 limbo kernel:        c80b48c0 c01352ff c80b48c0 c88ed0c0 cbb04e00 00000000 080526c0 c013466a
Jan 31 19:46:30 limbo kernel:        c0135731 cbb04e00 00000000 c88ed0c0 c023ce8c ffffffff cd07a000 c0135803
Jan 31 19:46:30 limbo kernel: Call Trace: [dput+238/336] [kill_super+63/304] [remove_vfsmnt+138/144] [do_umount+433/448] [sys_umount+195/240] [sys_munmap+43/64] [sys_oldumount+12/16]
Jan 31 19:46:30 limbo kernel:        [system_call+51/56]
Jan 31 19:46:30 limbo kernel:
Jan 31 19:46:30 limbo kernel: Code: 0f 0b 83 c4 0c eb 6c 39 1b 74 38 f6 83 ec 00 00 00 07 75 26
---cut

I couldn't unmount that partition, but SysRq <Sync> <Unmount> <Boot> saved
all other partitions.

After reboot I fsck'd /dev/hda5 and it was seriously messed up. Actually it
was very likely once part of RAID array tests I did a while back (/dev/hda5
was 5GB but fsck said ext2 was a 6GB filesystem).

So ok, I did try to mount a seriously messed up filesystem, but it shouldn't
be possible in the first place or at least it shouldn't do that when I try to
umount.


// /
....................................Timo Jantunen  ......................
       ZZZ      (Used to represent :Kuunsäde 8 A 28: Email: jeti@iki.fi :
the  sound of  a person  snoring.) :02210 Espoo    : http://iki.fi/jeti :
Webster's  Encyclopedic Unabridged :Finland        : GSM+358-40-5763131 :
Dictionary of the English Language :...............:....................:


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: kernel BUG at inode.c:889!

[Marcelo Tosatti]

On Wed, 31 Jan 2001, Timo Jantunen wrote:

> Heip!
> 
> 
> While I was looking unused partitions to be used for ReiserFS testing

Haven't you forgot to inform which kernel version are you using? 


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: kernel BUG at inode.c:889!

[Timo Jantunen]

On Wed, 31 Jan 2001, Marcelo Tosatti wrote:

>> While I was looking unused partitions to be used for ReiserFS testing
> Haven't you forgot to inform which kernel version are you using?

Ah, sorry! 2.4.1

(Is anybody using anything else but the newest ;-)


// /
....................................Timo Jantunen  ......................
       ZZZ      (Used to represent :Kuunsäde 8 A 28: Email: jeti@iki.fi :
the  sound of  a person  snoring.) :02210 Espoo    : http://iki.fi/jeti :
Webster's  Encyclopedic Unabridged :Finland        : GSM+358-40-5763131 :
Dictionary of the English Language :...............:....................:

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: kernel BUG at inode.c:889!

[Andreas Dilger]

Timo Jantunen writes:
> While I was looking unused partitions to be used for ReiserFS testing
> (paranoia is a way of life when dealing with my data ;-), I did
> 
> mount /dev/hda5 /mnt/tmp
> 
> to a partition which I thought to be unused (just to be sure). This resulted
> in a Really Weird(tm) /mnt/tmp _file_ which didn't have any permissions to
> anyone. When checking kernel messages, I found "EXT2-fs warning: checktime
> reached, running e2fsck is recommended" line. Then I tried to unmount the
> partition. It checkfaulted. Messages had following entries.

It could be that the root inode was cleared out, and we don't check the
mode bits, so it was a file instead of a directory.  This would be worth
checking to avoid getting into a situation like this in the first place.

> Jan 31 19:46:30 limbo kernel: EXT2-fs error (device ide0(3,5)): free_inode: reserved inode or nonexistent inode
> Jan 31 19:46:30 limbo kernel: kernel BUG at inode.c:889!

It looks like it was trying to delete the root inode because it has a link
count of zero.  This would be consistent with the above mode issue, if
the root inode was corrupt.  It is (somewhat) surprising that you had this
corruption, yet still managed to mount the filesystem, given the number of
other checks in ext2_read_super().

Your OOPS trace shows dput() and iput() being called.  This will call
ext2_delete_inode() if i_nlink == 0, which calls ext2_update_inode()
and ext2_free_inode() (which is where the EXT2-fs error is coming from.
If it were another inode, you would have gotten an invalid inode error
from ext2_update_inode() instead.  In any case, ext2_free_inode() exits
without setting inode->i_state = I_CLEAR, hence the BUG in inode.c.

One way to fix this is to set inode->i_state = I_CLEAR before jumping to
error_return in ext2_free_inode().  It _may_ also be possible to call
clear_inode() from within the error path, expecially since ext2 doesn't
have a clear_inode method.  In any case, something has to be done, because
we can't just get a BUG whenever we try to free an invalid inode number.

Below is a patch which should fix this.  It _should_ prevent you from
mounting this filesystem in the first place, and should also stop the BUG
in inode.c.  I'm not 100% sure of correctness, however:
- is calling clear_inode() in these error cases OK?
- is calling dput() the right thing to do for the root dentry?  This
  is what kill_super() does when cleaning up the filesystem.

Cheers, Andreas
============================================================================
--- fs/ext2/ialloc.c.orig	Tue Jan 23 17:22:19 2001
+++ fs/ext2/ialloc.c	Wed Jan 31 12:14:04 2001
@@ -202,15 +202,18 @@
 	if (ino < EXT2_FIRST_INO(sb) || 
 	    ino > le32_to_cpu(es->s_inodes_count)) {
 		ext2_error (sb, "free_inode",
-			    "reserved inode or nonexistent inode");
+			    "reserved inode or nonexistent inode %d", ino);
+		clear_inode(inode);
 		goto error_return;
 	}
 	block_group = (ino - 1) / EXT2_INODES_PER_GROUP(sb);
 	bit = (ino - 1) % EXT2_INODES_PER_GROUP(sb);
 	bitmap_nr = load_inode_bitmap (sb, block_group);
-	if (bitmap_nr < 0)
+	if (bitmap_nr < 0) {
+		clear_inode(inode);
 		goto error_return;
-	
+	}
+
 	bh = sb->u.ext2_sb.s_inode_bitmap[bitmap_nr];
 
 	is_directory = S_ISDIR(inode->i_mode);
--- fs/ext2/super.c.orig	Tue Jan 23 17:24:45 2001
+++ fs/ext2/super.c	Wed Jan 31 12:27:25 2001
@@ -628,13 +628,19 @@
 	 */
 	sb->s_op = &ext2_sops;
 	sb->s_root = d_alloc_root(iget(sb, EXT2_ROOT_INO));
-	if (!sb->s_root) {
+	if (!sb->s_root || !S_ISDIR(sb->s_root->d_inode) ||
+	    !sb->s_root->d_inode->i_blocks || !sb->s_root->d_inode->i_size) {
+		if (sb->s_root) {
+			dput(sb->s_root);
+			sb->s_root = NULL;
+			printk ("EXT2-fs: corrupt root inode, run e2fsck\n");
+		} else
+			printk ("EXT2-fs: get root inode failed\n");
 		for (i = 0; i < db_count; i++)
 			if (sb->u.ext2_sb.s_group_desc[i])
 				brelse (sb->u.ext2_sb.s_group_desc[i]);
 		kfree(sb->u.ext2_sb.s_group_desc);
 		brelse (bh);
-		printk ("EXT2-fs: get root inode failed\n");
 		return NULL;
 	}
 	ext2_setup_super (sb, es, sb->s_flags & MS_RDONLY);
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: kernel BUG at inode.c:889!

[Timo Jantunen]

On Wed, 31 Jan 2001, Andreas Dilger wrote:

> Below is a patch which should fix this.  It _should_ prevent you from
> mounting this filesystem in the first place, and should also stop the BUG
> in inode.c.  I'm not 100% sure of correctness, however:

I tried to reproduce the BUG message, but I was unable to get to the same
situation again. (I tried to create several different RAID0 partitions,
format them to ext2 and tried mounting the partitions alone. I did get some
weird messages from partitions I did manage to mount (what you would expect
from mounting such partitions) but no more BUG messages.)

So unfortunately I can't help you to check if your fix works.


// /
....................................Timo Jantunen  ......................
       ZZZ      (Used to represent :Kuunsäde 8 A 28: Email: jeti@iki.fi :
the  sound of  a person  snoring.) :02210 Espoo    : http://iki.fi/jeti :
Webster's  Encyclopedic Unabridged :Finland        : GSM+358-40-5763131 :
Dictionary of the English Language :...............:....................:

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/