http://oss.sgi.com/bugzilla/show_bug.cgi?id=253
Summary: xfs_repair saegfaults while doing insecure memory-
operations
Product: Linux XFS
Version: Current
Platform: IA32
OS/Version: Linux
Status: NEW
Severity: major
Priority: Medium
Component: xfsprogs
AssignedTo: xfs-master@xxxxxxxxxxx
ReportedBy: sgi@xxxxxxxxxxxxxxxxx
Hi
I think I found a bug in xfs_repair. It saegfaults when I run it on a
filesystem which is a little bit corrupt. After I ran it with efence, I
got these backtraces. I think it cannot handle this block-out-of-range
condition correctly. I have attached all important informations.
Here is the output of xfs_check:
dir 128 block 0 entry /ost+found bad inode number -72057594037927937
dir 128 block 0 extra leaf entry 21aa60c 28
dir ino 128 missing leaf entry for 821aa62d/28
block 9/65529 out of range
block 9/65530 out of range
block 9/65531 out of range
block 9/65532 out of range
block 9/65533 out of range
block 9/65534 out of range
block 9/65535 out of range
block 9/65536 out of range
block 9/65537 out of range
block 9/65538 out of range
block 9/65539 out of range
block 9/65540 out of range
block 9/65541 out of range
block 9/65542 out of range
block 9/65543 out of range
block 9/65544 out of range
block 9/65545 out of range
block 9/65546 out of range
block 9/65547 out of range
block 9/65548 out of range
blocks 9/65529..65548 claimed by block 9/338
block 9/65529 out of range
block 9/65530 out of range
block 9/65531 out of range
block 9/65532 out of range
block 9/65533 out of range
block 9/65534 out of range
block 9/65535 out of range
block 9/65536 out of range
^^^^^
This is the block where gdb tells me that xfs_repair saegfaults
block 9/65537 out of range
block 9/65538 out of range
block 9/65539 out of range
block 9/65540 out of range
block 9/65541 out of range
block 9/65542 out of range
block 9/65543 out of range
block 9/65544 out of range
block 9/65545 out of range
block 9/65546 out of range
block 9/65547 out of range
block 9/65548 out of range
blocks 9/65529..65548 claimed by block 9/902
block 10/4200613472 out of range
blocks 10/4200613472..4200613472 claimed by block 10/0
block 10/2742227945 out of range
blocks 10/2742227945..2742227945 claimed by block 10/0
block 10/1030081898 out of range
blocks 10/1030081898..1030081898 claimed by block 10/0
block 10/1266619198 out of range
blocks 10/1266619198..1266619198 claimed by block 10/0
link count mismatch for inode 3594 (name ?), nlink 1, counted 3
link count mismatch for inode 59683 (name ?), nlink 2, counted 1
block 9/65529 type unknown not expected
block 9/65530 type unknown not expected
block 9/65531 type unknown not expected
block 9/65532 type unknown not expected
block 9/65533 type unknown not expected
block 9/65534 type unknown not expected
link count mismatch for inode 9446615 (name ?), nlink 2, counted 1
block 10/4 type unknown not expected
block 10/5 type unknown not expected
block 10/6 type unknown not expected
block 10/7 type unknown not expected
sb_ifree 57790, counted 57791
Here is the output of xfs_repair:
Phase 1 - find and verify superblock...
Phase 2 - using internal log
- zero log...
- scan filesystem freespace and inode maps...
Segmentation fault
Here is a gdb backtrace on the core:
(gdb) bt
#0 0x0807918f in scanfunc_bno (ablock=0x405bd000, level=0, bno=338, agno=9,
+suspect=0, isroot=1) at scan.c:569
#1 0x0807760a in scan_sbtree (root=338, nlevels=1, agno=9, suspect=0,
+func=0x8078d05 <scanfunc_bno>, isroot=1) at scan.c:84
#2 0x0807b401 in scan_ag (agno=9) at swab.h:125
#3 0x0806570f in phase2 (mp=0xbfffdc70) at phase2.c:149
#4 0x0807c9e9 in main (argc=2, argv=0xbfffdc70) at xfs_repair.c:506
the blocknumber is at 65536 and the ag-number is at 9.
Everything is done with efence.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
|