Segfault in fsck.reiser4

Segfault in fsck.reiser4

[Jonáš Vidra]

Hello!

I found a bug in fsck.reiser4 from reiser4progs-1.0.7. It segfaults when I  
try to check my storage partition.
The FS is currently mounted read-only, as I need the data and I don't have  
a spare disk.
I haven't noticed any other problems so far, the fsck was just a weekly  
check.

I recompiled reiser4progs with debug statements and made a backtrace,
but I'm not skilled in these things, so let me know if additional info is  
needed.
I've also packed the filesystem metadata, I can post them somewhere if you  
want.

By the way, how do I find a filename by node number or key? Debugfs allows  
me to search for nodes when I type a filename, but not vice versa.
I'd like to know which file caused the corruption.

The output from GDB is below.


(gdb) run
Starting program: /sbin/fsck.reiser4 /dev/sda7
*******************************************************************
This is an EXPERIMENTAL version of fsck.reiser4. Read README first.
*******************************************************************

Fscking the /dev/sda7 block device.
Will check the consistency of the Reiser4 SuperBlock.
Will check the consistency of the Reiser4 FileSystem.
Continue?
(Yes/No): y
***** fsck.reiser4 started at Tue Mar 23 16:32:33 2010
Reiser4 fs was detected on /dev/sda7.
Master super block (16):
magic:          ReIsEr4
blksize:        4096
format:         0x0 (format40)
uuid:           7e3c26ff-e382-4f6f-9686-ca06ff31c615
label:          data

Format super block (17):
plugin:         format40
description:    Disk-format plugin.
version:        0
magic:          ReIsEr40FoRmAt
mkfs id:        0x7c89491a
flushes:        0
blocks:         47640736
free blocks:    9067517
root block:     36345512
tail policy:    0x2 (smart)
next oid:       0x64883
file count:     6842
tree height:    5
key policy:     LARGE


CHECKING THE STORAGE TREE
         Read nodes 3394397
         Nodes left in the tree 3394397
                 Leaves of them 3354276, Twigs of them 39373
         Time interval: Tue Mar 23 16:32:53 2010 - Tue Mar 23 16:46:58 2010
CHECKING EXTENT REGIONS.
FSCK: extent40_repair.c: 96: extent40_check_layout: Node (36296453), item  
(31), unit (7), [64744:4(FB):4d4f563042422e:6487d:0]: points to the  
already used blocks,  region [38491215..38497535].
FSCK: extent40_repair.c: 96: extent40_check_layout: Node (36296453), item  
(35), unit (0), [64744:4(FB):4d4f563042442e:64881:0]: points to the  
already used blocks,  region [32036064..32036064].
FSCK: extent40_repair.c: 96: extent40_check_layout: Node (36296453), item  
(35), unit (1), [64744:4(FB):4d4f563042442e:64881:0]: points to the  
already used blocks,  region [36296457..36296457].
FSCK: extent40_repair.c: 96: extent40_check_layout: Node (36296453), item  
(35), unit (2), [64744:4(FB):4d4f563042442e:64881:0]: points to the  
already used blocks,  region [36345512..36345512].
FSCK: extent40_repair.c: 96: extent40_check_layout: Node (36296453), item  
(35), unit (3), [64744:4(FB):4d4f563042442e:64881:0]: points to the  
already used blocks,  region [36425556..36425556].
FSCK: extent40_repair.c: 96: extent40_check_layout: Node (36296453), item  
(35), unit (4), [64744:4(FB):4d4f563042442e:64881:0]: points to the  
already used blocks,  region [38293910..38293910].
         Read twigs 39373
         Invaid extent pointers 6
         Time interval: Tue Mar 23 16:46:58 2010 - Tue Mar 23 16:50:25 2010
CHECKING THE SEMANTIC TREE
FSCK: ccreg40_repair.c: 77: ccreg40_check_item: The file  
[64744:4d4f563042442e:64882] (ccreg40), node [38551031], item [0]: item of  
the wrong cluster size (-2147483648) found, Should be (65536).

Program received signal SIGSEGV, Segmentation fault.
0xb7f6f7d2 in aux_adler32 (adler=<value optimized out>, buff=0xbffe22ca  
"", n=4294839597) at aux.c:194

