All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bill O'Donnell <billodo@redhat.com>
To: Eric Sandeen <sandeen@sandeen.net>,
	"Darrick J. Wong" <darrick.wong@oracle.com>,
	linux-xfs@vger.kernel.org
Subject: Re: [PATCH] xfs_db: update sector size when type is set
Date: Thu, 22 Jun 2017 15:34:34 -0500	[thread overview]
Message-ID: <20170622203434.GC22273@redhat.com> (raw)
In-Reply-To: <20170622203108.GB22273@redhat.com>

On Thu, Jun 22, 2017 at 03:31:08PM -0500, Bill O'Donnell wrote:
> On Thu, Jun 22, 2017 at 03:16:27PM -0500, Eric Sandeen wrote:
> > 
> > 
> > On 6/22/17 2:47 PM, Darrick J. Wong wrote:
> > > On Thu, Jun 22, 2017 at 02:33:52PM -0500, Bill O'Donnell wrote:
> > >> xfs_db doesn't take sector size into account when setting type.
> > >> This can result in an errant crc. For example, with a sector size
> > >> of 4096:
> > >>
> > >> xfs_db> agi 0
> > >> xfs_db> p crc
> > >> crc = 0xab85043e (correct)
> > >> xfs_db> daddr
> > >> current daddr is 16
> > >> xfs_db> daddr 42
> > >> xfs_db> daddr 16
> > >> xfs_db> type agi
> > >> Metadata CRC error detected at xfs_agi block 0x10/0x200
> > >> xfs_db> p crc
> > >> crc = 0xab85043e (bad)
> > >>
> > >> When xfs_db sets the new daddr in daddr_f, it does so with one
> > >> BBSIZE sector (512). Changing the type doesn't change the size
> > >> of the current buffer in iocur_top, so the checksum is calculated
> > >> on the wrong length for the type (when the actual sector size > BBSIZE (512).
> > >>
> > >> For types with fields, reread the buffer to pick up the correct size for
> > >> the new type when it gets set. Facilitate the reread by setting the cursor
> > >> with set_cur().
> > >>
> > >> Signed-off-by: Bill O'Donnell <billodo@redhat.com>
> > >> ---
> > >>  db/io.c | 6 ++++++
> > >>  1 file changed, 6 insertions(+)
> > >>
> > >> diff --git a/db/io.c b/db/io.c
> > >> index 9918a51..7e6d330 100644
> > >> --- a/db/io.c
> > >> +++ b/db/io.c
> > >> @@ -616,6 +616,12 @@ set_iocur_type(
> > >>  {
> > >>  	struct xfs_buf	*bp = iocur_top->bp;
> > >>  
> > 
> > a comment about why only this "if" case is there would be good.
> 
> agreed.
> 
> > 
> > >> +	if (t->fields)
> > >> +		set_cur(t,
> > >> +			iocur_top->bb,
> > >> +			fsize(t->fields, iocur_top->data,
> > >> +			      0, 0) / mp->m_sb.sb_blocksize,
> > > 
> > > I thought the third parameter to set_cur (which is fed as the third
> > > parameter to libxfs_readbuf) was expressed in units of basic blocks
> > > (i.e. 512 bytes)?  fsize returns the size of the field in bytes (I
> > > think?), 
> > 
> > nope, bits :)
> > 
> > > so dividing by sb_blocksize renders units of fs blocks, not
> > > basic blocks.
> > 
> > As Darrick just pointed out to me, you treated bits as bytes and
> > daddr as fsblock so for 4k blocks, 8/8 came out right ;)
> 
> Yeah. Doh! I tested with sector sizes 512 and 4096 and it all just worked,
> since mp->m_sb.sb_blocksize returned 1 and 8, respectively.
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Correction: _dividing by mp->m_sb.sb_blocksize_ gave 1 and 8, respectively.                         


> 
> > 
> > I think what you want for the size is something like:
> > 
> > BTOBB(byteize(fsize(t->fields, iocur_top->data, 0, 0)));
> > 
> > It might be a little nicer to stash that in a temp var so you
> > don't have all that gunk in the call to set_cur.
> 
> Yep.
> 
> 
> > > <shrug> the naming isn't helpful at all:
> > > 
> > > void
> > > set_cur(
> > > 	const typ_t	*t,
> > > 	int64_t		d,
> > > 	int		c,
> > > ...
> > > 	iocur_top->len = BBTOB(c);
> > > 
> > > <codeconfused>
> > 
> > yup isn't xfs_db fun?
> > 
> > > 
> > > --D
> > > 
> > >> +			DB_RING_IGN, NULL);
> > >>  	iocur_top->typ = t;
> > >>  
> > >>  	/* verify the buffer if the type has one. */
> > >> -- 
> > >> 2.9.4
> > >>
> > >> --
> > >> 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
> > > --
> > > 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
> > > 
> > --
> > 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
> --
> 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:[~2017-06-22 20:34 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-22 19:33 [PATCH] xfs_db: update sector size when type is set Bill O'Donnell
2017-06-22 19:47 ` Darrick J. Wong
2017-06-22 20:16   ` Eric Sandeen
2017-06-22 20:31     ` Bill O'Donnell
2017-06-22 20:34       ` Bill O'Donnell [this message]
2017-06-22 20:23   ` Bill O'Donnell
2017-06-22 20:39     ` Darrick J. Wong
2017-06-22 20:46       ` Bill O'Donnell
2017-06-22 23:45 ` [PATCH v2] " Bill O'Donnell
2017-06-23 10:16   ` Carlos Maiolino
2017-06-23 10:26     ` Bill O'Donnell
2017-06-23 10:34 ` [PATCH v3] " Bill O'Donnell
2017-06-23 11:03   ` Carlos Maiolino
2017-06-26 15:25   ` Darrick J. Wong

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=20170622203434.GC22273@redhat.com \
    --to=billodo@redhat.com \
    --cc=darrick.wong@oracle.com \
    --cc=linux-xfs@vger.kernel.org \
    --cc=sandeen@sandeen.net \
    /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.