> > Can anyone tell me what this is all about -- is there any basis in
> > reality for what they are saying?
> First I've heard of it, so it would be useful if someone has access to
> the sendmail problem report/test in question that shows it and I'll go
> find out.
Quoting Stephen Tweedie's earlier post to the list:
==
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.
==
-- JiKos.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/