On Wed, Dec 03, 2008 at 08:03:27AM -0500, James Carlson wrote: > > 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 ...
Adding crypto-discuss to the thread... ... I believe KCF losing a submitted mblk chain IS a possibility, which is why there's an index-and-check scheme. Also, IIRC, at least one well-understood HW provider's timeout can be measured in seconds. That same HW provider is known to call kmem_alloc() with KM_SLEEP set also. :( Crypto-heads --> Can you confirm/deny what I just said about KCF? Or what I said about that well-understood HW provider? Thanks, Dan _______________________________________________ networking-discuss mailing list [email protected]
