:
:But that doesn't fix the UP problem where cluster_wbuild() tries to
:recursively re-lock a buf that the current process already owns. I have a
:few ideas about that one though, I just don't understand the clustering
:well enough yet to fix it.
Ok, I just hit this testing the lockmgr changes.
I think the problem is that cluster_wbuild's algorithm was polluted
a little by Kirk's commit.
Previously it tested for B_BUSY to determine if it could then lock it
to include in the cluster.
Kirk changed this to actually attempt a lock, and then include it
if the lock succeeded and not include it if the lock failed.
The problem is that if the buffer was already locked by the same process,
this change results in a panic instead of a simple failure to obtain the
lock.
The solution is to re-tool the code to use the original algorithm ( test
the lock before trying to get it, rather then simply trying to get it ),
but with the new locks. I do not have time today to do this but I believe
I have given sufficient information for Peter, Kirk, or Alan to make the
fix.
I believe there are two or three areas in Kirk's patchset where he
replaced an explicit test with an attempt to actually gain the lock where
this sort of panic can occur. I think Kirk was trying to optimize the
code :-) Heh heh. Just goes to show that combining functional
replacements with optimizations all in one go does not always work.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
:Cheers,
:-Peter
:--
:Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