(gdb) bt
#0  0xb7f6f7d2 in aux_adler32 (adler=<value optimized out>,  
buff=0xbffe22ca "", n=4294839597) at aux.c:194
#1  0xb7f9ceb2 in ccreg40_check_crc (cc=0x8edf5f0, func=0,  
data=0xbfffeb1c, mode=1 '\001') at ccreg40_repair.c:130
#2  ccreg40_check_cluster (cc=0x8edf5f0, func=0, data=0xbfffeb1c, mode=1  
'\001') at ccreg40_repair.c:174
#3  ccreg40_check_struct (cc=0x8edf5f0, func=0, data=0xbfffeb1c, mode=1  
'\001') at ccreg40_repair.c:271
#4  0xb7f34a4a in repair_object_check_struct (object=0x8edf5f0,  
place_func=0, mode=<value optimized out>, data=0xbfffeb1c) at object.c:19
#5  0xb7f391ab in repair_semantic_check_struct (sem=0xbfffeb1c,  
object=0x8edf5f0) at semantic.c:68
#6  0xb7f3ae26 in cb_object_traverse (parent=0x8e5ef40, entry=0xbfff4410,  
data=0xbfffeb1c) at semantic.c:352
#7  0xb7f6791d in reiser4_object_traverse (object=0x8e5ef40,  
open_func=0xb7f3abb7 <cb_object_traverse>, data=0xbfffeb1c) at object.c:723
#8  0xb7f67959 in reiser4_object_traverse (object=0x8e614a0,  
open_func=0xb7f3abb7 <cb_object_traverse>, data=0xbfffeb1c) at object.c:731
#9  0xb7f67959 in reiser4_object_traverse (object=0x8e5baf0,  
open_func=0xb7f3abb7 <cb_object_traverse>, data=0xbfffeb1c) at object.c:731
#10 0xb7f67959 in reiser4_object_traverse (object=0x8e479e0,  
open_func=0xb7f3abb7 <cb_object_traverse>, data=0xbfffeb1c) at object.c:731
#11 0xb7f67959 in reiser4_object_traverse (object=0x80628e0,  
open_func=0xb7f3abb7 <cb_object_traverse>, data=0xbfffeb1c) at object.c:731
#12 0xb7f3a202 in repair_semantic (sem=0xbfffeb1c) at semantic.c:845
#13 0xb7f3cee8 in repair_check (repair=0xbfffee04) at repair.c:799
#14 0x0804b242 in main (argc=2, argv=Cannot access memory at address 0x8608
) at fsck.c:566


-- 
Jonáš Vidra
--
To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Segfault in fsck.reiser4

[Edward Shishkin]

Jonáš Vidra wrote:
> Hello!

Hello.

>
> I found a bug in fsck.reiser4 from reiser4progs-1.0.7. It segfaults 
> when I try to check my storage partition.
> The FS is currently mounted read-only, as I need the data and I don't 
> have a spare disk.
> I haven't noticed any other problems so far, the fsck was just a 
> weekly check.
>
> I recompiled reiser4progs with debug statements and made a backtrace,
> but I'm not skilled in these things, so let me know if additional info 
> is needed.
> I've also packed the filesystem metadata, I can post them somewhere if 
> you want.

Packed metadata won't help in this case.

The most efficient way is to provide me with a root access to your machine.
You have encountered a rare case of corruption, and it is important to 
fix this
fsck bug properly.

>
> By the way, how do I find a filename by node number or key?

find - inum 64881

> Debugfs allows me to search for nodes when I type a filename, but not 
> vice versa.
> I'd like to know which file caused the corruption.

What do you want to do with this file?

Thanks,
Edward.

