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

[Joerg Sonnenberger <joerg@xxxxxxxxxxxxxxxxx>]

On Tue, Apr 20, 2004 at 10:21:37AM -0700, Matthew Dillon wrote:
>     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.

That was my initial thought too, but it would be almost the same situation
as Devon's initial patch. The problem is that a lockf is allocated to be
used as parameter, even if it is not meant to be persistent.

> 
>     (and pass the lock flags into lf_alloc() so it can check F_POSIX).

Yeah, I like that one without lf_alloc. E.g. lf_cnt_increment and
lf_cnt_decrement, which get a lockf as argument.

> 
>     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 really prefer checking the resource limit in one place, so what do you
think of moving the resource limit check into lf_cnt_increment? Reminds me
that the change to kern_prot.c is not correct :(

Joerg

> 
> 					-Matt
> 					Matthew Dillon 
> 					<dillon@xxxxxxxxxxxxx>