Re: [patch] POSIX advisory mode lock panic fix by Dfly
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@backplane.com>
討論串 (同標題文章)
完整討論串 (本文為第 6 之 17 篇)：