Hi Adam,
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
With this patch, image can be fixed and mounted later, although, most of files
were deleted due to seriously damaged f2fs metadata....
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
Let me know if you have problem with above patches.
Thanks,
On 2020/4/3 14:37, Chao Yu wrote:
> Thanks for forwarding, Ted.
>
> On 2020/4/3 10:45, Adam Borowski wrote:
>> On Thu, Apr 02, 2020 at 03:16:58PM -0400, Theodore Y. Ts'o wrote:
>>> On Thu, Apr 02, 2020 at 02:01:26PM +0200, Adam Borowski wrote:
>>>>
>>>> After a lot of output on a damaged filesystem (SD card copied to an image)
>>>> fsck.f2fs dies with:
>>>>
>>>> - File name : mkfs.ext3.dpkg-new
>>>> - File size : 6 (bytes)
>>>>
>>>> Program received signal SIGSEGV, Segmentation fault.
>>>> 0x00005555555593ec in memcpy (__len=18446744073323892736,
>>>> __src=0x55555560760c, __dest=0x7fffffffe000) at
>>>> /usr/include/x86_64-linux-gnu/bits/string_fortified.h:34
>>>> 34 return __builtin___memcpy_chk (__dest, __src, __len, __bos0 (__dest));
>>
>>>> #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
>>
>>>> I have a copy of the filesystem in question from before any repair
>>>> attempts.
>>>> It has no sensitive data on it, thus I can share if needed -- 14GB.
>>>
>>> Thanks for the bug report. Can you make the file system image
>>> available somehow? Maybe for download at some URL? How well does it
>>> compress?
>>
>> 916MB -- https://angband.pl/rigel.f2fs.xz.gpg
>> The machine serves as a serial console logger/management for a bunch of
>> boxes; a root session is unlikely to have anything I'd not share with
>> developers but is not something to release to the wide world. Thus, I
>> symetrically encrypted the image, I'll send you the password privately --
>> feel free to share it with anyone semi-trusted.
>
> Would you mind sharing the password with me (c...@kernel.org)? I guess
> I can take a look at this issue.
>
> Thanks,
>
>>
>> The filesystem was on a SD card, with very light use (append), no issues,
>> ran kernel 4.13 until 9 days ago -- then I've upgraded to 5.5.11 with no
>> other changes. The corruption is probably caused by that, but there's
>> always a chance of SD being SD.
>>
>>
>> Meow!
>>
>
>
> _______________________________________________
> Linux-f2fs-devel mailing list
> linux-f2fs-de...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
> .
>
