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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox