public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@sandeen.net>
To: Rui Gomes <rgomes@rvx.is>
Cc: omar <omar@rvx.is>, xfs <xfs@oss.sgi.com>
Subject: Re: xfs_repair segfault
Date: Mon, 09 Mar 2015 13:34:13 -0400	[thread overview]
Message-ID: <54FDD995.5080307@sandeen.net> (raw)
In-Reply-To: <572429630.410924.1425918276266.JavaMail.zimbra@rvx.is>

On 3/9/15 12:24 PM, Rui Gomes wrote:
> Hello Eric, 
> 
> I would love to send you the xfs metadump but it segfaults as well.

woohoo!  \o/

> This is the output of xfs_repair truncated:
> 
...

> no . entry for directory 260215042
> no .. entry for directory 260215042
> problem with directory contents in inode 260215042
> would have cleared inode 260215042
> bad nblocks 7 for inode 260256256, would reset to 0
> bad nextents 1 for inode 260256256, would reset to 0
> entry "                 kchnfig" in shortform directory 260256256 references invalid inode 28428972647780227
> entry contains illegal character in shortform dir 260256256
> would have junked entry "kchnfig" in directory inode 260256256
> entry "                                                  " in shortform directory 260256256 references invalid inode 0
> size of last entry overflows space left in in shortform dir 260256256, would reset to -1
> *** buffer overflow detected ***: /usr/sbin/xfs_repair terminated

Ok, looking at the sheer number of errors, I really wonder what happened to the fs.

You''d do well to be 100% sure that storage is OK, and that you're not trying to
repair a filesytem on scrambled disks but in any case, xfs should not segfault.

But anyway, this:

> size of last entry overflows space left in in shortform dir 260256256, would reset to -1

is a good clue; it must be in here:

                        if (i == num_entries - 1)  {
                                namelen = ino_dir_size -
                                        ((__psint_t) &sfep->name[0] -
                                         (__psint_t) sfp);
                                do_warn(
_("size of last entry overflows space left in in shortform dir %" PRIu64 ", "),
                                        ino);
                                if (!no_modify)  {
                                        do_warn(_("resetting to %d\n"),
                                                namelen);
                                        sfep->namelen = namelen;
                                        *dino_dirty = 1;

which means the -1 namelen memmove choked on came from:

ino_dir_size - ((__psint_t) &sfep->name[0] - (__psint_t) sfp);

and those come from:

sfp = (struct xfs_dir2_sf_hdr *)XFS_DFORK_DPTR(dip) = ((char *)dip + xfs_dinode_size(dip->di_version))
ino_dir_size = be64_to_cpu(dip->di_size);
sfep = ... xfs_dir2_sf_firstentry(sfp);

We could just be defensive against a negative namelen, but maybe we should
understand a bit more clearly how we got here.

Might start by trying:

# xfs_db -c "inode 260256256" -c "p" /dev/whatever

and show us what you get.

-Eric

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  reply	other threads:[~2015-03-09 17:34 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-09 15:50 xfs_repair segfault Rui Gomes
2015-03-09 15:55 ` Carsten Aulbert
2015-03-09 16:11   ` Rui Gomes
2015-03-09 16:14 ` Eric Sandeen
2015-03-09 16:24   ` Rui Gomes
2015-03-09 17:34     ` Eric Sandeen [this message]
2015-03-09 17:50       ` Rui Gomes
2015-03-09 18:18         ` Eric Sandeen
2015-03-09 18:24           ` Rui Gomes
2015-03-09 20:13             ` Eric Sandeen
  -- strict thread matches above, loose matches on Subject: below --
2013-10-01 19:57 Viet Nguyen
2013-10-01 20:19 ` Dave Chinner
2013-10-01 21:12   ` Viet Nguyen
2013-10-02 10:42     ` Dave Chinner
2013-10-04 17:51       ` Viet Nguyen
2013-10-04 21:43         ` Dave Chinner
2013-10-07 20:09           ` Viet Nguyen
2013-10-08 20:23             ` Dave Chinner
2013-10-09 18:59               ` Viet Nguyen
2013-10-09 20:15                 ` Dave Chinner
2013-10-10 21:13               ` Viet Nguyen
2007-04-03 19:11 James W. Abendschan
2007-04-04  0:45 ` Barry Naujok

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54FDD995.5080307@sandeen.net \
    --to=sandeen@sandeen.net \
    --cc=omar@rvx.is \
    --cc=rgomes@rvx.is \
    --cc=xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox