From patchwork Thu Jan 4 07:02:02 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Yunlong Song X-Patchwork-Id: 10143969 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 61B5D6034B for ; Thu, 4 Jan 2018 07:02:52 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 55AD828438 for ; Thu, 4 Jan 2018 07:02:52 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 4A57128449; Thu, 4 Jan 2018 07:02:52 +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=unavailable 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 D3CCA28438 for ; Thu, 4 Jan 2018 07:02:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752077AbeADHCg (ORCPT ); Thu, 4 Jan 2018 02:02:36 -0500 Received: from szxga07-in.huawei.com ([45.249.212.35]:44735 "EHLO huawei.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1752065AbeADHCX (ORCPT ); Thu, 4 Jan 2018 02:02:23 -0500 Received: from DGGEMS410-HUB.china.huawei.com (unknown [172.30.72.59]) by Forcepoint Email with ESMTP id 38BA42C93142F; Thu, 4 Jan 2018 15:02:12 +0800 (CST) Received: from huawei.com (10.107.193.250) by DGGEMS410-HUB.china.huawei.com (10.3.19.210) with Microsoft SMTP Server id 14.3.361.1; Thu, 4 Jan 2018 15:02:07 +0800 From: Yunlong Song To: , , , , CC: , , , , , , Subject: [PATCH v4] f2fs: check segment type in __f2fs_replace_block Date: Thu, 4 Jan 2018 15:02:02 +0800 Message-ID: <1515049322-29555-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 Reviewed-by: Chao Yu --- fs/f2fs/segment.c | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c index 890d483..50575d5 100644 --- a/fs/f2fs/segment.c +++ b/fs/f2fs/segment.c @@ -2720,6 +2720,7 @@ void __f2fs_replace_block(struct f2fs_sb_info *sbi, struct f2fs_summary *sum, type = se->type; down_write(&SM_I(sbi)->curseg_lock); + f2fs_bug_on(sbi, se->valid_blocks && !IS_DATASEG(type)); if (!recover_curseg) { /* for recovery flow */