Bug 235324 - BUG: bad unlock balance detected! when doging xfs recovery
Summary: BUG: bad unlock balance detected! when doging xfs recovery
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: rawhide
Hardware: All
OS: Linux
medium
high
Target Milestone: ---
Assignee: Eric Sandeen
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks: FCMETA_LOCKDEP
TreeView+ depends on / blocked
 
Reported: 2007-04-05 05:17 UTC by Knut J BJuland
Modified: 2007-11-30 22:12 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-06-15 11:18:27 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Knut J BJuland 2007-04-05 05:17:03 UTC
Description of problem:
BUG: bad unlock balance detected! when doging xfs recovery. Which might cause
data lose. 

Version-Release number of selected component (if applicable):
kernel 2.6.20-1.3040.fc7

How reproducible:
cause an unclean reboot

Steps to Reproduce:
1. cut off power supply
2. restart pc
3.
  
Actual results:

XFS mounting filesystem sdb2
Starting XFS recovery on filesystem: sdb2 (logdev: internal)

=====================================
[ XFS mounting filesystem sdb2
Starting XFS recovery on filesystem: sdb2 (logdev: internal)

=====================================
[ BUG: bad unlock balance detected! ]
-------------------------------------
init/1 is trying to release lock (&(&ip->i_iolock)->mr_lock) at:
[<d8913ef7>] xfs_iunlock+0x2d/0x6f [xfs]
but there are no more locks to release!

other info that might help us debug this:
1 lock held by init/1:
 #0:  (&type->s_umount_key#18){--..}, at: [<c047fbad>] sget+0x1e5/0x31d

stack backtrace:
 [<c04061e9>] show_trace_log_lvl+0x1a/0x2f
 [<c04067ad>] show_trace+0x12/0x14
 [<c0406831>] dump_stack+0x16/0x18
 [<c0440dbb>] print_unlock_inbalance_bug+0xec/0xf9
 [<c0442c1c>] lock_release_non_nested+0x9e/0x162
 [<c0442e1d>] lock_release+0x13d/0x159
 [<c043b8ad>] up_read+0x16/0x29
 [<d8913ef7>] xfs_iunlock+0x2d/0x6f [xfs]
 [<d891416f>] xfs_ireclaim+0x78/0x82 [xfs]
 [<d893050f>] xfs_finish_reclaim+0x124/0x12e [xfs]
 [<d8930639>] xfs_reclaim+0x6b/0xe0 [xfs]
 [<d893dbe9>] xfs_fs_clear_inode+0x97/0xba [xfs]
 [<c048f5d5>] clear_inode+0xd3/0x122
 [<c048f6e2>] generic_delete_inode+0xbe/0x110
 [<c048f746>] generic_drop_inode+0x12/0x130
 [<c048ed32>] iput+0x63/0x66
 [<d8921aca>] xlog_recover_process_iunlinks+0x250/0x3ec [xfs]
 [<d8921ca7>] xlog_recover_finish+0x41/0xa9 [xfs]
 [<d891ddb3>] xfs_log_mount_finish+0x2c/0x35 [xfs]
 [<d8927a41>] xfs_mountfs+0xb41/0xc6c [xfs]
 [<d891a21b>] xfs_ioinit+0x26/0x2b [xfs]
 [<d892e2b3>] xfs_mount+0x2df/0x352 [xfs]
 [<d893e2b2>] vfs_mount+0x1a/0x1e [xfs]
 [<d893e182>] xfs_fs_fill_super+0x76/0x18c [xfs]
 [<c048057e>] get_sb_bdev+0xeb/0x136
 [<d893d4c6>] xfs_fs_get_sb+0x21/0x27 [xfs]
 [<c0480136>] vfs_kern_mount+0x81/0xf1
 [<c04801ee>] do_kern_mount+0x30/0x42
 [<c0492654>] do_mount+0x601/0x678
 [<c049273a>] sys_mount+0x6f/0xa4
 [<c0405078>] syscall_call+0x7/0xb
 =======================
Ending XFS recovery on filesystem: sdb2 (logdev: internal)
SELinux:  Disabled at runtime.]
-------------------------------------
init/1 is trying to release lock (&(&ip->i_iolock)->mr_lock) at:
[<d8913ef7>] xfs_iunlock+0x2d/0x6f [xfs]
but there are no more locks to release!

