From: "Timo Teräs" <timo.teras@iki.fi>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: broonie@opensource.wolfsonmicro.com, netdev@vger.kernel.org
Subject: Re: Crashes in xfrm_lookup
Date: Fri, 09 Apr 2010 11:30:49 +0300 [thread overview]
Message-ID: <4BBEE5B9.2060509@iki.fi> (raw)
In-Reply-To: <20100409082239.GA2194@gondor.apana.org.au>
Herbert Xu wrote:
> On Fri, Apr 09, 2010 at 11:11:48AM +0300, Timo Teräs wrote:
>> It's still really misleading to have generic function that does not
>> do the expected thing based on some config. Compiler should know
>> how to optimize the for loop away if it's being called with fixed
>> array size.
>
> But the compiler doesn't know because your patch makes it an
> array unconditionally.
>
> The SUB_POLICY stuff was a hack from the very start, but at least
> you could compile it out previously. Now it'll pollute things
> regardless of the configuration.
It has been array all along. The only difference was that only
the first element was used if SUB_POLICY was not defined.
I still think xfrm_pols_put should do always what the function
name says it's doing.
If we want to further optimize non-SUB_POLICY stuff, we should
probably make XFRM_POLICY_TYPE_MAX = 1 and arrange rest of code
so that the compiler can optimize things properly.
But the fact is, that in the new code we need to do conditional
xfrm_policy_put depending on if we had per-socket or global policy
which we matched. Thus we either end up with "if (x)" or the
inline functions for loop's implicit test. Or do you have better
ideas how to avoid that?
next prev parent reply other threads:[~2010-04-09 8:30 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-08 11:14 Crashes in xfrm_lookup Mark Brown
2010-04-08 11:24 ` Timo Teräs
2010-04-08 11:31 ` Mark Brown
2010-04-08 18:28 ` David Miller
2010-04-09 8:09 ` Herbert Xu
2010-04-09 8:11 ` Timo Teräs
2010-04-09 8:22 ` Herbert Xu
2010-04-09 8:30 ` Timo Teräs [this message]
2010-04-09 8:39 ` Herbert Xu
2010-04-09 8:47 ` Timo Teräs
2010-04-09 9:25 ` Herbert Xu
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=4BBEE5B9.2060509@iki.fi \
--to=timo.teras@iki.fi \
--cc=broonie@opensource.wolfsonmicro.com \
--cc=herbert@gondor.apana.org.au \
--cc=netdev@vger.kernel.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).