Dan McDonald wrote:
> Okay!
>
> I've spun nightlies now and will be running IKE-STC on 'em soon, but here is
> an improved webrev with a new bug:
>
> http://cr.opensolaris.org/~danmcd/6777776/
I'm not very happy about this type of code:
1049 ((ipsec_in_t *)lpkt->b_rptr)->ipsec_in_stackid =
1050 ahstack->ipsecah_netstack->netstack_stackid;
It should be cheap to always set the stackid when the larval pkt is added.
> and the new bug is:
>
> 6779183 AH and ESP taskq handlers have to remember the netstack ID.
>
> For now, I stuck with the existing *_kcf_callback() strategy of tagging the
> packet with the netstack ID, followed by a followup check and refhold. I
> didn't perform a refhold prior to the asynchrony because I figured the
> original IP Instance putback didn't do a refhold across the asynchrony of
> crypto for a reason.
The reason for that is that it is hard to avoid refcnt leaks, and the
question whether the kcf callback can take a long time - so long it
would hold up cleaning up the netstack_t. But perhaps that isn't an
issue. If you know that all kcf calls always results in a callback then
you can hold a ref.
> I know there's serious rewhacking of the IP datapath occurring, so it's
> possible some of these sources of double-locking that 6777776 exposes will
> disappear, but I'd like folks to take a look at the here-and-now fix.
FWIW your inbound_task() changes are not necessary in the new datapaths,
since they need to restore all the ip receive attributes, hence the code
already verifies the netstack/ip_stack_t and the ill_t. Same thing
applies to the sadb_clear_buf_pkt() changes.
Erik
_______________________________________________
networking-discuss mailing list
[email protected]
