From patchwork Thu Jan 4 06:24:36 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Yunlong Song X-Patchwork-Id: 10143933 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id C018E60594 for ; Thu, 4 Jan 2018 06:27:54 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id B4ACB2842A for ; Thu, 4 Jan 2018 06:27:54 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id A8A1528438; Thu, 4 Jan 2018 06:27:54 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 4A2372842A for ; Thu, 4 Jan 2018 06:27:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752149AbeADG1j (ORCPT ); Thu, 4 Jan 2018 01:27:39 -0500 Received: from szxga04-in.huawei.com ([45.249.212.190]:3679 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752109AbeADG1j (ORCPT ); Thu, 4 Jan 2018 01:27:39 -0500 Received: from DGGEMS403-HUB.china.huawei.com (unknown [172.30.72.60]) by Forcepoint Email with ESMTP id 75E63B4E31E98; Thu, 4 Jan 2018 14:24:49 +0800 (CST) Received: from huawei.com (10.107.193.250) by DGGEMS403-HUB.china.huawei.com (10.3.19.203) with Microsoft SMTP Server id 14.3.361.1; Thu, 4 Jan 2018 14:24:42 +0800 From: Yunlong Song To: , , , , CC: , , , , , , Subject: [PATCH v3] f2fs: check segment type in __f2fs_replace_block Date: Thu, 4 Jan 2018 14:24:36 +0800 Message-ID: <1515047076-27582-1-git-send-email-yunlong.song@huawei.com> X-Mailer: git-send-email 1.8.5.2 In-Reply-To: <1514619768-134531-1-git-send-email-yunlong.song@huawei.com> References: <1514619768-134531-1-git-send-email-yunlong.song@huawei.com> MIME-Version: 1.0 X-Originating-IP: [10.107.193.250] X-CFilter-Loop: Reflected Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP In some case, the node blocks has wrong blkaddr whose segment type is NODE, e.g., recover inode has missing xattr flag and the blkaddr is in the xattr range. Since fsck.f2fs does not check the recovery nodes, this will cause __f2fs_replace_block change the curseg of node and do the update_sit_entry(sbi, new_blkaddr, 1) with no next_blkoff refresh, as a result, when recovery process write checkpoint and sync nodes, the next_blkoff of curseg is used in the segment bit map, then it will cause f2fs_bug_on. So let's check segment type in __f2fs_replace_block. Signed-off-by: Yunlong Song --- fs/f2fs/segment.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c index 890d483..6c6d2dd 100644 --- a/fs/f2fs/segment.c +++ b/fs/f2fs/segment.c @@ -2719,6 +2719,8 @@ void __f2fs_replace_block(struct f2fs_sb_info *sbi, struct f2fs_summary *sum, se = get_seg_entry(sbi, segno); type = se->type; + f2fs_bug_on(sbi, se->valid_blocks && !IS_DATASEG(type)); + down_write(&SM_I(sbi)->curseg_lock); if (!recover_curseg) {