>
> The output from GDB is below.
>
>
> (gdb) run
> Starting program: /sbin/fsck.reiser4 /dev/sda7
> *******************************************************************
> This is an EXPERIMENTAL version of fsck.reiser4. Read README first.
> *******************************************************************
>
> Fscking the /dev/sda7 block device.
> Will check the consistency of the Reiser4 SuperBlock.
> Will check the consistency of the Reiser4 FileSystem.
> Continue?
> (Yes/No): y
> ***** fsck.reiser4 started at Tue Mar 23 16:32:33 2010
> Reiser4 fs was detected on /dev/sda7.
> Master super block (16):
> magic:          ReIsEr4
> blksize:        4096
> format:         0x0 (format40)
> uuid:           7e3c26ff-e382-4f6f-9686-ca06ff31c615
> label:          data
>
> Format super block (17):
> plugin:         format40
> description:    Disk-format plugin.
> version:        0
> magic:          ReIsEr40FoRmAt
> mkfs id:        0x7c89491a
> flushes:        0
> blocks:         47640736
> free blocks:    9067517
> root block:     36345512
> tail policy:    0x2 (smart)
> next oid:       0x64883
> file count:     6842
> tree height:    5
> key policy:     LARGE
>
>
> CHECKING THE STORAGE TREE
>         Read nodes 3394397
>         Nodes left in the tree 3394397
>                 Leaves of them 3354276, Twigs of them 39373
>         Time interval: Tue Mar 23 16:32:53 2010 - Tue Mar 23 16:46:58 
> 2010
> CHECKING EXTENT REGIONS.
> FSCK: extent40_repair.c: 96: extent40_check_layout: Node (36296453), 
> item (31), unit (7), [64744:4(FB):4d4f563042422e:6487d:0]: points to 
> the already used blocks,  region [38491215..38497535].
> FSCK: extent40_repair.c: 96: extent40_check_layout: Node (36296453), 
> item (35), unit (0), [64744:4(FB):4d4f563042442e:64881:0]: points to 
> the already used blocks,  region [32036064..32036064].
> FSCK: extent40_repair.c: 96: extent40_check_layout: Node (36296453), 
> item (35), unit (1), [64744:4(FB):4d4f563042442e:64881:0]: points to 
> the already used blocks,  region [36296457..36296457].
> FSCK: extent40_repair.c: 96: extent40_check_layout: Node (36296453), 
> item (35), unit (2), [64744:4(FB):4d4f563042442e:64881:0]: points to 
> the already used blocks,  region [36345512..36345512].
> FSCK: extent40_repair.c: 96: extent40_check_layout: Node (36296453), 
> item (35), unit (3), [64744:4(FB):4d4f563042442e:64881:0]: points to 
> the already used blocks,  region [36425556..36425556].
> FSCK: extent40_repair.c: 96: extent40_check_layout: Node (36296453), 
> item (35), unit (4), [64744:4(FB):4d4f563042442e:64881:0]: points to 
> the already used blocks,  region [38293910..38293910].
>         Read twigs 39373
>         Invaid extent pointers 6
>         Time interval: Tue Mar 23 16:46:58 2010 - Tue Mar 23 16:50:25 
> 2010
> CHECKING THE SEMANTIC TREE
> FSCK: ccreg40_repair.c: 77: ccreg40_check_item: The file 
> [64744:4d4f563042442e:64882] (ccreg40), node [38551031], item [0]: 
> item of the wrong cluster size (-2147483648) found, Should be (65536).
>
> Program received signal SIGSEGV, Segmentation fault.
> 0xb7f6f7d2 in aux_adler32 (adler=<value optimized out>, 
> buff=0xbffe22ca "", n=4294839597) at aux.c:194
>
> (gdb) bt
> #0  0xb7f6f7d2 in aux_adler32 (adler=<value optimized out>, 
> buff=0xbffe22ca "", n=4294839597) at aux.c:194
> #1  0xb7f9ceb2 in ccreg40_check_crc (cc=0x8edf5f0, func=0, 
> data=0xbfffeb1c, mode=1 '\001') at ccreg40_repair.c:130
> #2  ccreg40_check_cluster (cc=0x8edf5f0, func=0, data=0xbfffeb1c, 
> mode=1 '\001') at ccreg40_repair.c:174
> #3  ccreg40_check_struct (cc=0x8edf5f0, func=0, data=0xbfffeb1c, 
> mode=1 '\001') at ccreg40_repair.c:271
> #4  0xb7f34a4a in repair_object_check_struct (object=0x8edf5f0, 
> place_func=0, mode=<value optimized out>, data=0xbfffeb1c) at object.c:19
> #5  0xb7f391ab in repair_semantic_check_struct (sem=0xbfffeb1c, 
> object=0x8edf5f0) at semantic.c:68
> #6  0xb7f3ae26 in cb_object_traverse (parent=0x8e5ef40, 
> entry=0xbfff4410, data=0xbfffeb1c) at semantic.c:352
> #7  0xb7f6791d in reiser4_object_traverse (object=0x8e5ef40, 
> open_func=0xb7f3abb7 <cb_object_traverse>, data=0xbfffeb1c) at 
> object.c:723
> #8  0xb7f67959 in reiser4_object_traverse (object=0x8e614a0, 
> open_func=0xb7f3abb7 <cb_object_traverse>, data=0xbfffeb1c) at 
> object.c:731
> #9  0xb7f67959 in reiser4_object_traverse (object=0x8e5baf0, 
> open_func=0xb7f3abb7 <cb_object_traverse>, data=0xbfffeb1c) at 
> object.c:731
> #10 0xb7f67959 in reiser4_object_traverse (object=0x8e479e0, 
> open_func=0xb7f3abb7 <cb_object_traverse>, data=0xbfffeb1c) at 
> object.c:731
> #11 0xb7f67959 in reiser4_object_traverse (object=0x80628e0, 
> open_func=0xb7f3abb7 <cb_object_traverse>, data=0xbfffeb1c) at 
> object.c:731
> #12 0xb7f3a202 in repair_semantic (sem=0xbfffeb1c) at semantic.c:845
> #13 0xb7f3cee8 in repair_check (repair=0xbfffee04) at repair.c:799
> #14 0x0804b242 in main (argc=2, argv=Cannot access memory at address 
> 0x8608
> ) at fsck.c:566
>
>

