On Tue, 25 Jul 2000, Ollivier Robert wrote:
> According to Brian Fundakowski Feldman:
> > Actually, I'm pretty certain this is the fix:
>
> Well it won't panic but isn't it putting the problem under the carpet? I
> agree the panic seems to be here temporarely but...
No, I'm really certain this isn't the case. You see, struct buf has
a b_lock that until recently was a plain, exclusive lockmgr lock. In
Kirk's last round of changes, he converted b_lock to be LK_CANRECURSE,
which means that the lock, while still an exclusive lock, may be
relocked multiple times by the same caller.
The panics are plain wrong. What's left is to determine what is the
proper thing to do in each of these cases, which I'm certain that many
people already know already (you see, I'm still a bit green ;). What I
am _almost_ sure about is that the right thing is just to remove one
of the locks and let it get freed back up the call chain. I'm almost
certain this is the case because if you are grabbing exclusive locks
and recursing upon them, your call chain is the only consumer and in
a recursive-locking-callchain, you will have multiple symmetric lock
and unlock pairs. Anything else horribly complicates things, and this
makes me a good 95% certain that this is exactly the right fix, not
that it's sweeping any true bugs under the carpet.
Allowing recursive locks is pretty much the only way to solve many of
the problems here because it's simply not possible to support all code
paths without allowing for this recursion. The code would either be
horribly complicated or non-functional. I'm certain Kirk may be able
to back me up here. It seems that the cleanup is meant to make the
locks recursive mostly to facilitate correct/proper call chains, and
that's consistent with my understand at least :)
Indeed, if you look at the comment in brelse() from the delta, you
will see that the intention of allowing this very situation to occur
and simply BUF_UNLOCK() was planned for and the panic()s were for
debugging during the previous time that b_locks weren't LK_CANRECURSE.
As always, take what I say with a grain of salt since I'm definitely
not a VFS guru in any manner; I just happen to think I understand this
one :)
> --
> Ollivier ROBERT -=- Eurocontrol EEC/ITM -=- [EMAIL PROTECTED]
> The Postman hits! The Postman hits! You have new mail.
--
Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! /
[EMAIL PROTECTED] `------------------------------'
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
