[patch] POSIX advisory mode lock panic fix by Dfly
Devon H. O'Dell
dodell at sitetronics.com
Tue Apr 20 12:20:02 PDT 2004
Matthew Dillon wrote:
:Beside some typos, this fix provides a very persimistic solution and makes
:locking/unlocking impossible in a few cases, were the lock counter doesn't
:have to be increased.
:
:I have an optimistic fix for the same problem at
:ftp://dragonflybsd.dyndns.org/posix-locks.diff
:
:I hope someone else can review it :)
:
:Joerg
Ok, I like this a lot better. But I have the same issue with it as I
had with the Devon's code... the MALLOC() and free() operations are
tightly associated with the lock count operations, so encapsulate
the MALLOC() into its own function, say lf_alloc(), and the free() into
its own function, say, lf_free(), and have *these* functions also deal
with the resource counter.
Understood :)
(and pass the lock flags into lf_alloc() so it can check F_POSIX).
Also, the error checking should not be integrated into chgposixlockcnt().
That is, the resource counter increment/decrement should be unconditional
based on the allocation and freeing of the related structures. The
resource limit should be checked in the main switch, with a special case
in the case of a split.
I'll get a new patch implementing this behavior of an unconditional
up/downgrade of the count in lf_alloc() and lf_free(). By ``main
switch'', are you referring to the F_[SETLK|GETLK|UNLCK] switch, or the
overlap switches found in lf_setlock and lf_clearlock (I'm assuming the
latter). More to come later :)
-Matt
Matthew Dillon
<dillon at xxxxxxxxxxxxx>
.
Kind regards,
Devon H. O'Dell
More information about the Submit
mailing list