From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michal Piotrowski" Subject: Re: 2.6.18-mm2 Date: Thu, 28 Sep 2006 13:54:07 +0200 Message-ID: <6bffcb0e0609280454n34d40c0la8786e1eba6dcdf3@mail.gmail.com> References: <20060928014623.ccc9b885.akpm@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20060928014623.ccc9b885.akpm@osdl.org> Content-Disposition: inline Sender: linux-raid-owner@vger.kernel.org To: Andrew Morton Cc: Ingo Molnar , Neil Brown , linux-raid@vger.kernel.org, linux-kernel@vger.kernel.org List-Id: linux-raid.ids Hi, On 28/09/06, Andrew Morton wrote: > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18/2.6.18-mm2/ > > ======================================================= [ INFO: possible circular locking dependency detected ] 2.6.18-mm2 #1 ------------------------------------------------------- nash/1264 is trying to acquire lock: (&bdev_part_lock_key){--..}, at: [] mutex_lock+0x1c/0x1f but task is already holding lock: (&new->reconfig_mutex){--..}, at: [] mutex_lock_interruptible+0x1c/0x1f which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (&new->reconfig_mutex){--..}: [] add_lock_to_list+0x5c/0x7a [] __lock_acquire+0x9f3/0xaef [] lock_acquire+0x71/0x91 [] __mutex_lock_interruptible_slowpath+0xd2/0x326 [] mutex_lock_interruptible+0x1c/0x1f [] md_open+0x28/0x5d [] do_open+0x8b/0x377 [] blkdev_open+0x1d/0x46 [] __dentry_open+0x133/0x260 [] nameidata_to_filp+0x1c/0x2e [] do_filp_open+0x2e/0x35 [] do_sys_open+0x58/0xde [] sys_open+0x16/0x18 [] syscall_call+0x7/0xb [] 0xffffffff -> #1 (&bdev->bd_mutex){--..}: [] add_lock_to_list+0x5c/0x7a [] __lock_acquire+0x9f3/0xaef [] lock_acquire+0x71/0x91 [] __mutex_lock_slowpath+0xd2/0x2f1 [] mutex_lock+0x1c/0x1f [] do_open+0x5c/0x377 [] blkdev_get+0x6c/0x77 [] do_open+0x108/0x377 [] blkdev_get+0x6c/0x77 [] open_by_devnum+0x30/0x3c [] swsusp_check+0x14/0xc5 [] software_resume+0x7e/0x100 [] init+0x121/0x29f [] kernel_thread_helper+0x7/0x10 [] save_stack_trace+0x17/0x30 [] save_trace+0x4f/0xfb [] add_lock_to_list+0x5c/0x7a [] __lock_acquire+0x9f3/0xaef [] lock_acquire+0x71/0x91 [] __mutex_lock_slowpath+0xd2/0x2f1 [] mutex_lock+0x1c/0x1f [] do_open+0x5c/0x377 [] blkdev_get+0x6c/0x77 [] do_open+0x108/0x377 [] blkdev_get+0x6c/0x77 [] open_by_devnum+0x30/0x3c [] swsusp_check+0x14/0xc5 [] software_resume+0x7e/0x100 [] init+0x121/0x29f [] kernel_thread_helper+0x7/0x10 [] 0xffffffff -> #0 (&bdev_part_lock_key){--..}: [] print_circular_bug_tail+0x30/0x64 [] __lock_acquire+0x92a/0xaef [] lock_acquire+0x71/0x91 [] __mutex_lock_slowpath+0xd2/0x2f1 [] mutex_lock+0x1c/0x1f [] bd_claim_by_disk+0x5f/0x18e [] bind_rdev_to_array+0x1f0/0x20e [] autostart_arrays+0x24b/0x322 [] md_ioctl+0x91/0x13f4 [] blkdev_driver_ioctl+0x49/0x5b [] blkdev_ioctl+0x755/0x7a2 [] block_ioctl+0x16/0x1b [] do_ioctl+0x22/0x67 [] vfs_ioctl+0x249/0x25c [] sys_ioctl+0x47/0x75 [] syscall_call+0x7/0xb [] 0xffffffff other info that might help us debug this: 1 lock held by nash/1264: #0: (&new->reconfig_mutex){--..}, at: [] mutex_lock_interruptible+0x1c/0x1f stack backtrace: [] dump_trace+0x64/0x1cd [] show_trace_log_lvl+0x12/0x25 [] show_trace+0xd/0x10 [] dump_stack+0x19/0x1b [] print_circular_bug_tail+0x59/0x64 [] __lock_acquire+0x92a/0xaef [] lock_acquire+0x71/0x91 [] __mutex_lock_slowpath+0xd2/0x2f1 [] mutex_lock+0x1c/0x1f [] bd_claim_by_disk+0x5f/0x18e [] bind_rdev_to_array+0x1f0/0x20e [] autostart_arrays+0x24b/0x322 [] md_ioctl+0x91/0x13f4 [] blkdev_driver_ioctl+0x49/0x5b [] blkdev_ioctl+0x755/0x7a2 [] block_ioctl+0x16/0x1b [] do_ioctl+0x22/0x67 [] vfs_ioctl+0x249/0x25c [] sys_ioctl+0x47/0x75 [] syscall_call+0x7/0xb DWARF2 unwinder stuck at syscall_call+0x7/0xb Leftover inexact backtrace: ======================= md: bind config & dmesg http://www.stardust.webpages.pl/files/mm/2.6.18-mm2/ Regards, Michal -- Michal K. K. Piotrowski LTG - Linux Testers Group (http://www.stardust.webpages.pl/ltg/)