From: arno@natisbad.org (Arnaud Ebalard)
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: "David S. Miller" <davem@davemloft.net>,
Eric Dumazet <eric.dumazet@gmail.com>,
Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>,
netdev@vger.kernel.org
Subject: Re: [PATCHv4 net-next-2.6 1/5] XFRM,IPv6: Remove xfrm_spi_hash() dependency on destination address
Date: Mon, 04 Oct 2010 22:51:38 +0200 [thread overview]
Message-ID: <8739sl8yw5.fsf@small.ssi.corp> (raw)
In-Reply-To: 20101004083306.GA17939@gondor.apana.org.au
Hi,
Herbert Xu <herbert@gondor.apana.org.au> writes:
> On Mon, Oct 04, 2010 at 08:25:07AM +0200, Arnaud Ebalard wrote:
>>
>> At the moment, Linux XFRM stack includes the address when computing
>> the hash to perform state lookup by SPI. This patch changes XFRM
>> state hash computation to prevent destination address to be
>> used. This will later allow finding states for packets w/ mangled
>> destination addresses.
>
> I'm fine with doing this for inbound SAs. However, I can't see
> how we can do this for outbound SAs where the SPI is chosen by
> the remote end.
The change *does not* make the lookup in the hash table rely only on the
spi, i.e. __xfrm_state_lookup() is still passed the address. It only
removes the destination address from the computation of the hash. This
allows passing NULL to __xfrm_state_lookup() specifically for input path
and make the lookup only based on the SPI. The destination address check
is done later (possibly after IRO remapping).
Except if I really missed something, this has no impact on outbound SA
(other hashtables are used in that case).
> Incidentally, it appears that our hash could do with some
> strengthening.
After the change, xfrm_spi_hash() would contain:
unsigned int h = (__force u32)spi ^ proto;
return ((h ^ (h >> 10) ^ (h >> 20)) & hmask)
which seems to spread the bits h correctly into hmask bits (I mean for
the effort ;-) ). Are you thinking about something like changing the
shifts based on the length of the mask?
Cheers,
a+
next prev parent reply other threads:[~2010-10-04 20:51 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-04 6:24 [PATCHv4 net-next-2.6 0/5] Removal of RH2/HAO from IPsec-protected MIPv6 traffic Arnaud Ebalard
2010-10-04 6:25 ` [PATCHv4 net-next-2.6 1/5] XFRM,IPv6: Remove xfrm_spi_hash() dependency on destination address Arnaud Ebalard
2010-10-04 8:33 ` Herbert Xu
2010-10-04 20:51 ` Arnaud Ebalard [this message]
2010-10-05 2:11 ` Herbert Xu
2010-10-05 4:17 ` Herbert Xu
2010-10-07 20:13 ` Arnaud Ebalard
2010-10-08 0:42 ` Herbert Xu
2010-10-04 6:25 ` [PATCHv4 net-next-2.6 2/5] XFRM,IPv6: Introduce receive sockopts to access IRO remapped src/dst addresses Arnaud Ebalard
2010-10-04 6:25 ` [PATCHv4 net-next-2.6 3/5] XFRM,IPv6: Add IRO src/dst address remapping XFRM types and i/o handlers Arnaud Ebalard
2010-10-04 6:25 ` [PATCHv4 net-next-2.6 4/5] XFRM,IPv6: Add IRO remapping hook in xfrm_input() Arnaud Ebalard
2010-10-04 8:40 ` Herbert Xu
2010-10-04 20:51 ` Arnaud Ebalard
2010-10-05 6:27 ` Herbert Xu
2010-10-05 23:28 ` Arnaud Ebalard
2010-10-06 1:25 ` Herbert Xu
2010-10-06 21:42 ` Arnaud Ebalard
2010-10-04 6:25 ` [PATCHv4 net-next-2.6 5/5] XFRM,IPv6: Add IRO remapping capability via socket ancillary data path Arnaud Ebalard
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=8739sl8yw5.fsf@small.ssi.corp \
--to=arno@natisbad.org \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=herbert@gondor.apana.org.au \
--cc=netdev@vger.kernel.org \
--cc=yoshfuji@linux-ipv6.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.