* RFC: No more deadlock detection for POSIX locks
@ 2002-10-10 20:42 Matthew Wilcox
0 siblings, 0 replies; only message in thread
From: Matthew Wilcox @ 2002-10-10 20:42 UTC (permalink / raw)
To: linux-kernel; +Cc: linux-fsdevel
The deadlock detection for posix locks really isn't worth anything
any more. It was always slightly dubious, since a parent/child could
remove each other's locks (thanks, POSIX!). But now it's really dubious
since we store the TID, not the PID of the requesting process, and any
thread can unlock a lock set by another thread.
Here's one situation in which it can falsely return -EDEADLK:
TID 1001, PID 1002 takes lock A
TID 1003, PID 1004 takes lock B
TID 1001, PID 1005 takes lock B, blocks
TID 1003, PID 1004 takes lock A, gets -EDEADLK.
Even though (1001,1002) isn't blocking on any lock and will release lock A
in the future.
So how about we just delete the nasty deadlock detection code? I've never
been fond of the user-triggerable O(N^2) algorithm, and we're permitted
to not implement it (POSIX suggests applications set a timer to detect
deadlock themselves, so anyone writing a portable application is already
doing this).
Objections?
--
Revolutions do not require corporate support.
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2002-10-10 20:42 UTC | newest]
Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-10-10 20:42 RFC: No more deadlock detection for POSIX locks Matthew Wilcox
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).