linux-f2fs-devel.lists.sourceforge.net archive mirror
 help / color / mirror / Atom feed
From: Adam Borowski <kilobyte@angband.pl>
To: Chao Yu <yuchao0@huawei.com>
Cc: 955549@bugs.debian.org, linux-f2fs-devel@lists.sourceforge.net
Subject: Re: [f2fs-dev] Bug#955549: f2fs-tools: fsck.f2fs segfaults
Date: Fri, 10 Apr 2020 01:32:55 +0200	[thread overview]
Message-ID: <20200409233255.GA14286@angband.pl> (raw)
In-Reply-To: <45149351-4c07-ba55-dec3-9a0872bb159f@huawei.com>

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:

Program received signal SIGSEGV, Segmentation fault.
0x0000555555564444 in print_inode_info (sbi=0x555555584ca0 <gfsck>, node=0x55555558f170, name=<optimized out>) 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 <gfsck>, node=0x55555558f170, name=<optimized out>) at mount.c:240
#1  0x0000555555564c4e in print_node_info (sbi=<optimized out>, node_block=<optimized out>, verbose=<optimized out>) at mount.c:278
#2  0x000055555556317f in dump_node (sbi=sbi@entry=0x555555584ca0 <gfsck>, nid=nid@entry=2861, force=force@entry=1) at dump.c:511
#3  0x0000555555561060 in fsck_verify (sbi=0x555555584ca0 <gfsck>) at fsck.c:3259
#4  0x000055555555799a in do_fsck (sbi=0x555555584ca0 <gfsck>) at main.c:698
#5  main (argc=<optimized out>, argv=<optimized out>) at main.c:864

> 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=<optimized out>) at fsck.c:1132
> >>>> #2  0x0000555555562286 in print_inode_info (sbi=0x55555557db20 <gfsck>, node=0x5555556075b0, name=1) at mount.c:183
> >>>> #3  0x0000555555562a46 in print_node_info (sbi=<optimized out>, node_block=<optimized out>, verbose=<optimized out>) at mount.c:277
> >>>> #4  0x0000555555560d3f in dump_node (sbi=sbi@entry=0x55555557db20 <gfsck>, nid=nid@entry=24274, force=force@entry=1) at dump.c:520
> >>>> #5  0x000055555555e94c in fsck_verify (sbi=0x55555557db20 <gfsck>) at fsck.c:2568
> >>>> #6  0x000055555555699b in do_fsck (sbi=0x55555557db20 <gfsck>) at main.c:569


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good.
⢿⡄⠘⠷⠚⠋⠀                                       -- <willmore> on #linux-sunxi
⠈⠳⣄⠀⠀⠀⠀


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

  reply	other threads:[~2020-04-09 23:33 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <158582888648.9053.2167684001695943018.reportbug@umbar.angband.pl>
2020-04-02 19:16 ` [f2fs-dev] Bug#955549: f2fs-tools: fsck.f2fs segfaults Theodore Y. Ts'o
2020-04-03  2:45   ` Adam Borowski
2020-04-03  6:37     ` Chao Yu
2020-04-07 10:22       ` Chao Yu
2020-04-09 23:32         ` Adam Borowski [this message]
2020-04-15  3:28           ` Chao Yu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200409233255.GA14286@angband.pl \
    --to=kilobyte@angband.pl \
    --cc=955549@bugs.debian.org \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    --cc=yuchao0@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).