On Mon, Jun 30, 2008 at 09:10:09PM +0200, Manuel Bouyer wrote: > 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 :) Heh. I recommend learning mkid tools. eid is basically grep funneled into your favorite editor. > 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); I think that's ok. The only place that this code construct means you need to do something special is when you decriment (assuming we can never overflow v_numoutput). When decirmenting (which wasn't what started this as I recall), you need to also hold the interlock. Or, you need to notice when you decrimented to 0 then lock the interlock then cv_broadcast(). > 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. I haven't looked at it, so I can't say. > 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 ? Off the cuff, probably. Take care, Bill
Attachment:
pgpzFVC5AsORv.pgp
Description: PGP signature