From: Rui Gomes <rgomes@rvx.is>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: omar <omar@rvx.is>, xfs <xfs@oss.sgi.com>
Subject: Re: [PATCH] xfs_repair: junk last entry in sf dir if name starts beyond dir size
Date: Thu, 9 Apr 2015 10:42:35 +0000 (GMT) [thread overview]
Message-ID: <1560667825.678874.1428576155401.JavaMail.zimbra@rvx.is> (raw)
In-Reply-To: <1369906732.430278.1426089670705.JavaMail.zimbra@rvx.is>
Hello Eric,
Sorry for the late late reply, I didn't had the time to dig in to this earlier.
Actually gdb was lying us, the segfault doesn't happen at:
for (i = 0; i < be32_to_cpu(btp->count); i++)
but a bit later at:
if (be32_to_cpu(lep[i].address) == addr &&
be32_to_cpu(lep[i].hashval) == hash)
And the cause of the segfault is lep[i]
So I tried:
(gdb) print lep
$1 = (xfs_dir2_leaf_entry_t *) 0xfffffffc9ac12788
p lep[0].address
Cannot access memory at address 0xfffffffc9ac12794
For what I can see the lep[0] struct doesn't exist!
The inode where this happen bellow:
[root@icess8a xfsprogs-dev]# xfs_db -c "inode 620507648" -c "p" /dev/sdb1
Metadata corruption detected at block 0x4ffed6d08/0x1000
xfs_db: cannot init perag data (117). Continuing anyway.
core.magic = 0x494e
core.mode = 040755
core.version = 2
core.format = 2 (extents)
core.nlinkv2 = 3
core.onlink = 0
core.projid_lo = 0
core.projid_hi = 0
core.uid = 0
core.gid = 0
core.flushiter = 2
core.atime.sec = Fri May 16 12:21:52 2014
core.atime.nsec = 779442171
core.mtime.sec = Tue Mar 24 12:03:59 2009
core.mtime.nsec = 000000000
core.ctime.sec = Fri Feb 28 19:54:03 2014
core.ctime.nsec = 736630717
core.size = 4096
core.nblocks = 1
core.extsize = 0
core.nextents = 1
core.naextents = 0
core.forkoff = 0
core.aformat = 2 (extents)
core.dmevmask = 0
core.dmstate = 0
core.newrtbm = 0
core.prealloc = 0
core.realtime = 0
core.immutable = 0
core.append = 0
core.sync = 0
core.noatime = 0
core.nodump = 0
core.rtinherit = 0
core.projinherit = 0
core.nosymlinks = 0
core.extsz = 0
core.extszinherit = 0
core.nodefrag = 0
core.filestream = 0
core.gen = 3064228498
next_unlinked = null
u.bmx[0] = [startoff,startblock,blockcount,extentflag] 0:[0,38781727,1,0]
Regards
-------------------------------
Rui Gomes
CTO
RVX - Reykjavik Visual Effects
Seljavegur 2,
101 Reykjavik
Iceland
Tel: + 354 527 3330
Mob: + 354 663 3360
----- Original Message -----
From: "Rui Gomes" <rgomes@rvx.is>
To: "Eric Sandeen" <sandeen@sandeen.net>
Cc: "omar" <omar@rvx.is>, "xfs" <xfs@oss.sgi.com>
Sent: Wednesday, 11 March, 2015 16:01:10
Subject: Re: [PATCH] xfs_repair: junk last entry in sf dir if name starts beyond dir size
Hi,
Thank you for pointing out where to look, I will try to dissect this a bit further and report back to you.
Regards
-------------------------------
Rui Gomes
CTO
RVX - Reykjavik Visual Effects
Seljavegur 2,
101 Reykjavik
Iceland
Tel: + 354 527 3330
Mob: + 354 663 3360
----- Original Message -----
From: "Eric Sandeen" <sandeen@sandeen.net>
To: "Rui Gomes" <rgomes@rvx.is>
Cc: "omar" <omar@rvx.is>, "xfs" <xfs@oss.sgi.com>
Sent: Wednesday, 11 March, 2015 15:46:50
Subject: Re: [PATCH] xfs_repair: junk last entry in sf dir if name starts beyond dir size
On 3/11/15 11:04 AM, Rui Gomes wrote:
> Program received signal SIGSEGV, Segmentation fault.
> 0x000000000044dbcd in __xfs_dir3_data_check (dp=dp@entry=0x0, bp=bp@entry=0x1538e810) at xfs_dir2_data.c:148
> 148 for (i = 0; i < be32_to_cpu(btp->count); i++) {
> (gdb) bt
> #0 0x000000000044dbcd in __xfs_dir3_data_check (dp=dp@entry=0x0, bp=bp@entry=0x1538e810) at xfs_dir2_data.c:148
> #1 0x000000000044b9ea in xfs_dir3_block_verify (bp=bp@entry=0x1538e810) at xfs_dir2_block.c:62
Can you do a little digging around in gdb to sort out more
about why it segfaulted?
We got a xfs_dir2_data_hdr_t from the passed-in bp w/ valid magic:
hdr = bp->b_addr;
and from that got btp:
switch (hdr->magic) {
case cpu_to_be32(XFS_DIR2_BLOCK_MAGIC):
btp = xfs_dir2_block_tail_p(mp, hdr);
and this just finds an offset from hdr:
((char *)hdr + mp->m_dirblksize)) - 1;
but then apparently blew up when we tried to use btp:
for (i = 0; i < be32_to_cpu(btp->count); i++) {
I don't see offhand how the hdr is ok, with good magic, but an
offset from the hdr (btp) is causing a segfault. Can you dig around
a bit more in gdb?
-Eric
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
prev parent reply other threads:[~2015-04-09 10:42 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-09 20:13 [PATCH] xfs_repair: junk last entry in sf dir if name starts beyond dir size Eric Sandeen
2015-03-10 1:17 ` Brian Foster
2015-03-10 13:27 ` Eric Sandeen
2015-03-10 15:43 ` Eric Sandeen
2015-03-10 17:27 ` Rui Gomes
2015-03-10 17:37 ` Eric Sandeen
2015-03-11 14:26 ` Rui Gomes
2015-03-11 14:44 ` Eric Sandeen
2015-03-11 15:04 ` Rui Gomes
2015-03-11 15:46 ` Eric Sandeen
2015-03-11 16:01 ` Rui Gomes
2015-04-09 10:42 ` Rui Gomes [this message]
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=1560667825.678874.1428576155401.JavaMail.zimbra@rvx.is \
--to=rgomes@rvx.is \
--cc=omar@rvx.is \
--cc=sandeen@sandeen.net \
--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