xfs-masters
[Top] [All Lists]

[Bug 925] New: xfs_repair crash with SEGV on phase6 mk_orphanage

To: xfs-masters@xxxxxxxxxxx
Subject: [Bug 925] New: xfs_repair crash with SEGV on phase6 mk_orphanage
From: bugzilla-daemon@xxxxxxxxxxx
Date: Sat, 7 Jul 2012 21:13:15 -0500
Auto-submitted: auto-generated
http://oss.sgi.com/bugzilla/show_bug.cgi?id=925

           Summary: xfs_repair crash with SEGV on phase6 mk_orphanage
           Product: XFS
           Version: Current
          Platform: All
        OS/Version: Linux
            Status: NEW
          Severity: major
          Priority: P5
         Component: xfsprogs
        AssignedTo: xfs-masters@xxxxxxxxxxx
        ReportedBy: aqa@xxxxxxxxxxxxx
   Estimated Hours: 0.0
    Classification: Unclassified


xfs_repair receives SEGV on phase6.c:885 (mk_orphanage)

------------------------
        irec = find_inode_rec(mp,
                        XFS_INO_TO_AGNO(mp, ino),
                        XFS_INO_TO_AGINO(mp, ino));
        ino_offset = get_inode_offset(mp, ino, irec);
------------------------
irec was NULL after find_inode_rec call, and it case NULL pointer dereference
in get_inode_offset.
On the crash case, ino=320 which is located at the beginning of the newly
allocated inode block on libxfs_inode_alloc just before the find_inode_rec.
I guess that the internal structure of libxfs and the incore avtree of
xfs_repair become inconsistent when libxfs_inode_alloc allocates new inode
block.

By reverting the change set
http://oss.sgi.com/cgi-bin/gitweb.cgi?p=xfs/cmds/xfsprogs.git;a=commit;h=198b747f255346bca64408875763b6ca0ed3d57d
could avoid the crash and xfs_repair success fully repaired my damaged volume.

-- 
Configure bugmail: http://oss.sgi.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

<Prev in Thread] Current Thread [Next in Thread>
  • [Bug 925] New: xfs_repair crash with SEGV on phase6 mk_orphanage, bugzilla-daemon <=