Dan McDonald wrote: > 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? >
You mean that 4 letter HW provider? Yes it does call kmem_alloc() with KM_SLEEP. > Thanks, > Dan > _______________________________________________ > crypto-discuss mailing list > [EMAIL PROTECTED] > http://mail.opensolaris.org/mailman/listinfo/crypto-discuss > _______________________________________________ networking-discuss mailing list [email protected]
