Received: by 10.223.185.116 with SMTP id b49csp907616wrg; Sat, 10 Feb 2018 23:41:18 -0800 (PST) X-Google-Smtp-Source: AH8x2261nUtrpzrudGADrbBamvXKxbkeS23pPSJXuoWIRML+gbJ8KLgAK65LJpfhYu8uRysmJeHi X-Received: by 10.99.137.195 with SMTP id v186mr5952126pgd.90.1518334877903; Sat, 10 Feb 2018 23:41:17 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518334877; cv=none; d=google.com; s=arc-20160816; b=jBl0njMe2pbQT73CcHCZNfhfJSvFC9ve7EqpPxQwTxrp6Bx8gbX86W55HU6Lwjp8AC fADVbXohC0+pq7hIUcu6q80mw4T2dl7Hfd0ndtrYp1jYqlyFLyYjdCJmm9HI/coYq3Rk 2oBQ+s1u2+yC9Fi09zRrk4RJFvkM9e5cu0bRwl/65cDYKnw3DIdBgGPjF/2pHjQ5Ewbk G+aZXT/rpM0FvvzS2Nsu5NM0y+AD2edLH5v+tBpjxzIHY6nvP/cfzfoJsPT20VeM9T+z 1qrv2397Ex6lBcX0RraXPLqr3P3PqjxxDvCfuQteSHynVCNX1+Bcn0mtyYGJXaTwvVnf IDtg== 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:in-reply-to :references:subject:cc:to:mime-version:user-agent:from:date :message-id:arc-authentication-results; bh=zFSiSUpdRm1hWkStXm7VZBd8/S7HS0Y5F0vabXL7yLY=; b=LurvOhTXAKMDCMWBwhJodOO901DDjZFE8KPyqphTkchcECfvRPsHy/DaGsozbEjP8l DaSodhaz3Sdg2B53eK+uBPuVCSvA//wutS1cpoCijb5pKAHO+D2vkA5u/YKKRF6TZ6tD eAiahVIfQVw1hUvAuvD9vUYPQS2WivKn5hAut73KCzQ9X+1D7j8uyKSbKzA3GjxlA8x9 ElHSd24ikvbmGHW3/Lew4Rj/m5Zvh6iBmCnknrMzGyntz6Jvy/u/CSw12h9gJnA3F66D U87pERhMOhu3ZVOxYsuI3gyyA1trlqsUhGbc0JFjHO36X5ZA3yq1vqKybiqPK0seyMQZ BZDA== 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 b59-v6si4168347plc.302.2018.02.10.23.41.02; Sat, 10 Feb 2018 23:41:17 -0800 (PST) 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 S1752659AbeBKHkU (ORCPT + 99 others); Sun, 11 Feb 2018 02:40:20 -0500 Received: from szxga04-in.huawei.com ([45.249.212.190]:5192 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752224AbeBKHkS (ORCPT ); Sun, 11 Feb 2018 02:40:18 -0500 Received: from DGGEMS409-HUB.china.huawei.com (unknown [172.30.72.58]) by Forcepoint Email with ESMTP id 0B990F6601B3F; Sun, 11 Feb 2018 15:40:03 +0800 (CST) Received: from [127.0.0.1] (10.177.26.59) by DGGEMS409-HUB.china.huawei.com (10.3.19.209) with Microsoft SMTP Server id 14.3.361.1; Sun, 11 Feb 2018 15:39:58 +0800 Message-ID: <5A7FF337.3000705@huawei.com> Date: Sun, 11 Feb 2018 15:39:35 +0800 From: alex chen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Ben Hutchings CC: , , , Joel Becker , Joseph Qi , Jun Piao , Mark Fasheh , Changwei Ge , Junxiao Bi , Linus Torvalds Subject: Re: [PATCH 3.2 39/79] ocfs2: should wait dio before inode lock in ocfs2_setattr() References: In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.177.26.59] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Ben, ocfs2_dio_end_io_write() was introduced in 4.6 and the problem this patch fixes is only exist in the kernel 4.6 and above 4.6. Thanks, Alex On 2018/2/11 12:20, Ben Hutchings wrote: > 3.2.99-rc1 review patch. If anyone has any objections, please let me know. > > ------------------ > > From: alex chen > > commit 28f5a8a7c033cbf3e32277f4cc9c6afd74f05300 upstream. > > we should wait dio requests to finish before inode lock in > ocfs2_setattr(), otherwise the following deadlock will happen: > > process 1 process 2 process 3 > truncate file 'A' end_io of writing file 'A' receiving the bast messages > ocfs2_setattr > ocfs2_inode_lock_tracker > ocfs2_inode_lock_full > inode_dio_wait > __inode_dio_wait > -->waiting for all dio > requests finish > dlm_proxy_ast_handler > dlm_do_local_bast > ocfs2_blocking_ast > ocfs2_generic_handle_bast > set OCFS2_LOCK_BLOCKED flag > dio_end_io > dio_bio_end_aio > dio_complete > ocfs2_dio_end_io > ocfs2_dio_end_io_write > ocfs2_inode_lock > __ocfs2_cluster_lock > ocfs2_wait_for_mask > -->waiting for OCFS2_LOCK_BLOCKED > flag to be cleared, that is waiting > for 'process 1' unlocking the inode lock > inode_dio_end > -->here dec the i_dio_count, but will never > be called, so a deadlock happened. > > Link: http://lkml.kernel.org/r/59F81636.70508@huawei.com > Signed-off-by: Alex Chen > Reviewed-by: Jun Piao > Reviewed-by: Joseph Qi > Acked-by: Changwei Ge > Cc: Mark Fasheh > Cc: Joel Becker > Cc: Junxiao Bi > Signed-off-by: Andrew Morton > Signed-off-by: Linus Torvalds > Signed-off-by: Ben Hutchings > --- > fs/ocfs2/file.c | 9 +++++++-- > 1 file changed, 7 insertions(+), 2 deletions(-) > > --- a/fs/ocfs2/file.c > +++ b/fs/ocfs2/file.c > @@ -1130,6 +1130,13 @@ int ocfs2_setattr(struct dentry *dentry, > dquot_initialize(inode); > size_change = S_ISREG(inode->i_mode) && attr->ia_valid & ATTR_SIZE; > if (size_change) { > + /* > + * Here we should wait dio to finish before inode lock > + * to avoid a deadlock between ocfs2_setattr() and > + * ocfs2_dio_end_io_write() > + */ > + inode_dio_wait(inode); > + > status = ocfs2_rw_lock(inode, 1); > if (status < 0) { > mlog_errno(status); > @@ -1149,8 +1156,6 @@ int ocfs2_setattr(struct dentry *dentry, > if (status) > goto bail_unlock; > > - inode_dio_wait(inode); > - > if (i_size_read(inode) >= attr->ia_size) { > if (ocfs2_should_order_data(inode)) { > status = ocfs2_begin_ordered_truncate(inode, > > > . >