[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
:I hope someone else can review it :)
    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 :)

					Matthew Dillon 
					<dillon at xxxxxxxxxxxxx>


Kind regards,

Devon H. O'Dell

More information about the Submit mailing list