linux-f2fs-devel.lists.sourceforge.net archive mirror
 help / color / mirror / Atom feed
* Re: [f2fs-dev] Bug#955549: f2fs-tools: fsck.f2fs segfaults
       [not found] <158582888648.9053.2167684001695943018.reportbug@umbar.angband.pl>
@ 2020-04-02 19:16 ` Theodore Y. Ts'o
  2020-04-03  2:45   ` Adam Borowski
  0 siblings, 1 reply; 6+ messages in thread
From: Theodore Y. Ts'o @ 2020-04-02 19:16 UTC (permalink / raw)
  To: Adam Borowski, 955549; +Cc: linux-f2fs-devel

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
> warning: Source file is more recent than executable.
> 34	  return __builtin___memcpy_chk (__dest, __src, __len, __bos0 (__dest));
> (gdb) bt
> #0  0x00005555555593ec in memcpy (__len=18446744073323892736, __src=0x55555560760c, __dest=0x7fffffffe000) at /usr/include/x86_64-linux-gnu/bits/string_fortified.h:34
> #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
> #7  main (argc=<optimized out>, argv=<optimized out>) at main.c:726
> 
> 
> I tried building current upstream git, also segfaults.
> 
> 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?

						- Ted


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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [f2fs-dev] Bug#955549: f2fs-tools: fsck.f2fs segfaults
  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
  0 siblings, 1 reply; 6+ messages in thread
From: Adam Borowski @ 2020-04-03  2:45 UTC (permalink / raw)
  To: Theodore Y. Ts'o; +Cc: 955549, linux-f2fs-devel

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
> > #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.

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!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ 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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [f2fs-dev] Bug#955549: f2fs-tools: fsck.f2fs segfaults
  2020-04-03  2:45   ` Adam Borowski
@ 2020-04-03  6:37     ` Chao Yu
  2020-04-07 10:22       ` Chao Yu
  0 siblings, 1 reply; 6+ messages in thread
From: Chao Yu @ 2020-04-03  6:37 UTC (permalink / raw)
  To: Adam Borowski, Theodore Y. Ts'o; +Cc: 955549, linux-f2fs-devel

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 (chao@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-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [f2fs-dev] Bug#955549: f2fs-tools: fsck.f2fs segfaults
  2020-04-03  6:37     ` Chao Yu
@ 2020-04-07 10:22       ` Chao Yu
  2020-04-09 23:32         ` Adam Borowski
  0 siblings, 1 reply; 6+ messages in thread
From: Chao Yu @ 2020-04-07 10:22 UTC (permalink / raw)
  To: Adam Borowski, Theodore Y. Ts'o; +Cc: 955549, linux-f2fs-devel

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 (chao@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-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
> .
> 


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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [f2fs-dev] Bug#955549: f2fs-tools: fsck.f2fs segfaults
  2020-04-07 10:22       ` Chao Yu
@ 2020-04-09 23:32         ` Adam Borowski
  2020-04-15  3:28           ` Chao Yu
  0 siblings, 1 reply; 6+ messages in thread
From: Adam Borowski @ 2020-04-09 23:32 UTC (permalink / raw)
  To: Chao Yu; +Cc: 955549, linux-f2fs-devel

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [f2fs-dev] Bug#955549: f2fs-tools: fsck.f2fs segfaults
  2020-04-09 23:32         ` Adam Borowski
@ 2020-04-15  3:28           ` Chao Yu
  0 siblings, 0 replies; 6+ messages in thread
From: Chao Yu @ 2020-04-15  3:28 UTC (permalink / raw)
  To: Adam Borowski; +Cc: 955549, linux-f2fs-devel

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 <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

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=<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!
> 


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

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2020-04-15  3:29 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [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
2020-04-15  3:28           ` Chao Yu

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).