flock incorrectly detects deadlock on 7-stable and current
Paul Koch
paul.koch at statseeker.com
Thu May 8 08:26:03 UTC 2008
Hi,
We have been trying to track down a problem with one of our apps which
does a lot of flock(2) calls. flock returns errno 11 (Resource
deadlock avoided) under certain scenarios. Our app works fine on
7-Release, but fails on 7-stable and -current.
The problem appears to be when we have at least three processes doing
flock() on a file, and one is trying to upgrade a shared lock to an
exclusive lock but fails with a deadlock avoided.
Attached is a simple flock() test program.
a. Process 1 requests and gets a shared lock
b. Process 2 requests and blocks for an exclusive lock
c. Process 3 requests and gets a shared lock
d. Process 3 requests an upgrade to an exclusive lock but fails (errno
11)
If we change 'd' to
Process 3 requests unlock, then requests exclusive lock, it works.
The manual page says:
"A shared lock may be upgraded to an exclusive lock, and vice versa,
simply by specifying the appropriate lock type; this results in the
previous lock being released and the new lock applied (possibly after
other processes have gained and released the lock)."
The manual page doesn't mention that flock() can fail with a deadlock.
Our test environment is:
- 8 core Intel machine running i386 stable
- 4 core Intel machine running amd64 current (20080508)
- 4 core Intel machine running amd64 stable (20080508)
- 2 core AMD machine running i386 stable (20080418)
- 2 core AMD machine running i386 stable (20080418)
- single core (no hyperthreading) i386 stable (20080418)
There appears to have been changes to kern_lockf.c and other stuff
around the 10th April to do with deadlock detection. We don't see the
problem on 6.2-stable, 7-Release, or 7-stable pre ~10th April.
Paul.
More information about the freebsd-stable
mailing list