All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: linux-xfs@vger.kernel.org
Subject: Re: [RFC PATCH] db: Stop core dumping on attr3 if block header is not recognized
Date: Thu, 19 Apr 2018 13:01:26 -0700	[thread overview]
Message-ID: <20180419200126.GB24738@magnolia> (raw)
In-Reply-To: <20180419091302.coz4clrmr5ubdku2@odin.usersys.redhat.com>

On Thu, Apr 19, 2018 at 11:13:02AM +0200, Carlos Maiolino wrote:
> On Wed, Apr 18, 2018 at 08:44:35AM -0700, Darrick J. Wong wrote:
> > On Wed, Apr 18, 2018 at 11:49:35AM +0200, Carlos Maiolino wrote:
> > 
> > There are two possible magics for attr3 blocks -- this one, which is for
> > remote attr value blocks, and the xfs_da3_blkinfo magic for the attr
> > leaf and da node blocks.  Can you please fish out the second magic and
> > print that too?
> > 
> > Looks otherwise reasonable, and certainly better than the ASSERT.
> > 
> > --D
> > 
> 
> What do you think about this output. Using attr3 type trying to print a
> directory's leaf block.
> 
> xfs_db> type attr3
> Unknown attribute buffer type!
> xfs_db> p
> Unrecognized attr3 block, attempting to print magic numbers and/or blkinfo:
> Unrecognized attr3 block, attempting to print magic numbers and/or blkinfo:
> hdr.magic = 0
> hdr.info.hdr.forw = 0
> hdr.info.hdr.back = 0
> hdr.info.hdr.magic = 0x3df1

I like it better, though on further thought I think I like better the
idea of printing the contents of all potential magic numbers:

For a block starting with:

0xDE 0xAD 0xBE 0xEF 0xCA 0xFE 0xF0 0x0D 0xBA 0xAD...

xfs_db> p
Unrecognized attr3 block, attempting to print magic numbers and/or blkinfo:
unknown.blockhdr.magic = 0xDEADBEEF
unknown.da_blkinfo.magic = 0xBAAD
unknown.inode.magic = 0xDEAD

--D

> hdr.info.crc = 0x72e2e910 (correct)
> hdr.info.bno = 64
> hdr.info.lsn = 0x300002833
> hdr.info.uuid = 2b21796f-7f81-4cec-b583-968c55b7f4bb
> hdr.info.owner = 99
> xfs_db> 
> 
> -- 
> Carlos
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2018-04-19 20:01 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-18  9:49 [RFC PATCH] db: Stop core dumping on attr3 if block header is not recognized Carlos Maiolino
2018-04-18 15:44 ` Darrick J. Wong
2018-04-19  8:47   ` Carlos Maiolino
2018-04-19  9:13   ` Carlos Maiolino
2018-04-19 20:01     ` Darrick J. Wong [this message]
2018-04-19 20:18       ` Eric Sandeen
2018-04-19 20:21         ` Eric Sandeen
2018-04-23  9:11         ` Carlos Maiolino
2018-04-19 20:12 ` Eric Sandeen
2018-04-23  8:26   ` Carlos Maiolino
2018-04-23 14:54     ` Eric Sandeen
2018-04-30 10:30       ` Carlos Maiolino

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=20180419200126.GB24738@magnolia \
    --to=darrick.wong@oracle.com \
    --cc=linux-xfs@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.