[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <466EA36E.80206@trash.net>
Date: Tue, 12 Jun 2007 15:45:18 +0200
From: Patrick McHardy <kaber@...sh.net>
To: hadi@...erus.ca
CC: Robert Olsson <Robert.Olsson@...a.slu.se>,
David Miller <davem@...emloft.net>,
Herbert Xu <herbert@...dor.apana.org.au>,
netdev@...r.kernel.org, James Morris <jmorris@...ei.org>
Subject: Re: [PATCH] pktgen IPSEC 3/4: Introduce xfrm SAD only lookup
Looks good too me, just a few minor nitpicks as usual :)
jamal wrote:
> [XFRM] Introduce standalone SAD lookup
>
> +struct xfrm_state *
> +xfrm_stateonly_find(xfrm_address_t *daddr, xfrm_address_t *saddr,
> + unsigned short family, u8 mode, u8 proto, u32 reqid)
> +{
> + unsigned int h = xfrm_dst_hash(daddr, saddr, reqid, family);
> + struct xfrm_state *rx = NULL, *x = NULL;
> + struct hlist_node *entry;
> +
> + spin_lock(&xfrm_state_lock);
> + hlist_for_each_entry(x, entry, xfrm_state_bydst+h, bydst) {
> + if (x->props.family == family &&
> + x->props.reqid == reqid &&
> + !(x->props.flags & XFRM_STATE_WILDRECV) &&
> + xfrm_state_addr_check(x, daddr, saddr, family) &&
> + mode == x->props.mode &&
> + proto == x->id.proto) {
> +
^^ please delete empty line
> + if (x->km.state != XFRM_STATE_VALID)
> + continue;
^ one indentation level too much
> + else {
> + rx = x;
> + break;
> + }
The whole thing could be compacted by moving the XFRM_STATE_VALID
check to the first condition:
if (x->props.family == family &&
x->props.reqid == reqid &&
!(x->props.flags & XFRM_STATE_WILDRECV) &&
xfrm_state_addr_check(x, daddr, saddr, family) &&
mode == x->props.mode &&
proto == x->id.proto &&
x->km.state == XFRM_STATE_VALID) {
rx = x;
break;
}
or alternatively turn the != XFRM_STATE_VALID into == if you
want to keep the first condition similar to xfrm_state_find
(but the mode and proto conditions are reversed anyways).
BTW, wouldn't it make sense to allow use of the SPI as well?
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists