Erik Nordmark writes: > Dan McDonald wrote: > > 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'd much prefer to see a ref hold here rather than looking up the ID again; there's no question that it'll work right across stack tear-down/restart. If things can "disappear" inside kcf, then that may be a different problem ... -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ networking-discuss mailing list [email protected]
