Alfred Perlstein wrote:
> * Dima Dorfman <[EMAIL PROTECTED]> [010525 22:22] wrote:
> > Is there a reason vm_pager_allocate acquires vm_mtx itself if
> > necessary but vm_pager_deallocate does not?  At the moment, detaching
> > an md(4) disk will panic the system with a failed mtx_assert in
> > vm_pager_deallocate.  This can be fixed one of two ways:
> > vm_pager_deallocate could be made to deal with vm_mtx itself like
> > vm_pager_allocate does, or md(4) and any other drivers which call
> > vm_pager_deallocate can be fixed to acquire vm_mtx.  So which will it
> > be?  I'll supply patches for either case.
> Usually fixing the caller is better as it will catch people that
> expect vm state to remain unchanged across several calls.

It is a bit late now, but if we're going to push this to callers, I wish we
had set up VM_LOCK() and VM_UNLOCK() macros or something so that we dont
have to deal with fallout if something there changes (or gets
conditionalized).  At least use the macros outside of the vm/* and pmap.c

On the same train of thought, perhaps GIANT_LOCK() and GIANT_UNLOCK() might
have been an idea too.  It would certainly have changed the code impact
when the mutex api changed last time.

It also gives us better 4.x porting targets because we can provide stub (do
nothing) GIANT_LOCK()/UNLOCK() macros on 4.x.   OK, we could do the same
for mtx_lock()/unlock() too but I think the macros give us more flexability
should we want to globally change the giant lock implementation at some
point (or even locally add instrumentation for testing or whatever).

"All of this is for nothing if we don't go to the stars" - JMS/B5

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to