All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Graf <tgraf@suug.ch>
To: David Laight <David.Laight@ACULAB.COM>
Cc: nicolas.dichtel@6wind.com, bhutchings@solarflare.com,
	netdev@vger.kernel.org, davem@davemloft.net
Subject: Re: [PATCH v2] netlink: align attributes on 64-bits
Date: Tue, 18 Dec 2012 17:11:03 +0000	[thread overview]
Message-ID: <20121218171103.GI27746@casper.infradead.org> (raw)
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6026B70F5@saturn3.aculab.com>

On 12/18/12 at 04:50pm, David Laight wrote:
> > 2/ Suppose that the attribute is:
> > 
> >    struct foo {
> >    	__u64 bar1;
> >    	__u32 bar2;
> >    }
> >    => sizeof(struct foo) = 12 (= payload)
> 
> That is only true if the host architecture aligns 64bit items
> on 32 it boundaries (as i386 does).
> Otherwise there are 4 bytes of padding at the end and the
> size is 16.
> 
> Actually it is worse than that.
> Consider the structure:
> 	struct bar {
> 		__u32 foo1;
> 		__u64 foo2;
> 	}
> On i386 it will have size 12 and foo2 will be at offset 4.
> On sparc32 (and most 64bit) it will have size 16 with foo2
> at offset 8 (and 4 bytes of pad after foo1).

This is a known problem and I can't think of anything
that can be done about it except for memcpy()ing the
data before accessing it.

If you have ideas, I'm more that willing to listen :)

> Do these messages move between systems?
> If they do then any 64bit items need an explicit alignment
> eg tag with __attribute__((aligned(8))) (or aligned(4)).

They don't. Netlink has and will be host bound. It also
uses host byte order for that reason.

  reply	other threads:[~2012-12-18 17:11 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-04 11:13 [PATCH net-next 0/7] Allow to monitor multicast cache event via rtnetlink Nicolas Dichtel
2012-12-04 11:13 ` [PATCH net-next 1/7] netconf: advertise mc_forwarding status Nicolas Dichtel
2012-12-04 11:13 ` [PATCH net-next 2/7] ip6mr: use nla_nest_* helpers Nicolas Dichtel
2012-12-04 11:13 ` [PATCH net-next 3/7] ipmr/ip6mr: advertise mfc stats via rtnetlink Nicolas Dichtel
2012-12-04 11:13 ` [PATCH net-next 4/7] ipmr/ip6mr: report origin of mfc entry into rtnl msg Nicolas Dichtel
2012-12-04 11:13 ` [PATCH net-next 5/7] ipmr/ip6mr: allow to get unresolved cache via netlink Nicolas Dichtel
2012-12-04 11:13 ` [PATCH net-next 6/7] ipmr: advertise new mfc entries via rtnl Nicolas Dichtel
2012-12-04 11:13 ` [PATCH net-next 7/7] ip6mr: " Nicolas Dichtel
2012-12-04 18:09 ` [PATCH net-next 0/7] Allow to monitor multicast cache event via rtnetlink David Miller
2012-12-04 20:02   ` Nicolas Dichtel
2012-12-05 11:02     ` Nicolas Dichtel
2012-12-05 11:41       ` David Laight
2012-12-05 17:54         ` David Miller
2012-12-06  8:43           ` Nicolas Dichtel
2012-12-06 17:49             ` Thomas Graf
2012-12-06 21:49               ` Nicolas Dichtel
2012-12-07 10:38               ` David Laight
2012-12-07 10:58                 ` Thomas Graf
2012-12-11 15:03               ` Nicolas Dichtel
2012-12-11 18:40                 ` Thomas Graf
2012-12-12 17:30                   ` Nicolas Dichtel
2012-12-14 13:16                   ` [PATCH] netlink: align attributes on 64-bits Nicolas Dichtel
2012-12-14 15:49                     ` Ben Hutchings
2012-12-14 16:04                       ` Nicolas Dichtel
2012-12-17 16:49                       ` [PATCH v2] " Nicolas Dichtel
2012-12-17 17:06                         ` David Laight
2012-12-17 17:35                           ` Nicolas Dichtel
2012-12-18  9:19                             ` David Laight
2012-12-18 10:18                               ` Nicolas Dichtel
2012-12-18 12:57                         ` Thomas Graf
2012-12-18 16:23                           ` Nicolas Dichtel
2012-12-18 16:50                             ` David Laight
2012-12-18 17:11                               ` Thomas Graf [this message]
2012-12-19  9:17                                 ` David Laight
2012-12-19 17:20                                   ` Thomas Graf
2012-12-20  9:37                                     ` David Laight
2012-12-20  9:40                                     ` David Laight
2012-12-18 17:08                             ` Thomas Graf
2012-12-18 22:07                               ` Nicolas Dichtel
2012-12-19 11:22                           ` Nicolas Dichtel
2012-12-19 17:09                             ` Thomas Graf
2012-12-19 18:07                               ` Nicolas Dichtel
2012-12-17  9:59                     ` [PATCH] " David Laight
2012-12-17 16:53                       ` Nicolas Dichtel
2012-12-05 17:53       ` [PATCH net-next 0/7] Allow to monitor multicast cache event via rtnetlink David Miller

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=20121218171103.GI27746@casper.infradead.org \
    --to=tgraf@suug.ch \
    --cc=David.Laight@ACULAB.COM \
    --cc=bhutchings@solarflare.com \
    --cc=davem@davemloft.net \
    --cc=netdev@vger.kernel.org \
    --cc=nicolas.dichtel@6wind.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.