Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756084AbYBAIlh (ORCPT ); Fri, 1 Feb 2008 03:41:37 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752120AbYBAIl0 (ORCPT ); Fri, 1 Feb 2008 03:41:26 -0500 Received: from brick.kernel.dk ([87.55.233.238]:25895 "EHLO kernel.dk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754170AbYBAIk7 (ORCPT ); Fri, 1 Feb 2008 03:40:59 -0500 Date: Fri, 1 Feb 2008 09:40:56 +0100 From: Jens Axboe To: Ingo Molnar Cc: linux-kernel@vger.kernel.org Subject: Re: [bug] as_merged_requests(): possible recursive locking detected Message-ID: <20080201084056.GH15220@kernel.dk> References: <20080131221436.GA3760@elte.hu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080131221436.GA3760@elte.hu> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3455 Lines: 84 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: [] as_merged_requests+0xa7/0x110 > > but task is already holding lock: > (&ret->lock#2){.+..}, at: [] 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: [] __make_request+0x5f/0x3fd > #1: (&ret->lock#2){.+..}, at: [] as_merged_requests+0x9f/0x110 > > stack backtrace: > Pid: 1769, comm: vol_id Not tainted 2.6.24 #183 > > Call Trace: > [] print_deadlock_bug+0xcb/0xd6 > [] check_deadlock+0x50/0x60 > [] validate_chain+0x1ed/0x289 > [] __lock_acquire+0x547/0x608 > [] ? as_merged_requests+0xa7/0x110 > [] lock_acquire+0x99/0xc6 > [] ? as_merged_requests+0xa7/0x110 > [] _spin_lock+0x34/0x41 > [] as_merged_requests+0xa7/0x110 > [] elv_merge_requests+0x28/0x51 > [] attempt_merge+0xf5/0x14b > [] attempt_back_merge+0x27/0x30 > [] __make_request+0x180/0x3fd > [] generic_make_request+0x355/0x390 > [] ? create_empty_buffers+0xa0/0xa9 > [] submit_bio+0xfe/0x107 > [] submit_bh+0xe7/0x10b > [] block_read_full_page+0x289/0x2a5 > [] ? blkdev_get_block+0x0/0x4c > [] ? add_to_page_cache+0xa1/0xd3 > [] blkdev_readpage+0x13/0x15 > [] read_pages+0x81/0xa1 > [] __do_page_cache_readahead+0x195/0x1b8 > [] ? find_get_page+0x58/0x64 > [] ondemand_readahead+0xa1/0x155 > [] page_cache_sync_readahead+0x17/0x19 > [] do_generic_mapping_read+0xa8/0x372 > [] ? file_read_actor+0x0/0x1ac > [] generic_file_aio_read+0x125/0x164 > [] do_sync_read+0xeb/0x132 > [] ? mark_held_locks+0x59/0x75 > [] ? autoremove_wake_function+0x0/0x38 > [] ? __lock_release+0x5b/0x64 > [] ? mutex_unlock+0x9/0xb > [] ? __mutex_unlock_slowpath+0x10e/0x139 > [] ? trace_hardirqs_on+0xfe/0x128 > [] vfs_read+0xa4/0xe3 > [] sys_read+0x47/0x6f > [] 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/