On Fri, Jun 08, 2007 at 12:18:13PM -0700, Krishna Yenduri wrote: > James Carlson wrote: > >Dan McDonald writes: > > > >>On Fri, Jun 08, 2007 at 02:20:01PM -0400, James Carlson wrote: > >> > >>>Holding a lock across putnext is just a programming error. How far do > >>>we have to go to protect against programming errors? (Should the > >>>stack check for freed mblks?) > >>> > >>So Jim, are you saying that I *could* call crypto synchronously because the > >>correct behavior is not to hold locks? If so, that's encouraging for the HW > >>crypto folks in the audience. > >> > > > >I think Garrett's right that you may well get punished by bad drivers, > >so that's potentially a risk. > > > >Getting back to the original question, exactly how long are you > >blocking and why would you block? > > One of the reasons would be from > kmem_alloc(.., KM_SLEEP); > > I assume we are in interrupt context when in ip_input()? If so, all the > allocations have to be with KM_NOSLEEP.
You assume correctly AND you must not use KM_SLEEP for that reason! Also, a cv_wait() is unbounded (per meem's earlier mail), and is something we have to be weary of (even if, say, the HW crypto implementation does an excellent job of not cv_wait()-ing all that long). Dan _______________________________________________ networking-discuss mailing list [email protected]
