Received: by 2002:ac0:98c7:0:0:0:0:0 with SMTP id g7-v6csp734351imd; Thu, 1 Nov 2018 04:55:14 -0700 (PDT) X-Google-Smtp-Source: AJdET5dtQUWCNg4VjX5BpDzOhS2JQZqYzoya6IOGT/0D6scMoNqUzYO6mwGxJoCDRvQesEv0zZ2z X-Received: by 2002:aa7:8685:: with SMTP id d5-v6mr7348809pfo.58.1541073314235; Thu, 01 Nov 2018 04:55:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1541073314; cv=none; d=google.com; s=arc-20160816; b=yXTKLKqySObQXCsOmNikvvuBUm0L+T3F1L12khWoeAl7zwWaL2P41tZOfcF4WUogyl tuy8eI6LlXLjVOqKKj7JLNfdvoN4iya1UgZ9O1v7yb6Y27bZ5Olg+GVo8i3tmfV1D8t3 /Wr1KE8eBZ+ZPZx3si/xF3Tq+RBGSHThomEKcg91eBYHOOMEAjTu/xJHUeM5rt7k3rZ9 sgzupEM4JbzxSCo90FRlZlBYh3fmFF+MYA5HlxlMvTzYxEB2GL3b4wAWNR42psFsY+pl Ja6HBuzw5tM6Melp0GyY3RcOmogM8zJo+e80Flvgo6kWxkL3lHTJuZ9PjLi+yvge8lMH yTdA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:content-transfer-encoding :content-language:accept-language:references:message-id:date :thread-index:thread-topic:subject:cc:to:from; bh=CNotF+4Ghh2QbNbCBtJ8Jn5VCXlCOtghrZ5E0/wZeSE=; b=MuHNeLYfP8WO8GeoAhzHsevr7DxaBuGrUhFkzwE7UMyXSP6uoJHkIo+W6PK1AGr6+V T2IhHBy6onfcaEAVCfcbVhRYaEBonoQ6DRNI7GM8k4jj/zkcnGFinkrWxS23FPuXJXyg ZmeuAepDQ7xWJijqGpvLf0icgiEkyZ9gXSJBWNK4KkqBOVer9thMO3yt8BsvObLj/5Um s+zknX1GYEqvkLol027sPecoOh/gF6uCHzY9ChaMVjwrSSrzYCDK9BfKJxleYWYJJq+o BmMofiuZEpH0l03WuLh6IuoP2r4G19S5ahesdh7E0o4pzAZgQ0L1VUDHmahI4dvxVwP4 lCxw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 101-v6si30953608ple.326.2018.11.01.04.54.56; Thu, 01 Nov 2018 04:55:14 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728369AbeKAU4g convert rfc822-to-8bit (ORCPT + 99 others); Thu, 1 Nov 2018 16:56:36 -0400 Received: from smtp.h3c.com ([60.191.123.56]:22696 "EHLO h3cmg01-ex.h3c.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1728188AbeKAU4g (ORCPT ); Thu, 1 Nov 2018 16:56:36 -0400 Received: from BJHUB02-EX.srv.huawei-3com.com (unknown [10.63.20.170]) by h3cmg01-ex.h3c.com with smtp id 139e_16fb_5541ff97_8e9c_44ed_8eac_655ad34c2eea; Thu, 01 Nov 2018 19:52:18 +0800 Received: from H3CMLB12-EX.srv.huawei-3com.com ([fe80::10fe:abde:731b:fdde]) by BJHUB02-EX.srv.huawei-3com.com ([::1]) with mapi id 14.03.0415.000; Thu, 1 Nov 2018 19:52:07 +0800 From: Changwei Ge To: Joseph Qi , Larry Chen , "mark@fasheh.com" , "jlbec@evilplan.org" CC: "linux-kernel@vger.kernel.org" , "ocfs2-devel@oss.oracle.com" , Andrew Morton Subject: Re: [Ocfs2-devel] [PATCH V3] ocfs2: fix dead lock caused by ocfs2_defrag_extent Thread-Topic: [Ocfs2-devel] [PATCH V3] ocfs2: fix dead lock caused by ocfs2_defrag_extent Thread-Index: AQHUcbKZagBejW0xd0Sk/bgqi0J6UA== Date: Thu, 1 Nov 2018 11:52:06 +0000 Message-ID: <63ADC13FD55D6546B7DECE290D39E37301277DE397@H3CMLB12-EX.srv.huawei-3com.com> References: <20181101071422.14470-1-lchen@suse.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.125.20.206] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello Joseph, On 2018/11/1 17:01, Joseph Qi wrote: > Hi Larry, > > On 18/11/1 15:14, Larry Chen wrote: >> ocfs2_defrag_extent may fall into deadlock. >> >> ocfs2_ioctl_move_extents >> ocfs2_ioctl_move_extents >> ocfs2_move_extents >> ocfs2_defrag_extent >> ocfs2_lock_allocators_move_extents >> >> ocfs2_reserve_clusters >> inode_lock GLOBAL_BITMAP_SYSTEM_INODE >> >> __ocfs2_flush_truncate_log >> inode_lock GLOBAL_BITMAP_SYSTEM_INODE >> >> As backtrace shows above, ocfs2_reserve_clusters() will call inode_lock >> against the global bitmap if local allocator has not sufficient cluters. >> Once global bitmap could meet the demand, ocfs2_reserve_cluster will >> return success with global bitmap locked. >> >> After ocfs2_reserve_cluster(), if truncate log is full, >> __ocfs2_flush_truncate_log() will definitely fall into deadlock because it >> needs to inode_lock global bitmap, which has already been locked. >> >> To fix this bug, we could remove from ocfs2_lock_allocators_move_extents() >> the code which intends to lock global allocator, and put the removed code >> after __ocfs2_flush_truncate_log(). >> >> ocfs2_lock_allocators_move_extents() is referred by 2 places, one is here, >> the other does not need the data allocator context, which means this patch >> does not affect the caller so far. >> >> Change log: >> 1. Correct the function comment. >> 2. Remove unused argument from ocfs2_lock_meta_allocator_move_extents. >> >> Signed-off-by: Larry Chen >> --- >> fs/ocfs2/move_extents.c | 47 ++++++++++++++++++++++++++--------------------- >> 1 file changed, 26 insertions(+), 21 deletions(-) >> > IMO, here clusters_to_move is only for data_ac, since we change this > function to only handle meta_ac, I'm afraid clusters_to_move related > logic has to been changed correspondingly. I think we can't remove *clusters_to_move* from here as clusters can be reserved latter outsides this function, but we still have to reserve metadata(extents) in advance. So we need that argument. Thanks, Changwei > > Thanks, > Joseph >> u32 extents_to_split, >> struct ocfs2_alloc_context **meta_ac, >> - struct ocfs2_alloc_context **data_ac, >> int extra_blocks, >> int *credits) >> { >> @@ -192,13 +188,6 @@ static int ocfs2_lock_allocators_move_extents(struct inode *inode, >> goto out; >> } >> >> - if (data_ac) { >> - ret = ocfs2_reserve_clusters(osb, clusters_to_move, data_ac); >> - if (ret) { >> - mlog_errno(ret); >> - goto out; >> - } >> - } >> >> *credits += ocfs2_calc_extend_credits(osb->sb, et->et_root_el); >> >> @@ -257,10 +246,10 @@ static int ocfs2_defrag_extent(struct ocfs2_move_extents_context *context, >> } >> } >> >> - ret = ocfs2_lock_allocators_move_extents(inode, &context->et, *len, 1, >> - &context->meta_ac, >> - &context->data_ac, >> - extra_blocks, &credits); >> + ret = ocfs2_lock_meta_allocator_move_extents(inode, &context->et, >> + *len, 1, >> + &context->meta_ac, >> + extra_blocks, &credits); >> if (ret) { >> mlog_errno(ret); >> goto out; >> @@ -283,6 +272,21 @@ static int ocfs2_defrag_extent(struct ocfs2_move_extents_context *context, >> } >> } >> >> + /* >> + * Make sure ocfs2_reserve_cluster is called after >> + * __ocfs2_flush_truncate_log, otherwise, dead lock may happen. >> + * >> + * If ocfs2_reserve_cluster is called >> + * before __ocfs2_flush_truncate_log, dead lock on global bitmap >> + * may happen. >> + * >> + */ >> + ret = ocfs2_reserve_clusters(osb, *len, &context->data_ac); >> + if (ret) { >> + mlog_errno(ret); >> + goto out_unlock_mutex; >> + } >> + >> handle = ocfs2_start_trans(osb, credits); >> if (IS_ERR(handle)) { >> ret = PTR_ERR(handle); >> @@ -600,9 +604,10 @@ static int ocfs2_move_extent(struct ocfs2_move_extents_context *context, >> } >> } >> >> - ret = ocfs2_lock_allocators_move_extents(inode, &context->et, len, 1, >> - &context->meta_ac, >> - NULL, extra_blocks, &credits); >> + ret = ocfs2_lock_meta_allocator_move_extents(inode, &context->et, >> + len, 1, >> + &context->meta_ac, >> + extra_blocks, &credits); >> if (ret) { >> mlog_errno(ret); >> goto out; >> > > _______________________________________________ > Ocfs2-devel mailing list > Ocfs2-devel@oss.oracle.com > https://oss.oracle.com/mailman/listinfo/ocfs2-devel >