--
To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Segfault in fsck.reiser4

[Edward Shishkin]

Edward Shishkin wrote:
> Jonáš Vidra wrote:
>> Hello!
>
> Hello.
>
>>
>> I found a bug in fsck.reiser4 from reiser4progs-1.0.7. It segfaults 
>> when I try to check my storage partition.
>> The FS is currently mounted read-only, as I need the data and I don't 
>> have a spare disk.
>> I haven't noticed any other problems so far, the fsck was just a 
>> weekly check.
>>
>> I recompiled reiser4progs with debug statements and made a backtrace,
>> but I'm not skilled in these things, so let me know if additional 
>> info is needed.
>> I've also packed the filesystem metadata, I can post them somewhere 
>> if you want.
>
> Packed metadata won't help in this case.
>
> The most efficient way is to provide me with a root access to your 
> machine.
> You have encountered a rare case of corruption, and it is important to 
> fix this
> fsck bug properly.
>
>>
>> By the way, how do I find a filename by node number or key?
>
> find - inum 64881

oops, I was wrong:  the inode number of the corrupted file is 64882
in accordance with this fsck message:

FSCK: ccreg40_repair.c: 77: ccreg40_check_item: The file 
[64744:4d4f563042442e:64882] (ccreg40), node [38551031], item [0]: item 
of the wrong cluster size (-2147483648) found, Should be (65536).