other info that might help us debug this:
1 lock held by init/1:
 #0:  (&type->s_umount_key#18){--..}, at: [<c047fbad>] sget+0x1e5/0x31d

stack backtrace:
 [<c04061e9>] show_trace_log_lvl+0x1a/0x2f
 [<c04067ad>] show_trace+0x12/0x14
 [<c0406831>] dump_stack+0x16/0x18
 [<c0440dbb>] print_unlock_inbalance_bug+0xec/0xf9
 [<c0442c1c>] lock_release_non_nested+0x9e/0x162
 [<c0442e1d>] lock_release+0x13d/0x159
 [<c043b8ad>] up_read+0x16/0x29
 [<d8913ef7>] xfs_iunlock+0x2d/0x6f [xfs]
 [<d891416f>] xfs_ireclaim+0x78/0x82 [xfs]
 [<d893050f>] xfs_finish_reclaim+0x124/0x12e [xfs]
 [<d8930639>] xfs_reclaim+0x6b/0xe0 [xfs]
 [<d893dbe9>] xfs_fs_clear_inode+0x97/0xba [xfs]
 [<c048f5d5>] clear_inode+0xd3/0x122
 [<c048f6e2>] generic_delete_inode+0xbe/0x110
 [<c048f746>] generic_drop_inode+0x12/0x130
 [<c048ed32>] iput+0x63/0x66
 [<d8921aca>] xlog_recover_process_iunlinks+0x250/0x3ec [xfs]
 [<d8921ca7>] xlog_recover_finish+0x41/0xa9 [xfs]
 [<d891ddb3>] xfs_log_mount_finish+0x2c/0x35 [xfs]
 [<d8927a41>] xfs_mountfs+0xb41/0xc6c [xfs]
 [<d891a21b>] xfs_ioinit+0x26/0x2b [xfs]
 [<d892e2b3>] xfs_mount+0x2df/0x352 [xfs]
 [<d893e2b2>] vfs_mount+0x1a/0x1e [xfs]
 [<d893e182>] xfs_fs_fill_super+0x76/0x18c [xfs]
 [<c048057e>] get_sb_bdev+0xeb/0x136
 [<d893d4c6>] xfs_fs_get_sb+0x21/0x27 [xfs]
 [<c0480136>] vfs_kern_mount+0x81/0xf1
 [<c04801ee>] do_kern_mount+0x30/0x42
 [<c0492654>] do_mount+0x601/0x678
 [<c049273a>] sys_mount+0x6f/0xa4
 [<c0405078>] syscall_call+0x7/0xb
 =======================
Ending XFS recovery on filesystem: sdb2 (logdev: internal)
SELinux:  Disabled at runtime.
Expected results:
Should replay log with out this bug

Additional info:

Comment 1 Timothy Shimmin 2007-04-13 07:25:26 UTC
Hi,

I added CONFIG_DEBUG_LOCK_ALLOC and other lock checking configs,
and then ran thru xfstests/121 which does iunlink log recovery testing
but was unable to get this msg out to the system log.
Is it reproducible everytime for you?
I'm trying to think about what is different in your setup
that would increase the chances of hitting this lock message.

--Tim

Comment 2 Knut J BJuland 2007-04-19 16:46:13 UTC
I reboot after a unclean umount, due to the fact that pc freezed when using
booth nvidia driver and rt61pci. However I started the system in single mod
without X and nvidia driver.

Comment 3 Eric Sandeen 2007-05-25 15:41:32 UTC
Tim, which kernel did you test on, he was on 2.6.20 from FC - were you testing
w/ the lockdep annotations in place?  Not sure that'd matter but worth asking
perhaps...

Comment 4 Knut J BJuland 2007-05-25 20:37:45 UTC
I think i might be in place. It was standard compiled from devel. 

Comment 5 Timothy Shimmin 2007-05-28 06:56:18 UTC
I think I just tested on xfs TOT with all the locking/lockdep configs.
Not from FC.
--Tim

Comment 6 Knut J BJuland 2007-06-15 11:18:27 UTC
Resolved with latest kernel from F-7


Note You need to log in before you can comment on or make changes to this bug.