Received: by 2002:a25:ef43:0:0:0:0:0 with SMTP id w3csp1011379ybm; Fri, 29 May 2020 18:32:26 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx7LEbxaENOj9S2n0k+alnixCVh1sGcU4RnTkynLKRQHxEPDFwkbc9yk2YG36zVTk9C80Ns X-Received: by 2002:a17:906:14db:: with SMTP id y27mr10510821ejc.427.1590802346605; Fri, 29 May 2020 18:32:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1590802346; cv=none; d=google.com; s=arc-20160816; b=o78xZP+dYskZrY3IkZyX4hh5AHheq2LpxIvoy0x28Sm+2uz744hiS+ABLBuo5dDHdp mejcAa3r67EcpG1sBHGpXEbuxCWaCwO60ubWpQMyBSfpRasZZCWEXcxbPUCXjCgEHJLd WsgQCAKMZaQzDAKzV8YnWAvJKzcQRQAIkt+lgCNj3avUORXDRjXZfdNX5iLifkeZgawJ mjFUW+W0kYDd1icCuCw+MoHWBPJuMF6xW9l9HjtYcVbF0ujAp6sTl944XBGzyfr4iqED t0E/iJf+SgurPDlNAGbeadr6TaXXZ8tUCtunq0BwSj+WV+4yf9lIde6h3sNNflr0Xz+5 q5jA== 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=sKvIrN7LdaxiCXxbD3KKW3EjVxwxuuB56odldjlhGfI=; b=Ej0mVhSlHR31/y8Q/sNIzGsKb1rUcK0cbdKAEToQbE4mOY/Z+IY5f8ShhiOnKes9K7 zSLTDqT2yR8wGZAUBW/a+kKDrI9aBNpaBVDwvYZgnafcqX/bz3seyYhDaZqFDADtMXzp GXPv53aAvnygUBspRc9yPi0zmKOFkrWwJz3lbVarOG9sEq4FFWU6ohPxAYAsuqZOLRqm 9loB1OwTQk+yURyLKp3yEpf5HZyjX7es4LEztj4zgnpNhPDSiA7hs6R3mcnZdVmKHZTP GKUF4mEIf7k1L4Yri0SX7GSKhGfbWg8M5w1/vFRW0pGthm0vCy20Yn6SeJv39PKiR9wy XZvQ== 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 l16si5455623ejn.716.2020.05.29.18.32.02; Fri, 29 May 2020 18:32:26 -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 S1728551AbgE3BaP (ORCPT + 99 others); Fri, 29 May 2020 21:30:15 -0400 Received: from szxga06-in.huawei.com ([45.249.212.32]:58030 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727876AbgE3BaP (ORCPT ); Fri, 29 May 2020 21:30:15 -0400 Received: from DGGEMS402-HUB.china.huawei.com (unknown [172.30.72.58]) by Forcepoint Email with ESMTP id 27B375CB4E9BE0AE5A1A; Sat, 30 May 2020 09:30:13 +0800 (CST) Received: from [10.134.22.195] (10.134.22.195) by smtp.huawei.com (10.3.19.202) with Microsoft SMTP Server (TLS) id 14.3.487.0; Sat, 30 May 2020 09:30:11 +0800 Subject: Re: [PATCH] Revert "f2fs: fix quota_sync failure due to f2fs_lock_op" To: Jaegeuk Kim CC: , , References: <20200529092947.7890-1-yuchao0@huawei.com> <20200529223426.GA249109@google.com> From: Chao Yu Message-ID: <96ba756e-a354-1ee8-689e-211f63c294e6@huawei.com> Date: Sat, 30 May 2020 09:30:07 +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: <20200529223426.GA249109@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/30 6:34, Jaegeuk Kim wrote: > On 05/29, Chao Yu wrote: >> Under heavy fsstress, we may triggle panic while issuing discard, >> because __check_sit_bitmap() detects that discard command may earse >> valid data blocks, the root cause is as below race stack described, >> since we removed lock when flushing quota data, quota data writeback >> may race with write_checkpoint(), so that it causes inconsistency in >> between cached discard entry and segment bitmap. >> >> - f2fs_write_checkpoint >> - block_operations >> - set_sbi_flag(sbi, SBI_QUOTA_SKIP_FLUSH) >> - f2fs_flush_sit_entries >> - add_discard_addrs >> - __set_bit_le(i, (void *)de->discard_map); >> - f2fs_write_data_pages >> - f2fs_write_single_data_page >> : inode is quota one, cp_rwsem won't be locked >> - f2fs_do_write_data_page >> - f2fs_allocate_data_block >> - f2fs_wait_discard_bio >> : discard entry has not been added yet. >> - update_sit_entry >> - f2fs_clear_prefree_segments >> - f2fs_issue_discard >> : add discard entry >> >> This patch fixes this issue by reverting 435cbab95e39 ("f2fs: fix quota_sync >> failure due to f2fs_lock_op"). >> >> Fixes: 435cbab95e39 ("f2fs: fix quota_sync failure due to f2fs_lock_op") > > The previous patch fixes quota_sync gets EAGAIN all the time. > How about this? It seems this works for fsstress test. > > --- > fs/f2fs/segment.c | 11 +++++++++++ > 1 file changed, 11 insertions(+) > > diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c > index ebbadde6cbced..f67cffc38975e 100644 > --- a/fs/f2fs/segment.c > +++ b/fs/f2fs/segment.c > @@ -3095,6 +3095,14 @@ void f2fs_allocate_data_block(struct f2fs_sb_info *sbi, struct page *page, > struct curseg_info *curseg = CURSEG_I(sbi, type); > bool put_pin_sem = false; > > + /* > + * We need to wait for node_write to avoid block allocation during > + * checkpoint. This can only happen to quota writes which can cause > + * the below discard race condition. > + */ > + if (IS_DATASEG(type)) type is CURSEG_COLD_DATA_PINNED, IS_DATASEG(CURSEG_COLD_DATA_PINNED) should be false, then node_write lock will not be held, later type will be updated to CURSEG_COLD_DATA, then we will try to release node_write. Thanks, > + down_write(&sbi->node_write); > + > if (type == CURSEG_COLD_DATA) { > /* GC during CURSEG_COLD_DATA_PINNED allocation */ > if (down_read_trylock(&sbi->pin_sem)) { > @@ -3174,6 +3182,9 @@ void f2fs_allocate_data_block(struct f2fs_sb_info *sbi, struct page *page, > > if (put_pin_sem) > up_read(&sbi->pin_sem); > + > + if (IS_DATASEG(type)) > + up_write(&sbi->node_write); > } > > static void update_device_state(struct f2fs_io_info *fio) >