Received: by 2002:ac0:98c7:0:0:0:0:0 with SMTP id g7-v6csp501482imd; Thu, 1 Nov 2018 00:25:56 -0700 (PDT) X-Google-Smtp-Source: AJdET5esEOKjgQqPrBG5ZiyqzyXYRqwx+NsBPW+jhQQMvMKPHzK6ENXagZes33yzB2StcONa2v+u X-Received: by 2002:a65:60c9:: with SMTP id r9-v6mr6130220pgv.285.1541057156828; Thu, 01 Nov 2018 00:25:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1541057156; cv=none; d=google.com; s=arc-20160816; b=eTftuM6uTdSXsKLqCih9Jb9rE/R/QbTtU/nOCcJobVXYa0QxcGNAgKNJONYKAdwYvJ 0PklNYHbKlF7ZuhUt5+tUQQo/w4dkdFo2ze8JOI/OPaVkjCUlHDPu1/BgASI/jV1Sndf dykR2u8yFn1mADBgzGTesIwWdMeEbOJwsNuQJUBOf9m2SImXZlxglmVQ6Js7p60nWRA+ DVxxr2YAdx0BKVUp5CEWCphouGUsloCEvCd2ITvR8VZ9QOxalwfV9X1C5I/o/pL9MCSj UeE+Kubd41p5GLxvTvpKDYyJE4qpC0WxuCUtfhtihN6btMpMxgvfJ2SLAf0yrEb272oU bw4A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=3L8Pa44gmONniU7GipoHDkaXSmBj1+lug9DBcJLZGTM=; b=y3MDIcdogvMs1Pct4NN0Z+Ghy0V4XowLZkwvLnK4AWCMe5YMoWbjatEcgNGspEQqm+ 4/6BinJ/hiEoSohb93Xe9HN2ere9NiZidVy1r+EIWRijOc/yrOgntdrDGzJePomCR+Rc isLvNIKEgODjB9Ty3c5Y2RI3yAELeaq/Li3JK0pF8BHjzZkm89Cah4G0jJobIN0mO0sl tLvwWaJ1CJkLw2ftnHhbiEvavWO5pg5ft5jK1OVbIeRYJsX83iPLrY33bMHmiW7rYcnu RDtUPAcr3pZf/aSJKEwOb3V+MivyoqMSEPCtEjhH5Mqa1m7HT1Ujhw/lXnDLyCfvRUJx z9qw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=ksX2jJJy; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t1-v6si28834897plr.64.2018.11.01.00.25.41; Thu, 01 Nov 2018 00:25:56 -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; dkim=pass header.i=@gmail.com header.s=20161025 header.b=ksX2jJJy; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728091AbeKAQ1C (ORCPT + 99 others); Thu, 1 Nov 2018 12:27:02 -0400 Received: from mail-ot1-f65.google.com ([209.85.210.65]:35143 "EHLO mail-ot1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727833AbeKAQ1C (ORCPT ); Thu, 1 Nov 2018 12:27:02 -0400 Received: by mail-ot1-f65.google.com with SMTP id 81so1162211otj.2 for ; Thu, 01 Nov 2018 00:25:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=3L8Pa44gmONniU7GipoHDkaXSmBj1+lug9DBcJLZGTM=; b=ksX2jJJyQaMGkTKEnSrWwUgEwn85grOVkm9j9zyG5EE+XFznbNh5fjKEVORmdM9Z+q rLZcG43uCNshfNCxkOO1k78R9f5jo7nj+l/hpQiXKqcjjDtbo2aZlMqU6Kfu/sNU/5J4 r/gu6z8sHVu7ovtQ/IGvsgTmEMHMe+4jccxGRce9qaGeuaHawY249UIuac8KySKkQ4kF qt46KcQhr1TsjvwOXi/8Wc4k+qN2L1CQP673DABXJTWNRP5gyigZGaqLUtRqaUzRzq9i z3B3gGgFquEP7FomEgUChbaWDWHUF/PCg8Lg4hxojSANUFiFUIRVK1QC5AmU80TPM1ym da1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=3L8Pa44gmONniU7GipoHDkaXSmBj1+lug9DBcJLZGTM=; b=nszxnHUHwTtJpY5Lt0o++tWC5K+mqY7cUBkNixmdP2CO2moPb8Sg/mtGEdPs/mTgPG YibfPj2HzNayL91lFs7vEqU095UgLf2KIc34ITTkyNnUJuyG+RmLJEw8yq2bO1xlEJ30 NfiwyYe4reg2u8gigUESfkL5Dx+ytorB9x0zX3pMGVLkiu6zbUWBgR9bw68YnrwGwxc+ TgA/yWtYtRs2E6PFtEA22gpHfnXPvpwEtpVfcZxr8NaHe2KzZV7SJ+3JrbETMs2E69Tn cfp9EdXfGDXFo88NLXmoTs16To2mkdyta7zdyQyx81D5NSEEEedkLaum8bSWW42q+v0C oEGg== X-Gm-Message-State: AGRZ1gICUgBkDSHLkRazof4AL4ArRBlnIuuVx2qcKlVENVOuR2jpFr52 G6XcnZuttkgMgBXfmc8UUdE= X-Received: by 2002:a9d:44a6:: with SMTP id v38mr3353578ote.282.1541057113778; Thu, 01 Nov 2018 00:25:13 -0700 (PDT) Received: from JosephdeMacBook-Pro.local ([47.89.83.53]) by smtp.gmail.com with ESMTPSA id e198-v6sm10069437oic.5.2018.11.01.00.25.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Nov 2018 00:25:13 -0700 (PDT) Subject: Re: [Ocfs2-devel] [PATCH V2] ocfs2: fix dead lock caused by ocfs2_defrag_extent To: Changwei Ge , Andrew Morton , Larry Chen Cc: "linux-kernel@vger.kernel.org" , "ocfs2-devel@oss.oracle.com" References: <20180902091455.23862-1-lchen@suse.com> <20181031142632.c523108bc137caa8cb1c6282@linux-foundation.org> <63ADC13FD55D6546B7DECE290D39E37301277DDF02@H3CMLB12-EX.srv.huawei-3com.com> From: Joseph Qi Message-ID: <2fa82349-a32b-514c-d59d-8910a36cf255@gmail.com> Date: Thu, 1 Nov 2018 15:25:06 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <63ADC13FD55D6546B7DECE290D39E37301277DDF02@H3CMLB12-EX.srv.huawei-3com.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 18/11/1 11:11, Changwei Ge wrote: > Hi Larry, > > I still have a few tiny comments for your patch, please refer to them. > > On 2018/11/1 5:28, Andrew Morton wrote: >> >> Folks, could we please review this patch for upstream inclusion? >> >> Thanks. >> >> >> From: Larry Chen >> Subject: ocfs2: fix deadlock caused by ocfs2_defrag_extent >> >> 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 refered 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. >> >> [lchen@suse.com: rename ocfs2_lock_allocators_move_extents() to ocfs2_lock_meta_allocator_move_extents(), add some comments] >> Link: https://urldefense.proofpoint.com/v2/url?u=http-3A__lkml.kernel.org_r_20180902091455.23862-2D1-2Dlchen-40suse.com&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=C7gAd4uDxlAvTdc0vmU6X8CMk6L2iDY8-HD0qT6Fo7Y&m=K8aRgOiMescamJW-IuHq-cW4mWedGQv2JTT-2KPy1RI&s=3fQHFtwgixirPeQ5Px4fRBnd_UcSx3rvSsLKLidwESo&e= >> Link: https://urldefense.proofpoint.com/v2/url?u=http-3A__lkml.kernel.org_r_20180827080121.31145-2D1-2Dlchen-40suse.com&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=C7gAd4uDxlAvTdc0vmU6X8CMk6L2iDY8-HD0qT6Fo7Y&m=K8aRgOiMescamJW-IuHq-cW4mWedGQv2JTT-2KPy1RI&s=PQOJREyeElsg_1IlINdSGefNqA6w_cUrI1ezdVxyi7o&e= >> Signed-off-by: Larry Chen >> Cc: Mark Fasheh >> Cc: Joel Becker >> Cc: Junxiao Bi >> Cc: Joseph Qi >> Cc: Changwei Ge >> Signed-off-by: Andrew Morton >> --- >> >> fs/ocfs2/move_extents.c | 40 +++++++++++++++++++++++--------------- >> 1 file changed, 25 insertions(+), 15 deletions(-) >> >> --- a/fs/ocfs2/move_extents.c~fix-dead-lock-caused-by-ocfs2_defrag_extent >> +++ a/fs/ocfs2/move_extents.c >> @@ -162,7 +162,7 @@ out: >> * in some cases, we don't need to reserve clusters, just let data_ac >> * be NULL. >> */ >> -static int ocfs2_lock_allocators_move_extents(struct inode *inode, >> +static int ocfs2_lock_meta_allocator_move_extents(struct inode *inode, >> struct ocfs2_extent_tree *et, >> u32 clusters_to_move, >> u32 extents_to_split, > > After removing 'reserving clusters logic' out of this function, I suggest to also change the function header comments. > And I think there is no need for arguments _data_ac_ now. > Otherwise this patch looks sane to me. > Agree, I think I have commented this out before. Thanks, Joseph > Thanks, > Changwei > >> @@ -192,13 +192,6 @@ static int ocfs2_lock_allocators_move_ex >> 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 +250,11 @@ static int ocfs2_defrag_extent(struct oc >> } >> } >> >> - 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, >> + &context->data_ac, >> + extra_blocks, &credits); >> if (ret) { >> mlog_errno(ret); >> goto out; >> @@ -283,6 +277,21 @@ static int ocfs2_defrag_extent(struct oc >> } >> } >> >> + /* >> + * 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 +609,10 @@ static int ocfs2_move_extent(struct ocfs >> } >> } >> >> - 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, >> + NULL, 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 >> > > _______________________________________________ > Ocfs2-devel mailing list > Ocfs2-devel@oss.oracle.com > https://oss.oracle.com/mailman/listinfo/ocfs2-devel >