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$(echo .)org \
--cc=davem@davemloft$(echo .)net \
--cc=eric.dumazet@gmail$(echo .)com \
--cc=herbert@gondor$(echo .)apana.org.au \
--cc=netdev@vger$(echo .)kernel.org \
--cc=yoshfuji@linux-ipv6$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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