Re: [patch] POSIX advisory mode lock panic fix by Dfly

["Devon H. O'Dell" <dodell@xxxxxxxxxxxxxxx>]

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@xxxxxxxxxxxxx>
>
> .

Kind regards,

Devon H. O'Dell