From: Fan Du <fengyuleidian0615@gmail.com>
To: David Laight <David.Laight@ACULAB.COM>
Cc: 'Fan Du' <fan.du@intel.com>,
"steffen.klassert@secunet.com" <steffen.klassert@secunet.com>,
"herbert@gondor.apana.org.au" <herbert@gondor.apana.org.au>,
"davem@davemloft.net" <davem@davemloft.net>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: [PATCHv3 ipsec-next] xfrm: Do not parse 32bits compiled xfrm netlink msg on 64bits host
Date: Wed, 28 Jan 2015 12:34:29 +0800 [thread overview]
Message-ID: <54C866D5.4070708@gmail.com> (raw)
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D1CAD3B2B@AcuExch.aculab.com>
于 2015年01月27日 17:46, David Laight 写道:
> From: Fan Du
>> structure like xfrm_usersa_info or xfrm_userpolicy_info
>> has different sizeof when compiled as 32bits and 64bits
>> due to not appending pack attribute in their definition.
>
> Don't 'pack' the structure, just ensure that all the fields
> are fixed sized and on their natural boundary.
Is that simple??
The layout is exactly the same between 32bits and 64bits, only difference
is the last cache line padding, because even if last cache line is not fully
occupied, but at least use even bytes, not odd bytes. I think this relates
to cache HW behaviour, not how the structure is naturally aligned or not.
Actually, the structure members is aligned indeed.
#### 64bits
struct xfrm_usersa_info {
struct xfrm_selector sel; /* 0 56 */
struct xfrm_id id; /* 56 24 */
/* XXX last struct has 3 bytes of padding */
/* --- cacheline 1 boundary (64 bytes) was 16 bytes ago --- */
xfrm_address_t saddr; /* 80 16 */
struct xfrm_lifetime_cfg lft; /* 96 64 */
/* --- cacheline 2 boundary (128 bytes) was 32 bytes ago --- */
struct xfrm_lifetime_cur curlft; /* 160 32 */
/* --- cacheline 3 boundary (192 bytes) --- */
struct xfrm_stats stats; /* 192 12 */
__u32 seq; /* 204 4 */
__u32 reqid; /* 208 4 */
__u16 family; /* 212 2 */
__u8 mode; /* 214 1 */
__u8 replay_window; /* 215 1 */
__u8 flags; /* 216 1 */
/* size: 224, cachelines: 4, members: 12 */
/* padding: 7 */
/* paddings: 1, sum paddings: 3 */
/* last cacheline: 32 bytes */
};
#### 32bits
struct xfrm_usersa_info {
struct xfrm_selector sel; /* 0 56 */
struct xfrm_id id; /* 56 24 */
/* XXX last struct has 3 bytes of padding */
/* --- cacheline 1 boundary (64 bytes) was 16 bytes ago --- */
xfrm_address_t saddr; /* 80 16 */
struct xfrm_lifetime_cfg lft; /* 96 64 */
/* --- cacheline 2 boundary (128 bytes) was 32 bytes ago --- */
struct xfrm_lifetime_cur curlft; /* 160 32 */
/* --- cacheline 3 boundary (192 bytes) --- */
struct xfrm_stats stats; /* 192 12 */
__u32 seq; /* 204 4 */
__u32 reqid; /* 208 4 */
__u16 family; /* 212 2 */
__u8 mode; /* 214 1 */
__u8 replay_window; /* 215 1 */
__u8 flags; /* 216 1 */
/* size: 220, cachelines: 4, members: 12 */
/* padding: 3 */
/* paddings: 1, sum paddings: 3 */
/* last cacheline: 28 bytes */
};
> Possibly add a compile-time check that the structure is
> of the expected size.
>
> David
>
--
No zuo no die but I have to try.
next prev parent reply other threads:[~2015-01-28 4:38 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20150127.001226.711259930266409202.davem () davemloft ! net>
2015-01-27 9:00 ` [PATCHv3 ipsec-next] xfrm: Do not parse 32bits compiled xfrm netlink msg on 64bits host Fan Du
2015-01-27 9:46 ` David Laight
2015-01-27 11:04 ` Florian Westphal
2015-01-27 11:54 ` David Laight
2015-01-27 19:24 ` David Miller
2015-01-28 9:53 ` David Laight
2015-01-28 4:34 ` Fan Du [this message]
2015-01-29 10:29 ` [PATCHv3, " Nicolas Dichtel
2015-01-29 13:56 ` David Laight
2015-01-29 14:14 ` Nicolas Dichtel
2015-01-30 2:11 ` Fan Du
2015-02-02 8:44 ` Steffen Klassert
2015-02-02 9:02 ` Nicolas Dichtel
2015-02-02 19:45 ` David Miller
2015-02-03 12:24 ` Steffen Klassert
2015-02-03 14:02 ` Nicolas Dichtel
2015-03-06 6:13 ` [PATCHv3 " Steffen Klassert
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=54C866D5.4070708@gmail.com \
--to=fengyuleidian0615@gmail.com \
--cc=David.Laight@ACULAB.COM \
--cc=davem@davemloft.net \
--cc=fan.du@intel.com \
--cc=herbert@gondor.apana.org.au \
--cc=netdev@vger.kernel.org \
--cc=steffen.klassert@secunet.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;
as well as URLs for NNTP newsgroup(s).