From patchwork Thu Feb 11 19:18:30 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Liu Bo X-Patchwork-Id: 8284721 Return-Path: X-Original-To: patchwork-linux-btrfs@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id A07A7BEEE5 for ; Thu, 11 Feb 2016 19:20:03 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id C16C32025B for ; Thu, 11 Feb 2016 19:20:02 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C3676200E9 for ; Thu, 11 Feb 2016 19:20:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750784AbcBKTSo (ORCPT ); Thu, 11 Feb 2016 14:18:44 -0500 Received: from aserp1040.oracle.com ([141.146.126.69]:16832 "EHLO aserp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750735AbcBKTSn (ORCPT ); Thu, 11 Feb 2016 14:18:43 -0500 Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u1BJIYkD019697 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 11 Feb 2016 19:18:34 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u1BJIXPb019416 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 11 Feb 2016 19:18:34 GMT Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id u1BJIX0D001932; Thu, 11 Feb 2016 19:18:33 GMT Received: from localhost.localdomain (/98.210.248.99) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 11 Feb 2016 11:18:33 -0800 Date: Thu, 11 Feb 2016 11:18:30 -0800 From: Liu Bo To: =?utf-8?B?0JzQuNGF0LDQuNC7INCT0LDQstGA0LjQu9C+0LI=?= , Chris Murphy Cc: Btrfs BTRFS Subject: Re: task btrfs-cleaner:770 blocked for more than 120 seconds. Message-ID: <20160211191741.GA4762@localhost.localdomain> Reply-To: bo.li.liu@oracle.com References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2015-06-09) X-Source-IP: aserv0021.oracle.com [141.146.126.233] Sender: linux-btrfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Wed, Feb 10, 2016 at 02:23:00PM -0700, Chris Murphy wrote: > On Wed, Feb 10, 2016 at 1:39 PM, ?????? ???????? > wrote: > > > > > > Here full log: http://btrfs.sy24.ru/kernel-sysrqw-btrfscleaner770blocked-2.txt > > > > I am so sorry if this log is useless. > > Looks good to me. The blocked task happens out of no where with > nothing reported for almost an hour before the blocking. And I see the > sysrq: SysRq : Show Blocked State was issued and lots of information > is in the file. > > > If "sysrq" is needed enabled before hang then I need set this > > permanently because as I said I not having exactly reproducing this. > > echo 1 > /proc/sys/kernel/sysrq can happen anytime, it just enables > sysrq triggering functions which on Fedora kernels is not enabled by > default. The main thing is that the echo w to the sysrq trigger needs > to happen at the time of the problem to show the state. You did that. > Let's see what Liu Bo has to say about it. Really appreciate for collecting these, it should be helpful. Unfortunately I still could not figure out who's holding fs tree's root WRITE_LOCK so that others are blocked. A possible bug in log code (the follwing patch addressed it), - log_new_dir_dentries() is holding log tree's leaf READ_LOCK and may try to get fs tree's READ_LOCK via btrfs_iget() -> btrfs_lookup(). (This is shown in the backtrac) - btrfs_log_inode() can call btrfs_search_forward() to get fs tree's leaf READ_LOCK and then call copy_items() -> btrfs_insert_empty_items() to acquire WRITE_LOCK of log tree's leaf and leaf's parent. (In the backtrace, this is blocked by item 1 because log_new_dir_dentries is holding a log tree leaf's READ_LOCK() which happens to be sibling to the leaf that btrfs_insert_empty_items() is accessing, when doing split_leaf() it needs to get the sibling's WRITE_LOCK(). ) Thanks, -liubo --- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c index 323e12c..4a64fdd 100644 --- a/fs/btrfs/tree-log.c +++ b/fs/btrfs/tree-log.c @@ -4956,6 +4956,7 @@ process_leaf: if (di_key.type == BTRFS_ROOT_ITEM_KEY) continue; + btrfs_release_path(path); di_inode = btrfs_iget(root->fs_info->sb, &di_key, root, NULL); if (IS_ERR(di_inode)) { @@ -4971,7 +4972,6 @@ process_leaf: ctx->log_new_dentries = false; if (type == BTRFS_FT_DIR) log_mode = LOG_INODE_ALL; - btrfs_release_path(path); ret = btrfs_log_inode(trans, root, di_inode, log_mode, 0, LLONG_MAX, ctx); iput(di_inode);