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~} <[EMAIL PROTECTED]> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
