On Fri, 2006-07-07 at 09:34 +0200, Arjan van de Ven wrote:
> > <4> [<c0463f46>] __blkdev_put+0x22/0x123
> > <4> [<c0464060>] blkdev_put+0xa/0xc
> > <4> [<c04644e2>] do_open+0x313/0x385
> > <4> [<c0464759>] blkdev_open+0x1f/0x48
> 
> ok this is a missing annotation in the error path
> 
> the patch below should fix this, can you verify this?

Seems to have fixed it.  I different one this morning (I'm assuming it's
unrelated):

<4>=============================================
<4>[ INFO: possible recursive locking detected ]
<4>---------------------------------------------
<4>parted/525 is trying to acquire lock:
<4> (&bdev->bd_mutex){--..}, at: [<c05ebd9d>] mutex_lock+0x21/0x24
<4>
<4>but task is already holding lock:
<4> (&bdev->bd_mutex){--..}, at: [<c05ebd9d>] mutex_lock+0x21/0x24
<4>
<4>other info that might help us debug this:
<4>1 lock held by parted/525:
<4> #0:  (&bdev->bd_mutex){--..}, at: [<c05ebd9d>] mutex_lock+0x21/0x24
<4>
<4>stack backtrace:
<4> [<c040373c>] show_trace_log_lvl+0x54/0xfd
<4> [<c0403cba>] show_trace+0xd/0x10
<4> [<c0403d57>] dump_stack+0x19/0x1b
<4> [<c042c3ba>] __lock_acquire+0x760/0x987
<4> [<c042cb52>] lock_acquire+0x4b/0x6d
<4> [<c05ebc05>] __mutex_lock_slowpath+0xb6/0x22d
<4> [<c05ebd9d>] mutex_lock+0x21/0x24
<4> [<c04c4acf>] blkdev_ioctl+0x5dd/0x732
<4> [<c046323b>] block_ioctl+0x16/0x1b
<4> [<c046cb99>] do_ioctl+0x19/0x50
<4> [<c046cdd0>] vfs_ioctl+0x200/0x217
<4> [<c046ce2e>] sys_ioctl+0x47/0x61
<4> [<c0402dc7>] syscall_call+0x7/0xb

I'm not sure I can reproduce this one reliably :/  . Again, the whole
dmesg is attached.

-- 
  Peter