On Fri, Apr 02, 2010 at 02:45:02PM +0000, Andrew Doran wrote: > On Fri, Apr 02, 2010 at 03:45:21PM +0200, Manuel Bouyer wrote: > > On Fri, Apr 02, 2010 at 01:01:12PM +0000, Andrew Doran wrote: > > > > - that buffer queue manipulations are done at splbio() with the > > > > kernel_lock held in dkstart() and dkstrategy(): > > > > KASSERT(curcpu()->ci_biglock_count > 0); > > > > KASSERT(curcpu()->ci_ilevel >= IPL_BIO); > > > > KASSERT(curlwp->l_blcnt > 0); > > > > - that the buffer doesn't change under us in dkstart(): > > > > KASSERT(BUFQ_GET(sc->sc_bufq) == bp); > > > > > > Should this not be bufq_peek()? > > > > No, the bufq_peek() has been done earlier, this is where bp comes from. > > At this point we really want to dequeue the buffer (because we know we can > > handle it); I just changed > > BUFQ_GET(sc->sc_bufq); > > to > > KASSERT(BUFQ_GET(sc->sc_bufq) == bp); > > > > > > > > Hmm, it shouldn't be doing dkiodone -> dkstart -> VOP_STRATEGY. > > > VOP_STRATEGY should be called with process context (kthread, user). > > > Anyhow that's unlikely to fix your problem. > > > > dkiodone() is always called from thread or software interrupt context, isn't > > that enough ? > > Conceptually VOP_STRATEGY is file system code which always runs with > process context.
I'm sure someone will be along shortly to crucify me for saying that, but before they do I'll add a "you know what I mean". :-)
