Re: xfrm_input() and ->seq oddities

[Herbert Xu <herbert@gondor.apana.org.au>]

On Sun, Feb 03, 2008 at 11:04:44AM +0000, Al Viro wrote:
>
> So what you are saying is
> 	* callers of xfrm_input_resume() are in callbacks that couldn't
> have been set other than from esp_input()/esp6_input()
> 	* these two could have only been called via ->type->input()
> 	* ->type->input() is called from xfrm_input(), immediately after
> having set ->seq.input, *or* from xfrm6_input_addr().  The former is safe.
> 	* xfrm6_input_addr() calls ->type->input() of object it gets from
> xfrm_state_lookup_byaddr().  The protocol number passed to the latter comes
> from xfrm6_input_addr() argument.
> 	* the protocol numbers given to xfrm6_input_addr() by its callers
> are IPPROTO_DSTOPTS and IPPROTO_ROUTING resp; ->input() instances in their
> xfrm_type do *not* set callbacks that could lead to xfrm_input_resume(),
> so we are safe.

This doesn't look so bad if you take out the xfrm6_input_addr call.
And you can't blame that one on me :)

The xfrm6_input_addr function is really a parallel universe which has
nothing to do with IPsec.  It's used by Mobile IPv6 just because it
happened to fit in the same schema.

In other words, IPsec transforms such as ESP cannot be called from
xfrm6_input_addr and as such async resumption never occurs with
xfrm6_input_addr.

> IMO that at least deserves a comment near xfrm_input()...

Sure.  There is already a comment about encap_type < 0 in there, but
I think you'll probably be able to explain it much better than I can
looking in from the outside so if you have a patch... :)

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt