Bug 2829
Summary: | posix_locks_deadlock() loops infinitely | ||
---|---|---|---|
Product: | File System | Reporter: | i-sakamoto |
Component: | VFS | Assignee: | fs_vfs |
Status: | CLOSED CODE_FIX | ||
Severity: | normal | CC: | diegocg, mingo, protasnb |
Priority: | P2 | ||
Hardware: | i386 | ||
OS: | Linux | ||
Kernel Version: | 2.6.6 | Subsystem: | |
Regression: | --- | Bisected commit-id: | |
Attachments: | fix infinite loop in posix_locks_deadlock |
Description
i-sakamoto
2004-06-03 22:45:53 UTC
Can you tell is this problem is still present in recent kernels? Recent kernel works fine. Thank you. Sorry, my previous report was not correct. It seems that this problem is still present in debien's 2.6.8-3-686 kernel. I do not test newer vanilla kernel such as 2.6.17. It'd be interesting to get results from 2.6.17, as 2.6.8 was released on August 2004 I tested 2.6.17 on uni processer PC. This kernel also has this problem. :/ CC'ing Ingo Molnar We simulated the above given situation using lockf and fcntl functions to aquire locks on files by threads on 2.6.17.6 kernel on i386 arch. We found that lockf generates error EDEADLK which tells that : The command was T_LOCK and this lock operation would cause a deadlock. Hence the deadlock situation is already handled in this case. Also while debugging we found that the 'posix_locks_deadlock()' function is not looping infinitely. Regards, Tanmay and Pranav (Calsoftinc, India) i-sakamoto, are you still having locking problem with recent kernels? #7 from Tinmay suggested that the problem was supposedly fixed. Thanks. Created attachment 13337 [details]
fix infinite loop in posix_locks_deadlock
The attached patch should address the infinite loop which can be hit in the case described above; submitted for 2.6.24 and 2.6.23.x. The problem is that (as noted in the comment above posix_locks_deadlock()), the loop there only terminates if the existing lock dependency graph only terminates if the existing lock dependency graph is acyclic. But the posix_locks_deadlock() function is only guaranteed to detect (and prevent) such cycles if each node of that graph has outdegree 1. In the example above, the node corresponding to lock owner A has outdegree 2 (because it's blocking on two locks at once--something not possible in the presence only of traditional posix processes)--so posix_locks_deadlock() misses the cycle that's created at step 6, which allows it to go into an infinite loop when it's called again at step 9.
It looks like the code was commited (and later reworked further). Closing the bug, thanks. |