From: Fan Du <fan.du@windriver.com>
To: David Laight <David.Laight@aculab.com>
Cc: Steffen Klassert <steffen.klassert@secunet.com>,
"stephen@networkplumber.org" <stephen@networkplumber.org>,
"davem@davemloft.net" <davem@davemloft.net>,
"dev@lists.strongswan.org" <dev@lists.strongswan.org>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: [PATCH net-next 0/2] Pack struct xfrm_usersa_info and struct xfrm_userpolicy_info
Date: Thu, 9 Jan 2014 16:34:41 +0800 [thread overview]
Message-ID: <52CE5F21.1070800@windriver.com> (raw)
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D453AEE@AcuExch.aculab.com>
On 2014年01月07日 18:00, David Laight wrote:
>> From: Fan Du
>> > Sent: 07 January 2014 08:00
>> > On 2014?01?07? 15:47, Steffen Klassert wrote:
>>> > > On Tue, Jan 07, 2014 at 02:48:57PM +0800, Fan Du wrote:
>>>> > >> When trying to setup IPsec configuration on a 64bits host with
>>>> > >> iproute2(32bits compiled), the intened xfrm policy and sa is
>>>> > >> either deficit or wrong when kernel trying to parse user land
>>>> > >> information.
>>>> > >>
>>>> > >> Further investigatino shows that:
>>>> > >> L: kernel
>>>> > >> R: iproute2
>>>> > >>
>>>> > >> sizeof userpolicy usersa
>>>> > >> 64bits(unpacked) 168/168 224/224
>>>> > >> 32bits(unpacked) 164/164 220/220
>>>> > >> ^ ^
>>>> > >> L R
>>>> > >>
>>>> > >> To keep kernel and user land see a consistent structure, after
>>>> > >> add packing attribute, now it looks like this:
>>>> > >>
>>>> > >> 64bits( packed) 164/164 217/217
>>>> > >> 32bits( packed) 164/164 217/217
>>>> > >> ^ ^
>>>> > >> L R
>>>> > >>
>>> > >
>>> > > We don't change userspace exported structures. This breaks
>>> > > existing userspace tools.
>>> > >
>> >
>> > Then user with 32bits iproute2 or StrongSwan has to rebuild as 64bits?
> The kernel has support (in various places) for different structure
> layouts for 32bit and 64bit processes.
> Looks like it needs one here as well (I'm not volunteering though).
>
> At a guess the structures contain a 64bit field that is on an 8n+4
> byte boundary. On i386 64bit fields are only 4 byte aligned, on
> amd64 they are 8 byte aligned.
>
> Packing the structures is definitely wrong. Some 32bit systems (IIRC sparc)
> align 64bit items on 8 byte boundaries. Not to mention the expensive byte
> by byte accesses this forces on some systems.
I don't know much about sparc, if I read your message right, you mean 32bit sparc
system also has padding even if pack attribute is supplied.
And in this scenario, the code path here is only for configuration, i.e., not hot
path, so performance issue is not so crucial here.
>
> The structure could have been defined with the 64bit field marked
> __attribute__((aligned(4))) - so using the same layout on 32bit
> and 64 bit systems , but it is too late to do that now.
Thanks for this useful information.
--
浮沉随浪只记今朝笑
--fan
_______________________________________________
Dev mailing list
Dev@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/dev
next prev parent reply other threads:[~2014-01-09 8:34 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-07 6:48 [PATCH net-next 0/2] Pack struct xfrm_usersa_info and struct xfrm_userpolicy_info Fan Du
2014-01-07 6:48 ` [PATCH net-next 1/2] include/uapi/linux/xfrm.h: Pack " Fan Du
2014-01-07 22:52 ` Sergei Shtylyov
2014-01-09 8:39 ` Fan Du
2014-01-09 22:58 ` Sergei Shtylyov
2014-01-09 23:07 ` Sergei Shtylyov
2014-01-07 6:48 ` [PATCH net-next 2/2] include/uapi/linux/xfrm.h: Pack struct xfrm_usersa_info Fan Du
2014-01-08 20:33 ` Ben Hutchings
2014-01-09 8:24 ` Fan Du
2014-01-09 18:58 ` Ben Hutchings
2014-01-07 6:55 ` [PATCH net-next 0/2] Pack struct xfrm_usersa_info and struct xfrm_userpolicy_info Fan Du
2014-01-07 7:47 ` Steffen Klassert
2014-01-07 7:59 ` Fan Du
2014-01-07 10:00 ` David Laight
2014-01-09 8:34 ` Fan Du [this message]
2014-01-09 9:07 ` David Laight
2014-01-07 18:07 ` David Miller
2014-01-09 8:24 ` Fan Du
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=52CE5F21.1070800@windriver.com \
--to=fan.du@windriver.com \
--cc=David.Laight@aculab.com \
--cc=davem@davemloft.net \
--cc=dev@lists.strongswan.org \
--cc=netdev@vger.kernel.org \
--cc=steffen.klassert@secunet.com \
--cc=stephen@networkplumber.org \
/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).