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
next prev 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.