>
>
>> Debugfs allows me to search for nodes when I type a filename, but not 
>> vice versa.
>> I'd like to know which file caused the corruption.
>
> What do you want to do with this file?
>
> Thanks,
> Edward.
>
>>
>> The output from GDB is below.
>>
>>
>> (gdb) run
>> Starting program: /sbin/fsck.reiser4 /dev/sda7
>> *******************************************************************
>> This is an EXPERIMENTAL version of fsck.reiser4. Read README first.
>> *******************************************************************
>>
>> Fscking the /dev/sda7 block device.
>> Will check the consistency of the Reiser4 SuperBlock.
>> Will check the consistency of the Reiser4 FileSystem.
>> Continue?
>> (Yes/No): y
>> ***** fsck.reiser4 started at Tue Mar 23 16:32:33 2010
>> Reiser4 fs was detected on /dev/sda7.
>> Master super block (16):
>> magic:          ReIsEr4
>> blksize:        4096
>> format:         0x0 (format40)
>> uuid:           7e3c26ff-e382-4f6f-9686-ca06ff31c615
>> label:          data
>>
>> Format super block (17):
>> plugin:         format40
>> description:    Disk-format plugin.
>> version:        0
>> magic:          ReIsEr40FoRmAt
>> mkfs id:        0x7c89491a
>> flushes:        0
>> blocks:         47640736
>> free blocks:    9067517
>> root block:     36345512
>> tail policy:    0x2 (smart)
>> next oid:       0x64883
>> file count:     6842
>> tree height:    5
>> key policy:     LARGE
>>
>>
>> CHECKING THE STORAGE TREE
>>         Read nodes 3394397
>>         Nodes left in the tree 3394397
>>                 Leaves of them 3354276, Twigs of them 39373
>>         Time interval: Tue Mar 23 16:32:53 2010 - Tue Mar 23 16:46:58 
>> 2010
>> CHECKING EXTENT REGIONS.
>> FSCK: extent40_repair.c: 96: extent40_check_layout: Node (36296453), 
>> item (31), unit (7), [64744:4(FB):4d4f563042422e:6487d:0]: points to 
>> the already used blocks,  region [38491215..38497535].
>> FSCK: extent40_repair.c: 96: extent40_check_layout: Node (36296453), 
>> item (35), unit (0), [64744:4(FB):4d4f563042442e:64881:0]: points to 
>> the already used blocks,  region [32036064..32036064].
>> FSCK: extent40_repair.c: 96: extent40_check_layout: Node (36296453), 
>> item (35), unit (1), [64744:4(FB):4d4f563042442e:64881:0]: points to 
>> the already used blocks,  region [36296457..36296457].
>> FSCK: extent40_repair.c: 96: extent40_check_layout: Node (36296453), 
>> item (35), unit (2), [64744:4(FB):4d4f563042442e:64881:0]: points to 
>> the already used blocks,  region [36345512..36345512].
>> FSCK: extent40_repair.c: 96: extent40_check_layout: Node (36296453), 
>> item (35), unit (3), [64744:4(FB):4d4f563042442e:64881:0]: points to 
>> the already used blocks,  region [36425556..36425556].
>> FSCK: extent40_repair.c: 96: extent40_check_layout: Node (36296453), 
>> item (35), unit (4), [64744:4(FB):4d4f563042442e:64881:0]: points to 
>> the already used blocks,  region [38293910..38293910].
>>         Read twigs 39373
>>         Invaid extent pointers 6
>>         Time interval: Tue Mar 23 16:46:58 2010 - Tue Mar 23 16:50:25 
>> 2010
>> CHECKING THE SEMANTIC TREE
>> FSCK: ccreg40_repair.c: 77: ccreg40_check_item: The file 
>> [64744:4d4f563042442e:64882] (ccreg40), node [38551031], item [0]: 
>> item of the wrong cluster size (-2147483648) found, Should be (65536).
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> 0xb7f6f7d2 in aux_adler32 (adler=<value optimized out>, 
>> buff=0xbffe22ca "", n=4294839597) at aux.c:194
>>
>> (gdb) bt
>> #0  0xb7f6f7d2 in aux_adler32 (adler=<value optimized out>, 
>> buff=0xbffe22ca "", n=4294839597) at aux.c:194
>> #1  0xb7f9ceb2 in ccreg40_check_crc (cc=0x8edf5f0, func=0, 
>> data=0xbfffeb1c, mode=1 '\001') at ccreg40_repair.c:130
>> #2  ccreg40_check_cluster (cc=0x8edf5f0, func=0, data=0xbfffeb1c, 
>> mode=1 '\001') at ccreg40_repair.c:174
>> #3  ccreg40_check_struct (cc=0x8edf5f0, func=0, data=0xbfffeb1c, 
>> mode=1 '\001') at ccreg40_repair.c:271
>> #4  0xb7f34a4a in repair_object_check_struct (object=0x8edf5f0, 
>> place_func=0, mode=<value optimized out>, data=0xbfffeb1c) at 
>> object.c:19
>> #5  0xb7f391ab in repair_semantic_check_struct (sem=0xbfffeb1c, 
>> object=0x8edf5f0) at semantic.c:68
>> #6  0xb7f3ae26 in cb_object_traverse (parent=0x8e5ef40, 
>> entry=0xbfff4410, data=0xbfffeb1c) at semantic.c:352
>> #7  0xb7f6791d in reiser4_object_traverse (object=0x8e5ef40, 
>> open_func=0xb7f3abb7 <cb_object_traverse>, data=0xbfffeb1c) at 
>> object.c:723
>> #8  0xb7f67959 in reiser4_object_traverse (object=0x8e614a0, 
>> open_func=0xb7f3abb7 <cb_object_traverse>, data=0xbfffeb1c) at 
>> object.c:731
>> #9  0xb7f67959 in reiser4_object_traverse (object=0x8e5baf0, 
>> open_func=0xb7f3abb7 <cb_object_traverse>, data=0xbfffeb1c) at 
>> object.c:731
>> #10 0xb7f67959 in reiser4_object_traverse (object=0x8e479e0, 
>> open_func=0xb7f3abb7 <cb_object_traverse>, data=0xbfffeb1c) at 
>> object.c:731
>> #11 0xb7f67959 in reiser4_object_traverse (object=0x80628e0, 
>> open_func=0xb7f3abb7 <cb_object_traverse>, data=0xbfffeb1c) at 
>> object.c:731
>> #12 0xb7f3a202 in repair_semantic (sem=0xbfffeb1c) at semantic.c:845
>> #13 0xb7f3cee8 in repair_check (repair=0xbfffee04) at repair.c:799
>> #14 0x0804b242 in main (argc=2, argv=Cannot access memory at address 
>> 0x8608
>> ) at fsck.c:566
>>
>>
>
>

--
To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Segfault in fsck.reiser4

[Jonáš Vidra]

