Received: by 2002:a25:ef43:0:0:0:0:0 with SMTP id w3csp47644ybm; Wed, 27 May 2020 18:52:16 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwOagCx0jK3ID+d89LBQuEJlPmOJxw4SnLMWWExO96zK3mVrLgZ8edj07uLyzHTlTv4UGJS X-Received: by 2002:a17:906:bce6:: with SMTP id op6mr938704ejb.337.1590630736067; Wed, 27 May 2020 18:52:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1590630736; cv=none; d=google.com; s=arc-20160816; b=i2Uq88lgpBMFU9EV7IjZEFsvr3uMcTSQ7sWir/5lo128XxJ5bxTQS3bNVGpL6pbytF 1D0fu4EA2Ru26t+3bugdXnx8jAaaQORo82AJymMZ7hZd/OKDd3XlUs/B/r1AwSCrsWi2 DEIQ/VoN2vKQn0iTkCNh7wT8WyN9/nA328kMbH57iCKB5wdWVCsbtgFX1D98Ej+olJFQ N1h9JZQZoyhFbaNVKNx1M+zxg4NTTOK8Q8YWHrBkgxTjl6lXKQbaP60xamUXDgxLKLUh mGYgR31BXJgT6kc7z0MCYCmDeFHS4Uu5E08/mFonAkuHeGWcKNCoFjpOVlFaJAm+Hx7u raUw== 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; bh=xN4m7skEpzGPr9jgoMYo4IL5slVoq9r3cGRyctEILeQ=; b=BkHTs+yMsyswE+GIO4V2w+dJ6AJ2zKFb5N/cd7B78zWmEo1ozV5g1LmiIdREKG+uaF i06yyu4iSrugWWj6XK5W0BADpWD/YlI0PIencme5V2/SeUktvA9WOpamWF6ADrauhKhr tra0TeYVsgpOxVg1ej6dhaWUHjOKVXhY2uN462P8QFy2RSf8BRcL8zYgChJzg2ZvsVAG Us7Se20rts/3aU+i931taQFzZudafLRI8nag+Jw4+TpcU65ZwaWxDovXOdoarKV49+xd mPUBW/X7SjFPI7cNxGYwxOjpsDwv2ZKOvPC32+haYxJt10RSE4JUZFeFQYnOdq78M+F6 ALeA== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id cz19si2707306edb.40.2020.05.27.18.51.53; Wed, 27 May 2020 18:52:16 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726393AbgE1BrW (ORCPT + 99 others); Wed, 27 May 2020 21:47:22 -0400 Received: from szxga06-in.huawei.com ([45.249.212.32]:39728 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725959AbgE1BrW (ORCPT ); Wed, 27 May 2020 21:47:22 -0400 Received: from DGGEMS403-HUB.china.huawei.com (unknown [172.30.72.59]) by Forcepoint Email with ESMTP id 7826F79C38DB58841F19; Thu, 28 May 2020 09:47:19 +0800 (CST) Received: from [10.134.22.195] (10.134.22.195) by smtp.huawei.com (10.3.19.203) with Microsoft SMTP Server (TLS) id 14.3.487.0; Thu, 28 May 2020 09:47:16 +0800 Subject: Re: [PATCH 3/3] f2fs: fix to cover meta flush with cp_lock To: Jaegeuk Kim CC: , , References: <20200527102753.15743-1-yuchao0@huawei.com> <20200527102753.15743-3-yuchao0@huawei.com> <20200527210233.GC206249@google.com> <23245f6e-528d-43ab-57b6-4ca16db43fe5@huawei.com> <20200528012615.GA232094@google.com> From: Chao Yu Message-ID: <8e30b18d-bf8e-dd2f-35fa-08bbfd1b507e@huawei.com> Date: Thu, 28 May 2020 09:47:15 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20200528012615.GA232094@google.com> Content-Type: text/plain; charset="windows-1252" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.134.22.195] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2020/5/28 9:26, Jaegeuk Kim wrote: > On 05/28, Chao Yu wrote: >> On 2020/5/28 5:02, Jaegeuk Kim wrote: >>> On 05/27, Chao Yu wrote: >>>> meta inode page should be flushed under cp_lock, fix it. >>> >>> It doesn't matter for this case, yes? >> >> It's not related to discard issue. > > I meant we really need this or not. :P Yes, let's keep that rule: flush meta pages under cp_lock, otherwise checkpoint flush order may be broken due to race, right? as checkpoint should write 2rd cp park page after flushing all meta pages. > >> >> Now, I got some progress, I can reproduce that bug occasionally. >> >> Thanks, >> >>> >>>> >>>> Signed-off-by: Chao Yu >>>> --- >>>> fs/f2fs/file.c | 2 ++ >>>> 1 file changed, 2 insertions(+) >>>> >>>> diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c >>>> index f7de2a1da528..0fcae4d90074 100644 >>>> --- a/fs/f2fs/file.c >>>> +++ b/fs/f2fs/file.c >>>> @@ -2260,7 +2260,9 @@ static int f2fs_ioc_shutdown(struct file *filp, unsigned long arg) >>>> set_sbi_flag(sbi, SBI_IS_SHUTDOWN); >>>> break; >>>> case F2FS_GOING_DOWN_METAFLUSH: >>>> + mutex_lock(&sbi->cp_mutex); >>>> f2fs_sync_meta_pages(sbi, META, LONG_MAX, FS_META_IO); >>>> + mutex_unlock(&sbi->cp_mutex); >>>> f2fs_stop_checkpoint(sbi, false); >>>> set_sbi_flag(sbi, SBI_IS_SHUTDOWN); >>>> break; >>>> -- >>>> 2.18.0.rc1 >>> . >>> > . >