All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Ben Myers <bpm@sgi.com>
Cc: "Michael L. Semon" <mlsemon35@gmail.com>, xfs@oss.sgi.com
Subject: Re: [PATCH 2/3] xfs: fix implicit padding in directory and attr CRC formats
Date: Thu, 13 Jun 2013 12:27:29 +1000	[thread overview]
Message-ID: <20130613022729.GH29338@dastard> (raw)
In-Reply-To: <20130613005819.GW20932@sgi.com>

On Wed, Jun 12, 2013 at 07:58:19PM -0500, Ben Myers wrote:
> On Wed, Jun 12, 2013 at 12:19:07PM +1000, Dave Chinner wrote:
> > From: Dave Chinner <dchinner@redhat.com>
> > 
> > Michael L. Semon has been testing CRC patches ona 32 bit system and
> 						on a
> 
> > been seeing assert failures in the directory code from xfs/080.
> > Thanks to Michael's heroic efforts with printk debugging, we found
> > that the problem was that the last free space being left in the
> > directory structure was too small to fit a unused tag structure and
> > it was being corrupted and attempting to log a region out of bounds.
> > Hence the assert failure looked something like:
> > 
> > .....
> > #5 calling xfs_dir2_data_log_unused() 36 32
> > #1 4092 4095 4096
> > #2 8182 8183 4096
>      first? 
>           last?
>                bp->b_length?

Yup.

> > 
> > Note that this only affects 32 bit systems with CRCs enabled.
> > Everything else is just fine. Note that filesystems created before
> 					 CRC enabled filesystems
> 
> I suggest this be added to head off any confusion.

Sure.  Do I need to resubmit this, or are you going to just modify
the commit message yourself before applying it?

> > index 995f1f5..7826782 100644
> > --- a/fs/xfs/xfs_dir2_format.h
> > +++ b/fs/xfs/xfs_dir2_format.h
> > @@ -266,6 +266,7 @@ struct xfs_dir3_blk_hdr {
> >  struct xfs_dir3_data_hdr {
> >  	struct xfs_dir3_blk_hdr	hdr;
> >  	xfs_dir2_data_free_t	best_free[XFS_DIR2_DATA_FD_COUNT];
> > +	__be32			pad;	/* 64 bit alignment */
> 
> I counted these up and it looks fine.  Nice work gents.

pahole is a much better way of determining structure size - it tells
you exactly what the compiler did, rather than having to assume what
the compiler is going to do...

$ pahole fs/xfs/xfs_dir2_data.o |less
.....
struct xfs_dir3_blk_hdr {
        __be32                     magic;                /*     0     4 */
        __be32                     crc;                  /*     4     4 */
        __be64                     blkno;                /*     8     8 */
        __be64                     lsn;                  /*    16     8 */
        uuid_t                     uuid;                 /*    24    16 */
        __be64                     owner;                /*    40     8 */

        /* size: 48, cachelines: 1, members: 6 */
        /* last cacheline: 48 bytes */
};
struct xfs_dir3_data_hdr {
        struct xfs_dir3_blk_hdr    hdr;                  /*     0    48 */
        xfs_dir2_data_free_t       best_free[3];         /*    48    12 */
        __be32                     pad;                  /*    60     4 */
        /* --- cacheline 1 boundary (64 bytes) --- */

        /* size: 64, cachelines: 1, members: 3 */
};
....


Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

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

  parent reply	other threads:[~2013-06-13  2:27 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-12  2:19 [PATCH 0/3] xfs: fixes for 3.10-rc6 Dave Chinner
2013-06-12  2:19 ` [PATCH 1/3] xfs: don't shutdown log recovery on validation errors Dave Chinner
2013-06-13  1:04   ` Ben Myers
2013-06-13  2:08     ` Dave Chinner
2013-06-13 22:09       ` Ben Myers
2013-06-14  0:13         ` Dave Chinner
2013-06-14 12:55           ` Mark Tinguely
2013-06-14 16:09           ` Ben Myers
2013-06-14 16:15             ` Eric Sandeen
2013-06-14 19:08               ` Ben Myers
2013-06-14 19:18                 ` Eric Sandeen
2013-06-14 19:44                   ` Ben Myers
2013-06-14 19:54                     ` Eric Sandeen
2013-06-14 20:22                       ` Ben Myers
2013-06-28 18:54                         ` Dave Jones
2013-06-28 19:24                           ` Ben Myers
2013-06-28 19:28                             ` Dave Jones
2013-06-28 19:31                               ` Ben Myers
2013-06-15  0:56                     ` Dave Chinner
2013-06-17 14:53                       ` Ben Myers
2013-06-18  1:22                         ` Dave Chinner
2013-06-14 16:17             ` Dave Jones
2013-06-14 16:31               ` Ben Myers
2013-06-12  2:19 ` [PATCH 2/3] xfs: fix implicit padding in directory and attr CRC formats Dave Chinner
2013-06-13  0:58   ` Ben Myers
2013-06-13  1:40     ` Michael L. Semon
2013-06-13  2:27     ` Dave Chinner [this message]
2013-06-13 21:31       ` Ben Myers
2013-06-12  2:19 ` [PATCH 3/3] xfs: ensure btree root split sets blkno correctly Dave Chinner
2013-06-13 19:16   ` Ben Myers
2013-06-14  0:21     ` Dave Chinner

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=20130613022729.GH29338@dastard \
    --to=david@fromorbit.com \
    --cc=bpm@sgi.com \
    --cc=mlsemon35@gmail.com \
    --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 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.