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

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:I didn't have time to check the actual limits, but the patch
:ftp://dragonflybsd.dyndns.org/lockf5.diff
:implements the whole kern_lockf stuff, some adjusts to the global
:interface and the resource limits. I'll do the rest later with the
:new world at home.
:
:It passes the sys/kern/lockf regression test from NetBSD and boots fine.
:I'm doing some more checks, moving the debug conditionals out of INVARIANTS
:and add a general print function for struct lockf. But the functionality
:itself should be working.
:
:What do you think? I got some feedback from Hiten and Devon already.
:I suppose ref counting and allocation are as near as possible :)
:
:Joerg

    Well, I guess I can't convince people to change the counting scheme.
    Oh well, I tried :-)  I guess you can go ahead and put it on a commit
    track.  You've certainly done the work!

    I noticed one issue with the code, and that is the fact that since the
    malloc() can block and the locking operations appear to be called
    without a locked vnode (which is how we want to call them), there is
    a race where the lock list can get corrupted if malloc() blocks.

    I think the solution is to pre-allocate two lock structures at the
    beginning and then free whichever ones we wind up not using at 
    the end.  If you are worried about performance, you can implement a
    simple linked list in the per-cpu globaldata to cache free structures.
    For a first implementation, though, I'd simply use malloc().

						-Matt