>From http://sendmail.org/
NOTE: Linux appears to have broken flock() again. Unless
the bug is fixed before sendmail 8.13 is shipped,
8.13 will change the default locking method to
fcntl() for Linux kernel 2.4 and later. You may
want to do this in 8.12 by compiling with
-DHASFLOCK=0. Be sure to update other sendmail
related programs to match locking techniques.
Is it really broken or is sendmail smoking crack like when they said that itimers in Linux didn't work?
David
Hi,
On Fri, Jun 28, 2002 at 01:02:59PM -0400, David Ford wrote:
> NOTE: Linux appears to have broken flock() again. Unless
> the bug is fixed before sendmail 8.13 is shipped,
> 8.13 will change the default locking method to
> fcntl() for Linux kernel 2.4 and later. You may
> want to do this in 8.12 by compiling with
> -DHASFLOCK=0. Be sure to update other sendmail
> related programs to match locking techniques.
> Is it really broken or is sendmail smoking crack like when they said
> that itimers in Linux didn't work?
It really is broken, and sendmail triggers it (at least their
commercial binaries do). I've already been talking to willy about the
problem.
The trouble is the accounting: if one process opens a fd and then
fork()s, it is possible for the lock to be taken in the parent and
released in the child (or vice versa) --- unless there's an explicit
flock(LOCK_UN), then the lock will be released implicitly when the
last reference to the fd is closed.
When this happens, we get the lock count incremented in one task and
decremented in another. That can wrap the lock count backwards to -1
(or rather ~0UL), which causes the locks rlimit check to think we've
exceeded the lock quota and new lock requests will fail. It's easy to
reproduce this: try the attached prog. It produces an erroneous
ENOLCK due to the bug.
Cheers,
Stephen