Matthew Dillon wrote:
> Ah, yes, some of us were just discussing this in a small mailing list.
> Hopefully Kirk will pick up on it soon. Ah well.. someone else gets to b
e
> the brunt of it for a change :-). Kirk doesn't have an SMP box so he
> didn't see the bug.
>
> I have tentitively tracked the problem down to the apparent inability of
> lockmgr() locks to function from interrupts, even when used in a
> non-blocking manner, due to the simplelock's it uses internally. The
> new buffer cache code Kirk committed switched from B_BUSY (manually
> implemented locks) to lockmgr() locks. I think what is going on is
> that mainline code is getting a simplelock and then an interrupt is
> coming along and also trying to get the same lock, but I can't be sure
> because my DDB backtraces are somewhat munged.
In this case, it was just a programming error.. The key to remember is that
the simplelocks are used to protect the state of the complex lock, they are
not the lock themselves. lockmgr() holds the interlock while gaining or
removing references etc and then frees the simplelock so that it can sleep
if required etc. The actual implementation of the simplelock routines
is interrupt safe (and has to be).
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
