From: Dave Chinner <david@fromorbit.com>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH 3/3] xfs: remove __arch_pack
Date: Mon, 18 Jul 2016 15:37:46 +1000 [thread overview]
Message-ID: <20160718053746.GA16044@dastard> (raw)
In-Reply-To: <478743f8-774f-d363-2e3e-40cd0963d8a1@sandeen.net>
On Fri, Jun 24, 2016 at 09:55:37AM -0500, Eric Sandeen wrote:
> On 6/24/16 2:52 AM, Christoph Hellwig wrote:
> > Instead we always declare struct xfs_dir2_sf_hdr as packed. That's
> > the expected layout, and while most major architectures do the packing
> > by default the new structure size and offset checker showed that not
> > only the ARM old ABI got this wrong, but various minor embedded
> > architectures did as well.
> >
> > Signed-off-by: Christoph Hellwig <hch@lst.de>
> > ---
> > fs/xfs/libxfs/xfs_da_format.h | 2 +-
> > fs/xfs/xfs_linux.h | 7 -------
> > 2 files changed, 1 insertion(+), 8 deletions(-)
> >
> > diff --git a/fs/xfs/libxfs/xfs_da_format.h b/fs/xfs/libxfs/xfs_da_format.h
> > index f877bb1..685f23b 100644
> > --- a/fs/xfs/libxfs/xfs_da_format.h
> > +++ b/fs/xfs/libxfs/xfs_da_format.h
> > @@ -229,7 +229,7 @@ typedef struct xfs_dir2_sf_hdr {
> > __uint8_t count; /* count of entries */
> > __uint8_t i8count; /* count of 8-byte inode #s */
> > __uint8_t parent[8]; /* parent dir inode number */
> > -} __arch_pack xfs_dir2_sf_hdr_t;
> > +} __packed xfs_dir2_sf_hdr_t;
>
> The reason I did this in the first place was a vague notion that unconditional
> packing was harmful.
>
> http://digitalvampire.org/blog/index.php/2006/07/31/why-you-shouldnt-use-__attribute__packed/
>
> "However, it's actively harmful to add the attribute to a structure that's
> already going to be laid out with no padding."
> ...
> "gcc gets scared about unaligned accesses and generates six times as much code
> (96 bytes vs. 16 bytes)! sparc64 goes similarly crazy, bloating from 12 bytes
> to 52 bytes"
>
> I don't know if that's (still) correct or not, but that was the reason
> for the selective __pack application way back when. Might be worth
> investigating?
Christoph? The first two ptches are fine, but more info is needed
for this one...
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:[~2016-07-18 5:37 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-24 7:52 get rid of unaligned embedded structs in on-disk structures Christoph Hellwig
2016-06-24 7:52 ` [PATCH 1/3] xfs: kill xfs_dir2_sf_off_t Christoph Hellwig
2016-06-24 7:52 ` [PATCH 2/3] xfs: kill xfs_dir2_inou_t Christoph Hellwig
2016-06-24 7:52 ` [PATCH 3/3] xfs: remove __arch_pack Christoph Hellwig
2016-06-24 14:55 ` Eric Sandeen
2016-07-18 5:37 ` Dave Chinner [this message]
2016-07-19 8:52 ` Christoph Hellwig
2016-07-19 23:46 ` 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=20160718053746.GA16044@dastard \
--to=david@fromorbit.com \
--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 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.