Re: getiobuf(x, false) can sleep ?

[Andrew Doran <ad%NetBSD.org@localhost>]

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". :-)