Re: vwakeup: neg numoutput

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Mon, Jun 30, 2008 at 10:27:07AM -0700, Bill Stouder-Studenmund wrote:
> > > Would this be a good candidate for the atomic update operations? That way 
> > > you don't need a lock.
> > 
> > Could be, but then it needs to be updated atomically everywhere.
> 
> Right.
> 
> But if you can't take a lock, then you need to do something. :-) And 
> either cscope or eid (probably eid) can help you change the whole tree at 
> once.

I don't know either, but I can do it with grep :)

I don't know how to translate this kind of construct then:
                mutex_enter(&vp->v_interlock);
                while (vp->v_numoutput > 0)
                        cv_wait(&vp->v_cv, &vp->v_interlock);
                mutex_exit(&vp->v_interlock);

they're used in several places. There are also places where it seems it's
expected to have vp->v_numoutput stable for several lines of code:
vfs_subr2.c:
        mutex_enter(&vp->v_interlock);
                while (vp->v_numoutput != 0)
                        cv_wait(&vp->v_cv, &vp->v_interlock);
        dirty = !LIST_EMPTY(&vp->v_dirtyblkhd);
        mutex_exit(&vp->v_interlock);

there's also genfs_do_putpages().
I'm not sure it's doable to change this to atomic ops.

Last, I suspect ccd.c also has locking issues with v_numoutput and locking.

Would using a software interrupt to run the xbdback handler work to take
v_interlock mutex ?

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--