Dne Tue, 23 Mar 2010 21:26:53 +0100 Edward Shishkin  
<edward.shishkin@gmail.com> napsal(a):

> The most efficient way is to provide me with a root access to your  
> machine.
> You have encountered a rare case of corruption, and it is important to  
> fix this fsck bug properly.

Well …
I don't think that would be possible, but I'll see what I can do.
Several users have accounts on the machine, so even though they are just
family members, not corporate customers, I can't allow everyone in.
I'd like to help, so I'll try to arrange it somehow.


>> By the way, how do I find a filename by node number or key?
>
> find - inum 64881

Thanks. That's straightforward, shame on me for asking stupid questions.


>> I'd like to know which file caused the corruption.
>
> What do you want to do with this file?

I'd like to know if it is backed up somewhere, unique
or downloaded from the Internet or whatever.
I know I can't really trust *any* data on this partition anymore,
but I'd still like to know which files are the most likely to be lost.

-- 
Jonáš Vidra
--
To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Segfault in fsck.reiser4

[Edward Shishkin]

Jonáš Vidra wrote:
> Dne Tue, 23 Mar 2010 21:26:53 +0100 Edward Shishkin 
> <edward.shishkin@gmail.com> napsal(a):
>
>> The most efficient way is to provide me with a root access to your 
>> machine.
>> You have encountered a rare case of corruption, and it is important 
>> to fix this fsck bug properly.
>
> Well …
> I don't think that would be possible, but I'll see what I can do.

Segfault is caused by aux_adler32: offset (4294839597) is out of bounds..
Could you print and show us the structure "hint"?


> Several users have accounts on the machine, so even though they are just
> family members, not corporate customers, I can't allow everyone in.
> I'd like to help, so I'll try to arrange it somehow.
>
>
>>> By the way, how do I find a filename by node number or key?
>>
>> find - inum 64881
>
> Thanks. That's straightforward, shame on me for asking stupid questions.
>
>
>>> I'd like to know which file caused the corruption.
>>
>> What do you want to do with this file?
>
> I'd like to know if it is backed up somewhere, unique
> or downloaded from the Internet or whatever.
> I know I can't really trust *any* data on this partition anymore,
> but I'd still like to know which files are the most likely to be lost.
--
To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Segfault in fsck.reiser4

[Vidra.Jonas]

Dne Tue, 23 Mar 2010 23:31:48 +0100 Edward Shishkin <edward.shishkin@gmail.com> napsal(a):

> Segfault is caused by aux_adler32: offset (4294839597) is out of bounds..
> Could you print and show us the structure "hint"?

(gdb) print hint
No symbol "hint" in current context.

Am I doing it right or should I set a breakpoint somewhere before the crash?


-- 
Joná¹ Vidra, vidra.jonas@seznam.cz
--
To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Segfault in fsck.reiser4

[Edward Shishkin]

Vidra.Jonas@seznam.cz wrote:
> Dne Tue, 23 Mar 2010 23:31:48 +0100 Edward Shishkin 
> <edward.shishkin@gmail.com> napsal(a):
>
>> Segfault is caused by aux_adler32: offset (4294839597) is out of 
>> bounds..
>> Could you print and show us the structure "hint"?
>
> (gdb) print hint
> No symbol "hint" in current context.

try to jump several levels up: the function ccreg40_check_cluster
has an argument ccreg40_hint_t *hint, it shouldn't be optimized.

>
> Am I doing it right or should I set a breakpoint somewhere before the 
> crash?

Re: Segfault in fsck.reiser4

[Jonáš Vidra]

Dne Wed, 24 Mar 2010 14:10:26 +0100 Edward Shishkin
<edward.shishkin@gmail.com> napsal(a):

> try to jump several levels up: the function ccreg40_check_cluster
> has an argument ccreg40_hint_t *hint, it shouldn't be optimized.

I'm working on it, but gdb is so slow and it needs constant attention,
so it'll take a while.
I'm not very skilled at this and I don't have much time.

But I've got other news: I found a file that causes an oops when read.
I was just tarring up everything that might still be left on the FS
when it happened. The FS is still readonly, I haven't umounted it yet.

The oops is probably not very useful, but here you are anyway:

