netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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.

  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).