From: Fan Du <fan.du@windriver.com>
To: David Miller <davem@davemloft.net>
Cc: <steffen.klassert@secunet.com>, <netdev@vger.kernel.org>,
Paul Moore <paul@paul-moore.com>
Subject: Re: [PATCH net-next] {selinux, af_key} Rework pfkey_sadb2xfrm_user_sec_ctx
Date: Mon, 21 Oct 2013 11:01:09 +0800 [thread overview]
Message-ID: <526498F5.5000308@windriver.com> (raw)
In-Reply-To: <20131018.155833.1412406960170647411.davem@davemloft.net>
On 2013年10月19日 03:58, David Miller wrote:
> From: Fan Du<fan.du@windriver.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@windriver.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
prev parent reply other threads:[~2013-10-21 3:02 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-16 6:15 [PATCH net-next] {selinux, af_key} Rework pfkey_sadb2xfrm_user_sec_ctx Fan Du
2013-10-16 15:15 ` Paul Moore
2013-10-17 1:34 ` Fan Du
2013-10-17 9:51 ` Steffen Klassert
2013-10-18 1:18 ` Paul Moore
2013-10-18 19:58 ` David Miller
2013-10-21 3:01 ` Fan Du [this message]
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=526498F5.5000308@windriver.com \
--to=fan.du@windriver.com \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
--cc=paul@paul-moore.com \
--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).