[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <52CE5F21.1070800@windriver.com>
Date: Thu, 9 Jan 2014 16:34:41 +0800
From: Fan Du <fan.du@...driver.com>
To: David Laight <David.Laight@...lab.com>
CC: Steffen Klassert <steffen.klassert@...unet.com>,
"davem@...emloft.net" <davem@...emloft.net>,
"stephen@...workplumber.org" <stephen@...workplumber.org>,
"dev@...ts.strongswan.org" <dev@...ts.strongswan.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next 0/2] Pack struct xfrm_usersa_info and struct
xfrm_userpolicy_info
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
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists