Re: [RFC, PATCH] locks: remove posix deadlock detection

On Sun, Oct 28, 2007 at 06:40:52PM +0000, Alan Cox wrote:
NAK. This is an ABI change. It was also comprehensively rejected before
because

- EDEADLK behaviour is ABI

Not in any meaningful way.

- EDEADLK behaviour is required by SuSv3

What SuSv3 actually says is:

If the system detects that sleeping until a locked region is
unlocked would cause a deadlock, fcntl() shall fail with an
[EDEADLK] error.

It doesn't require the system to detect it, only mandate what to return
if it does detect it.

- We have no idea what applications may rely on this behaviour.

I've never heard of one that does.

so we need to fix the bugs - the lock usage and the looping. At that
point it merely becomes a performance concern to those who use it, which
is the proper behaviour. If you want a faster non-checking one use
flock(), or add another flag that is a Linux "don't check for deadlock"

You can't fix the false EDEADLK detection without solving the halting
problem. Best of luck with that.

--
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: Killing POSIX deadlock detection
    ... or allowing the potential deadlock? ... Relying on EDEADLK is broken. ... But unless my memory is shaky detecting deadlocks is a hard problem. ... send the line "unsubscribe linux-kernel" in ...
    (Linux-Kernel)
  • Re: [RFC, PATCH] locks: remove posix deadlock detection
    ... I think the resolution was that the EDEADLK stayed. ... The EDEADLK doesn't account for threads, ... The practical requirement I see here is that our deadlock detection ... And if posix file locks are to be useful to threaded applications, ...
    (Linux-Kernel)
  • Re: [RFC, PATCH] locks: remove posix deadlock detection
    ... I've seen SYS5 software that relies on it so we should be careful. ... see the 2004 discussion where the conclusion was that EDEADLK should stay ... or add another flag that is a Linux "don't check for deadlock" ...
    (Linux-Kernel)