On Tue, Mar 4, 2014 at 11:10 AM, Jeff Layton <jlayton@xxxxxxxxxx> wrote: > My expectation is that programs shouldn't mix classic and file-private > locks, but Glenn Skinner pointed out to me that that may occur at times > even if the programmer isn't aware. > > Suppose we have a program that uses file-private locks. That program > then links in a library that uses classic POSIX locks. If those locks > end up conflicting and one is using blocking locks, then the program > could end up deadlocked. > > Try to catch this situation in posix_locks_deadlock by looking for the > case where the blocking lock was set by the same process but has a > different type, and have the kernel return EDEADLK if that occurs. > > This check is not perfect. You could (in principle) have a threaded > process that is using classic locks in one thread and file-private locks > in another. That's not necessarily a deadlockable situation but this > check would cause an EDEADLK return in that case. > > By the same token, you could also have a file-private lock that was > inherited across a fork(). If the inheriting process ends up blocking on > that while trying to set a classic POSIX lock then this check would miss > it and the program would deadlock. > This particular case IMO should *not* return -EDEADLK -- there's another process that has that fd open, and that process could release the lock. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
