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