From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.1 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E2A9EC2BB1D for ; Wed, 15 Apr 2020 03:29:07 +0000 (UTC) Received: from lists.sourceforge.net (lists.sourceforge.net [216.105.38.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id A12C0206F9; Wed, 15 Apr 2020 03:29:07 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=sourceforge.net header.i=@sourceforge.net header.b="SSUmqwlo"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=sf.net header.i=@sf.net header.b="f7R4GbYc" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A12C0206F9 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=huawei.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linux-f2fs-devel-bounces@lists.sourceforge.net Received: from [127.0.0.1] (helo=sfs-ml-2.v29.lw.sourceforge.com) by sfs-ml-2.v29.lw.sourceforge.com with esmtp (Exim 4.90_1) (envelope-from ) id 1jOYjb-0006fa-98; Wed, 15 Apr 2020 03:29:07 +0000 Received: from [172.30.20.202] (helo=mx.sourceforge.net) by sfs-ml-2.v29.lw.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jOYja-0006fU-Uv for linux-f2fs-devel@lists.sourceforge.net; Wed, 15 Apr 2020 03:29:06 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sourceforge.net; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:CC:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=7dBSMlt48TuNAPHuFk/2XRsXFtuPuNF9w2C7tk7osx4=; b=SSUmqwloBn05sfsrwtYfx3VO1D kxM8KbtGr/dNWNWZN1qn6EFHXPQBE9OLGSfRAS/uPo7mW4f5PQWALQnLn7jjJk1mqmX66Jzq60fr4 ZtfimbTpBPTuMcKiqQ/2Y46mCEkfJPoHFdeGEKXdiWFCLYs1sEv458pPktqcBVneuF8g=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sf.net; s=x ; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:CC:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=7dBSMlt48TuNAPHuFk/2XRsXFtuPuNF9w2C7tk7osx4=; b=f7R4GbYcYO8Was3RqLximMMPGn GPCElzV7/dpikV1gF21MrHbFolIthC8n+bo93BQ4dPpNyZPlDOiC8IQwRc+jkGw+xK+9AFjuj4fER TFsJH9AOfPFWsStAHrEiPfU2lgqfUjKkTLy4obroyR8hciNQIau1r/EHgkyhxtBk8h10=; Received: from szxga07-in.huawei.com ([45.249.212.35] helo=huawei.com) by sfi-mx-1.v28.lw.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.2) id 1jOYjZ-00GoVx-AK for linux-f2fs-devel@lists.sourceforge.net; Wed, 15 Apr 2020 03:29:06 +0000 Received: from DGGEMS403-HUB.china.huawei.com (unknown [172.30.72.59]) by Forcepoint Email with ESMTP id C305656453E0F6A2117B; Wed, 15 Apr 2020 11:28:58 +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; Wed, 15 Apr 2020 11:28:56 +0800 To: Adam Borowski References: <158582888648.9053.2167684001695943018.reportbug@umbar.angband.pl> <20200402191658.GR768293@mit.edu> <20200403024535.GA23417@angband.pl> <58dd64a1-4f2b-3201-6cb7-215b420f804b@huawei.com> <45149351-4c07-ba55-dec3-9a0872bb159f@huawei.com> <20200409233255.GA14286@angband.pl> From: Chao Yu Message-ID: Date: Wed, 15 Apr 2020 11:28:46 +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: <20200409233255.GA14286@angband.pl> Content-Language: en-US X-Originating-IP: [10.134.22.195] X-CFilter-Loop: Reflected X-Headers-End: 1jOYjZ-00GoVx-AK Subject: Re: [f2fs-dev] Bug#955549: f2fs-tools: fsck.f2fs segfaults X-BeenThere: linux-f2fs-devel@lists.sourceforge.net X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: 955549@bugs.debian.org, linux-f2fs-devel@lists.sourceforge.net Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-f2fs-devel-bounces@lists.sourceforge.net On 2020/4/10 7:32, Adam Borowski wrote: > On Tue, Apr 07, 2020 at 06:22:19PM +0800, Chao Yu wrote: >> I figured out two patches to fix segfault issues, could you please have >> a try: >> >> fsck.f2fs: fix to check validation of i_xattr_nid >> fsck.f2fs: fix to check validation of block address >> >> In addition, I found that fsck main flow failed because it can not load root >> inode based on wrong block address in nat, so I wrote another patch to enable >> fsck to lookup root inode by traversing all nodes in f2fs main area, and relink >> nat to root inode correctly. >> >> fsck.f2fs: lookup and relink root inode > > I still get a segfault: Oops.. > > Program received signal SIGSEGV, Segmentation fault. > 0x0000555555564444 in print_inode_info (sbi=0x555555584ca0 , node=0x55555558f170, name=) at mount.c:240 > 240 block_t blkaddr = le32_to_cpu(inode->i_addr[i + ofs]); > (gdb) bt > #0 0x0000555555564444 in print_inode_info (sbi=0x555555584ca0 , node=0x55555558f170, name=) at mount.c:240 > #1 0x0000555555564c4e in print_node_info (sbi=, node_block=, verbose=) at mount.c:278 > #2 0x000055555556317f in dump_node (sbi=sbi@entry=0x555555584ca0 , nid=nid@entry=2861, force=force@entry=1) at dump.c:511 > #3 0x0000555555561060 in fsck_verify (sbi=0x555555584ca0 ) at fsck.c:3259 > #4 0x000055555555799a in do_fsck (sbi=0x555555584ca0 ) at main.c:698 > #5 main (argc=, argv=) at main.c:864 Fixed with [PATCH] fsck.f2fs: fix to avoid overflow during print_inode_info() Thanks, > >> With this patch, image can be fixed and mounted later, although, most of files >> were deleted due to seriously damaged f2fs metadata.... > > Yeah, I've later tested the hardware -- writes to it are borked, so no > complaint against the filesystem failing. I got backups. :) > >> The patches were made on top of dev-test branch of Jaegeuk's tree: >> https://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs-tools.git/log/?h=dev-test > >>>>>> #0 0x00005555555593ec in memcpy (__len=18446744073323892736, __src=0x55555560760c, __dest=0x7fffffffe000) at /usr/include/x86_64-linux-gnu/bits/string_fortified.h:34 >>> >>> At a glance, immediate reason of this issue is we didn't check inode.i_namelen's >>> validation. >>> >>>>>> #1 convert_encrypted_name (name=name@entry=0x55555560760c " ", len=-385658880, new=new@entry=0x7fffffffe000 " ", enc_name=) at fsck.c:1132 >>>>>> #2 0x0000555555562286 in print_inode_info (sbi=0x55555557db20 , node=0x5555556075b0, name=1) at mount.c:183 >>>>>> #3 0x0000555555562a46 in print_node_info (sbi=, node_block=, verbose=) at mount.c:277 >>>>>> #4 0x0000555555560d3f in dump_node (sbi=sbi@entry=0x55555557db20 , nid=nid@entry=24274, force=force@entry=1) at dump.c:520 >>>>>> #5 0x000055555555e94c in fsck_verify (sbi=0x55555557db20 ) at fsck.c:2568 >>>>>> #6 0x000055555555699b in do_fsck (sbi=0x55555557db20 ) at main.c:569 > > > Meow! > _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel