From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752243Ab1GYTtz (ORCPT ); Mon, 25 Jul 2011 15:49:55 -0400 Received: from rcsinet15.oracle.com ([148.87.113.117]:50455 "EHLO rcsinet15.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751639Ab1GYTty (ORCPT ); Mon, 25 Jul 2011 15:49:54 -0400 Content-Type: text/plain; charset=UTF-8 From: Chris Mason To: Ed Tomlinson Cc: Linux Kernel Mailing List , Linus Torvalds , linux-btrfs , Josef Bacik Subject: Re: Linux 3.0 release - btrfs possible locking deadlock In-reply-to: <201107221921.00798.edt@aei.ca> References: <201107221921.00798.edt@aei.ca> Date: Mon, 25 Jul 2011 15:49:37 -0400 Message-Id: <1311623259-sup-8037@shiny> User-Agent: Sup/git Content-Transfer-Encoding: 8bit X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090203.4E2DC8DC.002C:SCFMA922111,ss=1,re=-4.000,fgs=0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Excerpts from Ed Tomlinson's message of 2011-07-22 19:21:00 -0400: > On Thursday 21 July 2011 22:59:53 Linus Torvalds wrote: > > So there it is. Gone are the 2.6. days, and 3.0 is out. > > > > Hi, > > Managed to get this with btrfs rsync(ing) from ext4 to a btrfs fs with three partitions using raid1. > > [16018.211493] device fsid f7186eeb-60df-4b1a-890a-4a1eb42f81fe devid 1 transid 10 /dev/sdd4 > [16018.230643] btrfs: use lzo compression > [16018.234619] btrfs: enabling disk space caching > [25949.414011] > [25949.414011] ======================================================= > [25949.416549] [ INFO: possible circular locking dependency detected ] > [25949.423187] 3.0.0-crc+ #348 > [25949.423187] ------------------------------------------------------- > [25949.423187] rsync/20237 is trying to acquire lock: > [25949.423187] (btrfs-extent-01){+.+...}, at: [] btrfs_try_spin_lock+0x78/0xb0 [btrfs] > [25949.423187] > [25949.423187] but task is already holding lock: > [25949.423187] (&(&eb->lock)->rlock){+.+...}, at: [] btrfs_clear_lock_blocking+0x22/0x30 [btrfs] > [25949.423187] > [25949.423187] which lock already depends on the new lock. > > Kernel is 3.0.0 without any extras. > > Ideas? Did this actually deadlock? lockdep has issues with the btrfs clear_lock_blocking code, and I need to redo the annotations a bit. The problem is that we have the same lock class representing unrelated locks from different trees. -chris