[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <526498F5.5000308@windriver.com>
Date: Mon, 21 Oct 2013 11:01:09 +0800
From: Fan Du <fan.du@...driver.com>
To: David Miller <davem@...emloft.net>
CC: <steffen.klassert@...unet.com>, <netdev@...r.kernel.org>,
Paul Moore <paul@...l-moore.com>
Subject: Re: [PATCH net-next] {selinux, af_key} Rework pfkey_sadb2xfrm_user_sec_ctx
On 2013年10月19日 03:58, David Miller wrote:
> From: Fan Du<fan.du@...driver.com>
> Date: Wed, 16 Oct 2013 14:15:14 +0800
>
>> Taking advantages of sadb_x_sec_ctx and xfrm_user_sec_ctx share the same
>> structure arrangement, rework pfkey_sadb2xfrm_user_sec_ctx by casting
>> sadb_x_sec_ctx into xfrm_user_sec_ctx with minor len fix.
>>
>> Then we can:
>> -Avoid kmalloc/free memory for xfrm_user_sec_ctx, sadb_x_sec_ctx would be fine.
>> -Fix missing return value check bug for pfkey_compile_policy when kmalloc fails
>>
>> Signed-off-by: Fan Du<fan.du@...driver.com>
>
> This isn't safe, one structure is packed and the other is not.
Might be. No clue why "one structure is packed and the other is not" happens :(
And why not pack the unpacked structure? or more generally does the packed structure
in this case must be packed in this case?(I doubt this.)
> Furthermore, unless there is some enormous gain (in this case there
> is not) losing the type checking by casting two data structures like
> this is undesirable.
Comparing with the hot path optimization, yes this proposal doesn't bring great
performance boosting. The aim of this patch is not the structure casting indeed
but the avoiding kmalloc/memcpy for a PAGE_SIZE string("context" in SELINUX word)
which maps into a ID for security checking against every AF_KEY operation.
--
浮沉随浪只记今朝笑
--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