Received: by 2002:a25:ef43:0:0:0:0:0 with SMTP id w3csp382945ybm; Fri, 29 May 2020 02:32:20 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyfABPpw4NGeYRWngp4h+jKJpCnTV+3/CoTZm6itFLTt345SErkIaiK827p8jVebSe3dg8P X-Received: by 2002:a17:906:8694:: with SMTP id g20mr6999221ejx.75.1590744739896; Fri, 29 May 2020 02:32:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1590744739; cv=none; d=google.com; s=arc-20160816; b=ulcAcbvcvwNCjV+WvDJlOyTm0QWD9ypaK2HZLoJCen3DCi3XG1RuWog3Kr2CFD8WtH 82WkvxodI+NA8mRJNKl73xs7P+UoGqjjhRWIETaDZzfg13yeFVXE5oCM8BMvQ4gEWB9A 73QJ+PT1dN6hBuhTbLuhNs0HR2H7c719tU9p5T3p59BrCSh0f94KkvZf9dlCxqwsIyrH jxE3h7IXGlj3ZDGMiII3GRSKPTSlB20xIvozNXtxIqBiTxEmquVoUiHdeWsn7gFc0JX6 cj9svsHi4C7pIAyu7cd/5TYTQqU6qAprg9DcSrl46idCwM6hRTwU/rBpRsXKYUsWr0oQ Fhsg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:subject:cc :to:from; bh=b3Or16xs2x04h/6DmDDduRlsDcQKAsV66L9oNLVBFAg=; b=axRIySLhTDKEj890raoV7YJrEJcK/fYIqYsnnNGhpSzXxAvfSiXbi3knvKkfNgR6GW 75JT7se5Qoogu38Z2wfxZrPxgfBP1bCoZEsCuPZIAhXGCnoesDwrEzATMFZDfvipbIzu kGTnltQaSq41k1zObHTHW/7NHzo7Oe+2qqmtndV32z3h1n2+F7JpIrgUX0LYeyHdOJ+a hahAMAilniYg9X3sjxPY5XTjYsNHKYls64sIHj22fkN641/9aZV3kS0V0LW5XcZoB9eC ZWj5YuiUO2zA92IRCIJySkPVYIAk4N7CwxYJ8hTBLLz4EDzx1ddbRKF7+z7DNYeHYvFc 9dgw== 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 l26si5405262ejx.390.2020.05.29.02.31.57; Fri, 29 May 2020 02:32:19 -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 S1726282AbgE2JaJ (ORCPT + 99 others); Fri, 29 May 2020 05:30:09 -0400 Received: from szxga04-in.huawei.com ([45.249.212.190]:5391 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725601AbgE2JaI (ORCPT ); Fri, 29 May 2020 05:30:08 -0400 Received: from DGGEMS405-HUB.china.huawei.com (unknown [172.30.72.59]) by Forcepoint Email with ESMTP id 9C4A5505144E1C536119; Fri, 29 May 2020 17:30:06 +0800 (CST) Received: from szvp000203569.huawei.com (10.120.216.130) by DGGEMS405-HUB.china.huawei.com (10.3.19.205) with Microsoft SMTP Server id 14.3.487.0; Fri, 29 May 2020 17:30:00 +0800 From: Chao Yu To: CC: , , , Chao Yu Subject: [PATCH] Revert "f2fs: fix quota_sync failure due to f2fs_lock_op" Date: Fri, 29 May 2020 17:29:47 +0800 Message-ID: <20200529092947.7890-1-yuchao0@huawei.com> X-Mailer: git-send-email 2.18.0.rc1 MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [10.120.216.130] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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") Signed-off-by: Chao Yu --- fs/f2fs/compress.c | 8 +++----- fs/f2fs/data.c | 4 ++-- 2 files changed, 5 insertions(+), 7 deletions(-) diff --git a/fs/f2fs/compress.c b/fs/f2fs/compress.c index a53578a89211..62c4857ae46d 100644 --- a/fs/f2fs/compress.c +++ b/fs/f2fs/compress.c @@ -1097,7 +1097,7 @@ static int f2fs_write_compressed_pages(struct compress_ctx *cc, loff_t psize; int i, err; - if (!IS_NOQUOTA(inode) && !f2fs_trylock_op(sbi)) + if (!f2fs_trylock_op(sbi)) return -EAGAIN; set_new_dnode(&dn, cc->inode, NULL, NULL, 0); @@ -1204,8 +1204,7 @@ static int f2fs_write_compressed_pages(struct compress_ctx *cc, set_inode_flag(inode, FI_FIRST_BLOCK_WRITTEN); f2fs_put_dnode(&dn); - if (!IS_NOQUOTA(inode)) - f2fs_unlock_op(sbi); + f2fs_unlock_op(sbi); spin_lock(&fi->i_size_lock); if (fi->last_disk_size < psize) @@ -1231,8 +1230,7 @@ static int f2fs_write_compressed_pages(struct compress_ctx *cc, out_put_dnode: f2fs_put_dnode(&dn); out_unlock_op: - if (!IS_NOQUOTA(inode)) - f2fs_unlock_op(sbi); + f2fs_unlock_op(sbi); return -EAGAIN; } diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c index 999a36ff05f1..d983ad54f318 100644 --- a/fs/f2fs/data.c +++ b/fs/f2fs/data.c @@ -2724,8 +2724,8 @@ int f2fs_write_single_data_page(struct page *page, int *submitted, f2fs_available_free_memory(sbi, BASE_CHECK)))) goto redirty_out; - /* Dentry/quota blocks are controlled by checkpoint */ - if (S_ISDIR(inode->i_mode) || IS_NOQUOTA(inode)) { + /* Dentry blocks are controlled by checkpoint */ + if (S_ISDIR(inode->i_mode)) { fio.need_lock = LOCK_DONE; err = f2fs_do_write_data_page(&fio); goto done; -- 2.18.0.rc1