Mar 27 01:55:01 [kernel] Kernel BUG at c10e0681 [verbose debug info  
unavailable]
Mar 27 01:55:01 [kernel] Modules linked in: af_packet sco rfcomm bnep
l2cap crc16 acpi_cpufreq cpufreq_conservative cpufreq_powersave
cpufreq_userspace snd_hda_codec_realtek btusb snd_hda_intel bluetooth
snd_hda_codec snd_hwdep psb ath9k snd_pcm drm_psb uvcvideo snd_timer
mac80211 agpgart snd videodev v4l1_compat video ath rtc_cmos processor
soundcore backlight thermal rtc_core cfg80211 ehci_hcd output evdev
battery button ac rtc_lib uhci_hcd i2c_isch i2c_algo_bit snd_page_alloc
thermal_sys usbcore rfkill i2c_core atl1c hwmon unix
Mar 27 01:55:01 [kernel] Pid: 10097, comm: tar Not tainted  
(2.6.32-gentoo-r5 #1) 1101HA
Mar 27 01:55:01 [kernel] EIP: 0060:[<c10e0681>] EFLAGS: 00010246 CPU: 0
Mar 27 01:55:01 [kernel] EIP is at do_readpage_ctail+0x2a1/0x367
Mar 27 01:55:01 [kernel] EAX: 00000000 EBX: 00000002 ECX: c1906880 EDX:  
c00122b4
Mar 27 01:55:01 [kernel] ESI: 00000000 EDI: e573fcf0 EBP: e573fc94 ESP:  
e573fc74
Mar 27 01:55:01 [kernel]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
Mar 27 01:55:01 [kernel]  00000000 c1906880 c00122b4 0000040f 00000000  
00000000 e573fcf0 c1906880
Mar 27 01:55:01 [kernel] <0> e573fcbc c10e0890 00000001 c1906880 00000000  
c00122b4 00000000 c1906880
Mar 27 01:55:01 [kernel] <0> e573fdb0 c0012360 e573fcd8 c105d02f e6febd90  
c10e0747 00000010 c0012360
Mar 27 01:55:01 [kernel]  [<c10e0890>] ? ctail_readpages_filler+0x149/0x195
Mar 27 01:55:01 [kernel]  [<c105d02f>] ? read_cache_pages+0x6d/0xca
Mar 27 01:55:01 [kernel]  [<c10e0747>] ? ctail_readpages_filler+0x0/0x195
Mar 27 01:55:01 [kernel]  [<c10e03d7>] ? readpages_ctail+0x29f/0x2a8
Mar 27 01:55:01 [kernel]  [<c10d4030>] ? readpages_cryptcompress+0x36/0x5b
Mar 27 01:55:01 [kernel]  [<c10c82d3>] ? reiser4_readpages+0x26/0x2e
Mar 27 01:55:01 [kernel]  [<c10c82ad>] ? reiser4_readpages+0x0/0x2e
Mar 27 01:55:01 [kernel]  [<c105cc54>] ?  
__do_page_cache_readahead+0xeb/0x160
Mar 27 01:55:01 [kernel]  [<c105cce0>] ? ra_submit+0x17/0x1c
Mar 27 01:55:01 [kernel]  [<c105cef6>] ? ondemand_readahead+0x161/0x16d
Mar 27 01:55:01 [kernel]  [<c105cf7a>] ?  
page_cache_sync_readahead+0x16/0x1b
Mar 27 01:55:01 [kernel]  [<c10580c7>] ? generic_file_aio_read+0x1fe/0x550
Mar 27 01:55:01 [kernel]  [<c107857b>] ? do_sync_read+0xab/0xe9
Mar 27 01:55:01 [kernel]  [<c10385c3>] ? autoremove_wake_function+0x0/0x33
Mar 27 01:55:01 [kernel]  [<c10d3d37>] ? read_cryptcompress+0x5f/0x7e
Mar 27 01:55:01 [kernel]  [<c10d2335>] ? reiser4_read_careful+0xa9/0xf1
Mar 27 01:55:01 [kernel]  [<c10d228c>] ? reiser4_read_careful+0x0/0xf1
Mar 27 01:55:01 [kernel]  [<c1078fa7>] ? vfs_read+0x87/0x118
Mar 27 01:55:01 [kernel]  [<c10790d1>] ? sys_read+0x3b/0x60
Mar 27 01:55:01 [kernel]  [<c1002b0f>] ? sysenter_do_call+0x12/0x26
Mar 27 01:55:01 [kernel] ---[ end trace 26ea3afca4e81c3e ]---


-- 
Jonáš Vidra
--
To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Segfault in fsck.reiser4

[Edward Shishkin]

[-- Attachment #1: Type: text/plain, Size: 1871 bytes --]

Jonáš Vidra wrote:

[...]
>
>
> The oops is probably not very useful, but here you are anyway:

This is very useful. The attached patch should fix this oops.
However, your partition remains inconsistent. I'll fix up fsck
a bit later..

Thanks,
Edward.

>
> Mar 27 01:55:01 [kernel] Kernel BUG at c10e0681 [verbose debug info
> unavailable]
[..]
> Mar 27 01:55:01 [kernel]  [<c10e0890>] ?
> ctail_readpages_filler+0x149/0x195
> Mar 27 01:55:01 [kernel]  [<c105d02f>] ? read_cache_pages+0x6d/0xca
> Mar 27 01:55:01 [kernel]  [<c10e0747>] ? ctail_readpages_filler+0x0/0x195
> Mar 27 01:55:01 [kernel]  [<c10e03d7>] ? readpages_ctail+0x29f/0x2a8
> Mar 27 01:55:01 [kernel]  [<c10d4030>] ?
> readpages_cryptcompress+0x36/0x5b
> Mar 27 01:55:01 [kernel]  [<c10c82d3>] ? reiser4_readpages+0x26/0x2e
> Mar 27 01:55:01 [kernel]  [<c10c82ad>] ? reiser4_readpages+0x0/0x2e
> Mar 27 01:55:01 [kernel]  [<c105cc54>] ?
> __do_page_cache_readahead+0xeb/0x160
> Mar 27 01:55:01 [kernel]  [<c105cce0>] ? ra_submit+0x17/0x1c
> Mar 27 01:55:01 [kernel]  [<c105cef6>] ? ondemand_readahead+0x161/0x16d
> Mar 27 01:55:01 [kernel]  [<c105cf7a>] ?
> page_cache_sync_readahead+0x16/0x1b
> Mar 27 01:55:01 [kernel]  [<c10580c7>] ?
> generic_file_aio_read+0x1fe/0x550
> Mar 27 01:55:01 [kernel]  [<c107857b>] ? do_sync_read+0xab/0xe9
> Mar 27 01:55:01 [kernel]  [<c10385c3>] ?
> autoremove_wake_function+0x0/0x33
> Mar 27 01:55:01 [kernel]  [<c10d3d37>] ? read_cryptcompress+0x5f/0x7e
> Mar 27 01:55:01 [kernel]  [<c10d2335>] ? reiser4_read_careful+0xa9/0xf1
> Mar 27 01:55:01 [kernel]  [<c10d228c>] ? reiser4_read_careful+0x0/0xf1
> Mar 27 01:55:01 [kernel]  [<c1078fa7>] ? vfs_read+0x87/0x118
> Mar 27 01:55:01 [kernel]  [<c10790d1>] ? sys_read+0x3b/0x60
> Mar 27 01:55:01 [kernel]  [<c1002b0f>] ? sysenter_do_call+0x12/0x26
> Mar 27 01:55:01 [kernel] ---[ end trace 26ea3afca4e81c3e ]---
>
>


[-- Attachment #2: reiser4-do_readpage_ctail-fixup.patch --]
[-- Type: text/x-patch, Size: 1162 bytes --]

Hanle the case of orphan unprepped disk cluster:
return EIO and suggest fsck the partition instead of BUG_ON(1).

Signed-off-by: Edward Shishkin <edward.shishkin@gmail.com>
---
 fs/reiser4/plugin/item/ctail.c |   14 +++++++++++---
 1 file changed, 11 insertions(+), 3 deletions(-)

--- linux-2.6.33-reiser4.orig/fs/reiser4/plugin/item/ctail.c
+++ linux-2.6.33-reiser4/fs/reiser4/plugin/item/ctail.c
@@ -649,9 +649,11 @@ int do_readpage_ctail(struct inode * ino
 		ret = ctail_read_disk_cluster(clust, inode, page, mode);
 
 		assert("edward-212", PageLocked(page));
-		if (ret)
+		if (ret) {
+			ClearPageUptodate(page);
+			SetPageError(page);
 			return ret;
-
+		}
 		/* refresh bytes */
 		to_page = pbytes(page_index(page), inode);
 		if (to_page == 0) {
@@ -669,7 +671,13 @@ int do_readpage_ctail(struct inode * ino
 
 	switch (clust->dstat) {
 	case UNPR_DISK_CLUSTER:
-		BUG_ON(1);
+		warning("edward-1563",
+			"orphan unprepped cluster %lu (inode %lli). Fsck?",
+			clust->index,
+			(unsigned long long)get_inode_oid(inode));
+		ClearPageUptodate(page);
+		SetPageError(page);
+		return -EIO;
 	case TRNC_DISK_CLUSTER:
 		/*
 		 * Race with truncate!