Received: by 2002:a25:23cc:0:0:0:0:0 with SMTP id j195csp181240ybj; Fri, 8 May 2020 09:13:21 -0700 (PDT) X-Google-Smtp-Source: APiQypJ8Tkd0mCqoTx1cO0nfRK7kW2ato3B/8CNu3gYdAKKAXuEytqh/YIKOTeeMkvkdSBqnOfsE X-Received: by 2002:a17:906:310e:: with SMTP id 14mr2570447ejx.177.1588954401205; Fri, 08 May 2020 09:13:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588954401; cv=none; d=google.com; s=arc-20160816; b=VTFn8zj/awF3UCHIwcywjQmHJAk764WfRkYErWRGb8eRBIP3idepm2jFgpAZoUfmas UDZ+L6I5tg4SVMcPtgXV468AzrJrl+aKfK4oKNYKwTX3dPIjwDiUot1NP6YmnfzdjMUf aKEbSY4reP5LoqcAJmErao9/syLrLbrmsbY+OnZxrWUHyVdySx2aQ9b3G4O10VGFwOyz oGfNY4+5lyOFVyd4GaU7063JWeCLh+IK1pvw2el/d2qoz0ISEgUjgEEb8ojiVWNSXzAs E6RkJiiufr+JzQpuQfogxyDj5e02svcQf7F+npQM1yhB+KeAOmk3CQaIpyFQ3hzZ5Q3l 5Ylw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=2oBFHESUV6LZ4ysh1mnwnoclw8pghTfGbTZvip9FZEw=; b=Yj3gSsAQnsh7FYP+6AxCwG0tSOZSeNybnmwZ/1Xm5DEdjy6RxAod4AauVZtWkret3P LQfG0dM2SVwuhkJA7hUYMPHsD53sN/A2Dihaha/qFHJYB/OduS4cwreUke9voU84sJIZ uKy4wE/iKjv5cr8BO8myi6osNwhX7wrs/XNrllPjADlGQLZICWi3+nU/XUzYryY32v0P HgbUdYYjvC53NdFI5yKZuyGEuX6uXvLGhv+ZtZHD+7ED0xGua0eUGpgF1YA1RE6AVDYH KWKUyQ3E354+IhP+0WIF+5YNQtgE2eBxD/ECUZV87/HVrj+cZUQpGeg7nKh6QYBoQdaB 4EnA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=oStbxdgl; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id m10si1116292edr.459.2020.05.08.09.12.56; Fri, 08 May 2020 09:13:21 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=oStbxdgl; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727911AbgEHQKx (ORCPT + 99 others); Fri, 8 May 2020 12:10:53 -0400 Received: from mail.kernel.org ([198.145.29.99]:36530 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726771AbgEHQKx (ORCPT ); Fri, 8 May 2020 12:10:53 -0400 Received: from localhost (unknown [104.132.1.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id C6A6921473; Fri, 8 May 2020 16:10:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1588954252; bh=CngiETS7U8ogJRzhIAr/EkeUvISa1C5VP4Jj6loUtak=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=oStbxdglOMtUlQGeVwfj1nbCiFYPbNAyqYsWAckLKAfCrntEbOxHnepG8AU/EuuQP S9Ys7M4l6CEpsTsKd7OZ5UgO6WuMZhMM73CLZu+avs+f4q6nDVoC6LcqkOORyGx2m4 yir+WIq2rwTMo5QWsw757cHq67kWjTtLeBKTFl58= Date: Fri, 8 May 2020 09:10:52 -0700 From: Jaegeuk Kim To: Sayali Lokhande Cc: yuchao0@huawei.com, linux-f2fs-devel@lists.sourceforge.net, stummala@codeaurora.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH V4] f2fs: Avoid double lock for cp_rwsem during checkpoint Message-ID: <20200508161052.GA49579@google.com> References: <1588244309-1468-1-git-send-email-sayalil@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1588244309-1468-1-git-send-email-sayalil@codeaurora.org> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Sayali, In order to address the perf regression, how about this? From 48418af635884803ffb35972df7958a2e6649322 Mon Sep 17 00:00:00 2001 From: Jaegeuk Kim Date: Fri, 8 May 2020 09:08:37 -0700 Subject: [PATCH] f2fs: avoid double lock for cp_rwsem during checkpoint There could be a scenario where f2fs_sync_node_pages gets called during checkpoint, which in turn tries to flush inline data and calls iput(). This results in deadlock as iput() tries to hold cp_rwsem, which is already held at the beginning by checkpoint->block_operations(). Call stack : Thread A Thread B f2fs_write_checkpoint() - block_operations(sbi) - f2fs_lock_all(sbi); - down_write(&sbi->cp_rwsem); - open() - igrab() - write() write inline data - unlink() - f2fs_sync_node_pages() - if (is_inline_node(page)) - flush_inline_data() - ilookup() page = f2fs_pagecache_get_page() if (!page) goto iput_out; iput_out: -close() -iput() iput(inode); - f2fs_evict_inode() - f2fs_truncate_blocks() - f2fs_lock_op() - down_read(&sbi->cp_rwsem); Fixes: 2049d4fcb057 ("f2fs: avoid multiple node page writes due to inline_data") Signed-off-by: Sayali Lokhande Signed-off-by: Jaegeuk Kim --- fs/f2fs/node.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c index 1db8cabf727ef..626d7daca09de 100644 --- a/fs/f2fs/node.c +++ b/fs/f2fs/node.c @@ -1870,8 +1870,8 @@ int f2fs_sync_node_pages(struct f2fs_sb_info *sbi, goto continue_unlock; } - /* flush inline_data */ - if (is_inline_node(page)) { + /* flush inline_data, if it's not sync path. */ + if (do_balance && is_inline_node(page)) { clear_inline_node(page); unlock_page(page); flush_inline_data(sbi, ino_of_node(page)); -- 2.26.2.645.ge9eca65c58-goog