On Sun, Jun 04, 2006 at 04:49:56PM -0500, Dave Kleikamp wrote:
> On Sun, 2006-06-04 at 19:44 +0400, Evgeniy Dushistov wrote:
> > I should add that this happened during boot, when root jfs
> > file system become from ro->rw
> >
> > I look at code, and see that
> > 1)locks wasn't release in the opposite order in which
> > they were taken
>
> Why does this matter?
>
Like "3" it make code more understandable,
reader of code don't have to think why
code looks like:
lock A, lock B unlock A, unlock B
while a normal practice in kernel:
lock A, lock B unlock B unlock A
the goal of change just simplicity and clearness,
and nothing more.
> I think the warning needs to be fixed by introducing mutex_lock_nested
> in some places. I'll take a look at it.
>
To avoid incomprehension, previous patch just make code more
understandable and unlock mutex on "error path", it doesn't fix
this warning and I have no idea why it happend:
====================================
[ BUG: possible deadlock detected! ]
------------------------------------
mount/5587 is trying to acquire lock:
(&jfs_ip->commit_mutex){--..}, at: [<c02f7096>] mutex_lock+0x12/0x15
but task is already holding lock:
(&jfs_ip->commit_mutex){--..}, at: [<c02f7096>] mutex_lock+0x12/0x15
which could potentially lead to deadlocks!
other info that might help us debug this:
2 locks held by mount/5587:
#0: (&inode->i_mutex){--..}, at: [<c02f7096>] mutex_lock+0x12/0x15
#1: (&jfs_ip->commit_mutex){--..}, at: [<c02f7096>] mutex_lock+0x12/0x15
stack backtrace:
[<c0103095>] show_trace+0x16/0x19
[<c0103562>] dump_stack+0x1a/0x1f
[<c012ddd7>] __lockdep_acquire+0x6c6/0x907
[<c012e063>] lockdep_acquire+0x4b/0x63
[<c02f6f0c>] __mutex_lock_slowpath+0xa4/0x21c
[<c02f7096>] mutex_lock+0x12/0x15
[<c01b99be>] jfs_create+0x90/0x2b8
[<c0161016>] vfs_create+0x91/0xda
[<c0163939>] open_namei+0x15a/0x5b0
[<c015326c>] do_filp_open+0x22/0x39
[<c01541a8>] do_sys_open+0x40/0xbc
[<c015424d>] sys_open+0x13/0x15
[<c02f875d>] sysenter_past_esp+0x56/0x8d
--
/Evgeniy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
