Re: [bug] as_merged_requests(): possible recursive locking detected

[Jens Axboe]

On Thu, Jan 31 2008, Ingo Molnar wrote:
> 
> 
> Jens,
> 
> AS still has some locking issues - see the lockdep warning below that 
> the x86 test-rig just triggered. Config attached. Never saw this one 
> before. Can send more info if needed.
> 
> 	Ingo
> 
> ---------->
> udev: renamed network interface eth0_rename to eth1
> 
> =============================================
> [ INFO: possible recursive locking detected ]
> 2.6.24 #183
> ---------------------------------------------
> vol_id/1769 is trying to acquire lock:
>  (&ret->lock#2){.+..}, at: [<ffffffff8047afee>] as_merged_requests+0xa7/0x110
> 
> but task is already holding lock:
>  (&ret->lock#2){.+..}, at: [<ffffffff8047afe6>] as_merged_requests+0x9f/0x110
> 
> other info that might help us debug this:
> 2 locks held by vol_id/1769:
>  #0:  (&q->__queue_lock){.+..}, at: [<ffffffff80473ffb>] __make_request+0x5f/0x3fd
>  #1:  (&ret->lock#2){.+..}, at: [<ffffffff8047afe6>] as_merged_requests+0x9f/0x110
> 
> stack backtrace:
> Pid: 1769, comm: vol_id Not tainted 2.6.24 #183
> 
> Call Trace:
>  [<ffffffff8024f2b9>] print_deadlock_bug+0xcb/0xd6
>  [<ffffffff8024f314>] check_deadlock+0x50/0x60
>  [<ffffffff80250c41>] validate_chain+0x1ed/0x289
>  [<ffffffff80251224>] __lock_acquire+0x547/0x608
>  [<ffffffff8047afee>] ? as_merged_requests+0xa7/0x110
>  [<ffffffff8025137e>] lock_acquire+0x99/0xc6
>  [<ffffffff8047afee>] ? as_merged_requests+0xa7/0x110
>  [<ffffffff8090004e>] _spin_lock+0x34/0x41
>  [<ffffffff8047afee>] as_merged_requests+0xa7/0x110
>  [<ffffffff80471184>] elv_merge_requests+0x28/0x51
>  [<ffffffff80476c1b>] attempt_merge+0xf5/0x14b
>  [<ffffffff80476cc4>] attempt_back_merge+0x27/0x30
>  [<ffffffff8047411c>] __make_request+0x180/0x3fd
>  [<ffffffff80472fb0>] generic_make_request+0x355/0x390
>  [<ffffffff802ac5ed>] ? create_empty_buffers+0xa0/0xa9
>  [<ffffffff804744ff>] submit_bio+0xfe/0x107
>  [<ffffffff802abfc4>] submit_bh+0xe7/0x10b
>  [<ffffffff802aefcd>] block_read_full_page+0x289/0x2a5
>  [<ffffffff802b1d7f>] ? blkdev_get_block+0x0/0x4c
>  [<ffffffff80268422>] ? add_to_page_cache+0xa1/0xd3
>  [<ffffffff802b0ef7>] blkdev_readpage+0x13/0x15
>  [<ffffffff8026f3fb>] read_pages+0x81/0xa1
>  [<ffffffff8026f5b0>] __do_page_cache_readahead+0x195/0x1b8
>  [<ffffffff80267fda>] ? find_get_page+0x58/0x64
>  [<ffffffff8026f7f4>] ondemand_readahead+0xa1/0x155
>  [<ffffffff8026f93b>] page_cache_sync_readahead+0x17/0x19
>  [<ffffffff80268c3f>] do_generic_mapping_read+0xa8/0x372
>  [<ffffffff80267d32>] ? file_read_actor+0x0/0x1ac
>  [<ffffffff80269f94>] generic_file_aio_read+0x125/0x164
>  [<ffffffff8028b9cc>] do_sync_read+0xeb/0x132
>  [<ffffffff80250416>] ? mark_held_locks+0x59/0x75
>  [<ffffffff8024549f>] ? autoremove_wake_function+0x0/0x38
>  [<ffffffff802515f9>] ? __lock_release+0x5b/0x64
>  [<ffffffff808fee67>] ? mutex_unlock+0x9/0xb
>  [<ffffffff808fee33>] ? __mutex_unlock_slowpath+0x10e/0x139
>  [<ffffffff802505d7>] ? trace_hardirqs_on+0xfe/0x128
>  [<ffffffff8028c0c4>] vfs_read+0xa4/0xe3
>  [<ffffffff8028c440>] sys_read+0x47/0x6f
>  [<ffffffff8020c10a>] system_call_after_swapgs+0x8a/0x8f

Are you sure this triggered with the as fixup in place? It looks like
the same bug.

-- 
Jens Axboe

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